- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by StÃ©phane Ducasse

> > I would go so far as to say comments in tests are *especially* important. > It's sometimes hard to tell whether a failure is due to a faulty test, or an actual bug, when you have no idea (even when looking at the code) what case the test was actually written to cover. > With a comment of what the test was intended to do, you have a better feel for how to handle it. > > TL;DR: Intent, while obvious to whoever is writing the test, may not be so clear to whoever is around when it starts failing. > > Cheers, > Henry +1 >

Dec. 5, 2012

Re: [Pharo-project] using a long running native thread - NativeBoost or Plugin?

by Igor Stasenko

On 2 December 2012 23:59, drush66 <davorin.rusevljan(a)gmail.com> wrote: > Would it be possible to start native thread inside pharo? This thread would > run (for quite a long time) some event loop (like the libev), and post some > info to the SharedQueue. Smalltalk code would in turn be reading stuff from > this queue. You could say it would be pumping events from libev to > SharedQueue instance for Smalltalk code to consume. > > Is this doable? With NativeBoost or Plugin? > > I have also found some info on threaded VM, but if I understand it correctly > it seems more oriented to provide a thread to execute FFI call on it. > I have a prototype for worker thread loop implemented in NB.. The idea is to call some function in that thread and then signal a semaphore when call complete. And of course making VM thread to be 'owned' by non-main thread needs to be supported. The main problem with this approach is that some primitives/functions has to be invoked in main thread.. and to control that, it will require some work in VM/language side to fulfill such requirement. The hard part of it, that we have barrier between language and VM, and lack of coordination to manage and correct usage of native threads. -- Best regards, Igor Stasenko.

Dec. 5, 2012

Re: [Pharo-project] Open Source and Constraints | Documentation is King

by StÃ©phane Ducasse

On Dec 4, 2012, at 12:57 PM, Sven Van Caekenberghe wrote: > But I think we do agree ;-) > > What makes me value tests a bit above documentation (but not so much that I am saying that documentation is not important), are two things: > > - tests are machine enforceable/controllable > - you can find them exactly using senders or references sure I still want somebody to help with <testForDocumentation> idea. so that some tests are added to the documentation of package Stef > > On 04 Dec 2012, at 12:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Comments are ***REEEAALLLLY*** important because they help a guy reading the code to say yes you are smart and you got it right >> I will explain you why. >> >> Even writing comment in test is cool. >> >> Stef >> >>> Well written: >>> >>> http://kennethreitz.org/open-source-and-constraints.html >>> >>> I also find that writing documentation (minimal method/class comments or longer standalone documents) improves coding, because you take another perspective. I wouldn't value it above tests though. >>> >>> Sven >>> >>> -- >>> Sven Van Caekenberghe >>> http://stfx.eu >>> Smalltalk is the Red Pill >>> >> > >

Dec. 5, 2012

Re: [Pharo-project] Performance Tip: Using buffered streams

by Camillo Bruni

=> Xtreams and Pharo 3.0 ;) I think anything else is a major waste of time :P On 2012-12-05, at 14:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > one day we will have to address the old streams :) > > > On Dec 3, 2012, at 9:44 PM, Sven Van Caekenberghe wrote: > >> >> On 03 Dec 2012, at 19:24, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Yes, the lack of FileStream buffering was (re)-discovered and >>> corrected when I have experimented with my own SqueaXTream experiments >>> http://www.squeaksource.com/XTream/ before porting the original >>> Xtreams to Squeak http://www.squeaksource.com/Xtreams/ >>> Then Levente soon came up with an excellent patch for buffering Squeak >>> FIleStream and this was later ported to Pharo. >>> >>> What I also re-discovered is that not only buffering the raw file >>> counts, but also buffering the decoding. >>> Indded, an uncarefull implementation would read file by chunk but >>> decode byte after byte... >>> While a buffered one would decode large chunks of ASCII (if any) in a >>> single copy primitive. >>> >>> This was reported near the end of this post: >>> http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/151341 >>> >>> For Xtreams, I don't remember exactly where I put some experiments, >>> but pre-allocating a WideString instead of a String can also make a >>> noticeable difference in presence of WideCharacter... >> >> Many people seem to be rediscovering the same problems, not a good sign ;-) >> >> I think that in particular MultiByteFileStream>>#peek is not efficient. >> >> Yeah, there seems to be a WideString construction issue as well, I haven't looked into it yet. >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> > >

Dec. 5, 2012

Re: [Pharo-project] [Pharo-users] Legacy FileDirectory

by StÃ©phane Ducasse

thanks camillo Stef On Dec 4, 2012, at 11:20 PM, Camillo Bruni wrote: > I finally found the motivation to properly package my compatibility package. > > http://smalltalkhub.com/#!/~dh83/fisleg/packages/FileSystem-Legacy > > For people who want to migrate to 2.0 but depend on FileDirectory, they can > load this compatibility package for 2.0 which will add a mock FileDirectory. > It will mostly forward to FileReference. > > This is legacy software and should only be used for migration ;) > > best > cami >

Dec. 5, 2012

Re: [Pharo-project] using a long running native thread - NativeBoost or Plugin?

by StÃ©phane Ducasse

Hi eliot > > Would it be possible to start native thread inside pharo? This thread would > run (for quite a long time) some event loop (like the libev), and post some > info to the SharedQueue. Smalltalk code would in turn be reading stuff from > this queue. You could say it would be pumping events from libev to > SharedQueue instance for Smalltalk code to consume. > > Is this doable? With NativeBoost or Plugin? > > I have also found some info on threaded VM, but if I understand it correctly > it seems more oriented to provide a thread to execute FFI call on it. > > I wouldn't say that. The threading scheme is David Simmons' architecture, used in his AOS and S# VMs and similar to that used in the python VM, but more efficient. It allows multiple threads to share the VM, but only allows one to run Smalltalk at any one time. It is designed to allow Smalltalk to interact freely with any number of native threads. Cal-backs can come in from any thread. SMalltalk processes can be associated with specific threads, allowing one to control which thread a call-out is made on. do you know where we can read on that? Stef

Dec. 5, 2012

Re: [Pharo-project] Performance Tip: Using buffered streams

by StÃ©phane Ducasse

one day we will have to address the old streams :) On Dec 3, 2012, at 9:44 PM, Sven Van Caekenberghe wrote: > > On 03 Dec 2012, at 19:24, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Yes, the lack of FileStream buffering was (re)-discovered and >> corrected when I have experimented with my own SqueaXTream experiments >> http://www.squeaksource.com/XTream/ before porting the original >> Xtreams to Squeak http://www.squeaksource.com/Xtreams/ >> Then Levente soon came up with an excellent patch for buffering Squeak >> FIleStream and this was later ported to Pharo. >> >> What I also re-discovered is that not only buffering the raw file >> counts, but also buffering the decoding. >> Indded, an uncarefull implementation would read file by chunk but >> decode byte after byte... >> While a buffered one would decode large chunks of ASCII (if any) in a >> single copy primitive. >> >> This was reported near the end of this post: >> http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/151341 >> >> For Xtreams, I don't remember exactly where I put some experiments, >> but pre-allocating a WideString instead of a String can also make a >> noticeable difference in presence of WideCharacter... > > Many people seem to be rediscovering the same problems, not a good sign ;-) > > I think that in particular MultiByteFileStream>>#peek is not efficient. > > Yeah, there seems to be a WideString construction issue as well, I haven't looked into it yet. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Dec. 5, 2012

Re: [Pharo-project] PharoConf 2013 @ Bern?

by Hilaire Fernandes

Hello, So during the week days 4/4 to 8/4 ? Hilaire Le 05/12/2012 09:44, StÃ©phane Ducasse a Ã©crit : > Hello Pharoers > > The software composition group of the university of Bern proposed to organize the next pharo conf at berne during the week > of 2-3 of April 2013. We are really happy of this proposal. Now we would like to know what you think about it > before committing to the date and location. > > The Pharo board and crew >

Dec. 5, 2012

Re: [Pharo-project] The monkey is back in town

by Camillo Bruni

On 2012-12-05, at 10:05, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 05/12/2012 13:47, Esteban Lorenzano a Ã©crit : >> >> On Dec 5, 2012, at 1:21 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> >>> Sources are in my smalltalkhub repository: >>> http://smalltalkhub.com/#!/~dh83/ci >>> >>> On 2012-12-05, at 06:28, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> Le 05/12/2012 04:43, Camillo Bruni a Ã©crit : >>>>> I had a sudden urge to program something so I revived the monkey (partly) >>>>> >>>>> - full smalltalk implementation (no more ruby) >>>>> - basic command line handler (could be better but works..) >>>> >>>>> - using OSProcess with FileSystem-Legacy in 2.0 >>>> >>>> So that would be the way to have OSProcess in 2.0? >> >> "for now" :) >> OSProcess should load fine and without legacy when 2.0 is released > > +1. > > But I'm longing for the ability to integrate Pharo images in a mixed language git repository by loading in there a Makefile which: > > Builds a Pharo-based tool: > - downloads the latest Pharo image and vm > - loads the additional configurations and packages as setup (filetree, for example:)) on the command line... > - loads the local packages > - save the built image. > - install a startup shell in a bin/ or build/ directory, the image in a share/ or lib/ somewhere. > > I know I can do that in 2.0, but I need OSProcess... then I think you should be fine with the approach I took. I think once 2.0 is declared stable someone will take care of OSProcess. So looks like 2.0 almost covered all your needs, the only thing missing is the startup shell. Of course we can extend Pharo's command line tools a bit, they are still in early stage and need improvement.. > By the way, is this expected that the current directory in a Pharo image is not where the vm was started, but where the image file is kept? I have to use > > (PipeableOSProcess command: 'pwd') output asFileReference > > to get the true working directory. yeah, the whole working directory stuff is a mess: - FileSystem has it's own notion of working directory, - so does the rest of the Image, - the only one getting it more or less right is OSProcess :/ I wanted to unify it at some point, but well, too many things at the same time :P

Dec. 5, 2012

Re: [Pharo-project] The monkey is back in town

by Goubier Thierry

Le 05/12/2012 13:47, Esteban Lorenzano a Ã©crit : > > On Dec 5, 2012, at 1:21 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> Sources are in my smalltalkhub repository: >> http://smalltalkhub.com/#!/~dh83/ci >> >> On 2012-12-05, at 06:28, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> Le 05/12/2012 04:43, Camillo Bruni a Ã©crit : >>>> I had a sudden urge to program something so I revived the monkey (partly) >>>> >>>> - full smalltalk implementation (no more ruby) >>>> - basic command line handler (could be better but works..) >>> >>>> - using OSProcess with FileSystem-Legacy in 2.0 >>> >>> So that would be the way to have OSProcess in 2.0? > > "for now" :) > OSProcess should load fine and without legacy when 2.0 is released +1. But I'm longing for the ability to integrate Pharo images in a mixed language git repository by loading in there a Makefile which: Builds a Pharo-based tool: - downloads the latest Pharo image and vm - loads the additional configurations and packages as setup (filetree, for example:)) on the command line... - loads the local packages - save the built image. - install a startup shell in a bin/ or build/ directory, the image in a share/ or lib/ somewhere. I know I can do that in 2.0, but I need OSProcess... By the way, is this expected that the current directory in a Pharo image is not where the vm was started, but where the image file is kept? I have to use (PipeableOSProcess command: 'pwd') output asFileReference to get the true working directory. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dec. 5, 2012