March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] LabelModel>>#text: Deprecation

by Nicolai Hess

2015-03-04 14:00 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > What is the reason for this? I searched the lists & fogbugz for "labelmodel > text" to no avail. To me, "label label: aString" seems odd. Why is this > better than "label text: aString"? > I think the idea behind this was, one common api for all widgets with a label CheckBoxModel /RadioButtonModel /ButtonModel .... all have a label: method. But of course, one can argue, a label itself has a text. > > In general, for refactors like this, where the purpose is not obvious as it > would be for a bug fix or new feature, it would be good to somehow link > somewhere for more info. Maybe the deprecation message, since by definition > will be deleted in the next verison, would be a good place to put an issue > number or url to a discussion. Also, might I humbly suggest having a native > English speaker review changes where the intent is to increase "clarity" so > we don't have another #ensureCreateDirectory incident ;) j/k... But a > grammar/idiom review would be super quick/easy. Maybe a tag or status in > fogbugz would help? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/LabelModel-text-Deprecation-tp4809424.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 5, 2015

Re: [Pharo-dev] LabelModel>>#text: Deprecation

by Nicolai Hess

2015-03-04 14:04 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Sean P. DeNigris wrote > > To me, "label label: aString" seems odd > > btw this fix broke LabelModel because #initialize still refers to the now > non-existent textHolder instVar instead of labelHolder > This is now fixed, but the deprecate warnings are annoying. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/LabelModel-text-Deprecation-tp4809424p4809426.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 5, 2015

Re: [Pharo-dev] Athens/Morphic

by stepharo

+1 Le 25/2/15 15:02, Igor Stasenko a Ã©crit : > Nice work, Nicolai > > Thank you for putting your hands on it! > > On 23 February 2015 at 23:47, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > No, it is not yet integrated. > but this should work with pharo 40501 > Merge (from pharo4 inbox): ConfigurationOfAthens-NicolaiHess.52 > ConfigurationOfAthens loadVersion:'2.9' > > AthensWrapWorldMorph new openInWorld > > > > 2015-02-23 23:09 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > I tried to load 2.9 from the athens repo into Latest update: > #40501 and I got > incompatibleLayoutConflict.... > because apparently I got some packages that were saved.... > > Well I got totally lost. > > > Le 23/2/15 23:06, stepharo a Ã©crit : >> >> Le 23/2/15 09:59, Nicolai Hess a Ã©crit : >>> Load the new configuration of athens (2.9) >> >> I could not find it in the ConfigurationBrowser or in the >> Pharo40 main repo. >> I thought that it was integrated in Pharo (I used the latest >> version 40501) >> >>> Open an AthensWorld: >>> AthensWrapWorldMorph new openInWorld >>> >>> >>> Drag and drop some morphs on this athens world. >>> (Nautilus /Old Workspace should fully work/ GT Inspector and >>> Playground not) >>> >>> >>> >>> 2015-02-23 9:51 GMT+01:00 stepharo <stepharo(a)free.fr >>> <mailto:stepharo@free.fr>>: >>> >>> how can I play with that? >>> >>> even if I should not. >>> >>> Le 20/2/15 08:54, Marcus Denker a Ã©crit : >>>> Very nice! Works here (on Mac). >>>> >>>> I will integrate as soon as the CI is up againâ¦ >>>> >>>> Marcus >>>> >>>>> On 19 Feb 2015, at 12:44, Nicolai Hess >>>>> <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>>>> >>>>> Most of this (without the test class >>>>> (AthensTestDisplay)) is now ready for >>>>> integration. >>>>> >>>>> A lot of changes for making Mophic and Text(Morphs) >>>>> work on Athens >>>>> (For testing purpose there is also the >>>>> AthensWrapWorldMorph included). >>>>> >>>>> The Canvas wrapper (AthensCanvasWrapper) is not yet >>>>> included and therefore >>>>> all Morphs that do not explicit have a proper >>>>> drawOnAthensCanvas method arent't drawn (or just like >>>>> rectangles). >>>>> >>>>> Should work with any image >= 40490 >>>>> Just load the latest ConfigurationOfAthens from pharo >>>>> 40 inbox and >>>>> load >>>>> ConfigurationOfAthens loadVersion:'2.9' >>>>> >>>>> If this is working (or not:) ) please leave a note on >>>>> fogbugz: >>>>> "14954 load new configuration 2.9 (more morphic support)" >>>>> >>>>> >>>>> nicolai >>>>> >>>>> >>>>> 2015-01-31 11:54 GMT+01:00 Alain Plantec >>>>> <alain.plantec(a)yahoo.com >>>>> <mailto:alain.plantec@yahoo.com>>: >>>>> >>>>> >>>>>> >>>>>> Yes the HandMorph is handled like any other >>>>>> Morph, it draws itself and >>>>>> after that it draws all its submorphs. (And >>>>>> actually it does not use any caching, and it is >>>>>> still quite fast) >>>>> >>>>> the same in Bloc, no caching and it works just fine :) >>>>> >>>>>> But yes, it needs a special drawOnAthens method. >>>>>> >>>>>> Do you plane to make a package for it ? >>>>>> I would like to integrate it in Bloc. >>>>>> >>>>>> >>>>>> What would like to integrate? >>>>> In fact I do not see any change when in Bloc. >>>>> So I guess I will have to adapt Bloc to your changes. >>>>> >>>>>> I will upload the changes in Athens-Morphic >>>>>> package to >>>>>> the Athens repository. >>>>> >>>>> cool. >>>>> >>>>> thanks >>>>> >>>>> Alain >>>>> >>>>> >>>> >>> >>> >> > > > > > > -- > Best regards, > Igor Stasenko.

March 5, 2015

Re: [Pharo-dev] Horizontal Wheel Events Broke Linux Word Jumping

by stepharo

Le 4/3/15 01:57, Sean P. DeNigris a Ã©crit : > Apparently, Ctrl+left/rightArrow, which used to move to the previous/next > word in an editor, now gets treated as a horizontal wheel event. The > offending code is in #generateKeyboardEvent:, but I find it incomprehensible > e.g. why is buttons bit shifted by 3? Why does Ctrl-leftArrow report > different modifiers than Ctrl alone? > > Before I dig in, is anyone familiar with Morphic events that can take a > quick peek? > > Thanks. > > p.s. I thought we had replaced the event buffers with real objects NO we had a proto and OSWindow arrived and we will use it instead. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Horizontal-Wheel-Events-Broke-Linux-Word-Jumping-tp48… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

March 5, 2015

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

by stepharo

we should ask a modeling expert. We have one in the team. Le 4/3/15 06:20, Ben Coman a Ã©crit : > Could someone explain why the "ToOne" and "ToMany" are the preferred > semantics for the class names versus OneRelatedTo or RelatedToOne ? > To me, "ToOne" feels like its describing the #directedMovies part. > I guess it makes sense if you are looking in towards #director. > cheers -ben > > On Fri, Feb 27, 2015 at 7:51 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > > On 27 Feb 2015, at 11:46, Jan van de Sandt <jvdsandt(a)gmail.com > <mailto:jvdsandt@gmail.com>> wrote: > > > > Hello, > > > > Thanks for your suggestions. I have improved the naming and > definition to this: > > > > Object subclass: #SlotExampleMovie > > slots: { > > #name. > > #year. > > #director => ToOneRelationSlot inverse: > #directedMovies inClass: #SlotExamplePerson. > > #actors => ToManyRelationSlot inverse: > #actedInMovies inClass: #SlotExamplePerson } > > classVariables: { } > > category: 'SlotAssociations-Tests-Example' > > > > Because it is for now just an example I haven't renamed the Slot > classes yet. > > > > Thanks! I will add the associations as examples to Pharo4 (today I > think) > > Marcus > > >

March 5, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by phil＠highoctane.be

Le 4 mars 2015 23:08, "Stephan Eggermont" <stephan(a)stack.nl> a Ã©crit : > > On 04/03/15 14:19, phil(a)highoctane.be wrote: > >> Interesting but not sure I'd like to have images going through >> decompression everytime I spin them up. >> Especially if there are a lot of the in a server. > > > 2GB/s is twice as fast as you can get from a fast SSD atm. > And as that is per core, that puts a boundary of starting > 2200 pharo images/s on a modern dual socket server. > After half a minute of that you run out of ram with a > 1.5TB ram machine. The bottlenecks might be elsewhere. There is no way an image starts that fast today. There is the delay thing that slows things down. > > > Norbert wrote: > > To be sure if you want that you have to test it. You have always take > into account that a smaller file will have less I/O to read from disk. > > +1 Ok. > > Stephan > > > > >

March 5, 2015

Reading an SQL db on OS X

by Alexandre Bergel

Hi! I would like to read a SQL .db file. The page http://smalltalkhub.com/#!/~PharoExtras/NBSQLite3 mention how to do this on Windows and Linux, but not on OSX. What should I do to read a SQL file on OS X? I tried google, but it did not work. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 4, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Stephan Eggermont

On 04/03/15 14:19, phil(a)highoctane.be wrote: > Interesting but not sure I'd like to have images going through > decompression everytime I spin them up. > Especially if there are a lot of the in a server. 2GB/s is twice as fast as you can get from a fast SSD atm. And as that is per core, that puts a boundary of starting 2200 pharo images/s on a modern dual socket server. After half a minute of that you run out of ram with a 1.5TB ram machine. The bottlenecks might be elsewhere. Norbert wrote: > To be sure if you want that you have to test it. You have always take > into account that a smaller file will have less I/O to read from disk. +1 Stephan

March 4, 2015

Re: [Pharo-dev] STHub is fast!!

by phil＠highoctane.be

indeed... feels much faster. Le 4 mars 2015 22:42, "Max Leske" <maxleske(a)gmail.com> a Ã©crit : > To whoever made STHub suddenly run fast: THANK YOU!! SOOOOO MUCH!! > > Max > >

March 4, 2015

Re: [Pharo-dev] strange bevahiour between three dependent Metacello configurations

by Stefan Reichhart

thanks cheers stef Am 04/03/15 um 18:58 schrieb Dale Henrichs: > Stef, > > You can use the `get` command in the Metacello scripting api[1] to force > a reload of a ConfigurationOf/BaselineOf. > > I don't think that the lastest version of Metacello is loaded into > Pharo4.0/Pharo3.0 so you probably should explicitly load Metacello[2] > (that'll work for Pharo4.0 and Pharo3.0) .... > > If you are going to use the Metacello scripting api, then you should be > using the scripting api for loading as well ... the scripting API > records the versions of projects that you've loaded into the image while > the old way of loading calculates the loaded version which is slow and > at times just plain wrong. > > Metacello new > configuration: 'GlamourCore'; > version: #development; > get; > load > > Refreshes the ConfigurationOfGlamourCore and then does the load. > > There is also a bit more documentation in the Metacello User Guide[3]... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr… > > [2] https://github.com/dalehenrich/metacello-work#pharo30 > [3] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > > > On 03/04/2015 08:57 AM, Stefan Reichhart wrote: >> Hi, >> >> We solved it but we could still need some help from you. >> >> Without using gofer to load/update metacello configurations >> manually/explicitly, is there a way to force metacello to update >> existing configurations to the very latest ones while metacello is >> loading a configuration ? >> >> Example: >> >> The dependencies of the configurations is as follows: >> ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + >> ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter >> ... >> Whereas ConfigurationOfGTInspectorCore, >> ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are already >> in a fresh Pharo 4 image (but outdated) >> >> Updating and loading "ConfigurationOfGToolkitCore" will only load >> itself and the latest packages that are defined by the configurations >> which are already in the image. But we would actually like to update >> those configurations (and their packages) as well. Otherwise the load >> would be "incomplete" (dependencies broken). >> >> Can Metacello do that ? Is there an easy way to do it ? Or is gofer >> the only solution ? >> >> How do you handle configurations that depend on other configurations >> (already loaded, but outdated) ? <-> Consistency of dependencies >> >> >> Thanks >> stef >> >> >> ---------- >> >> >> What we want is equivalent to the following snippet: >> >> { 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. >> 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. >> 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ >> :aConfigurationName | >> Gofer new >> smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; >> package: aConfigurationName; >> load ]. >> (ConfigurationOfGToolkitCore project version: #development) load. >> >> >> >> >> Am 04/03/15 um 14:53 schrieb Andrei Chis: >>> Hi, >>> >>> We fixed this but we are not sure if the behaviour that we got was a >>> result of a bug or a feature in Metacello. >>> >>> Again our setup is that we have three configurations with linear >>> dependencies between them: >>> -- ConfigurationOfGTInspectorCore (2.0-baseline) >>> -- ConfigurationOfGlamourCore (3.1-baseline) >>> -- ConfigurationOfRubric (0.2-baseline) >>> >>> In ConfigurationOfRubric we had version "1.2.8" that uses >>> '0.2-baseline'. >>> >>> The development version is '0.2-baseline' and the stable version '1.2.8' >>> >>> [1] (ConfigurationOfGlamourCore project version: #development) record >>> loadDirective >>> [2] (ConfigurationOfGTInspectorCore project version: #development) >>> record loadDirective. >>> >>> When performing [1] Metacello decides to load Rubric. >>> This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" >>> (since none was specified before) to figure out whether something should >>> be loaded. At a certain point this is executed: >>> >>> compareCurrentVersion:targetVersionStatus:using: (from above) >>> ... >>> ... >>> ... >>> ... >>> #allLoadedToSpec = #allLoadedToSpec ===> TRUE >>> "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline >>> [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE >>> ===> Rubric is not removed from the loader list >>> >>> When performing [2] Metacello decides not to load Rubric. >>> In this case Metacello deals first with #ConfigurationOfGlamourCore. But >>> after "GlamorCore" has been processed, the operator in the global >>> mcLoader is set to ">=". All further specs-to-load >>> (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now >>> rubric get's removed: >>> >>> compareCurrentVersion:targetVersionStatus:using: (from above) >>> ... >>> ... >>> ... >>> ... >>> #allLoadedToSpec >= #allLoadedToSpec ===> TRUE >>> "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline >>> [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE >>> ===> Rubric is removed from the loader list >>> >>> That's why "Rubric" doesn't show up in the final loader list. The second >>> (inner/nested) spec-to-load will remove it (after it has been >>> successfully resolved by the previous nested configuration >>> ConfigurationOfGlamourCore) because of the operator. >>> >>> So there is a difference between #ConfigurationOfGlamourCore and >>> #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded. >>> >>> Anybody else encountered this? >>> >>> Cheers, >>> GT team >>> >>> >>> >>> >>> On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei(a)gmail.com >>> <mailto:chisvasileandrei@gmail.com>> wrote: >>> >>> Hi, >>> >>> We are having the following problem when trying to update GTolols to >>> their latest version in the latest Pharo 4 image: Rubric does not >>> get updated. >>> We have: >>> >>> -- ConfigurationOfGTInspectorCore (2.0-baseline) >>> -- ConfigurationOfGlamourCore (3.1-baseline) >>> -- ConfigurationOfRubric (0.2-baseline) >>> >>> Performing [1] shows that rubric gets updated (atomic load : >>> 0.2-baseline [ConfigurationOfRubric]) >>> Performing [2] contains no trace of rubric. >>> >>> [1] (ConfigurationOfGlamourCore project version: #development) >>> record loadDirective >>> [2] (ConfigurationOfGTInspectorCore project version: #development) >>> record loadDirective. >>> >>> Loading then the inspector [3] does not update Rubric. >>> Loading just Glamour [4] updates it. >>> >>> [3] (ConfigurationOfGTInspectorCore project version: >>> #development) load. >>> [4] (ConfigurationOfGlamourCore project version: #development) load >>> >>> Any ideas or sugestions? Maybe we are missing something trivial. >>> This updates the previous configurations to their latest versions: >>> >>> Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; >>> package: 'ConfigurationOfGTInspectorCore'; load. >>> Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; >>> package: 'ConfigurationOfGlamourCore'; load. >>> Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; >>> package: 'ConfigurationOfRubric'; load. >>> >>> >>> Cheers, >>> Andrei >>> >>> >> > >

March 4, 2015