On May 17, 2006, at 3:55 PM, Alan Lovejoy wrote:
I think our attitude is wrong, even if we're "right." We absolutely should enable more "traditional" approaches for doing Smalltalk programming. If the Mountain won't come to Mohammed, then Mohammed must go to the Mountain.
I like the attitude, but I think it's really tough in practice. I see two problems:
1) The tools for doing "traditional" programming would have to be implemented by fairly adept Smalltalkers. This means that they're working on tools based in a paradigm they don't themselves share. They'd be creating tools they have no interest in using. Who's going to want to put effort into that, and who could do it well?
2) The reasons Smalltalk is good are basically the same as the reasons it's different. If we enable newcomers to retain their old habits and coding style, are we really doing them a service? We just make it that much less likely they'll learn the Smalltalk way, and ultimately give them no reason to use Smalltalk at all. Heck, if you want a more "traditional" version of Smalltalk, just use Ruby. The syntax is a little awkward, but otherwise, it's all there.
Colin
Dear all,
I agree with you Colin. I think tht we should think in terms of technology [see below*]I think that to be worried by number is to think as a technology evangelizer wich I dont care about. I dont have any intention of evangelize or convince anybody of anything (even a technology) just because it is a dogmatic and manipulative thing to do. But I do have intention to show to everybody the strengths of this technology are more than what it has been shown to everybody until now. Smalltalk it's much more than a language and it has a potential to be more than what we saw by now.
I do think Smalltalk should give a reason strong enough to motivate all the demotivation a newcomer could have. More than that... That reason should not be just for that. I could/should exists for several motivations.
[*] I can think a reason that could do that: to marry Smalltalk with assembler. A Smalltalk that makes it's compilations to machine code.
Imagine a Smalltalk that never will need a JITER because it's cache is the L1 of the pentium (or other vendor architectures). The peek of the eficiency in using the CPU hardware by software. Nothing the industry has seen something near this before. I think Smalltalk are not as far osf this as other techonogies are.
Demistify once and for good speed and Smalltalk problem gets so little that anybody will ever think in that again just because that technology will have no match. At least not a reasonable one (you allways could do in assembler everything, but think in making 3DStudio all in assembler, it's insane).
I think this technology is feasible with a considerable effort. More than that I saw a little *proof of concept* of this idea based on a largely modified squeak image. To give you an idea that limted prototype makes sends about x54 times than Exuperys do. And please don't get me wrong, I do like Exupery, but I think we could get a lot longer than that. Smalltalk will never be small again. A Smalltalk like that will be the technology of the tecnologies for the software industry. People will start to talk of IT sice this technology. It will became *a must* and will be that just for it's owns strenghts, wich the most of them (99.99%) it already has.
I wanted to post this because I want to know if anybody has ever thought about this and if so why it don't became a project. In the other hand, if is the first time to think in this here, what do you think about making Squeak to be married with assembler this way and what are the posibilities of this group to make a project to materialize this?
best regards,
Sebsatian Sastre
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Colin Putney Enviado el: Miércoles, 17 de Mayo de 2006 17:22 Para: The general-purpose Squeak developers list Asunto: Re: A Lisper asks, "Am I supposed to like Smalltalk?"
On May 17, 2006, at 3:55 PM, Alan Lovejoy wrote:
I think our attitude is wrong, even if we're "right." We
absolutely
should enable more "traditional" approaches for doing Smalltalk programming. If the Mountain won't come to Mohammed, then Mohammed must go to the Mountain.
I like the attitude, but I think it's really tough in practice. I see two problems:
- The tools for doing "traditional" programming would have
to be implemented by fairly adept Smalltalkers. This means that they're working on tools based in a paradigm they don't themselves share. They'd be creating tools they have no interest in using. Who's going to want to put effort into that, and who could do it well?
- The reasons Smalltalk is good are basically the same as
the reasons it's different. If we enable newcomers to retain their old habits and coding style, are we really doing them a service? We just make it that much less likely they'll learn the Smalltalk way, and ultimately give them no reason to use Smalltalk at all. Heck, if you want a more "traditional" version of Smalltalk, just use Ruby. The syntax is a little awkward, but otherwise, it's all there.
Colin
On 17-May-06, at 4:09 PM, Sebastián Sastre wrote:
I can think a reason that could do that: to marry Smalltalk with assembler. A Smalltalk that makes it's compilations to machine code.
That's (indirectly) been done since 1984 or thereabouts. Peter Deutsch and Allan Schiffman did the work at PARQ and wrote a very famous paper for POPL (L. Peter Deutsch and Allan M. Schiffman, "Efficient Implementation of the Smalltalk-80 System", Conference Record of the Eleventh Annual ACM Symposium on Principles of Programming Languages, January 1984, pp. 297--302) This was a specialized VM targetted at the 68k architecture and a couple of years later it was redone and extended and made portable as part of developing ParcPlace's HPS VM. At various times that has run (to my knowledge) on 68k, 386/486/pentium/blahblah, PPC, POWER, ARM, MIPS under a wide range of OSs. I did the first working ARM version in '94. HPS compiles Smalltalk to bytecodes and then the VM converts those to quite well optimised machine code at need; it was a JIT many years before the javanauts made the term popular.
Compiling straight to machine code is certainly doable; it simply involves a lot more work since you have to develop and optimise and debug a *lot* more stuff. For example, you'd have to rewrite the compiler, the debugger, the InstructionStream related classes and tools, any system that expects to write out methods, etc etc. Send enough money and I will arrange it for you. Discussions could start at, ooh, One *Million* Euros.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Gramen artificiosum odi = I hate Astroturf.
tim Rowledge wrote:
Compiling straight to machine code is certainly doable; it simply involves a lot more work since you have to develop and optimise and debug a *lot* more stuff. For example, you'd have to rewrite the compiler, the debugger, the InstructionStream related classes and tools, any system that expects to write out methods, etc etc. Send enough money and I will arrange it for you. Discussions could start at, ooh, One *Million* Euros.
Doable, but not really a good way to implement Smalltalk. You'd lose the binary portability and in turn gain a lot of weight, since bytecodes are so much more compact than machine language. IIRC, Peter Deutsch stated that dynamic compilation of bytecodes to machine language is actually faster than paging pre-compiled machine code into memory.
Cheers, Hans-Martin
P.S.: Tim certainly knows that, but he'd use every trick he can pull to get at One Million Euros for doing something Smalltalk-related :-) P.P.S.: If you have One Million Euros to spend on something Smalltalk-related, *do* give it to Tim. You won't be disappointed.
Hi!
Hans-Martin Mosner hmm@heeg.de wrote:
tim Rowledge wrote:
Compiling straight to machine code is certainly doable; it simply involves a lot more work since you have to develop and optimise and debug a *lot* more stuff. For example, you'd have to rewrite the compiler, the debugger, the InstructionStream related classes and tools, any system that expects to write out methods, etc etc. Send enough money and I will arrange it for you. Discussions could start at, ooh, One *Million* Euros.
Doable, but not really a good way to implement Smalltalk.
And so what do you guys think of Exupery? I had the distinct impression that Exupery is exactly this (a sophisticated machine code compiler for Smalltalk) - and as long as Exupery can mop the floor with the regular VM performance wise - then why would it be "not really a good way"?
If the reader don't know what Exupery is then look at the movie or read the handout:
http://goran.krampe.se/blog/Squeak/ExuperyTalk2006.rdoc
regards, Göran
Dear Goran,
I'd love to see Exupery reach it's objetives and run squeak for Windows (as I guess other would love to see it in Mac). Is a good project Squeak have. I'm favorable in all means to the improvements exupery's is trying to bring. I think is all "profit" for us all.
cheers,
Sebastian
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de goran@krampe.se Enviado el: Jueves, 18 de Mayo de 2006 05:56 Para: The general-purpose Squeak developers list Asunto: Re: Technology of the technologies (WAS: A Lisper asks,"Am I supposed to like Smalltalk?")
Hi!
Hans-Martin Mosner hmm@heeg.de wrote:
tim Rowledge wrote:
Compiling straight to machine code is certainly doable; it simply involves a lot more work since you have to develop and
optimise and
debug a *lot* more stuff. For example, you'd have to rewrite the compiler, the debugger, the InstructionStream related classes and tools, any system that expects to write out methods, etc
etc. Send
enough money and I will arrange it for you. Discussions
could start
at, ooh, One *Million* Euros.
Doable, but not really a good way to implement Smalltalk.
And so what do you guys think of Exupery? I had the distinct impression that Exupery is exactly this (a sophisticated machine code compiler for Smalltalk) - and as long as Exupery can mop the floor with the regular VM performance wise - then why would it be "not really a good way"?
If the reader don't know what Exupery is then look at the movie or read the handout:
http://goran.krampe.se/blog/Squeak/ExuperyTalk2006.rdoc
regards, Göran
Of course, now that Macs are based on Intel as well - this should make the whole thing lots easier - just support intel.
On May 18, 2006, at 5:50 AM, Sebastián Sastre wrote:
Dear Goran,
I'd love to see Exupery reach it's objetives and run squeak for Windows (as I guess other would love to see it in Mac). Is a good project Squeak have. I'm favorable in all means to the improvements exupery's is trying to bring. I think is all "profit" for us all.
cheers,
Sebastian
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de goran@krampe.se Enviado el: Jueves, 18 de Mayo de 2006 05:56 Para: The general-purpose Squeak developers list Asunto: Re: Technology of the technologies (WAS: A Lisper asks,"Am I supposed to like Smalltalk?")
Hi!
Hans-Martin Mosner hmm@heeg.de wrote:
tim Rowledge wrote:
Compiling straight to machine code is certainly doable; it simply involves a lot more work since you have to develop and
optimise and
debug a *lot* more stuff. For example, you'd have to rewrite the compiler, the debugger, the InstructionStream related classes and tools, any system that expects to write out methods, etc
etc. Send
enough money and I will arrange it for you. Discussions
could start
at, ooh, One *Million* Euros.
Doable, but not really a good way to implement Smalltalk.
And so what do you guys think of Exupery? I had the distinct impression that Exupery is exactly this (a sophisticated machine code compiler for Smalltalk) - and as long as Exupery can mop the floor with the regular VM performance wise - then why would it be "not really a good way"?
If the reader don't know what Exupery is then look at the movie or read the handout:
http://goran.krampe.se/blog/Squeak/ExuperyTalk2006.rdoc
regards, Göran
On 21-May-06, at 5:36 PM, Todd Blanchard wrote:
Of course, now that Macs are based on Intel as well - this should make the whole thing lots easier - just support intel.
Sadly this is almost true and I wonder how much damage a monoculture is going to cause in the long term. I don't think there has ever been a case where catastrophe didn't follow.
Sort of good news is that the remaining major architecture is ARM, which utterly dominates non-desktop systems. Last year approximately 1.6*billion* ARMs were sold. I'm fairly sure that is a good bit more than sales of x86 units. Now if only we could do a decent job of using a load of ARMs instead of one or two x86. We'd save a lot of power but we'd have to start doing a better job of using multiple cpus effectively; but then we need to do that anyway.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Looks for the "Any" key.
Sort of good news is that the remaining major architecture is ARM, which utterly dominates non-desktop systems. Last year approximately 1.6*billion* ARMs were sold. I'm fairly sure that is a good bit more than sales of x86 units. Now if only we could do a decent job of using a load of ARMs instead of one or two x86. We'd save a lot of power but we'd have to start doing a better job of using multiple cpus effectively; but then we need to do that anyway.
I want an ARM workstation.
I am being lead, inextricably, towards a vast conspiracy theory regarding all RISC workstations... =(
tim Rowledge puso en su mail :
Sadly this is almost true and I wonder how much damage a monoculture is going to cause in the long term. I don't think there has ever been a case where catastrophe didn't follow.
Sort of good news is that the remaining major architecture is ARM, which utterly dominates non-desktop systems. Last year approximately 1.6*billion* ARMs were sold. I'm fairly sure that is a good bit more than sales of x86 units. Now if only we could do a decent job of using a load of ARMs instead of one or two x86. We'd save a lot of power but we'd have to start doing a better job of using multiple cpus effectively; but then we need to do that anyway.
I feel the same without your knowledge. What think about X360 chip ? Could Microsoft go to some different what X86 in a future ?
Edgar
_________________________________________________________ Hor�scopos, Salud y belleza, Chistes, Consejos de amor: el contenido m�s divertido para tu celular est� en Yahoo! M�vil. Obtenelo en http://movil.yahoo.com.ar
On Mon, 22 May 2006 11:39:06 +0200, Lic. Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote: ...
What think about X360 chip ? Could Microsoft go to some different what X86 in a future ?
Edgar
What is a x360 chip? I learned and used IBM/360 assembler in the early 70' of the previous century, does x360 have anything to do with IBM's /360 series ? <grin> ;-)
/Klaus
Klaus D. Witzel puso en su mail :
What is a x360 chip? I learned and used IBM/360 assembler in the early 70' of the previous century, does x360 have anything to do with IBM's /360 series ? <grin> ;-)
/Klaus
I mean the chip what IBM build for Microsoft Xbox 360 Game Console and what have 3 cores and could be a "super PowerPC" of super power.
Life is odd if Apple go Intel and Microsoft to IBM chips, don't you think ?
Maybe in a while Microsoft build computers with a decent OS on this chip (or some derivative)
I support Big Endian and refuse break eggs ohterwise !! :=)
Edgar
____________________________________________________ Esa persona especial te espera en Yahoo! Encuentros. �Dejate encontrar! http://ar.encuentros.yahoo.com/
Göran Krampe wrote on Thu, 18 May 2006 10:55:58 +0200
Hans-Martin Mosner wrote:
tim Rowledge wrote:
Compiling straight to machine code is certainly doable; it simply involves a lot more work since you have to develop and optimise and debug a *lot* more stuff. For example, you'd have to rewrite the compiler, the debugger, the InstructionStream related classes and tools, any system that expects to write out methods, etc etc. Send enough money and I will arrange it for you. Discussions could start at, ooh, One *Million* Euros.
Doable, but not really a good way to implement Smalltalk.
And so what do you guys think of Exupery? I had the distinct impression that Exupery is exactly this (a sophisticated machine code compiler for Smalltalk) - and as long as Exupery can mop the floor with the regular VM performance wise - then why would it be "not really a good way"?
Exupery translates bytecodes to x86 (for now) machine code, so it is like the alternative Hans-Martin mentioned instead of the solution Tim said wasn't a good idea.
The SOAR (Smalltalk On A RISC) project at Berkeley did actually translate directly to machine code and skipped the bytecodes altogether and one of the lessons learned was that it wasted memory and didn't gain any speed compared to the dynamic translation alternative. Smalltalk X also started as a pure translations system (to C rather than directly to machine code) and later added bytecodes to the mix to make interactive use faster. Smalltalk MT is, as far as I know, a bytecodeless system.
Sebastián Sastre wrote:
I think this technology is feasible with a considerable effort. More than that I saw a little *proof of concept* of this idea based on a largely modified squeak image. To give you an idea that limted prototype makes sends about x54 times than Exuperys do. And please don't get me wrong, I do like Exupery, but I think we could get a lot longer than that.
The only way I can see that a "limited prototype" could make sends faster than what Exupery does is by extensively inlining code, and that is something which future versions of Exupery will have as well (it has been on the roadmap since the beginning). If you have any more information about this, I would love to see it.
As we saw in Self, when combined with other optimizations inlining can actually make sends take a negative number of clock cycles as measured by benchmarks! Trying to match that with a hardware solution (like the ones I build) is, obviously, not possible.
-- Jecel
Peter Deutsch stated that dynamic compilation of bytecodes to machine language is actually faster than paging pre-compiled machine code into memory.
Then th eproblem is when to throw it away... Can anyone give more information on this? Any statistics or any other valuable information?
Ale.
----- Original Message ----- From: "Hans-Martin Mosner" hmm@heeg.de To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Thursday, May 18, 2006 1:17 AM Subject: Re: Technology of the technologies (WAS: A Lisper asks, "Am I supposed to like Smalltalk?")
tim Rowledge wrote:
Compiling straight to machine code is certainly doable; it simply involves a lot more work since you have to develop and optimise and debug a *lot* more stuff. For example, you'd have to rewrite the compiler, the debugger, the InstructionStream related classes and tools, any system that expects to write out methods, etc etc. Send enough money and I will arrange it for you. Discussions could start at, ooh, One *Million* Euros.
Doable, but not really a good way to implement Smalltalk. You'd lose the binary portability and in turn gain a lot of weight, since bytecodes are so much more compact than machine language. IIRC, Peter Deutsch stated that dynamic compilation of bytecodes to machine language is actually faster than paging pre-compiled machine code into memory.
Cheers, Hans-Martin
P.S.: Tim certainly knows that, but he'd use every trick he can pull to get at One Million Euros for doing something Smalltalk-related :-) P.P.S.: If you have One Million Euros to spend on something Smalltalk-related, *do* give it to Tim. You won't be disappointed.
Hans-Martin Mosner writes:
Doable, but not really a good way to implement Smalltalk. You'd lose the binary portability and in turn gain a lot of weight, since bytecodes are so much more compact than machine language. IIRC, Peter Deutsch stated that dynamic compilation of bytecodes to machine language is actually faster than paging pre-compiled machine code into memory.
Today, I'd suspect that the time to fetch code from main memory will change the dynamic. It's possible that bytecode is the fastest technology for code that's not run frequently. If you combine bytecode execution with aggressively optimised machine code for many programs we may have the ideal solution. Exupery is designed to provide the aggressively optimised machine code.
P.S.: Tim certainly knows that, but he'd use every trick he can pull to get at One Million Euros for doing something Smalltalk-related :-) P.P.S.: If you have One Million Euros to spend on something Smalltalk-related, *do* give it to Tim. You won't be disappointed.
I could do something interesting with Exupery for a mere 100K Euros or so. Anything less isn't enough to give up the day job for a year or so. More money would of course buy more features and a larger team. ;-)
Bryce
On 18-May-06, at 12:26 PM, Bryce Kampjes wrote:
I could do something interesting with Exupery for a mere 100K Euros or so. Anything less isn't enough to give up the day job for a year or so. More money would of course buy more features and a larger team. ;-)
Of course, if someone gave me E1m you would get the 100k to be part of the team, like several others.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Mind like a steel sieve.
On 18.05.2006 21:42, tim Rowledge wrote:
On 18-May-06, at 12:26 PM, Bryce Kampjes wrote:
I could do something interesting with Exupery for a mere 100K Euros or so. Anything less isn't enough to give up the day job for a year or so. More money would of course buy more features and a larger team. ;-)
Of course, if someone gave me E1m you would get the 100k to be part of the team, like several others.
It would be a honour to work in such a team! But there is not just the technical task to get it work: it also would have to be made mature... (to get more millions ;-) , not just a joke!)
Regards, Stephan
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Mind like a steel sieve.
Hans-Martin Mosner writes:
Doable, but not really a good way to implement Smalltalk. You'd lose the binary portability and in turn gain a lot of weight, since bytecodes are so much more compact than machine language. IIRC, Peter Deutsch stated that dynamic compilation of bytecodes to machine language is actually faster than paging pre-compiled machine code into memory.
This is one of those things that varies over time as the relative performance of disk, main memory, cpu and cache (and its size of course) develop. In the 84-90 timeframe when LPD was doing this work discs were sloooooo oooow ww and caches were tiny and main memory wasn't hugely slower than cache. These days, caches are huge but still grossly inadequate to cope with the bloated obscenities that are claimed to be 'modern operating systems', cpus are massively faster than main memory and even more so if actual random access of data is considered. Set against that, we tend to have our little silicon servants doing many more things at once and so if compiled code were being paged in whilst some other useful work gets done it might seem like the total system is better. How aggressively one compiles will affect the equation as well; PS & HPS do fairly simplistic optimisation because the aim is to get a usable answer *right now*. Exupery is being more painstaking AIUI. On a machine with multiple cpus available (including a cluster of machines of course) one could imagine having a somewhat Spoon-like arrangement where a separate image running somewhere else does the careful optimised compile and provides the result to clients, rather than simply passing the method back. You'd need to make it work asynchronously to some extent I guess rather than blocking. Hell, extend Spoon a bit and have a compiler service for fee!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim My computer NEVER cras
[...
I could do something interesting with Exupery for a mere 100K Euros or so. Anything less isn't enough to give up the day job for a year or so. More money would of course buy more features and a larger team. ;-)
Bryce
It gives to me arround 300 euros from 300 investors. I don't think is too much money for an heatly organization (even non profit). If the volunteers can hold the organization of the event (nothing that smalltalk can do for them) the people will come. That will be a transparent way to get that ammount of money that the organization could invest on is main object of interest.
A big event with that finality could certainly do that. Get together key people, key persons who can give some light on this regard, the consecuences of the project and today's interesting subjects. Their reunion in a positive/constructive environment will certainly atract interest. The model could be 3 days (Friday, Saturday and Sunday) in some hotel with acceptable structure in an attactive city (Tip: change in southamerica makes more easy to find a good hotel by less $$ and there is a lot of cultural attractive cities). The event could have laboratories, seminars, panels and other expositions wich represent the investigations and foundings from people of this comunity.
The key for the success of an event like that will be the volunteers's hard work.
Cheers,
Sebastian PD: "If you build it, he will come..." (http://www.imdb.com/title/tt0097351/)
"Sebastián Sastre" wrote:
[...
I could do something interesting with Exupery for a mere 100K Euros or so. Anything less isn't enough to give up the day job for a year or so. More money would of course buy more features and a larger team. ;-)
Bryce
It gives to me arround 300 euros from 300 investors. I don't think is too much money for an heatly organization (even non profit). If the volunteers can hold the organization of the event (nothing that smalltalk can do for them) the people will come. That will be a transparent way to get that ammount of money that the organization could invest on is main object of interest.
A big event with that finality could certainly do that. Get together key people, key persons who can give some light on this regard, the
consecuences
of the project and today's interesting subjects. Their reunion in a positive/constructive environment will certainly atract interest. The
model
could be 3 days (Friday, Saturday and Sunday) in some hotel with
acceptable
structure in an attactive city (Tip: change in southamerica makes more
easy
to find a good hotel by less $$ and there is a lot of cultural attractive cities). The event could have laboratories, seminars, panels and other expositions wich represent the investigations and foundings from people of this comunity.
The key for the success of an event like that will be the volunteers's
hard
work.
This is an excellent idea.
The fine print is that all participants must pay all expenses. (Unless The Squeak Foundation decides to spend few million Euros for the event ;-)
The good news is that, I think, the expenses is not more than $50.
Some don't even have to pay this $50, because they already had it, the webcam.
Cheers,
PhiHo
tim Rowledge puso en su mail :
That's (indirectly) been done since 1984 or thereabouts. Peter Deutsch and Allan Schiffman did the work at PARQ and wrote a very famous paper for POPL (L. Peter Deutsch and Allan M. Schiffman, "Efficient Implementation of the Smalltalk-80 System", Conference Record of the Eleventh Annual ACM Symposium on Principles of Programming Languages, January 1984, pp. 297--302) This was a specialized VM targetted at the 68k architecture and a couple of years later it was redone and extended and made portable as part of developing ParcPlace's HPS VM. At various times that has run (to my knowledge) on 68k, 386/486/pentium/blahblah, PPC, POWER, ARM, MIPS under a wide range of OSs. I did the first working ARM version in '94. HPS compiles Smalltalk to bytecodes and then the VM converts those to quite well optimised machine code at need; it was a JIT many years before the javanauts made the term popular.
Several times I dreamed about this, as Sebastian said. Could be found the VM somewhere ? PPC version preferible.
About one million of Euros, I send a check as soon I win the "Quini", local lottery :=)
Edgar
____________________________________________________ Esa persona especial te espera en Yahoo! Encuentros. �Dejate encontrar! http://ar.encuentros.yahoo.com/
Lic. Edgar J. De Cleene wrote:
tim Rowledge puso en su mail :
... HPS compiles Smalltalk to bytecodes and then the VM converts those to quite well optimised machine code at need; it was a JIT many years before the javanauts made the term popular.
Several times I dreamed about this, as Sebastian said. Could be found the VM somewhere ? PPC version preferible.
It's the VisualWorks VM. I'm running it on a PPC Mac with Debian Linux, but MacOS is also supported :-) You can have it with the VisualWorks noncommercial download, however, the VM source code is not included (as a commercial customer you can have that, too).
Cheers, Hans-Martin
Hans-Martin Mosner puso en su mail :
It's the VisualWorks VM. I'm running it on a PPC Mac with Debian Linux, but MacOS is also supported :-) You can have it with the VisualWorks noncommercial download, however, the VM source code is not included (as a commercial customer you can have that, too).
Cheers, Hans-Martin
Very thanks, Hans I have it , but never know the fact
HPS compiles Smalltalk to bytecodes and then the VM converts those to quite well optimised machine code at need; it was a JIT many years before the javanauts made the term popular.
On this VM.
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
squeak-dev@lists.squeakfoundation.org
-
Alan Grimes -
Alejandro F. Reimondo -
Bryce Kampjes -
Colin Putney -
goran＠krampe.se -
Hans-Martin Mosner -
Jecel Assumpcao Jr -
Klaus D. Witzel -
Lic. Edgar J. De Cleene -
Sebastián Sastre -
SmallSqueak -
Stephan Rudlof -
tim Rowledge -
Todd Blanchard