- Pharo-dev - lists.pharo.org

[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

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

by Camillo Bruni

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? 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] [update 2.0] #20428

by Camillo Bruni

thanks marcus! On 2012-12-05, at 03:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20428 > ----- > > Issue 7097: VirtualMachine class improvements > http://code.google.com/p/pharo/issues/detail?id=7097 > > Issue 7095: Add GoferResolvedReference >> #merge method > http://code.google.com/p/pharo/issues/detail?id=7095 > > Issue 7096: Better option protocol for CommandLineHandler > http://code.google.com/p/pharo/issues/detail?id=7096 > > Issue 7094: Removing some Object methods > http://code.google.com/p/pharo/issues/detail?id=7094 > > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.997.diff > http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.487.diff > http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.752.diff > http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.65.diff > http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1297.diff > http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1263.diff > http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-MarcusDenker.189.diff > >

Dec. 5, 2012

[Pharo-project] PetitSmalltalk: portable number parsing

by Frank Shearar

I've attached a fix to PetitParser, using Number class >> #readSmalltalkSyntaxFrom: instead of Number class >> #readFrom:. The former selector makes clear the intention of reading a Smalltalk number. The latter selector means something slightly different in at least one Smalltalk: in Squeak, Number class >> #readFrom: is more "user facing" in the sense that it accepts a range of number representations that are not valid syntax. This change has no impact for Pharo because it has this selector: http://code.google.com/p/pharo/issues/detail?id=2063 (thanks to Nicolas Cellier). This fix makes PetitSmalltalk's tests all pass in Squeak. frank

Dec. 5, 2012

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

by Sven Van Caekenberghe

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). Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 5, 2012

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

by Stephan Eggermont

A better way would be to get all source from all the repositories and extract all method sends and symbols, compare that to the list you'd want to remove and mark the packages you don't want to be able to load anymore. You'd still miss some, but at least get a much better idea of impact Stephan

Dec. 5, 2012