I just noticed a new PDA with a built in keyboard and might make an interesting Squeak platform.
Sharp Zaurus SL-5000D is a handheld PDA that runs Linux on a 200 MHz StrongARM, and has a tiny built in QWERTY keyboard, as well as a touch screen and stylus. The keyboard looks a bit like the curved Blackberry keyboard.
The screen is 1/4 VGA in size, 65,536 Color Reflective TFT touch panel, 3.5" with front lighting. (I assume front lighting because it is reflective?).
It costs USD 500 for the prerelease developer version.
Mike
Mike Rutenberg mdrs@akasta.com is widely believed to have written:
I just noticed a new PDA with a built in keyboard and might make an interesting Squeak platform.
Yup, should be quite nice just as soon as somebody fixes the bumb floating point bug in gcc. Which is a year plus old and still appears to have no solution. In the meantime, you cannot use optimisation, so performance is about half of what it should be.
tim
Tim,
Isn't there an alternative to gcc for StrongARM? For example, does CodeWarrior support StrongARM? I suppose there could be linking issue...
-- John
At 8:36 AM -0800 11/30/01, Tim Rowledge wrote:
Mike Rutenberg mdrs@akasta.com is widely believed to have written:
I just noticed a new PDA with a built in keyboard and might make an interesting Squeak platform.
Yup, should be quite nice just as soon as somebody fixes the bumb floating point bug in gcc. Which is a year plus old and still appears to have no solution. In the meantime, you cannot use optimisation, so performance is about half of what it should be.
tim
John.Maloney@disney.com wrote:
Tim,
Isn't there an alternative to gcc for StrongARM? For example, does CodeWarrior support StrongARM? I suppose there could be linking issue...
It might well, but I have no idea if it is freely available for *nix. Acorn of course have/had the Norcroft/CodeMist compiler which is pretty good but probably not available. M$ support ARM under VC++ of course but I _really_ doubt that will run under *nix!
Of course there is the ol'Interval translator.....
tim
On Saturday 01 December 2001 03:51, you wrote:
John.Maloney@disney.com wrote:
Tim,
Isn't there an alternative to gcc for StrongARM? For example, does CodeWarrior support StrongARM? I suppose there could be linking issue...
It might well, but I have no idea if it is freely available for *nix. Acorn of course have/had the Norcroft/CodeMist compiler which is pretty good but probably not available. M$ support ARM under VC++ of course but I _really_ doubt that will run under *nix!
Of course there is the ol'Interval translator.....
Has anyone been working on this? It seems to me this could be a more powerful tool than Jitter.
Related to this, would the new compiled method format be able to handle (possibly multiple) native codes in addition to byte codes? This could be handy for the SqueakNOS people too.
On Sun, Dec 02, 2001 at 02:28:59PM +0000, Douglas Brebner wrote:
On Saturday 01 December 2001 03:51, you wrote:
John.Maloney@disney.com wrote:
Tim,
Isn't there an alternative to gcc for StrongARM? For example, does CodeWarrior support StrongARM? I suppose there could be linking issue...
It might well, but I have no idea if it is freely available for *nix. Acorn of course have/had the Norcroft/CodeMist compiler which is pretty good but probably not available. M$ support ARM under VC++ of course but I _really_ doubt that will run under *nix!
Of course there is the ol'Interval translator.....
Has anyone been working on this? It seems to me this could be a more powerful tool than Jitter.
Except that you have to write in Slang. It is certainly a nice complement to Jitter, but not a replacement.
Joshua
Related to this, would the new compiled method format be able to handle (possibly multiple) native codes in addition to byte codes? This could be handy for the SqueakNOS people too.
-- Douglas
Joshua 'Schwa' Gargus wrote:
On Sun, Dec 02, 2001 at 02:28:59PM +0000, Douglas Brebner wrote:
Of course there is the ol'Interval translator.....
Has anyone been working on this? It seems to me this could be a more powerful tool than Jitter.
Except that you have to write in Slang. It is certainly a nice complement to Jitter, but not a replacement.
This is true right now - it takes a slightly evolved form of Slang as its input stream. However, I doubt it would be beyond some of you CS jocks out there to extend it to take normal Smalltalk. After all, Slang is merely a subset. Since it already knows how to output C source, ARM assembler source and ARM object code, I'm guessing it would be a reasonable starting point for an in-image jitter system.
This isn't a new idea, by the way, Ian P wrote a thesis on something like this and I think his paper referenced still earlier similar suggestions. Rather than having a complex system hidden in the VM (as with the current jitter, the VW dynamic translator etc) to convert bytecodes to machine code, with all the attendant problems of it being hidden, you can have the convertor in the image and potentially have a very sophisticated compiler available. Even sending out across the net for a translator service would be possible! Improvements in performance due to better optimisation would be available via normal updating rather than waiting for a new vm.
Of course, you have to have something to run bytecodes until the translator has produced machine code; a normal interpreter is perfectly adequate and in fact a really small simple one would do. It could be a plugin that gets dropped automatically when everything is translated.
A big advantage of a sytem like this is the cofiguration flexibilty that becomes possible. You could use an image _without_ the translator on small machines or for a script running system. On a 'normal' machine you load the module with the basic translator and on large servers you might use a more exacting translator that works really hard and assumes a static codebase with no reflection etc etc.
Related to this, would the new compiled method format be able to handle (possibly multiple) native codes in addition to byte codes? This could be handy for the SqueakNOS people too.
The NCM changes remove the ugly magic from the copiled method format and make it a regular object. This means that adding extra instance variables becomes easy and an array of translated machine code would easy. More likely useful would be a weak pointer that goes away in a snapshot. Other people have expressed a wish to add ivars for security, database and sourcecode management purposes.
tim
On Sunday 02 December 2001 19:22, Tim Rowledge wrote:
Joshua 'Schwa' Gargus wrote:
On Sun, Dec 02, 2001 at 02:28:59PM +0000, Douglas Brebner wrote:
Of course there is the ol'Interval translator.....
Has anyone been working on this? It seems to me this could be a more powerful tool than Jitter.
Except that you have to write in Slang. It is certainly a nice complement to Jitter, but not a replacement.
This is true right now - it takes a slightly evolved form of Slang as its input stream. However, I doubt it would be beyond some of you CS jocks out there to extend it to take normal Smalltalk. After all, Slang is merely a subset. Since it already knows how to output C source, ARM assembler source and ARM object code, I'm guessing it would be a reasonable starting point for an in-image jitter system.
That's the sort of thing I was hoping could be done. <pipedream> Could it be made to handle other languages too? Maybe for the C interpreter mentioned on http://mathmorphs.swiki.net/50? </pipedream>
This isn't a new idea, by the way, Ian P wrote a thesis on something like this and I think his paper referenced still earlier similar suggestions. Rather than having a complex system hidden in the VM (as with the current jitter, the VW dynamic translator etc) to convert bytecodes to machine code, with all the attendant problems of it being hidden, you can have the convertor in the image and potentially have a very sophisticated compiler available.
Could the translator produce code in the manner that Jitter expects? That way, the translation part of Jitter can be removed leaving the native code execution engine. Or would that be excessively complex?
I'm envisioning a system where the image starts up with the bytecode interpreter, the translator and other essential bits are translated and then control passes from the interpreter to the Jitter engine and the rest of the image is translated on-the-fly.
Even sending out across the net for a translator service would be possible! Improvements in performance due to better optimisation would be available via normal updating rather than waiting for a new vm.
And of course with VMMaker and the translator, building new VMs and plugins could potentially be done with a few mouse clicks :)
Related to this, would the new compiled method format be able to handle (possibly multiple) native codes in addition to byte codes? This could be handy for the SqueakNOS people too.
The NCM changes remove the ugly magic from the copiled method format and make it a regular object. This means that adding extra instance variables becomes easy and an array of translated machine code would easy. More likely useful would be a weak pointer that goes away in a snapshot. Other people have expressed a wish to add ivars for security, database and sourcecode management purposes.
It would be nice if they could optionally hold on to code across snapshots. Persistant native code could be useful for SqueakNOS device drivers and maybe the translator and some essential bits to allow for full native execution.
Douglas Brebner wrote:
That's the sort of thing I was hoping could be done.
<pipedream> Could it be made to handle other languages too? Maybe for the C interpreter mentioned on http://mathmorphs.swiki.net/50? </pipedream>
Well I guess that one could make a front end that would do that, but I remember with horror the amount of work it took to write the C headerfile parser for the VW FFI system back in 92/3/4. It might be a rather large amount of work for dubious value - after all there are C compilers out there that already do that work. There are even (if legend can be believed) people _that like writing C compilers_!
Could the translator produce code in the manner that Jitter expects? That way, the translation part of Jitter can be removed leaving the native code execution engine. Or would that be excessively complex?
To a first approximation, if you removed the translation part of the jitter you would have almost nothing left. There is an improved stack design that the J3 system provides and takes advantage of, but I think it is fair to say it could pretty much be used independently.
I suspect the thing to do would be to have an instvar in each compiled method that can have nil or a wordarray of translated machine code. If it's nil, the interpreter runs the bytecodes and adds the method to a list for potential translation. If it's a wordarray, run it, assuming it is correct code. I wonder if there is a nice way to fold primitives into this?
And of course with VMMaker and the translator, building new VMs and plugins could potentially be done with a few mouse clicks :)
Well, that's pretty much true now :-)
It would be nice if they could optionally hold on to code across snapshots. Persistant native code could be useful for SqueakNOS device drivers and maybe the translator and some essential bits to allow for full native execution.
Oh, surely. Some startup code that knows it is returning from a snapshot rathe rthan starting fresh should handle that.
For those that have expressed an interest I've shipped the mac VM as 3.2.1B2
Based on feedback I'll then ship a 'real' 3.2.1 production VM in a few days. This will replace the Carbon VM, however this VM won't run under 9.x! I'm not sure if this is a problem, but to solve it I would need to migrate to CW 7.x.
However I've found OS-X 10.1.1 quite a nice system now and wonder, if you are attempting to use OS-X do you need a carbon version that runs under 9 and 10 since you shouldn't *ever* need to boot OS-9 and run squeak, right?
For the curious I attempted to migrate the C code to use MPW's libraries under CW 6 and use Apple's common C library. There is a common C library for OS-9 and OS-10, it uses Carbon. However right now an application using this library runs under 9, but crashs under 10. The usage of Apple C library was needed because CW 6 libraries don't support 64bit file io (maybe CW 7 does). Of course if someone could show me a MPW build with CW that uses the carbon library and runs in both I'd be delighted to use it.
On Sun, Dec 02, 2001 at 08:00:21PM -0800, Tim Rowledge wrote:
I suspect the thing to do would be to have an instvar in each compiled method that can have nil or a wordarray of translated machine code. If it's nil, the interpreter runs the bytecodes and adds the method to a list for potential translation. If it's a wordarray, run it, assuming it is correct code. I wonder if there is a nice way to fold primitives into this?
Smalltalk/X uses a "code pointer". This contains the adress of some runtime genated code or a pointer to some code compiled with gcc (for Primitives or statically compiled methods with the smalltalk-to-c compiler).
Marcus
Marcus Denker marcus@ira.uka.de is widely believed to have written:
Smalltalk/X uses a "code pointer". This contains the adress of some runtime genated code or a pointer to some code compiled with gcc (for Primitives or statically compiled methods with the smalltalk-to-c compiler).
Mmm, is it just the one pointer? What happens with a primitive _and_ translated Smalltalk backup code? Or is that not allowed?
tim
Tim Rowledge wrote:
Marcus Denker marcus@ira.uka.de is widely believed to have written:
Smalltalk/X uses a "code pointer". This contains the adress of some runtime genated code or a pointer to some code compiled with gcc (for Primitives or statically compiled methods with the smalltalk-to-c compiler).
Mmm, is it just the one pointer? What happens with a primitive _and_ translated Smalltalk backup code? Or is that not allowed?
Don't know if I understand the context completely... ST/X doesn't have primitives. It just has inline C code. Want to see how integers added in the browser? You just browse to that method and there the C/Smalltalk/assembler is! Want to look at how Object>>basicNew works? Go for it. What's more (and not even Squeak can do this one). Want to change the way basicNew work (say, add an extra byte to every object header and printf the address of each new object). Make the change and hit accept button. Realtime, right there, it happens.
On Thu, Dec 06, 2001 at 05:20:42PM -0800, Travis Griggs wrote:
Don't know if I understand the context completely... ST/X doesn't have primitives. It just has inline C code. Want to see how integers added in the browser? You just browse to that method and there the C/Smalltalk/assembler is! Want to look at how Object>>basicNew works? Go for it. What's more (and not even Squeak can do this one). Want to change the way basicNew work (say, add an extra byte to every object header and printf the address of each new object). Make the change and hit accept button. Realtime, right there, it happens.
Hi Travis!
Yes, you are right: the current version does not have primitives. The primitives are "normal" Smaltalk-To-C statically compiled methods (with inlined C-code).
But: The problem is that the image is not portable across architectures anymore. You can even run into problemes simply by re-compiling the VM using a different compiler. (There are pointers in the saved image to code generated by the C-compiler, these won't be the same on an other architecture) There are some hacks to prevent running such an image, and it tries hard to fix the refences, but according to Claus this never really worked in all cases. So he decided that the new VM (I think for version 5?) will have "real" primitives. (As an execution-mechanism, it will look the same for the programmer. You won't see <primitive 224> but the code of the primitive...) He talked a little bit about the new vm some time ago, the following is what I understood from his description (My understanding might not be entirely correct...):
The "primitive" methods are like "normal", not-yet-jitted Smalltalk methods (*codeptr is nil), but they have the "primitive" bit set. If such a method is called the first time, the vm looks up the right adress for the primitive and sets the *codeptr.
If the codeptr is nil and we have a non-primitive method, the jitter is called to produce native code. The code is held in a cache outside the image, and the adress of the code is stored in the codeptr.
If we compile a Method with the Smtlk-To-C Compiler, stc produces a C-source-file, gcc compiles this to an dll (.so), it's loaded at runtime (dlopen()), and the *codeptr is updated to point to the right function.
If the codeptr is not-nil, run the code at that adress.
Tim asked:
Mmm, is it just the one pointer?
Yep. In the prototype-interpreter claus re-used the codeptr to store the primitive-number. So a one-bit flag for primitives is sufficient.
What happens with a primitive _and_ translated Smalltalk backup code? Or is that not allowed?
I don't now... but the simplest thing would be to make that method a non-primitive-method, and than translate it with the Smlt-To-native-compiler, update the codeptr to that new method. (That image would not be platform-independend anymore).
There might be even more intelligent ways to do this, like checking the the dlls for certain names and patching the primitive table or something like that... actually the question is if you'd need a real primitive table with numbered primitives at all: searching by name should be fast enough if it's only done once.
Marcus
I have recently reinstalled 3.0 on SuSe 7. I launched Squeak on one window, and a MP3 (KDE) player elsewhere, and on the surface of Squeak I decided to get rid of the rodent face, its eyes make me nervous... As you know, it dies with a specific sound. Apparently it could not die in an elegant manner because sound resources were not available, so as a blind vengeance it blocked the application. Nothing worked anymore.
(One of my students reported that under Windows NT the application window in such circumstances behaves as a textual console writing some unpleasant messages, but the system continues to work...)
Any suggestions? I am almost sure that the sound service of my Linux is the responsible for the mess, but for the moment I might try to find a replacement solution. For example to kill the sounds in Squeak, I don't really need them *now*. Where can I do that? Somewhere near AbstractSound/SequentialSound? Or where else? Thanks.
Jerzy Karczmarczuk Caen, France
you can disable sound using the preferences panel. To open it choose "help" in the world-menu and then "preferences". The sound stuff is in the category "media" (soundsEnabled).
Cheers,
felix
I have recently reinstalled 3.0 on SuSe 7. I launched Squeak on one window, and a MP3 (KDE) player elsewhere, and on the surface of Squeak I decided to get rid of the rodent face, its eyes make me nervous... As you know, it dies with a specific sound. Apparently it could not die in an elegant manner because sound resources were not available, so as a blind vengeance it blocked the application. Nothing worked anymore.
(One of my students reported that under Windows NT the application window in such circumstances behaves as a textual console writing some unpleasant messages, but the system continues to work...)
Any suggestions? I am almost sure that the sound service of my Linux is the responsible for the mess, but for the moment I might try to find a replacement solution. For example to kill the sounds in Squeak, I don't really need them *now*. Where can I do that? Somewhere near AbstractSound/SequentialSound? Or where else? Thanks.
Jerzy Karczmarczuk Caen, France
This is a stupid part of most Linux sound drivers -- only one program can connect at a time. Worse, some sound cards *block* when you try to open them a second time. I'd love to know how to tell the open to just give up, if there is another process using it.... but not all sound drivers allow this.
Anyway, you can solve this problem by using the Network Audio System (NAS). Does SuSe have a package for this? The way it works is that a "sound server" is the only guy talking directly to the sound device; other apps talk to the saund server. Squeak has patches for NAS on my Squeak site:
http://www.cc.gatech.edu/~lex/squeak
To deal with other programs that don't support NAS, you can use "audiooss" -- if SuSe doesn't have it, you can do a web search for it. (Probably only Debian has this in it....)
-Lex
So I take it that other (non-Squeak) Linux applications also generally crash when trying to play sounds with a typical (non-NAS) sound driver setup? (or whatever setup causes Squeak to crash) Or is this just a Squeak thing?
I'm just wondering if there's any way that Squeak could at least fail silently rather than crash in this situation. It seems a bit ridiculous that it's this easy for a newbie to crash Squeak on Linux.
- Doug Way dway@riskmetrics.com
Lex Spoon wrote:
This is a stupid part of most Linux sound drivers -- only one program can connect at a time. Worse, some sound cards *block* when you try to open them a second time. I'd love to know how to tell the open to just give up, if there is another process using it.... but not all sound drivers allow this.
Anyway, you can solve this problem by using the Network Audio System (NAS). Does SuSe have a package for this? The way it works is that a "sound server" is the only guy talking directly to the sound device; other apps talk to the saund server. Squeak has patches for NAS on my Squeak site:
http://www.cc.gatech.edu/~lex/squeakTo deal with other programs that don't support NAS, you can use "audiooss" -- if SuSe doesn't have it, you can do a web search for it. (Probably only Debian has this in it....)
-Lex
Doug Way dway@riskmetrics.com wrote:
So I take it that other (non-Squeak) Linux applications also generally crash when trying to play sounds with a typical (non-NAS) sound driver setup? (or whatever setup causes Squeak to crash) Or is this just a Squeak thing?
Right, it affects all programs.
By the way, they aren't crashing -- just waiting for the sound to become available. If you exit the program that is using the sound device, then the next program in line should procede.
I'm just wondering if there's any way that Squeak could at least fail silently rather than crash in this situation. It seems a bit ridiculous that it's this easy for a newbie to crash Squeak on Linux.
Yep, it sucks. We should all be using sound servers, anyway, and the major distributions seem to be moving slowly in that direction.
I don't know why the sound drivers do what they do here -- blocking until the device is available is rarely going to be helpful, as far as I can imagine.
-Lex
Doug Way wrote:
So I take it that other (non-Squeak) Linux applications also generally crash when trying to play sounds with a typical (non-NAS) sound driver setup? (or whatever setup causes Squeak to crash) Or is this just a Squeak thing?
I'm just wondering if there's any way that Squeak could at least fail silently rather than crash in this situation. It seems a bit ridiculous that it's this easy for a newbie to crash Squeak on Linux.
As you can imagine, it's pretty complex! Indeed, there are probably people out there who see the very idea of sound in a Unix (or *nix alike) as the work of the devil. (And I'm not 100% convinced that they're wrong!)
Without the NAS stuff _some_ Linux applications know how to handle "sound sharing". For example, XMMS is a rather nice mp3 and wav player. If I run it under Kde (which has its own sound effects, a la Windows 9* -- or Mac, I guess) then the Kde effects play and XMMS "comes back" immediately, as though nothing untoward had happened. Others, like mtvp (an mpeg player) behave OK, but simply loose their sound if XMMS is running.
The sound in Kde doesn't interfere with Squeak, but XMMS causes the dreaded crash/lock-up. (But only, IIRC, with Squeak's mpeg player.)
How all this is done, I've no idea. Perhaps one of the Kde developers could tell us?
Cheers
John
"Lex Spoon" lex@cc.gatech.edu is widely believed to have written:
This is a stupid part of most Linux sound drivers -- only one program can connect at a time.
I'm pretty sure the exobox revised sound driver that was able to handle multiple sources and mix them was released to whatever was thought to be the appropriate place; Duane? Can you remember what happenned?
tim
Tim Rowledge said:
"Lex Spoon" lex@cc.gatech.edu is widely believed to have written:
This is a stupid part of most Linux sound drivers -- only one program can connect at a time.
I'm pretty sure the exobox revised sound driver that was able to handle multiple sources and mix them was released to whatever was thought to be the appropriate place; Duane? Can you remember what happenned?
Yeah, we did put something together that addressed the general multiple-sound-source problem in legacy Linux applications and released it to the world *somewhere*, but not sure exactly where.
The strategy was to create a stub driver in the place where applications were expecting it (/dev/dsp?). When the driver was opened it was renamed, then another stub put in its place with the original name (in actual practice, it has done through symbolic links). Therefore each application that opened sound got what appeared to be an unused sound device. The stub drivers forwarded their data to a mixer, which had grabbed the *actual* driver at system startup. This made it so we could mix MP3 audio from a closed-source system we had licensed with audio from Squeak. There was a minor change to the Squeak VM that we had to make in order to get it to play nice - as I recall there was something funny it did that was a deep assumption that it had exclusive access to audio.
-- Duane
Marcus Denker wrote:
Hi Travis!
Yes, you are right: the current version does not have primitives. The primitives are "normal" Smaltalk-To-C statically compiled methods (with inlined C-code).
But: The problem is that the image is not portable across architectures anymore. You can even run into problemes simply by re-compiling the VM using a different compiler. (There are pointers in the saved image to code generated by the C-compiler, these won't be the same on an other architecture) There are some hacks to prevent running such an image, and it tries hard to fix the refences, but according to Claus this never really worked in all cases. So he decided that the new VM (I think for version 5?) will have "real" primitives. (As an execution-mechanism, it will look the same for the programmer. You won't see <primitive 224> but the code of the primitive...) He talked a little bit about the new vm some time ago, the following is what I understood from his description (My understanding might not be entirely correct...):
The "primitive" methods are like "normal", not-yet-jitted Smalltalk methods (*codeptr is nil), but they have the "primitive" bit set. If such a method is called the first time, the vm looks up the right adress for the primitive and sets the *codeptr.
If the codeptr is nil and we have a non-primitive method, the jitter is called to produce native code. The code is held in a cache outside the image, and the adress of the code is stored in the codeptr.
If we compile a Method with the Smtlk-To-C Compiler, stc produces a C-source-file, gcc compiles this to an dll (.so), it's loaded at runtime (dlopen()), and the *codeptr is updated to point to the right function.
If the codeptr is not-nil, run the code at that adress.
In a way, I think that's too bad. I'm trying to remember the last time in 10 years I actually took advantage of xplatform image portability. I can remember two cases. I've done it many more times than that, but usually just for a "isn't that cool" grin. I've got two platforms (Squeak and VW) that have xplatform binary portability. If Claus does this I'll have three, but (IMO) the _best_ Smalltalk for looking at image/VM interaction/coupling will no longer be. Sad.
On Friday 07 December 2001 08:56 am, Travis Griggs wrote:
In a way, I think that's too bad. I'm trying to remember the last time in 10 years I actually took advantage of xplatform image portability. I can remember two cases. I've done it many more times than that, but usually just for a "isn't that cool" grin.
I spent 5 years or so doing embedded systems in Smalltalk where we'd develop a program in VisualWorks on x86/Windows machines and move the image unchanged to the target machines, which were running under vxWorks and could have any processor we wanted.
It was essential to us to be able to do this.
In Squeak I do this for developing programs for my WinCE device, which runs really slowly and has a tiny screen.
You've just got to get out of the desktop/server paradigm...
Ned Konz wrote:
On Friday 07 December 2001 08:56 am, Travis Griggs wrote:
In a way, I think that's too bad. I'm trying to remember the last time in 10 years I actually took advantage of xplatform image portability. I can remember two cases. I've done it many more times than that, but usually just for a "isn't that cool" grin.
I spent 5 years or so doing embedded systems in Smalltalk where we'd develop a program in VisualWorks on x86/Windows machines and move the image unchanged to the target machines, which were running under vxWorks and could have any processor we wanted.
It was essential to us to be able to do this.
In Squeak I do this for developing programs for my WinCE device, which runs really slowly and has a tiny screen.
You've just got to get out of the desktop/server paradigm...
I'm not necesarily disputing the value of xplatform portability. I think its great that VW and Squeak both do it, and recognize that there are people who derive more value that I do from it. I'm not quite sure what you mean with this last statement; or rather how it applies?
On Friday 07 December 2001 10:27 am, Travis Griggs wrote:
You've just got to get out of the desktop/server paradigm...
I'm not necesarily disputing the value of xplatform portability. I think its great that VW and Squeak both do it, and recognize that there are people who derive more value that I do from it. I'm not quite sure what you mean with this last statement; or rather how it applies?
Just that in the desktop and server world cross-platform is less important, since the development environment is usually the same as or very similar to the target environment, which isn't always the case in embedded systems.
In a way, I think that's too bad. I'm trying to remember the last time in 10 years I actually took advantage of xplatform image portability. I can remember two cases. I've done it many more times than that, but usually just for a "isn't that cool" grin. I've got two platforms (Squeak and VW) that have xplatform binary portability. If Claus does this I'll have three, but (IMO) the _best_ Smalltalk for looking at image/VM interaction/coupling will no longer be. Sad.
Here's two places I see it helping all the time:
I give most presentations using Squeak, and I like being able to develop on my Linux box and then display on whatever computer is handy where I'm giving the talk.
Students working in Squeak can develop their projects either at home or on any of the university's computers or on any of their group-members' computers, without any hassle.
-lex
On Fri, Dec 07, 2001 at 08:56:33AM -0800, Travis Griggs wrote:
In a way, I think that's too bad. I'm trying to remember the last time in 10 years I actually took advantage of xplatform image portability. I can remember two cases. I've done it many more times than that, but usually just for a "isn't that cool" grin. I've got two platforms (Squeak and VW) that have xplatform binary portability. If Claus does this I'll have three, but (IMO) the _best_ Smalltalk for looking at image/VM interaction/coupling will no longer be. Sad.
Non, No! The primitves would only be an *execution* facility inside the VM. There shouldn't be any changes for the programmer at all. (I'm really bad in explaining things... sorry). Important: *NO* "<primitive 123>. It will look the same like now, you will be able to change these kind of messages in the running system. It will only be portable. You can think about it as some kind of "late binding" of all native methods that are compiled statically inside the VM.
Marcus
Correct price is $399 http://www.sharpplace.com/product.asp?sku=1865193
As for the ARM gcc issue, if it really bugs people here such a lot, why doesn't someone fix it, or put a bounty of a few hundred dollars on it ? I am sure rms would be delighted to hack gcc if encouraged by the promise of a little money :)
Edmund
On Fri, 30 Nov 2001, Mike Rutenberg wrote:
I just noticed a new PDA with a built in keyboard and might make an interesting Squeak platform.
Sharp Zaurus SL-5000D is a handheld PDA that runs Linux on a 200 MHz StrongARM, and has a tiny built in QWERTY keyboard, as well as a touch screen and stylus. The keyboard looks a bit like the curved Blackberry keyboard.
The screen is 1/4 VGA in size, 65,536 Color Reflective TFT touch panel, 3.5" with front lighting. (I assume front lighting because it is reflective?).
It costs USD 500 for the prerelease developer version.
Mike
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Doug Way -
Douglas Brebner -
Duane Maxwell -
Edmund Ronald -
fefr＠gmx.net -
Jerzy Karczmarczuk -
John Hinsley -
John M McIntosh -
John.Maloney＠disney.com -
Joshua 'Schwa' Gargus -
Lex Spoon -
Marcus Denker -
Mike Rutenberg -
Ned Konz -
Tim Rowledge -
Travis Griggs