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

Re: [Pharo-project] Stupid question about Fuel

by David T. Lewis

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 :) Dave

April 15, 2012

Re: [Pharo-project] Stupid question about Fuel

by Pavel Krivanek

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 > > >

April 15, 2012

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

by Schwab,Wilhelm K

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.

April 15, 2012

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

by Igor Stasenko

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.

April 15, 2012

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

by Edgar J. De Cleene

On 4/15/12 10:41 AM, "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > 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. > Thanks for clarify, and I have Fuel working on Squeak. Not on Cuis, yet > 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, I read all you and Martin made in GSoC. Good luck Very thanks Edgar

April 15, 2012

[Pharo-project] [issue tracker] cleaned up pre-defined Milestones

by Marcus Denker

Hi, I cleaned up the pre-defined Milestone- tag on the issue tracker. -> removed all tags for milestones that don't see any new changes. (the tags set on old issues stay, so searching is not impacted) -> renamed 1.5 to 2.0 (next major release) So now we just have pre-defined tags for 1.3, 1.4 and 2.0 Marcus -- Marcus Denker -- http://marcusdenker.de

April 15, 2012

Re: [Pharo-project] InternetConfigPlugin for unix - [WAS]Tips to create a plugin with specific platform dependant stuff

by Marcus Denker

On Apr 15, 2012, at 3:47 PM, Guillermo Polito wrote: > > Another option is to write this using FFI, but then I'm not so sure what should be part of the core and what not. I.e. should FFI be part of the Core? > Yes, it should be. Marcus -- Marcus Denker -- http://marcusdenker.de

April 15, 2012

Re: [Pharo-project] InternetConfigPlugin for unix - [WAS]Tips to create a plugin with specific platform dependant stuff

by Guillermo Polito

On Sun, Apr 15, 2012 at 2:37 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Bump :) > > I've been working last week a bit on the internet plugin to fetch some > system proxy configuration in unix. > > Since > > - the plugin is external > - it loads gconf libraries using dlopen, so the libraries are not needed > during compilation nor running > - if gconf library is not found, looks at the http-proxy and ftp-proxy env > vars. > > It should break nothing :P > > But I'm not an expert :/. > > What do you think? Is it worth of integration? > Another option is to write this using FFI, but then I'm not so sure what should be part of the core and what not. I.e. should FFI be part of the Core? > > Guille > > On Mon, Apr 9, 2012 at 4:38 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> ok, >> >> I did this: >> - configured the plugin as external >> - created >> >> CogFamilyUnixConfig>>configureInternetConfigPlugin: maker >> super configureInternetConfigPlugin: maker. >> maker addPlatformSources: #( 'sqUnixInternetConfiguration') >> >> and put the file attached in /platforms/unix/plugins/InternetConfigPlugin. >> I finally used dlopen to load gconf dinamically and check if it is >> available, and if it's not, I check the env vars with getenv(). >> >> If someone can do a little review, it would be nice :). >> >> Guille >> >> >> On Sun, Apr 8, 2012 at 9:55 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Haha! :) >>> >>> You won me :). I was about to reply this: >>> >>> "Ok, so I talked with Esteban today :). And thanks to him I reached the >>> conclussion that this plugin should be external." >>> >>> I'll spend some hours tomorrow to finish it. >>> >>> Now, as I think it happens with the ssl plugin... Where should we put >>> the code and what should I in order to get it easily integrated in the ci >>> buildings? :) >>> >>> Thanks! >>> Guille >>> >>> >>> On Sun, Apr 8, 2012 at 9:46 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> On 7 April 2012 17:55, Guillermo Polito <guillermopolito(a)gmail.com> >>>> wrote: >>>> > Was playing in my weekend on the InternetConfigPlugin for ubuntu. And >>>> > that's the problem :), It uses gnome2 stuff to access the system >>>> > configuration (because gnome handles it's own configuration... :/). >>>> > >>>> > Now, I made it work doing something like this in vmmaker: >>>> > >>>> > CogFamilyUnixConfig>>configureInternetConfigPlugin: maker >>>> > "extra rules for InternetConfigPlugin" >>>> > >>>> > super configureInternetConfigPlugin: maker. >>>> > maker addDefinitions: '`pkg-config --libs --cflags gtk+-2.0 >>>> gconf-2.0`'. >>>> > maker addExternalLibrary: '/usr/lib/libgconf-2.so.4'. >>>> > maker addPlatformSources: #( 'sqUnixInternetConfiguration.c'). >>>> > >>>> > And adding it in the list of internal plugins for Unix. >>>> > >>>> > But this should only compile and work on a system with gconf and stuff >>>> > installed :). >>>> > >>>> Then don't make this plugin internal, but external instead. Because if >>>> library is missing, >>>> VM will refuse to start. In contrast, if your plugin will be in >>>> external module, then module will refuse to load >>>> if lib is missing. >>>> >>>> > So, how does or should vmmaker and vm building process handle >>>> something like >>>> > this? >>>> > >>>> >>>> The philosophy of CMake configurations is to be concrete and without >>>> conditionals. I.E. they should >>>> not contain "if this, do this, if that do that" , instead if you have >>>> such choice, one should make another configuration. >>>> >>>> There is no way to predict how different is platform on which you >>>> building VM from platform where it used (especially in case of unix >>>> systems and their numerous flavors). So, what is working on your OS, >>>> could not work on another. That's why i don't see a point to put >>>> conditionals in build process. >>>> >>>> In contrast, if you have a concrete configuration, which says: if you >>>> want to build me, you should have this, this and this, and if you want >>>> to use the built artifact you should have this, this and this >>>> installed, then it makes things much more predictable and >>>> straightforward. >>>> >>>> >>>> > Guille >>>> > >>>> > _______________________________________________ >>>> > VM-beginners mailing list >>>> > VM-beginners(a)lists.squeakfoundation.org >>>> > http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners >>>> > >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >

April 15, 2012

Re: [Pharo-project] Pharo one click 1.4 and Linux COGVM

by Nahuel Garbezza

On 15 April 2012 09:27, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I've uploaded the fix to https://gitorious.org/cogvm/blessed > > Now, have to wait for the new build in here: > > https://ci.lille.inria.fr/pharo/job/Cog%20Git%20Tracker/ > > https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-VM/Architecture=32,OS=linu… > > Guille > > Thanks Guille!

April 15, 2012

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

by Mariano Martinez Peck

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>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

April 15, 2012