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

Re: [Pharo-project] Now you can use Fuel with FileSystem

by Nick Papoylias

Hallo Francois, The most stable package for distributed (or "remote" if you prefer) computing is rST in http://squeaksource.org/rST/ at the moment this is your best bet. I had provided some fixes in the past, but decided to experiment with a smaller code base, because *rST could not handle our heavy scenario*: * Parametrize all programming tools in pharo with the notion of an 'environment' (local or remote) * Distribute environments at will ;) So I' ve been working on and off with rTalk in http://squeaksource.org/rTalk/ (no custom VM or weirdies, works on top of zinc) -- but it's still rough around the edges. Nick On Sun, Jan 8, 2012 at 6:05 PM, Francois Stephany <tulipe.moutarde(a)gmail.com > wrote: > > That is awesome. > Do you know where does Nick commit his code ?! Is it in usable state > without too much preconditions (ie. no custom VM or other weirdies)? > > > Not exactly the same, but just to show you, in ESUG 2011 I showed how I >> could serialize a living debugger from one image, open it in another >> one, and continue debugging from there...having the state and >> everything. Then I also showed how I can save the state when an error >> happens (PharoDebug.fuel in addition to PharoDebug.log) into a file and >> debug it later on in the same or another image. In fact, Esteban >> Lorenzano was trying that for a real app. Instead of sending logs the >> client send a .fuel of the serialized context. >> >> Dave Lewis said Fuel could be used for RemoteTask: >> http://wiki.squeak.org:8080/**squeak/6176<http://wiki.squeak.org:8080/squeak/6176> >> >> Nick Papoylias (PhD just next to my desk haha) is working with rST and >> he may use Fuel as well for the serialization part. But not sure what he >> will exactly do with rST. He have several things in mind like remote >> debugging :) >> >> Maybe someone has done something more. That's all I know. >> > > >

Jan. 8, 2012

Re: [Pharo-project] [update 1.4] #14279

by Ben Coman

I was more curious about the process for the minor releases than pushing to get that particular fix into 1.3. It is somewhat cosmetic. Still thanks again. Benjamin wrote: > Concerning my changes, I think they can be applied as they are for 1.3. > > I will test that this evening > > > > Ben > > On Jan 8, 2012, at 1:23 PM, StÃ©phane Ducasse wrote: > > >> for each bug we assess whether it is important or not for the previous version and if this is the case >> we batch some changes for the previous version. >> Now this is a lot of work and really few people help or seem concerned so we do as much as we >> can and it makes sense. >> >> Now I guess that this is always the case: people have to decide. >> Then integrating a fix for a bug that has not been discovered after 10 months does not imply anything on the >> stability of the system. Pharo 1.3 is stable, as 1.2 was and as 1.4 is. >> >> >> Stef >> >> >>> StÃ©phane Ducasse wrote: >>> >>>> 14279 >>>> ----- >>>> >>>> - Issue 5157: Finder > Class > right-click > Hierarchy opens not on Class but on FinderClassNode. Tx Benjamin van Ryseghem. >>>> http://code.google.com/p/pharo/issues/detail?id=5157 >>>> >>>> >>>> >>> This was reported by me on Pharo-1.3-13315 yesterday and closed overnight, so I'm impressed with the response time. Now while this is hardly a critical issue I'm curious... now that it issue is marked closed, what is the plan to track these small fixes and roll them into a Pharo-1.3.1? Once you get the business support model up and running I would imagine this task falls to the paid engineers. (Release management is not exciting.) From a business perspective I would think that this is (almost) MORE important than the good refactoring work your doing to come out in a future version. >>> >>> There is a rule I've commonly seen in business to never use anything that is x.x.0. Wait for the "first service release" is the mantra. Seeing the versions go only from 1.3.0 to 1.4.0 to 1.5.0 does not instill business confidence in the stability of the platform. Maybe you are willing to sacrifice that image at this early stage to move faster with limited resources, but just something to consider. >>> >>> keep up the good work, >>> cheers, Ben >>> >>> >> > > > >

Jan. 8, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by ncalexan

fstephany wrote > > I'm also a bit lost between all the different options (plugins, > NativeBoost, FFI, Alien). > I also found this confusing, so let me tell my recent experience and my conclusion. I have written bindings to the SDL game programming library for use with Pharo. SDL is cross-platform, and I want to support Mac (most of all), Windows (one must), and Linux (if I must). As far as I can tell, Alien is not cross-platform and not maintained, so I have not spent time investigating it. Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs package which parses the relevant C header files and then writes either an NB or FFI callout class tree. I need to define a few structures, make a class pool with some constants, and then define lots of callouts, many of which take references to structures (like 'foo(struct x*)'). I was able to make both work, more or less, on my Macbook Pro, using stock Pharo 1.3 images and Igor's NBCog.app. I found NB to be a nicer programmer experience but I found that the FFI just works. There are a lot of gratuitous differences, but: * NB requires a VM compiled with a separate plugin (that I built from source with no trouble -- Igor has done splendid work with CMakeVMMaker). * NB should be faster than the FFI at pretty much everything, but I can't say since I haven't measured. * NB has useful primitives for determining if your external objects are still valid and for determining the current operating system (I intend to use these even if I don't use NB). * NB has very few tests and examples and essentially no documentation. * NB has a simple conceptual model, but it is still not as simple as the FFI model. * NB uses variableByteClasses to great advantage -- this is very cool. * NB makes it easy to crash your image, since you are evaluating native code in image. * NB is still, to my eye, raw and untested on Mac. I had problems with stack alignments in bizarre places, and NB's interaction with garbage collection basically ended my attempts to use it. * NB is basically impossible to debug if you aren't very strong with x86 assembly (I'm not even strong with x86 assembly), and the stack manipulations rendered GDB pretty much useless for me. * NB does not integrate well with the Pharo tools -- I think the MethodTrailers are screwing up references, implementors, and source views, but I haven't investigated. * NB does not seem to support indirections very easily -- I struggled to understand how to interface to foreign C functions with specs like 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and eventually gave up. I wanted to help Igor with the NB project, but the NB-OpenGL Mac bindings crash horribly for me, and although I was able to fix them, it I just don't hack enough x86 assembly to figure out all the tricks Igor is doing. The thought of making it all work on 3 platforms, and fix all the tool integration, was just too much for me. In conclusion, I prefer the FFI. It is old, cross platform, well tested, somewhat documented, and reliable. I think Igor has done some amazing work and I do not want to bash his project (and certainly not his code -- the man's a magician) but the fancy features are not necessary for my project. fstephany wrote > > Will this interface handle callbacks ? > I do not need callbacks so cannot speak to this issue. Yours, Nick Alexander -- View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 8, 2012

Re: [Pharo-project] Now you can use Fuel with FileSystem

by Mariano Martinez Peck

On Sun, Jan 8, 2012 at 6:31 PM, Francois Stephany <tulipe.moutarde(a)gmail.com > wrote: > Yep, Esteban's setup is a bit what I have now, rST and remote tools are > what I want. > Put it in the queue ;) > > If we had a bounty system I would even pay for this. =) > > > On 08/01/12 09:26, Mariano Martinez Peck wrote: > >> >> >> On Sun, Jan 8, 2012 at 6:05 PM, Francois Stephany >> <tulipe.moutarde(a)gmail.com <mailto:tulipe.moutarde@gmail.**com<tulipe.moutarde(a)gmail.com>>> >> wrote: >> >> >> That is awesome. >> Do you know where does Nick commit his code ?! Is it in usable state >> without too much preconditions (ie. no custom VM or other weirdies)? >> >> >> Hi Francois. For Nick I say "he may use Fuel as well for the >> serialization part" and "But not sure what he will exactly do with rST. >> He have several things in mind like remote >> debugging :)" >> So...I am not sure if he already did something. And if the did it, I >> don't know where it is. >> Maybe you rether to Esteban code? what is what you exactly want? >> >> Cheers >> >> >> >> Not exactly the same, but just to show you, in ESUG 2011 I >> showed how I >> could serialize a living debugger from one image, open it in >> another >> one, and continue debugging from there...having the state and >> everything. Then I also showed how I can save the state when an >> error >> happens (PharoDebug.fuel in addition to PharoDebug.log) into a >> file and >> debug it later on in the same or another image. In fact, Esteban >> Lorenzano was trying that for a real app. Instead of sending >> logs the >> client send a .fuel of the serialized context. >> >> Dave Lewis said Fuel could be used for RemoteTask: >> http://wiki.squeak.org:8080/__**squeak/6176<http://wiki.squeak.org:8080/__squeak/6176> >> >> <http://wiki.squeak.org:8080/**squeak/6176<http://wiki.squeak.org:8080/squeak/6176> >> > >> >> Nick Papoylias (PhD just next to my desk haha) is working with >> rST and >> he may use Fuel as well for the serialization part. But not sure >> what he >> will exactly do with rST. He have several things in mind like >> remote >> debugging :) >> >> Maybe someone has done something more. That's all I know. >> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > -- > http://tulipemoutarde.be > BE: +32 (0)65 709 131 > CA: +1 778 558 3225 > > -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2012

Re: [Pharo-project] Now you can use Fuel with FileSystem

by Francois Stephany

Yep, Esteban's setup is a bit what I have now, rST and remote tools are what I want. If we had a bounty system I would even pay for this. =) On 08/01/12 09:26, Mariano Martinez Peck wrote: > > > On Sun, Jan 8, 2012 at 6:05 PM, Francois Stephany > <tulipe.moutarde(a)gmail.com <mailto:tulipe.moutarde@gmail.com>> wrote: > > > That is awesome. > Do you know where does Nick commit his code ?! Is it in usable state > without too much preconditions (ie. no custom VM or other weirdies)? > > > Hi Francois. For Nick I say "he may use Fuel as well for the > serialization part" and "But not sure what he will exactly do with rST. > He have several things in mind like remote > debugging :)" > So...I am not sure if he already did something. And if the did it, I > don't know where it is. > Maybe you rether to Esteban code? what is what you exactly want? > > Cheers > > > > Not exactly the same, but just to show you, in ESUG 2011 I > showed how I > could serialize a living debugger from one image, open it in another > one, and continue debugging from there...having the state and > everything. Then I also showed how I can save the state when an > error > happens (PharoDebug.fuel in addition to PharoDebug.log) into a > file and > debug it later on in the same or another image. In fact, Esteban > Lorenzano was trying that for a real app. Instead of sending > logs the > client send a .fuel of the serialized context. > > Dave Lewis said Fuel could be used for RemoteTask: > http://wiki.squeak.org:8080/__squeak/6176 > <http://wiki.squeak.org:8080/squeak/6176> > > Nick Papoylias (PhD just next to my desk haha) is working with > rST and > he may use Fuel as well for the serialization part. But not sure > what he > will exactly do with rST. He have several things in mind like remote > debugging :) > > Maybe someone has done something more. That's all I know. > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225

Jan. 8, 2012

Re: [Pharo-project] Now you can use Fuel with FileSystem

by Mariano Martinez Peck

On Sun, Jan 8, 2012 at 6:05 PM, Francois Stephany <tulipe.moutarde(a)gmail.com > wrote: > > That is awesome. > Do you know where does Nick commit his code ?! Is it in usable state > without too much preconditions (ie. no custom VM or other weirdies)? > > Hi Francois. For Nick I say "he may use Fuel as well for the serialization part" and "But not sure what he will exactly do with rST. He have several things in mind like remote debugging :)" So...I am not sure if he already did something. And if the did it, I don't know where it is. Maybe you rether to Esteban code? what is what you exactly want? Cheers > Not exactly the same, but just to show you, in ESUG 2011 I showed how I >> could serialize a living debugger from one image, open it in another >> one, and continue debugging from there...having the state and >> everything. Then I also showed how I can save the state when an error >> happens (PharoDebug.fuel in addition to PharoDebug.log) into a file and >> debug it later on in the same or another image. In fact, Esteban >> Lorenzano was trying that for a real app. Instead of sending logs the >> client send a .fuel of the serialized context. >> >> Dave Lewis said Fuel could be used for RemoteTask: >> http://wiki.squeak.org:8080/**squeak/6176<http://wiki.squeak.org:8080/squeak/6176> >> >> Nick Papoylias (PhD just next to my desk haha) is working with rST and >> he may use Fuel as well for the serialization part. But not sure what he >> will exactly do with rST. He have several things in mind like remote >> debugging :) >> >> Maybe someone has done something more. That's all I know. >> > > > -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by Francois Stephany

I'm also a bit lost between all the different options (plugins, NativeBoost, FFI, Alien). Thanks for the clarification ! Will this interface handle callbacks ? On 08/01/12 04:37, StÃ©phane Ducasse wrote: > Hi Udo > > indeed this is a bit the mess :). > As soon as athens1.0 is out (planned for the end of the month). We will ask igor to clean the system. Our idea > is to provide one API where we can plug the two infrastructures > NativeBoost (we are writing a documentation too but I should pair write with igor so it goes slowly :( > With nativeBoost you can simply invoke C functions. For example the cairo binding is a good example to show how it works. The chapter is on the pharobooks inria gforge svn, I can send it to you if you want. > > FFI (when esteban arrives I would like to write the other chapter) and makes sure that FFI works also like a charm > on all the platforms. > > Stef > > > > >> All, >> >> what's the best way (at the moment& in the future) to call external libraries from Pharo. I'm a bit confused at the moment will all the stuff going around FFI, NativeBoost ... >> >> Is there maybe an abstraction layer above all those native-call mechanisms somewhere? >> >> Best Regards, >> >> Udo >> >> > > -- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225

Jan. 8, 2012

Re: [Pharo-project] Now you can use Fuel with FileSystem

by Francois Stephany

That is awesome. Do you know where does Nick commit his code ?! Is it in usable state without too much preconditions (ie. no custom VM or other weirdies)? > Not exactly the same, but just to show you, in ESUG 2011 I showed how I > could serialize a living debugger from one image, open it in another > one, and continue debugging from there...having the state and > everything. Then I also showed how I can save the state when an error > happens (PharoDebug.fuel in addition to PharoDebug.log) into a file and > debug it later on in the same or another image. In fact, Esteban > Lorenzano was trying that for a real app. Instead of sending logs the > client send a .fuel of the serialized context. > > Dave Lewis said Fuel could be used for RemoteTask: > http://wiki.squeak.org:8080/squeak/6176 > > Nick Papoylias (PhD just next to my desk haha) is working with rST and > he may use Fuel as well for the serialization part. But not sure what he > will exactly do with rST. He have several things in mind like remote > debugging :) > > Maybe someone has done something more. That's all I know.

Jan. 8, 2012

Re: [Pharo-project] [update 1.4] #14279

by Benjamin

Concerning my changes, I think they can be applied as they are for 1.3. I will test that this evening Ben On Jan 8, 2012, at 1:23 PM, StÃ©phane Ducasse wrote: > for each bug we assess whether it is important or not for the previous version and if this is the case > we batch some changes for the previous version. > Now this is a lot of work and really few people help or seem concerned so we do as much as we > can and it makes sense. > > Now I guess that this is always the case: people have to decide. > Then integrating a fix for a bug that has not been discovered after 10 months does not imply anything on the > stability of the system. Pharo 1.3 is stable, as 1.2 was and as 1.4 is. > > > Stef > >> StÃ©phane Ducasse wrote: >>> 14279 >>> ----- >>> >>> - Issue 5157: Finder > Class > right-click > Hierarchy opens not on Class but on FinderClassNode. Tx Benjamin van Ryseghem. >>> http://code.google.com/p/pharo/issues/detail?id=5157 >>> >>> >> This was reported by me on Pharo-1.3-13315 yesterday and closed overnight, so I'm impressed with the response time. Now while this is hardly a critical issue I'm curious... now that it issue is marked closed, what is the plan to track these small fixes and roll them into a Pharo-1.3.1? Once you get the business support model up and running I would imagine this task falls to the paid engineers. (Release management is not exciting.) From a business perspective I would think that this is (almost) MORE important than the good refactoring work your doing to come out in a future version. >> >> There is a rule I've commonly seen in business to never use anything that is x.x.0. Wait for the "first service release" is the mantra. Seeing the versions go only from 1.3.0 to 1.4.0 to 1.5.0 does not instill business confidence in the stability of the platform. Maybe you are willing to sacrifice that image at this early stage to move faster with limited resources, but just something to consider. >> >> keep up the good work, >> cheers, Ben >> > >

Jan. 8, 2012

Re: [Pharo-project] Small improvement for WriteStream >> nextPutAll:

by Nicolas Cellier

Yes it makes big differences when you mix ByteString/ByteArray for example... Or shouldn't we just let #replaceFrom:to:with:startingAt: do the job ? That's what I did in my own image in #next:putAll:startingAt:, I completely removed the test and it seems to work well. I then let #nextPutAll: invoke this one. I'm not completely sure that #replaceFrom:to:with:startingAt: will do the right thing with every pair of Collection class, but we are streaming on a restricted sub-hierarchy in practice. We should eventually test it. Nicolas 2012/1/8 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys. Some time ago Henry spot to us a small improvement for WriteStream >>> nextPutAll: that we are using in Fuel, but I think it can be general. > Henry comment was exactly: > > Also: For variableBytes classes, if you rewrite: > > WriteStream > nextPutAll: aCollection > > Â Â Â Â | newEnd | > Â Â Â Â collection class instSpec == aCollection class instSpec ifFalse: > Â Â Â Â Â Â Â [^ super nextPutAll: aCollection ]. > > Â Â Â Â newEnd := position + aCollection size. > Â Â Â Â newEnd > writeLimit ifTrue: > Â Â Â Â Â Â Â [self growTo: newEnd + 10]. > > Â Â Â Â collection replaceFrom: position+1 to: newEndÂ with: aCollection > startingAt: 1. > Â Â Â Â position := newEnd. > > Â Â Â ^ aCollection > > You can now pass all variableByte classes (Like ByteString) directly to a > stream with a ByteArray collection, and the replaceFrom:to:with: > startingAt: primitive will work correctly, just like the file primitive does > This means you don't need special Serializers for these either,Â using f.ex. > clunky nextStringPutAll: methods with manual asByteArray conversions. > > > So...if you agree, I can commit the patch. > > Let me know. > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 8, 2012