- Pharo-dev - lists.pharo.org

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

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

by askoh

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

April 15, 2012

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

by Guillermo Polito

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? 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 Guillermo Polito

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 On Sat, Apr 14, 2012 at 8:04 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Cog vm mappings are broken for the numpad. I the fix, but I have to > integrate it. Maybe tomorrow :$. > > > On Sat, Apr 14, 2012 at 8:00 PM, Nahuel Garbezza <n.garbezza(a)gmail.com>wrote: > >> Hi, >> >> I'm having this is issue in 1.3 too... I always forget to ask why >> >> Nahuel. >> >> >> On 14 April 2012 10:27, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch>wrote: >> >>> How stupid as it seems, numeric keyboard does not work under Linux and >>> several COG VM I tried on linux. Looks ok under Wine + Windows COG VM. >>> >>> How come? >>> >>> >>> -- >>> Dr. Geo -- http://www.drgeo.eu >>> >>> >>> >> >

April 15, 2012

Re: [Pharo-project] Stupid question about Fuel

by Marcus Denker

On Apr 15, 2012, at 2:11 PM, Edgar J. De Cleene 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. > Learning does not mean to be binary compatible. -- Marcus Denker -- http://marcusdenker.de

April 15, 2012