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

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

[Pharo-project] Roassal nested nodes withText

by roberto.minelli＠usi.ch

Hi guys, I'm using Roassal to build a visualization that looks like the following: http://www.xconomy.com/wordpress/wp-content/images/2012/11/skeuo-calendar.p… I create two ad-hoc layouts (i.e., extending the ROGridLayout) to individually layout days inside months and months inside years. I have a piece of code that looks something like: > view shape rectangle withText. > > view nodes: nodes forEach: [ :aGroupOfObjects | | innerNodes | > > innerNodes := do something with aGroupOfObjects. > ... > view shape rectangle size: 25; withCenteredText. > ... > view nodes: innerNodes. > view layout: ROMonthLayout new. > ] > > view layout: ROYearLayout new. > > view edges: ... Notice that I want the both the outer node (i.e., the month container) and the inner nodes (i.e., days) with labels. The problem is that when I set both nodes with labels the view takes time to be generated and interactions become impossible (i.e., the whole image actually becomes slow and you can no longer drag around shapes in the view). I explored the issue a little bit and discovered that it might be something related to ROShape>>chainedDrawOn:for: and the way Roassal handles shapes with "nested" shapes (i.e., when 'next' is not a RONullShape . I inspected one of my outer nodes and discovered that I have a chain such that 'outerNode next' is a ROLabel and the ROLabel has a ROChildrenShape as next and the next of the ROChildrenShape is a RONullShape . Have you ever experienced such a problem? Do you know how can I handle that? Do you see any potential problem in the snippet I posted above? Cheers and thanks in advance, Roberto

Dec. 5, 2012

Re: [Pharo-project] An excellent news

by Stephan Eggermont

Stef wrote: > We mentioned it in the past but now this is really official. To support the consortium, Inria is paying one full year > to Igor Stasenko. > > We want to thank Inria for its continuous support. Very good news. Thanks again for all your effort in realizing the Pharo Vision. Consortium membership is in the mail Stephan

Dec. 5, 2012

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

by Esteban Lorenzano

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 > > more or less: there is another deprecation warning coming from `Smalltalk osVersion` but it works... > You can check the ConfigurationOfCI to see how to include it from > > http://smalltalkhub.com/#!/~dh83/fisleg > > >>> the only thing missing are the couple of changes I proposed for the main image: >>> >>> - http://code.google.com/p/pharo/issues/detail?id=7097 >>> - http://code.google.com/p/pharo/issues/detail?id=7096 >>> - http://code.google.com/p/pharo/issues/detail?id=7095 >>> >>> once they are in, we're ready to roll >>> cami on fernet >

Dec. 5, 2012

Re: [Pharo-project] Some Object methods that could be removed ?

by Camillo Bruni

On 2012-12-05, at 07:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 05 Dec 2012, at 11:05, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> If the same holds true for the % of objects that are methods, you would probably remove around 90% depending on usage pattern during that particular week. > > Of course, just because there are no users doesn't mean that a method should be removed. > But there is just too much cruft on Object, SequenceableCollection, String, Integer, .. that does not belong there. > At least many of these less general methods should be packages as extensions. > > I am also sure that by 'using the image for a week', Camillo also meant running all tests, as well as building and running tests for major Pharo clients (@Stephan). yes of course :) my use-case would include something like - install a couple of huge configurations (here we should include all software that is important to us) - open all UI elements - run all tests and then removing the methods should not happen blindly, but reviewed.

Dec. 5, 2012

Re: [Pharo-project] An excellent news

by Camillo Bruni

awesome! On 2012-12-05, at 06:11, Jordi Delgado <jdelgado(a)lsi.upc.edu> wrote: > > Great!! > > Bests, > > Jordi > > > >> Hi guys >> >> We mentioned it in the past but now this is really official. To support the consortium, Inria is paying one full year >> to Igor Stasenko. >> >> We want to thank Inria for its continuous support. >> >> Stef >

Dec. 5, 2012