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

Re: [Pharo-project] About ArrayedCollection and at:/put:

by StÃ©phane Ducasse

On Nov 30, 2012, at 3:33 PM, Igor Stasenko wrote: > It says: > > "I am an abstract collection of elements with a fixed range of > integers (from 1 to n>=0) as external keys." > > now that leaves me clueless, why then it does not defines (introduces) > a protocol: > #at: > and > #at:put: > > at least as an abstract one , i.e. subclassResponsibility > > is it because they are already in Object protocol? And because > subclasses (like Array) using default #at: implementation? > > I don't know, but i think Object should not have #at:/#at:put: > protocol.. because: > - it applicable only to variable subclasses > - many classes have own implementation of it > - the behavior behind this is to access a variable fields . while > other classes use this protocol for higher abstractions (like > dictionaries) > > so, to my thinking, Object should not define this protocol.. for this > purpose we having #basicAt:/put: methods. > > btw, just an idea to clarify things even more, we could rename them to > variableAt: [put:] > (or any other name which properly tells that method provides an access > to variable fields of object). > + 1 > > -- > Best regards, > Igor Stasenko. >

Dec. 1, 2012

Re: [Pharo-project] [[ false ] whileFalse: [ ]] in workspace

by StÃ©phane Ducasse

Sebastian I can tell you that what you did is **useful** because we are all working like mad and such kind of help is really welcome. Stef On Dec 1, 2012, at 3:24 PM, Sebastian Nozzi wrote: > It's the #7076. > > 2012/11/29 Camillo Bruni <camillobruni(a)gmail.com>: >> perfect! can you open a bug report with this information? :) >

Dec. 1, 2012

Re: [Pharo-project] Comments in Packages?

by StÃ©phane Ducasse

Yes every package will have a manifest where we store first rules result then naturally the documentation. I would like to use a subset of SmallUML to describe some parts too. Stef On Dec 1, 2012, at 3:13 PM, Sebastian Nozzi wrote: > Dear Pharoers, > > by chance I read recently a comment from Stef that comments for > Packages are planned. > > Is this true? > > Would be a very welcome feature :-) > > Sometimes I load a package, or series of packages, from Monticello, > but have a hard time figuring out where to start. Through intuition, > trial and error I find the "core" package and then the "core" class > and then at the class side maybe there are examples, or look in the > documentation. But a better starting point would be of course > documentation (just a few lines) in the core package. > > Long story short, we need a way to compensate for the lack of > "README.txt" that file-based solutions have ;-) > > Also related: is there a way to execute a command after a > class/package is loaded by Monticello? Like opening a Workspace with > initial documentation? > > Thanks! > > Sebastian >

Dec. 1, 2012

Re: [Pharo-project] Vim Keys?

by Sean P. DeNigris

Igor Stasenko wrote > Pharo is open-source project. If you need it so > badly, then do it +100. This is really all there is to say. I *really* want vi bindings, because I am far more productive with them, so I started coding them (http://ss3.gemstone.com/ss/VimPharo.html) <rant> Of course, the instant I touched Paragraph/XxxEditor, and friends I got lost down the rabbit hole of incomprehensibility... like Paragraph, which draws the cursor and keeps track of the selection, obviously... not! wtf ?! Quick definition... paragraph |ËparÉËgraf| noun a distinct section of a piece of writing, usually dealing with a single theme and indicated by a new line, indentation, or numbering. Where, tell me, does it say anything about cursors and selections?? </rant> But Pharo is: - a gift - infinitely better than anything else I've ever worked with - and I've been told that the editor objects have been cleaned and were originally way more confusing So it is what it is. I'm taking a break, and will get back to it eventually. Any help is welcome and appreciated. Cheers, Sean -- View this message in context: http://forum.world.st/Re-Vim-Keys-tp4657381p4657594.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 1, 2012

Re: [Pharo-project] STON Update

by Sven Van Caekenberghe

On 30 Nov 2012, at 23:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Based on feedback by Norbert Hartl, Stuart Herring and Dale Hendrichs (thank you) I improved the current STON version a bit. > > http://ss3.gemstone.com/ss/STON > https://github.com/svenvc/ston > > Changelog: > > A nasty cycle bug was fixed > Performance was improved, especially for large structures. > Some implementation changes (recursion done using a stack, stonProcessSubObjects: optimized using stonContainsSubObjects) > > I did some stress/performance testing/tuning. Using > > STONTestMap classTreeExtended. > > to generate a structure mimicing the class hierarchy, with objects for all classes, about 7000 in my image and all methods, about 64000 in my image, with super/subclass and method owner links to create cycles. This results in a 7 Mb .ston file. > > The normal code, serializes this in 28 seconds and materializes it in 11.5 seconds. > The 'fast' versions (using ZnBuffered[Write|Read]Streams and Fuel Large Datastructures) does it in 1.1 and 3.8 seconds respectively. It occurred to me that I hadn't tried with Fuel (expecting it to be totally out of reach, since it is a binary protocol). Well, Fuel serializes my test structure in 5 seconds and materializes it in 1.2 seconds, the file being 6.4 Mb. Not bad for a textual protocol ;-) This does of course not proof a lot, results will depend on each specific use case. > New users are always welcome. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

Dec. 1, 2012

Re: [Pharo-project] About ArrayedCollection and at:/put:

by Camillo Bruni

On 2012-11-30, at 11:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > It says: > > "I am an abstract collection of elements with a fixed range of > integers (from 1 to n>=0) as external keys." > > now that leaves me clueless, why then it does not defines (introduces) > a protocol: > #at: > and > #at:put: > > at least as an abstract one , i.e. subclassResponsibility => definitely should be abstract > is it because they are already in Object protocol? And because > subclasses (like Array) using default #at: implementation? > > I don't know, but i think Object should not have #at:/#at:put: > protocol.. because: > - it applicable only to variable subclasses > - many classes have own implementation of it > - the behavior behind this is to access a variable fields . while > other classes use this protocol for higher abstractions (like > dictionaries) > > so, to my thinking, Object should not define this protocol.. for this > purpose we having #basicAt:/put: methods. yup I think the same way. Happened to already too many times that I call #at:put: on a random object and to my surprise it worked :P > btw, just an idea to clarify things even more, we could rename them to > variableAt: [put:] > (or any other name which properly tells that method provides an access > to variable fields of object). on simple collections: #at:put: => #basicAt:put: on normal objects: #fieldAt:put => #basicAt:Put: I prefer fieldAt: since it is not always the instance variable you access like on variableSized objects where you simply access an item. Also it goes along the naming convention we had in our slot paper ;)

Dec. 1, 2012

Re: [Pharo-project] Changes in announcements

by Camillo Bruni

nice! On 2012-11-30, at 10:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks ezequiel. > > Stef > > On Nov 27, 2012, at 11:09 AM, Ezequiel Lamonica wrote: > >> Hi, >> >> >> >> >> I was reviewing with Esteban about the lack of some announcements in the system and some bugs in other ones. >> >> I've been working on that for this week. >> >> This is the list: >> >> -MethodRename >> -Snapshot >> -Session (i don't know if this is necessary) >> -VariableAdded (one for every kind) >> -VariableRemoved (one for every kind) >> -Protocols (add/modif/remove/rename) >> -TraitComposition >> - When a package is created, the announcement is not released >> This only happens when a class is created with that category. >> -When I modify a class and also I change its category, then only class recategorized announcement is sent >> -Package removed is not sent > >

Dec. 1, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by Camillo Bruni

On 2012-11-30, at 18:15, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > camillo > > one of the problem that we have is that the refactoring stopped in the middle > because displayProgressFrom: minVal to: maxVal during: workBlock now works with job and this is nice > but job requires but all the user of displayProgressFrom: minVal to: maxVal during: workBlock > are using bar current: aNumber and not a value between 0 and 1.0. > > So this means that we will a lot of broken code. > Am I correct? right now Job works still with min/max/current so I still have to do the full transition. Ideally no code will be broken, since most people use progress bars via one of the public interfaces, either on String, Collections or directly on the UI Manager. => these will be the main places to change it. I think I can have a look at it today or tomorrow and finish the refactoring.

Dec. 1, 2012

Re: [Pharo-project] [[ false ] whileFalse: [ ]] in workspace

by Sebastian Nozzi

It's the #7076. 2012/11/29 Camillo Bruni <camillobruni(a)gmail.com>: > perfect! can you open a bug report with this information? :)

Dec. 1, 2012

[Pharo-project] Comments in Packages?

by Sebastian Nozzi

Dear Pharoers, by chance I read recently a comment from Stef that comments for Packages are planned. Is this true? Would be a very welcome feature :-) Sometimes I load a package, or series of packages, from Monticello, but have a hard time figuring out where to start. Through intuition, trial and error I find the "core" package and then the "core" class and then at the class side maybe there are examples, or look in the documentation. But a better starting point would be of course documentation (just a few lines) in the core package. Long story short, we need a way to compensate for the lack of "README.txt" that file-based solutions have ;-) Also related: is there a way to execute a command after a class/package is loaded by Monticello? Like opening a Workspace with initial documentation? Thanks! Sebastian

Dec. 1, 2012