- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Redline Smalltalk on heroku ....

by Marcus Denker

On Dec 1, 2012, at 8:36 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Nov 2012, at 23:33, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > >> I think Redline is not trying to be a full-fledged Smalltalk (not like >> the Squeak port to the JVM). It is more in the spirit of Amber. A >> Smalltalk-to-Java compiler, with some underlying runtime support. It >> does not aim at supporting the full enchilada :-) > > IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone. > Another aspect is that what got me hooked to Squeak back than was the idea to go further than Smalltalk. To take what humanity learned since 1978, to take the hardware advances, and to build a system that is Smalltalk by *Spirit*, yet just *much* *much* more so. How can you do that if your main concern is "how do I get it to run on the JVM?". And why does it matter? In 2000, Java was hype. Now Java is the new Cobol. Do I want to spend the rest of my live to get a dead language to run on a boring platform? I, personally, decided that there are more interesting things to do. Just imagine what you could build instead! Marcus

Dec. 1, 2012

Re: [Pharo-project] Redline Smalltalk on heroku ....

by Sven Van Caekenberghe

On 30 Nov 2012, at 23:33, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > I think Redline is not trying to be a full-fledged Smalltalk (not like > the Squeak port to the JVM). It is more in the spirit of Amber. A > Smalltalk-to-Java compiler, with some underlying runtime support. It > does not aim at supporting the full enchilada :-) IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone. Java/JVM makes a distinction between int and Integer (and so on), cannot add methods to closed classes, has some meta capacity but not all, needs much more typing, cannot change many things at run time, and so â¦ The question is: how much do you need for it to be this magical Smalltalk thing ? Objective-C is also clearly Smalltalk inspired, more so than Java, (dynamic typing / messaging) but you can hardly call it a real Smalltalk system/experience. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 1, 2012

Re: [Pharo-project] STON Update

by Sven Van Caekenberghe

On 01 Dec 2012, at 19:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > BTW, which stream class you use for the bench? Well, the 'fast' variants do two things: - use the Fuel datastructures - use ZnBuffered[Read|Write]Streams The underlying stream is a MulitByteFileStream. The buffering makes a huge difference, in both directions. I plan to write a separate mail message about that ;-)

Dec. 1, 2012

Re: [Pharo-project] Redline Smalltalk on heroku ....

by Alexandre Bergel

> Are there some vital things that are impossible if #become: is > missing? (no irony in my question, I just don't know) Changing a class on the fly. #become: is used behind the scene Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 1, 2012

Re: [Pharo-project] CogVM crash code

by StÃ©phane Ducasse

Thanks a lot Jon! I saw that eliot provided a fix. Stef On Nov 30, 2012, at 6:07 PM, Jon Anderson wrote: > Hi all, > > I don't post to lists often, but I thought some of you might be > interested in these few lines of code that crash the CogVM on both > Linux and Windows. File-in the Smalltalk code below, then evaluate > [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or > [56+98]. I put the code on nil, but that is not important either. I > think the important thing is that the primitive (+ or -) is evaluated > but the result is not assigned into any variable. Also important is > that the code is put into a loop that I assume has been JIT optimized. > The image I used is Pharo 1.4 one-click with latest update #14459. > This code does not crash StackVM. Have fun! - Jon. > > !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! > crashCogVM > " Evaluate [ > nil crashCogVM ]" > > | i | > i := 20. > 1 to: i do: [:d | 1-1 ] > ! ! >

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) > > Yes, using a stack is also a good idea :) Good to see you are tacking some of the Fuel code/ideas to improve STON. It is awesome to have both, a fast binary and text serializers :) > 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. > > 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] Vim Keys?

by StÃ©phane Ducasse

On Dec 1, 2012, at 6:10 PM, Sean P. DeNigris wrote: > 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> One day we will hang and bury paragraph editor. When I did BotsInc I got burned also :) We will have to fix it for real :) > > 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 Mariano Martinez Peck

On Sat, Dec 1, 2012 at 7:02 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 ] > > Excellent :) -- Mariano http://marianopeck.wordpress.com

Dec. 1, 2012

Re: [Pharo-project] Vim Keys?

by StÃ©phane Ducasse

>> the explanation is much easier than you think: > in my dev image, which i didn't updated for a while, this function is > non-existent. > i find myself that, time to time i pressing this magic key > combination, get nothing.. and then enduring and continue the old way. > :) good try to find an excuse :) You should build more often your image :) > but from other side, i bet you're not using my little patch to treat > multiple white-space characters as a single > entity for cursor movement, while i enjoying it :) Soon we will introduce it. By the way does it impact just the smalltalkEditor or the textEditor? Since we want to see how AST can help. >> Like Command-Click on Class/method names, so cool and technically not keyboard shortcuts ! >> > yes i like it.. but same issue: i do not change images that often. > > >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> > > -- > Best regards, > Igor Stasenko. >

Dec. 1, 2012

Re: [Pharo-project] STON Update

by Mariano Martinez Peck

On Sat, Dec 1, 2012 at 6:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 ;-) > > So 5.6x for serializing and 9.5x for materializing. Similar stream result. So, yes, not bad :) SIXX was way slower from what I remember. Don't have time now but I will check your STONTestMap classTreeExtended ... BTW, which stream class you use for the bench? > 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 > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 1, 2012