I would be pleased if you could take a look at:
http://www.guillermomolina.com.ar/huemul/index.php There you will find information to download a demo of the Smalltalk implementation that translates st code directly to assembler, using Exupery as the final compiler phase. Please let me know what you think. Regards, Guille _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
Guille, can this be used to take a normal squeak and transform it's image into something that runs like huemul? cheers, Sebastian > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Guillermo Adrián Molina > Enviado el: Lunes, 21 de Mayo de 2007 19:56 > Para: Discussion about Exupery a native code compiler. > Asunto: Introducing Huemul > > I would be pleased if you could take a look at: > > http://www.guillermomolina.com.ar/huemul/index.php > > There you will find information to download a demo of the > Smalltalk implementation that translates st code directly to > assembler, using Exupery as the final compiler phase. > > Please let me know what you think. > > Regards, Guille > > _______________________________________________ > Exupery mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
> > Guille, > > can this be used to take a normal squeak and transform it's image > into something that runs like huemul? > > cheers, > > Sebastian > > If the question is, if someone would ever load a Squeak image in Huemul. the answer is no. Huemul will not have an image as we know it from normal smalltalks. When finished, Huemul will load modules (as normal C libraries) on demand. May be, one class per module. This modules and the small Huemul's executable, will persist all the objects seen by the system. On the other hand, Huemul *is* smalltalk, so, you may file in whatever you want. I am trying to make as little modifications as I can to the smalltalk code. Remember that the source of Huemul's classes is Squeak. May be you have a web application that runs over seaside. It would be possible that you could port your app without modifications at all to Huemul. Cheers Guille _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Sebastian Sastre-2
great job. I'm just wondering, why its not a part of squeak :)
At some day i thought, why i want to reinvent the wheel, while there's already a good and working smalltalk implementation with reach set of projects/features. And i decided to join squeak community, and asking you to do the same. You can benefit from others works, while doing your part. For example: i know a good guy 'gulik' on IRC who is already doing a namespaces. So better to help him, rather than implement own. And there's many other areas which intersects with your goals, like HTML, GUI, Dynamic class loading e.t.c. I think you just need to focus on narrow area - making a good and fast VM, and then just share your code with others and reuse their code for own matters. Don't think that i want to offend you in this way, i'm just thinking it would be better for you as well as for community. On 23/05/07, Sebastian Sastre <[hidden email]> wrote: > > Guille, > > can this be used to take a normal squeak and transform it's image > into something that runs like huemul? > > cheers, > > Sebastian > > > -----Mensaje original----- > > De: [hidden email] > > [mailto:[hidden email]] En nombre > > de Guillermo Adrián Molina > > Enviado el: Lunes, 21 de Mayo de 2007 19:56 > > Para: Discussion about Exupery a native code compiler. > > Asunto: Introducing Huemul > > > > I would be pleased if you could take a look at: > > > > http://www.guillermomolina.com.ar/huemul/index.php > > > > There you will find information to download a demo of the > > Smalltalk implementation that translates st code directly to > > assembler, using Exupery as the final compiler phase. > > > > Please let me know what you think. > > > > Regards, Guille > > > > _______________________________________________ > > Exupery mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > > _______________________________________________ > Exupery mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
> great job. Thank you very much. > I'm just wondering, why its not a part of squeak :) Well, that's Bryce job :-) I mean. Exupery will be part of Squeak one day (a very important one). But Exupery is facing with the fact that most Squeak's internals can't be changed. I have the ability to change what ever I want in Huemul. An example, Bryce suggested 0 tagged SmallInts. I was using 1 tagged, changed that in a week, then Huemul got faster. The fact is that I am really into learning things. I didn't know how to implement 0 tagged int. Thanks to Klaus (a member of this list), I was able to do it. That kind of reaction is more difficult in Squeak. > At some day i thought, why i want to reinvent the wheel, while there's > already a good and working smalltalk implementation with reach set of > projects/features. I completely agree with you on this matters, I will try to make Huemul compatible with most of them. > And i decided to join squeak community, and asking you to do the same. > You can benefit from others works, while doing your part. Believe me, I use Squeak. There is another thing. Huemul is a Linux X86-32 application. Squeak images run without modification on lots of platforms. It would be very difficult to do that with Huemul. I think the target is different. > For example: i know a good guy 'gulik' on IRC who is already doing a > namespaces. So better to help him, rather than implement own. > And there's many other areas which intersects with your goals, like > HTML, GUI, Dynamic class loading e.t.c. > I think you just need to focus on narrow area - making a good and fast > VM, and then just share your code with others and reuse their code for > own matters. > Don't think that i want to offend you in this way, i'm just thinking > it would be better for you as well as for community. > Don't worry. I asked you for advise. Everybody is welcome. Cheers, Guille _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
Good! Your reply shows me that i may not vorry about this.
Then i would ask you about design of your VM architecture. Its better to start from a clean view, that everything in VM could be changed at some point. And changed by programmer using smalltalk, not C or other external tools. I mean, i want a truly flexible system. I want to be able the smalltalk VM to rebuild self from scratch (producing new VM executable) without using C complier/e.t.c. And be able to change any low level primitives in running VM. As example - let programmer to decide, how to tag smallintegers , with 0 or with 1 , and make this as easy as clicking a single button, just by changing a single line of code in single place. This will open a wide range perspective, how programmer can experiment with VM, how he can add or change its core functionality and test it. Another example - suppose we want to run our VM/image on different platform. All we need is a hooks (like special binary format, accessing to kernel function e.t.c), provided by that platform and assembler support from Exupery to generate opcodes suitable for platform CPU. The we generate a small bootstrap executable, which then can be used for loading image in new platform, and providing a bootstrapping mechanism for recompiling a core VM methods contained in your image. So, you can keep any low-level VM code in your image and be able to run it anywhere without dependancy from external tools like C compiler or linker e.t.c. On 23/05/07, Guillermo Adrián Molina <[hidden email]> wrote: > > > great job. > Thank you very much. > > > I'm just wondering, why its not a part of squeak :) > > Well, that's Bryce job :-) > I mean. Exupery will be part of Squeak one day (a very important one). > But Exupery is facing with the fact that most Squeak's internals can't be > changed. > I have the ability to change what ever I want in Huemul. An example, Bryce > suggested 0 tagged SmallInts. I was using 1 tagged, changed that in a > week, then Huemul got faster. The fact is that I am really into learning > things. I didn't know how to implement 0 tagged int. Thanks to Klaus (a > member of this list), I was able to do it. > That kind of reaction is more difficult in Squeak. > > > At some day i thought, why i want to reinvent the wheel, while there's > > already a good and working smalltalk implementation with reach set of > > projects/features. > > I completely agree with you on this matters, I will try to make Huemul > compatible with most of them. > > > And i decided to join squeak community, and asking you to do the same. > > You can benefit from others works, while doing your part. > > Believe me, I use Squeak. > There is another thing. Huemul is a Linux X86-32 application. Squeak > images run without modification on lots of platforms. It would be very > difficult to do that with Huemul. I think the target is different. > > > For example: i know a good guy 'gulik' on IRC who is already doing a > > namespaces. So better to help him, rather than implement own. > > And there's many other areas which intersects with your goals, like > > HTML, GUI, Dynamic class loading e.t.c. > > I think you just need to focus on narrow area - making a good and fast > > VM, and then just share your code with others and reuse their code for > > own matters. > > Don't think that i want to offend you in this way, i'm just thinking > > it would be better for you as well as for community. > > > > Don't worry. I asked you for advise. Everybody is welcome. > > Cheers, Guille > > > > _______________________________________________ > Exupery mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
Yes, I would like such a system too.
But right now, Huemul is very far away from that. Huemul's core is still in C. To translate it to ST, I would need your compiler. That is why I asked you about it. Klaus suggested that it would be interesting to use it, just the way you want. I am getting close to a Huemul release that doesn't need Squeak. When that is done. I will finally release source code, for anyone to play with it. Cheers, Guille PS: May be the example about changing SmallInts behavior would be a bit difficult to implement. Not the part of getting 0 or 1 tagged arithmetic, that part would be easy to implement for both behaviors. The problem is the way you access the other objects. It is much more difficult to access an oop with a 1 tagged int system, than a 0 tagged one. Believe me, the hardest part of implementing 0 tagged wasn't the arithmetic part, at least, that was my experience with Huemul. But apart from that, I got the idea behind the example, and I agree with you. > Good! Your reply shows me that i may not vorry about this. > > Then i would ask you about design of your VM architecture. > Its better to start from a clean view, that everything in VM could be > changed at some point. > And changed by programmer using smalltalk, not C or other external tools. > I mean, i want a truly flexible system. > I want to be able the smalltalk VM to rebuild self from scratch > (producing new VM executable) without using C complier/e.t.c. > And be able to change any low level primitives in running VM. > As example - let programmer to decide, how to tag smallintegers , with > 0 or with 1 , > and make this as easy as clicking a single button, just by changing a > single line of code in single place. > This will open a wide range perspective, how programmer can experiment > with VM, how he can add or change its core functionality and test it. > Another example - suppose we want to run our VM/image on different > platform. All we need is a hooks (like special binary format, > accessing to kernel function e.t.c), provided by that platform and > assembler support from Exupery to generate opcodes suitable for > platform CPU. The we generate a small bootstrap executable, which then > can be used for loading image in new platform, and providing a > bootstrapping mechanism for recompiling a core VM methods contained in > your image. > So, you can keep any low-level VM code in your image and be able to > run it anywhere without dependancy from external tools like C compiler > or linker e.t.c. > > On 23/05/07, Guillermo Adrián Molina <[hidden email]> wrote: >> >> > great job. >> Thank you very much. >> >> > I'm just wondering, why its not a part of squeak :) >> >> Well, that's Bryce job :-) >> I mean. Exupery will be part of Squeak one day (a very important one). >> But Exupery is facing with the fact that most Squeak's internals can't >> be >> changed. >> I have the ability to change what ever I want in Huemul. An example, >> Bryce >> suggested 0 tagged SmallInts. I was using 1 tagged, changed that in a >> week, then Huemul got faster. The fact is that I am really into learning >> things. I didn't know how to implement 0 tagged int. Thanks to Klaus (a >> member of this list), I was able to do it. >> That kind of reaction is more difficult in Squeak. >> >> > At some day i thought, why i want to reinvent the wheel, while there's >> > already a good and working smalltalk implementation with reach set of >> > projects/features. >> >> I completely agree with you on this matters, I will try to make Huemul >> compatible with most of them. >> >> > And i decided to join squeak community, and asking you to do the same. >> > You can benefit from others works, while doing your part. >> >> Believe me, I use Squeak. >> There is another thing. Huemul is a Linux X86-32 application. Squeak >> images run without modification on lots of platforms. It would be very >> difficult to do that with Huemul. I think the target is different. >> >> > For example: i know a good guy 'gulik' on IRC who is already doing a >> > namespaces. So better to help him, rather than implement own. >> > And there's many other areas which intersects with your goals, like >> > HTML, GUI, Dynamic class loading e.t.c. >> > I think you just need to focus on narrow area - making a good and fast >> > VM, and then just share your code with others and reuse their code for >> > own matters. >> > Don't think that i want to offend you in this way, i'm just thinking >> > it would be better for you as well as for community. >> > >> >> Don't worry. I asked you for advise. Everybody is welcome. >> >> Cheers, Guille >> >> >> >> _______________________________________________ >> Exupery mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery >> > _______________________________________________ > Exupery mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
On 23/05/07, Guillermo Adrián Molina <[hidden email]> wrote:
> Yes, I would like such a system too. > But right now, Huemul is very far away from that. > Huemul's core is still in C. To translate it to ST, I would need your > compiler. > That is why I asked you about it. Klaus suggested that it would be > interesting to use it, just the way you want. > > I am getting close to a Huemul release that doesn't need Squeak. When that > is done. I will finally release source code, for anyone to play with it. > > Cheers, Guille > > PS: May be the example about changing SmallInts behavior would be a bit > difficult to implement. Not the part of getting 0 or 1 tagged arithmetic, > that part would be easy to implement for both behaviors. The problem is > the way you access the other objects. It is much more difficult to access > an oop with a 1 tagged int system, than a 0 tagged one. Believe me, the > hardest part of implementing 0 tagged wasn't the arithmetic part, at > least, that was my experience with Huemul. But apart from that, I got the > idea behind the example, and I agree with you. > places, but still, this can be implemented at abstract level , such that any dependant code don't require any additional changes. Another example: on 64 bit systems we can use 2 bits for tag, and be able to make smallints, floats,chars immediate values. If someone wants to keep boxed floats, so just let him do this , all he's need is to supply a class name, which holds all low-level primitives written by him for that purpose. _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Igor Stasenko
> -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre de sig > Enviado el: Jueves, 24 de Mayo de 2007 09:56 > Para: Discussion about Exupery a native code compiler. > Asunto: Re: Introducing Huemul > > Good! Your reply shows me that i may not vorry about this. > > Then i would ask you about design of your VM architecture. > Its better to start from a clean view, that everything in VM > could be changed at some point. > And changed by programmer using smalltalk, not C or other > external tools. Sig, in general I agree with your position. The problem is costs to generate independece from those external tools in an equalized proportion to our communuty effort capability. How many optimizations the gcc are able to do? Now.. how many smalltalkers has experience with compilers and can develop the same degree of funcionality? How many of those can dedicate the hours that it'll require? And don't misundertood me, I'm not beign pesisimistinc, I'm beign realistic here. Until a .mzc with that compiler is available for squeak maybe the use of gcc to produce the result is the way to materialize results. It's 'changing the tire in a running car'. For sustainable projects we can't 'stop the car'. Otherwise people will easily be demotivated and efforts become quickly diluted. cheers, Sebastian _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
On 24/05/07, Sebastian Sastre <[hidden email]> wrote:
> > > -----Mensaje original----- > > De: [hidden email] > > [mailto:[hidden email]] En nombre de sig > > Enviado el: Jueves, 24 de Mayo de 2007 09:56 > > Para: Discussion about Exupery a native code compiler. > > Asunto: Re: Introducing Huemul > > > > Good! Your reply shows me that i may not vorry about this. > > > > Then i would ask you about design of your VM architecture. > > Its better to start from a clean view, that everything in VM > > could be changed at some point. > > And changed by programmer using smalltalk, not C or other > > external tools. > > Sig, in general I agree with your position. The problem is costs to generate > independece from those external tools in an equalized proportion to our > communuty effort capability. How many optimizations the gcc are able to do? > Now.. how many smalltalkers has experience with compilers and can develop > the same degree of funcionality? How many of those can dedicate the hours > that it'll require? And don't misundertood me, I'm not beign pesisimistinc, > I'm beign realistic here. Until a .mzc with that compiler is available for > squeak maybe the use of gcc to produce the result is the way to materialize > results. It's 'changing the tire in a running car'. For sustainable projects > we can't 'stop the car'. Otherwise people will easily be demotivated and > efforts become quickly diluted. while driving is impossible. Currently to write a plugin i need to use slate, then compile it , stop the car (VM) and finally start using it. With new architecture, which i propose you don't need to stop VM in most cases and you having instant results. So, who stops the car? ;) And if you talking about that i want to replace a slate, then i agree, every custom plugin written in slate must be rewritten. But who will argue about stopping the car, when tires you changing will give you more speed and maneurability? Also, don't forget that in spite of С compilers having heavy optimizing algorithms , they still have limitations which you can't avoid, because of language itself. For instance - you can't check the integer overflow in C while summing two integers. Can't construct a function calls based on previously unknown type info, and have no dynamic type system. _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
> > Otherwise people will easily be demotivated and efforts > become quickly diluted. > > Yes, sometimes you need to stop the car, because changing the > tires while driving is impossible. Currently to write a > plugin i need to use slate, then compile it , stop the car > (VM) and finally start using it. > With new architecture, which i propose you don't need to stop > VM in most cases and you having instant results. So, who > stops the car? ;) > > And if you talking about that i want to replace a slate, then > i agree, every custom plugin written in slate must be > rewritten. But who will argue about stopping the car, when > tires you changing will give you more speed and maneurability? > > Also, don't forget that in spite of С compilers having heavy > optimizing algorithms , they still have limitations which you > can't avoid, because of language itself. For instance - you > can't check the integer overflow in C while summing two > integers. Can't construct a function calls based on > previously unknown type info, and have no dynamic type system. > certainty of a way to do it in practice sustainably. The 'running car' metaphore was meant to be read also meaning that one are producting with a smalltalk besides developing with it. So, one should stop the car only if the costs of stopping are not too high. If one will have to stop several short (cheap) times probably will be no big deal. But what happen when you have a year of a non producting system? That could easily become inaceptable and you should provide alternatives. This is why people other than enthusiasts are still using Squeak with no optimizations at all but producing real value while others invest it's time in exploring new and experimental ways meant to be better ones of making Squeak to run, the future of Squeak. Anyway.. I really like to see a piece of software like you described to be materialized, Cheers, Sebastian _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Igor Stasenko
On Thu, 24 May 2007 16:38:20 +0200, sig wrote:
> On 24/05/07, Sebastian Sastre wrote: >> ... It's 'changing the tire in a running car'. For sustainable projects >> we can't 'stop the car'. Otherwise people will easily be demotivated and >> efforts become quickly diluted. > > Yes, sometimes you need to stop the car, because changing the tires > while driving is impossible. Have you considered using a ClassBox, available from SqueakSource. Let's change one of the tires while on at full speed: create a new ClassBox which includes all of your car. In that isolated box change the tire. If this works out fine, release the changes to the running car's ClassBox. A more practical Smalltalk example is to change the compiler in the running system, this needs the compiler. /Klaus _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Igor Stasenko
>From: sig <[hidden email]>
>Reply-To: "Discussion about Exupery a native code >compiler."<[hidden email]> >To: "Discussion about Exupery a native code >compiler."<[hidden email]> >Subject: Re: Introducing Huemul >Date: Thu, 24 May 2007 15:55:46 +0300 > >I want to be able the smalltalk VM to rebuild self from scratch >(producing new VM executable) without using C complier/e.t.c. +1. I think we are finally getting closer to a time when C wont be needed anymore. And this is something that is really needed for the reasons you mentioned (e.g. math overflow) and more. _________________________________________________________________ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07 _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Klaus D. Witzel
On 24/05/07, Klaus D. Witzel <[hidden email]> wrote:
> On Thu, 24 May 2007 16:38:20 +0200, sig wrote: > > On 24/05/07, Sebastian Sastre wrote: > >> ... It's 'changing the tire in a running car'. For sustainable projects > >> we can't 'stop the car'. Otherwise people will easily be demotivated and > >> efforts become quickly diluted. > > > > Yes, sometimes you need to stop the car, because changing the tires > > while driving is impossible. > > Have you considered using a ClassBox, available from SqueakSource. > > Let's change one of the tires while on at full speed: create a new > ClassBox which includes all of your car. In that isolated box change the > tire. If this works out fine, release the changes to the running car's > ClassBox. A more practical Smalltalk example is to change the compiler in > the running system, this needs the compiler. > can be used for hot-swapping VM at runtime . > /Klaus > > _______________________________________________ > Exupery mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery > _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Sebastian Sastre-2
> Yes, and, as I told you before I agree. But this does not give us more
VM is a program, which runs/interprets smalltalk. The innatural thing
> certainty of a way to do it in practice sustainably. The 'running car' > metaphore was meant to be read also meaning that one are producting with a > smalltalk besides developing with it. So, one should stop the car only if > the costs of stopping are not too high. If one will have to stop several > short (cheap) times probably will be no big deal. But what happen when you > have a year of a non producting system? That could easily become inaceptable > and you should provide alternatives. This is why people other than > enthusiasts are still using Squeak with no optimizations at all but > producing real value while others invest it's time in exploring new and > experimental ways meant to be better ones of making Squeak to run, the > future of Squeak. > is (as for me), that VM itself laying outside smalltalk universe and considered as low-level external entity to smalltalk image. I want to overthrow this concept, and move almost all VM functionality into smalltalk without losing speed, and by gaining a flexibility and scalability at same time. Without this, we doomed to be bound to C, and doomed having a static and rigid VM, hardly maintainable and even more hard to improve/experiment with. Just think about, if VM development speed can be compared to smalltalk dev speed. We can achieve a great progress in many areas in no time. For instance: while i studiyng different approaches for making GC, i saw that there at least two concepts which are never changes: Allocator and Mutator. Allocator is an entity, which keeps eye on system memory and interacts with one or more Mutators by giving them new memory chunks and recycling those which no longer in use. Now think about, if we have these concepts implemented in smalltalk as classes. Then a Process class is no longer something static and preset, its a Mutator and must follow only protocol rules, not anything else. As well as Allocator must follow own protocol rules, so we can have tons of allocators and tons of mutators living in same image and specialized for different tasks. All those 'multi-xxxx' problems which hard to even conceptualize in current system, in new system will be a toy to play with, so any dedicated 'hacker' can experiment very easily comparing to hacking C code for achieving some visible results. And concerning preserving an old standarts i'm totally agree with you. First what is needed is to make new system be 100% compatible for running anything which uses old ways. The trick is, that in old system you don't have any control on VM. You just have it and you can't change it behaviour. So, adding an ability to change and improve VM will not lead to change working smalltalk code, because currently they are perpendicular. Everything will be fine, except places where smalltalk code relies on some fixed things in VM. > Anyway.. I really like to see a piece of software like you described to be > materialized, > Thanks. I'm not first, who invents such approach, there already many talks and ideas in this area nowadays - create a self programming system. One of them are COLA/Pepsi project. I thinks this is a future of programming. And what is funny, that old smalltalk having a much stronger positions for achieving these goals comparing to current mainstream languages. _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Igor Stasenko
> > car's ClassBox. A more practical Smalltalk example is to change the
> > compiler in the running system, this needs the compiler. > > > Thanks for pointing out. I'll check details. I wonder if this > concept can be used for hot-swapping VM at runtime . > If the smalltalk is persistent it certainly could be feasible. In the other hand I find difficult to see two VM with hashes and instances assignations in sync for a clean swap. Cheers, Sebastian PS: by persistant I mean a smalltalk that has it's instances "living" in a persistent medium and the VM uses the RAM of the computer as a mere cache. Based on the blue book and with some theoretical guidelines from Guille here I've was able to make a prototype of a persistent ST for business objects (it didn't persist contexts and such) _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
On May 25, 2007, at 14:13 , Sebastian Sastre wrote: >>> car's ClassBox. A more practical Smalltalk example is to change the >>> compiler in the running system, this needs the compiler. >>> >> Thanks for pointing out. I'll check details. I wonder if this >> concept can be used for hot-swapping VM at runtime . >> > If the smalltalk is persistent it certainly could be feasible. In > the other > hand I find difficult to see two VM with hashes and instances > assignations > in sync for a clean swap. > > Cheers, > > Sebastian > PS: by persistant I mean a smalltalk that has it's instances > "living" in a > persistent medium and the VM uses the RAM of the computer as a mere > cache. > Based on the blue book and with some theoretical guidelines from > Guille here > I've was able to make a prototype of a persistent ST for business > objects > (it didn't persist contexts and such) That's how Gemstone Smalltalk works. It's got a transactional object memory on disk (arbitrary size) and you can run any number of VMs on that image concurrently ... pretty cool. - Bert - _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
> > Based on the blue book and with some theoretical guidelines from
Bert, yes, in fact the idea was to create the gemstone illusion because is
> > Guille here I've was able to make a prototype of a > persistent ST for > > business objects (it didn't persist contexts and such) > > That's how Gemstone Smalltalk works. It's got a transactional > object memory on disk (arbitrary size) and you can run any > number of VMs on that image concurrently ... pretty cool. > > - Bert - > > *the* way to work persistently with objects without too much interference. To complete that illusion it will need to implement something that help persisted objects to send async messages but I think it's possible. Also it will need optimizations to archieve better performance. To give you an idea, right now, without any optimization is better than using a remote image as server with rST. The main objetive is to allow smalltalkers to use smalltalk cleanly smalltalkishing and prevent them from entering the dark side of the use of smalltalk relationalish for persistent concerns. Also this opens the door to agresive horizontal scaling posibilities based on industry proven technologies. Cheers, Sebastian _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
In reply to this post by Bert Freudenberg
Bert Freudenberg writes:
> > Sebastian > > PS: by persistant I mean a smalltalk that has it's instances > > "living" in a > > persistent medium and the VM uses the RAM of the computer as a mere > > cache. > > Based on the blue book and with some theoretical guidelines from > > Guille here > > I've was able to make a prototype of a persistent ST for business > > objects > > (it didn't persist contexts and such) > > That's how Gemstone Smalltalk works. It's got a transactional object > memory on disk (arbitrary size) and you can run any number of VMs on > that image concurrently ... pretty cool. Magma does a similar thing for Squeak. Bryce _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
On May 25, 2007, at 22:17 , <[hidden email]> wrote: > Bert Freudenberg writes: >>> Sebastian >>> PS: by persistant I mean a smalltalk that has it's instances >>> "living" in a >>> persistent medium and the VM uses the RAM of the computer as a mere >>> cache. >>> Based on the blue book and with some theoretical guidelines from >>> Guille here >>> I've was able to make a prototype of a persistent ST for business >>> objects >>> (it didn't persist contexts and such) >> >> That's how Gemstone Smalltalk works. It's got a transactional object >> memory on disk (arbitrary size) and you can run any number of VMs on >> that image concurrently ... pretty cool. > > Magma does a similar thing for Squeak. Yeah, Magma is pretty cool, too :) - Bert - _______________________________________________ Exupery mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery |
Free forum by Nabble | Edit this page |