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

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

by Sebastian Nozzi

2012/12/1 Frank Shearar <frank.shearar(a)gmail.com>: > I'm not sure that's a limitation of the JVM (not being able to extend > classes, that is): in Clojure you can happily extend existing types > through extend-type: > > (extend-type clojure.lang.IPersistentVector > ComparableParser > (eq [this that] (reduce #(and %1 %2) (map eq this that)))) I'm no Clojure expert, but it looks like what you're doing is implementing an interface at runtime. If that's the case, the JVM has no problem doing that.

Dec. 1, 2012

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

by Sebastian Nozzi

2012/12/1 Marcus Denker <marcus.denker(a)inria.fr>: >> 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 then 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. Can you share what you have/had in mind...? I find it very interesting, and could be inspiring for others... > How can you do that if your main concern is "how do I get it to run on the JVM?". Well... you... don't... :-D I think it's not what the aim of Redline is. They want the language, some of its semantics (modifying classes of the fly should be supported, the author told me) and it should run on the JVM. It's a... pragmatic approach, if you want. I don't know what you guys do for a living - I used to program Java for the last 10 years, now I do Ruby at my current workplace; better, but still not Smalltalk. In order to extend and integrate with the current codebase I would even be grateful if there was, say, a Smalltalk-to-Ruby compiler. It would be nowhere the same as using Pharo, but it would be a start. But even then I don't know if my boss would approve (there's always the fear: "what happens once this dev is gone? who maintains his code?" - which is also sad, being Smalltalk so easy to pick up). > 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? What do you mean exactly by "dead"? (the "boring" I have no problem understanding ;-) As to mattering, well... it matters to the guys wanting to code Smalltalk and forced to do projects on a JVM basis... ;-) I think I agree with you that no great amount of innovation will come out of the JVM pretty much soon... maybe that's what you meant by "dead". It's just not the VM for innovative stuff. I, for example, am delighted about Cog, NativeBoost, Helvetia, distributed computation (like Croquet did?) etc. Very hard to do (or impossible) in a VM like the JVM... > I, personally, decided that there are more interesting > things to do. I also decided to give it a shot. And that's why when I see that one of the (if not *the*) goals of Pharo is to make possible to use Smalltalk professionally, it gave me hope. If I could program Smalltalk for a living, then... I would reach career nirvana. But for now I have to pay my bills :-( > Just imagine what you could build instead! I'm trying, and it looks good! :-) Cheers, Sebastian

Dec. 1, 2012

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

by Sebastian Nozzi

2012/12/1 Sven Van Caekenberghe <sven(a)stfx.eu>: > IMO, the secret of Smalltalk is a delicate combination of elements, take some out and the magic is gone. Fully agree. Only a "pure" or "classical" Smalltalk would give you that "magic", the true "experience". But I think, and hope, that the Redline developers are aware of that. I can imagine that they are trading off some of the "experience" in order to gain library support and toolchain integration (like deploying to heroku, in this case). > 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 â¦ Yes, ok, but you are comparing Java to Smalltalk, which is not the case. You have languages running on top of the JVM, like JRuby, that also kind of conform to the Smalltalk idea (no primitives, everything is an object, you can modify classes at runtime, extend/open them, etc.) > The question is: how much do you need for it to be this magical Smalltalk thing ? The question is: how much of the "magic" of Smalltalk can you live WITHOUT. If your answer is "zero" then Redline is clearly not for you ;-) > Objective-C is also clearly Smalltalk inspired, Being it a compied language, for me the experience is also lacking. > more so than Java, (dynamic typing / messaging) > but you can hardly call it a real Smalltalk system/experience. Yes, completely agree. For me just because it has to be compiled. The second I have to re-start the application to see the changes reflected the magic is gone. If I cannot interact with objects, add/remove methods/variables, change the class hierachy, etc. while running, the magick is gone. Nothing beats Smalltalk's "experience". Cheers, Sebastian

Dec. 1, 2012

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

by Sebastian Nozzi

Ok, wow. Didn't know that. So, whenever I change a class, I have both the old version and the new version co-existing? And then the instances are told to become: instances of the new class? Thanks for the info. 2012/12/1 Alexandre Bergel <alexandre.bergel(a)me.com>: >> 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

Dec. 1, 2012

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

by Frank Shearar

On 1 December 2012 19:36, 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. > > 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 â¦ I'm not sure that's a limitation of the JVM (not being able to extend classes, that is): in Clojure you can happily extend existing types through extend-type: (extend-type clojure.lang.IPersistentVector ComparableParser (eq [this that] (reduce #(and %1 %2) (map eq this that)))) comes from a library I'm working on. What's more, this extension is limited to this particular namespace. I _think_ this means that these extensions map selector namespacing. At any rate, you don't have the problems we have with overrides, because you can only use these functions when you import them (through require or use). > 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. Indeed, that is the interesting question. (I don't really know the answer. "Aliveness" is part of it, but even trying to define aliveness is tricky. frank > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Dec. 1, 2012

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