- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Vim Keys?

by StÃ©phane Ducasse

>> And here is where shortcuts come in handy.. > > Igor, you are not even using Command-Enter to search for classes/methods last time we sat togetherâ¦ ;-) :-) Imagine igor do not used refactoring :) > Like Command-Click on Class/method names, so cool and technically not keyboard shortcuts !

Dec. 1, 2012

Re: [Pharo-project] STON Update

by Sven Van Caekenberghe

On 01 Dec 2012, at 18:58, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > You mean FLLargeHashedCollection and subclasses? Yes: optimizeForLargeStructures self class environment at: #FLLargeIdentityDictionary ifPresent: [ :identityDictionaryClass | objects := identityDictionaryClass new ]. self class environment at: #FLSimpleStackstack ifPresent: [ :stackClass | stack := stackClass new ]

Dec. 1, 2012

Re: [Pharo-project] Vim Keys?

by StÃ©phane Ducasse

> We'll see. My problem right now is that I have dozens of projects that > steal my free time from getting into Smalltalk, but I'll fix that as > soon as I can. one a good attempt is invest in pharo and try to make money with projects you will build. We are really building bricks to support that. Stef

Dec. 1, 2012

Re: [Pharo-project] Vim Keys?

by StÃ©phane Ducasse

What we want is to clean all the hardcoded short cut and rethink all the them using key mapper Then people can define some maps and install them at wish. For example I miss end of line start of line (emacs like :)). I would like to have esc esc to select an expression so that I can do esc esc + cmd D and get done :) Stef

Dec. 1, 2012

Re: [Pharo-project] STON Update

by Mariano Martinez Peck

On Fri, Nov 30, 2012 at 11:39 PM, 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. > > You mean FLLargeHashedCollection and subclasses? > New users are always welcome. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 1, 2012

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