April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Stupid question about Fuel

by Marcus Denker

On Apr 15, 2012, at 5:52 PM, David T. Lewis wrote: > > > There is no reason that a well-written package cannot be maintained for > several flavors of the image. That is a sign of competent developers doing > good work :) What I want to avoid is the following: Imagine we have X. But sadly, X is not easy to do in Squeak. Will we not do X *just because* it will be hard to port code using X to Squeak? Marcus -- Marcus Denker -- http://marcusdenker.de

April 15, 2012

Re: [Pharo-project] Stupid question about Fuel

by StÃ©phane Ducasse

On Apr 15, 2012, at 7:59 PM, phil(a)highoctane.be wrote: > I think that pharo serves a need. The need for something solid and free from restrictions related to software. > > Got interested in Smallatalk and Squeak quite a long time ago. But never moved past the toy-stage with them. Went homoiconic with Tcl and "OO" with the whole Java chain. > > With Pharo, there is a sense of progress, cleanliness, and will to push the boundary by making some hard choices. Thanks and I can tell you that we have more plans :) > And this made me interested in how things worked inside, and invest time and energy in making it a key target platform for my ideas-materialization activities in my business. Because business thrives on something solid, and innovation doesn't like arbitrary restrictions. > > Owning and mastering the whole chain from VM up to Image detail is huge. In Squeak, it is accretion. I think Pharo leans more towards the "crystallization" side of things. (Yep, I drank the kool-aid). > I'm not sure. But we want a system to invent the next one.THis is why we work on the bootstrap and soon on new class builder and first instance variable work of camillo and toon.

April 15, 2012

Re: [Pharo-project] Stupid question about Fuel

by StÃ©phane Ducasse

> I can't do Morphic games without grab Morphs with Halo. there are halos in Pharo. > A simple thing like my SmartTrashMorph ported to Cuis or to Pharo takes too > much time to do.

April 15, 2012

Re: [Pharo-project] Fuel, FuelMetalevel, FuelPackageLevel and "code" serialization Re: Stupid question about Fuel

by Mariano Martinez Peck

On Sun, Apr 15, 2012 at 8:40 PM, Francois Stephany < tulipe.moutarde(a)gmail.com> wrote: > Woaw Mariano, thanks *a lot* for this email ! > > No problem. I was thinking to add this explanation to the Fuel website.... > > On 15/04/12 06:41, Mariano Martinez Peck wrote: > >> Hi Edgar. The question is not stupid at all. I would like to clarify a >> little bit the packages involved in Fuel and how they are related to >> "code" serialization. Then I answer your question. >> >> _Fuel package_: This is the "core" of Fuel. It works as a general >> >> purpose serializer and all it does is serialize and materialize. If the >> graph you provide to serialize contains classes, they will all be >> considered as "global". That is, in serialization we just store its >> global name and during materialization we read the global name and we >> search it in Smalltalk globals. Therefore, classes have to be present in >> the image you are materializing. 99% of the users will be using this >> package. >> >> _FuelMetalevel package_: This is an extension to Fuel package and what >> >> it does is to add the knowledge of how to correctly serialize and >> materialize classes, traits, method dictionaries, compiled methods etc. >> It knows how to serialize a class and correctly materialize it. However, >> FuelMetalevel just do that: serialize and materialize. Nothing else. It >> does not send class side #initialize, it does not notify the system, it >> does not add the class to Smalltalk globals, no nothing. _ >> >> FuelPackageLoader package_: This was a quick prototype (proof of >> >> concept) we did with Martin mostly to see whether we were able to >> serialize packages with Fuel and to see if in the future we could >> replace or integrate with Monticello. Martin could finish the package >> just in time so that I could show in ESUG last year how we could load >> full seaside in 15 seconds. Anyway, this packages uses FuelMetalevel >> (and therefore Fuel) and what it does is to ADD the class into the >> system. That means sendind class side #initialize, add classes to >> Smalltalk globals, sends notifications, etc, etc, etc. As said, this >> package was a prototype, it still have lot of work to do and that's why >> we proposed it for GSoC. >> >> What Pavel used, and what you asked, is about FuelPackageLoader. So, >> first we justo to load such package when using ConfigurationOfFuel. You >> should load the group 'PackageLoaderWithTests' in Pharo. Notice that nor >> FuelMetalevel nor FuelPackageLoader works on Squeak nor Quis. At least, >> not by default. This is because in Pharo classes have traits, which were >> removed in Squeak. >> >> Regarding your question of how to serialize a package with >> FuelPackageLoader, it is something like this: >> >> FileStream forceNewFileNamed: 'Morphic.fuel' do: [:aStream | >> aStream binary. >> FLPackageStore new storeOn: aStream packageNamed: 'Morphic'.]. >> >> >> So far we do not have the granularity of claases in FuelPackageLoader, >> that is, the granularity is packages. >> >> Cheers, >> >> >> On Sun, Apr 15, 2012 at 1:24 PM, Marcus Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr**>> wrote: >> >> >> On Apr 15, 2012, at 1:20 PM, Edgar J. De Cleene wrote: >> >> > Mariano, Martin, Pavel >> > >> >> For example, a class can be considered either a global or a >> regular object. In >> >> the former case, it will be encoded just its name; in the latter >> case, the >> >> class will be encoded in detail, with its method dictionary, etc. >> > >> > How you do this ? >> >> the class will be encoded in detail, with its method dictionary, >> etc. >> > >> > I export most of 1.4 OneClick classes in >> http://squeakros.org/Pharo%**201dot4/<http://squeakros.org/Pharo%201dot4/> >> > as cs.gz, like to have .fuel for load classes back in target >> image with no >> > compiler. >> >> Of course that can not work. .cs is source code, you of course need >> a compiler >> (if Fuel could load cs.gz, it *would be* a compiler). >> >> What you need to do is to serialize the *Objects* that are code >> (Classes, MethodDictioaries, >> CompiledMethods) using Fuel. Then the result can be loaded back >> using Fuel. >> >> Marcus >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > -- > http://tulipemoutarde.be > CA: +1 778 558 3225 > BE: +32 65 709 131 > > -- Mariano http://marianopeck.wordpress.com

April 15, 2012

Re: [Pharo-project] Fuel, FuelMetalevel, FuelPackageLevel and "code" serialization Re: Stupid question about Fuel

by Francois Stephany

Woaw Mariano, thanks *a lot* for this email ! On 15/04/12 06:41, Mariano Martinez Peck wrote: > Hi Edgar. The question is not stupid at all. I would like to clarify a > little bit the packages involved in Fuel and how they are related to > "code" serialization. Then I answer your question. > > _Fuel package_: This is the "core" of Fuel. It works as a general > purpose serializer and all it does is serialize and materialize. If the > graph you provide to serialize contains classes, they will all be > considered as "global". That is, in serialization we just store its > global name and during materialization we read the global name and we > search it in Smalltalk globals. Therefore, classes have to be present in > the image you are materializing. 99% of the users will be using this > package. > > _FuelMetalevel package_: This is an extension to Fuel package and what > it does is to add the knowledge of how to correctly serialize and > materialize classes, traits, method dictionaries, compiled methods etc. > It knows how to serialize a class and correctly materialize it. However, > FuelMetalevel just do that: serialize and materialize. Nothing else. It > does not send class side #initialize, it does not notify the system, it > does not add the class to Smalltalk globals, no nothing. _ > > FuelPackageLoader package_: This was a quick prototype (proof of > concept) we did with Martin mostly to see whether we were able to > serialize packages with Fuel and to see if in the future we could > replace or integrate with Monticello. Martin could finish the package > just in time so that I could show in ESUG last year how we could load > full seaside in 15 seconds. Anyway, this packages uses FuelMetalevel > (and therefore Fuel) and what it does is to ADD the class into the > system. That means sendind class side #initialize, add classes to > Smalltalk globals, sends notifications, etc, etc, etc. As said, this > package was a prototype, it still have lot of work to do and that's why > we proposed it for GSoC. > > What Pavel used, and what you asked, is about FuelPackageLoader. So, > first we justo to load such package when using ConfigurationOfFuel. You > should load the group 'PackageLoaderWithTests' in Pharo. Notice that nor > FuelMetalevel nor FuelPackageLoader works on Squeak nor Quis. At least, > not by default. This is because in Pharo classes have traits, which were > removed in Squeak. > > Regarding your question of how to serialize a package with > FuelPackageLoader, it is something like this: > > FileStream forceNewFileNamed: 'Morphic.fuel' do: [:aStream | > aStream binary. > FLPackageStore new storeOn: aStream packageNamed: 'Morphic'.]. > > > So far we do not have the granularity of claases in FuelPackageLoader, > that is, the granularity is packages. > > Cheers, > > > On Sun, Apr 15, 2012 at 1:24 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > On Apr 15, 2012, at 1:20 PM, Edgar J. De Cleene wrote: > > > Mariano, Martin, Pavel > > > >> For example, a class can be considered either a global or a > regular object. In > >> the former case, it will be encoded just its name; in the latter > case, the > >> class will be encoded in detail, with its method dictionary, etc. > > > > How you do this ? > >> the class will be encoded in detail, with its method dictionary, > etc. > > > > I export most of 1.4 OneClick classes in > http://squeakros.org/Pharo%201dot4/ > > as cs.gz, like to have .fuel for load classes back in target > image with no > > compiler. > > Of course that can not work. .cs is source code, you of course need > a compiler > (if Fuel could load cs.gz, it *would be* a compiler). > > What you need to do is to serialize the *Objects* that are code > (Classes, MethodDictioaries, > CompiledMethods) using Fuel. Then the result can be loaded back > using Fuel. > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131

April 15, 2012

Re: [Pharo-project] Stupid question about Fuel

by phil＠highoctane.be

I think that pharo serves a need. The need for something solid and free from restrictions related to software. Got interested in Smallatalk and Squeak quite a long time ago. But never moved past the toy-stage with them. Went homoiconic with Tcl and "OO" with the whole Java chain. With Pharo, there is a sense of progress, cleanliness, and will to push the boundary by making some hard choices. And this made me interested in how things worked inside, and invest time and energy in making it a key target platform for my ideas-materialization activities in my business. Because business thrives on something solid, and innovation doesn't like arbitrary restrictions. Owning and mastering the whole chain from VM up to Image detail is huge. In Squeak, it is accretion. I think Pharo leans more towards the "crystallization" side of things. (Yep, I drank the kool-aid). Philippe 2012/4/15 Pavel Krivanek <pavel.krivanek(a)gmail.com> > Hi Edgar, > > some weeks ago I played with an idea to have Pharo Kernel as the base > of Squeak. I compared the images to see how much work it would > constitute. I found out two things: > - it would not require too much work. It would be not simple but it is > possible > - there is no reason to do that > > I can imagine Squeak as an extension of Pharo but I do not see the > purpose and target users of the resultant system. > > -- Pavel > > On Sun, Apr 15, 2012 at 2:15 PM, Edgar J. De Cleene > <edgardec2005(a)gmail.com> wrote: > > > > > > > > On 4/15/12 8:50 AM, "Marcus Denker" <marcus.denker(a)inria.fr> wrote: > > > >> I would not waste time with that... we will improve Pharo constantly, > and it > >> will > >> be very hard (if not impossible) to keep some kind of compatibility > layer on a > >> binary > >> code level between Pharo, Squeak and Cuis. > >> > >> And what do you get out of it? Wouldn't it be better to use the time to > >> improve one system > >> and make sure that system has a future? > >> > >> Marcus > > > > And if none of actual forks have all as I wish? > > All have some good and all have some problem for me. > > It's why try to learn from all here and all in Squeak and from Juan. > > > > Don't' sell me the fish, teach me to fishing. > > > > Edgar > > > > > > > > -- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges

April 15, 2012

Re: [Pharo-project] gamedev.net post asking about Smalltalk

by phil＠highoctane.be

Well, ever tried to setup a proper maven repository in Java? Metacello looks pretty clean in comparison to iBiblio and friends. Modularization is hard, no matter with what tool. Phil 2012/4/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Sig, > > Not intending to give you a hard time, but I went to the page, saw a -X > package, and started to wonder if that might be linux support. But FWIW, I > can't load any of it. The instructions failed, so I tried #load, and each > variant gives some kine of DNU error. Maybe I have an inconsistent set of > code loaded?? > > In the grander view, Metacello continues to be (IMHO) a bottomless well of > ever-changing load instructions. Either we need a reliable on-line grid > (for Pharo x.x.x load this way...), or perhaps the configurations should > carry (and automatically use) this type of information. I know it's not > easy, but if we are trying to attract new users, this type of complexity is > not going to help our cause. > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [ > siguctua(a)gmail.com] > Sent: Sunday, April 15, 2012 10:12 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] gamedev.net post asking about Smalltalk > > On 15 April 2012 14:46, askoh <askoh(a)askoh.com> wrote: > > Some is interested in using Smalltalk for prototyping of games. > > http://www.gamedev.net/topic/623380-game-programming-in-smalltalk/ > > > > I think we should respond very constructively on gamedev.net to entice > > gamers to try Smalltalk. Programmers are coming to appreciate dynamic > > languages and we can capitalize on that. > > > > can you respond (i'm not registered there), that we have NBOpenGL > :) > http://www.squeaksource.com/NBOpenGL.html > > as guy want, a low-level binding. > > there's even some videos made by Lawson English running the demo. > > > Go Smalltalk, > > Aik-Siong Koh > > > > -- > > View this message in context: > http://forum.world.st/gamedev-net-post-asking-about-Smalltalk-tp4559039p455… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > -- > Best regards, > Igor Stasenko. > > > -- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges

April 15, 2012

Re: [Pharo-project] Stupid question about Fuel

by Pavel Krivanek

On Sun, Apr 15, 2012 at 6:05 PM, Edgar J. De Cleene <edgardec2005(a)gmail.com> wrote: > > > > On 4/15/12 12:02 PM, "Pavel Krivanek" <pavel.krivanek(a)gmail.com> wrote: > >> I can imagine Squeak as an extension of Pharo but I do not see the >> purpose and target users of the resultant system. > > Today we read > >> Some is interested in using Smalltalk for prototyping of games. >> http://www.gamedev.net/topic/623380-game-programming-in-smalltalk/ >> >> I think we should respond very constructively on gamedev.net to entice >> gamers to try Smalltalk. Programmers are coming to appreciate dynamic >> languages and we can capitalize on that. >> >> Go Smalltalk, >> Aik-Siong Koh > > A ideal all purpose system IMHO is Pharo Kernel as base, with all new ideas > Pharo bring us. > > Cuis is the best implementation of Morph, but lacks compatibility. > You need re think all and make from zero > > Squeak is a mess, no doubt about. > But have necessary backwards compatibility (for me). > I can't do Morphic games without grab Morphs with Halo. > A simple thing like my SmartTrashMorph ported to Cuis or to Pharo takes too > much time to do. > > For young people like most here caring about Web 2.0, Pharo is the answer > and Markus is right, we need focus on better Pharo. > > But for old people like me, need responses NOW , and know wish more as Web > 2.0. > > When GsoC ends, several projects give me 95% of info for learn how to build > my ideal system. > > > As PharoKernel builder and developer, I ask for tutorials for fools. > > Cheers > > Edgar > As far as I remember, the last big discussion about Squeak and Pharo joining was "Meeting Report for 8/18/2010": http://forum.world.st/Meeting-Report-for-8-18-2010-tt2332389.html#none We may be happy that this two forks share the same virtual machine. I didn't see any real Squeak vision and nothing changed from that time. You may try to change it and convince Squeak community about some. Cheers, -- Pavel

April 15, 2012

Re: [Pharo-project] Stupid question about Fuel

by Mariano Martinez Peck

On Sun, Apr 15, 2012 at 5:52 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Sun, Apr 15, 2012 at 01:50:06PM +0200, Marcus Denker wrote: > > > > On Apr 15, 2012, at 1:44 PM, Edgar J. De Cleene wrote: > > > > > > And wish made experiments if this Foo.fuel could be loaded into > different > > > fork as Squeak, Cuis having Fuel into. > > > > I would not waste time with that... we will improve Pharo constantly, > and it will > > be very hard (if not impossible) to keep some kind of compatibility > layer on a binary > > code level between Pharo, Squeak and Cuis. > > > > And what do you get out of it? Wouldn't it be better to use the time to > improve one system > > and make sure that system has a future? > > Fuel seems to be well written and organized. Even though I have only used > Fuel a little (for remote task execution with OSProcess), I was able to > easily understand the code when I loaded it in Squeak. > > There is no reason that a well-written package cannot be maintained for > several flavors of the image. That is a sign of competent developers doing > good work :) > > Thanks Dave for the nice words :) At the beginning (first releases of Fuel) most answers and feedback from the community was "yet another serializer?" "why you have started again from scratch?" Now, some time later, people is slowly understanding why we have started from scratch ;) Cheers -- Mariano http://marianopeck.wordpress.com

April 15, 2012

Re: [Pharo-project] Stupid question about Fuel

by Edgar J. De Cleene

On 4/15/12 12:02 PM, "Pavel Krivanek" <pavel.krivanek(a)gmail.com> wrote: > I can imagine Squeak as an extension of Pharo but I do not see the > purpose and target users of the resultant system. Today we read > Some is interested in using Smalltalk for prototyping of games. > http://www.gamedev.net/topic/623380-game-programming-in-smalltalk/ > > I think we should respond very constructively on gamedev.net to entice > gamers to try Smalltalk. Programmers are coming to appreciate dynamic > languages and we can capitalize on that. > > Go Smalltalk, > Aik-Siong Koh A ideal all purpose system IMHO is Pharo Kernel as base, with all new ideas Pharo bring us. Cuis is the best implementation of Morph, but lacks compatibility. You need re think all and make from zero Squeak is a mess, no doubt about. But have necessary backwards compatibility (for me). I can't do Morphic games without grab Morphs with Halo. A simple thing like my SmartTrashMorph ported to Cuis or to Pharo takes too much time to do. For young people like most here caring about Web 2.0, Pharo is the answer and Markus is right, we need focus on better Pharo. But for old people like me, need responses NOW , and know wish more as Web 2.0. When GsoC ends, several projects give me 95% of info for learn how to build my ideal system. As PharoKernel builder and developer, I ask for tutorials for fools. Cheers Edgar

April 15, 2012