- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

On Dec 1, 2012, at 10:19 PM, Sebastian Nozzi wrote: > You're right, sorry :-) :) > > 2012/12/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi guys >> >> just for your information this mailing-list is Pharo-development. You can discuss a lot of topics in Pharo-users >> but in Pharo-dev we would really appreciate to get a bit focused. >> I try to read all the mails to be able to help people but it means processing a lot of mails :) >> and I really have a lot of duties that are not pharo related and I would appreciate to get my pharo time for pharo. >> >> Stef >> >> >> On Dec 1, 2012, at 9:52 PM, Alexandre Bergel wrote: >> >>>> 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? >>> >>> Yes >>> >>> Alexandre >>> >>>> >>>> 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 >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>

Dec. 1, 2012

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

by Sebastian Nozzi

You're right, sorry :-) 2012/12/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > just for your information this mailing-list is Pharo-development. You can discuss a lot of topics in Pharo-users > but in Pharo-dev we would really appreciate to get a bit focused. > I try to read all the mails to be able to help people but it means processing a lot of mails :) > and I really have a lot of duties that are not pharo related and I would appreciate to get my pharo time for pharo. > > Stef > > > On Dec 1, 2012, at 9:52 PM, Alexandre Bergel wrote: > >>> 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? >> >> Yes >> >> Alexandre >> >>> >>> 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 >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >

Dec. 1, 2012

Re: [Pharo-project] Combining Regular Monticello with Github/FileTree

by StÃ©phane Ducasse

HI camillo I should release the changes I did: I grouped Job related classes into Kernel-Job and all the progressBar related class into Morphic-Progressbar and this is cool to get them grouped like that. Stef On Nov 30, 2012, at 11:25 PM, Camillo Bruni wrote: > > On 2012-11-30, at 19:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> I have been using both Github/FileTree and Monticello for STON this week, and things have definitively progressed. Thank you, Dale & friends. >> >> It does seem that I have to save a version to Github/FileTree first and then copy it to Monticello (ss3) and not the other way around - otherwise things seem to get messed up. So Github/FileTree is sticky ;-) >> >> Sven >> >> PS: in th FileTree code that I am using (from Metacello/Pharo 2.0) there is a small UI problem: >> >> SmallInteger>>/ >> Job>>progress >> JobChange>>progress >> SystemProgressMorph class>>updateJob: >> MessageSend>>value: >> MessageSend>>cull: >> MessageSend>>cull:cull: >> AnnouncementSubscription>>deliver: in Block: [action cull: anAnnouncement cull: announcer] >> BlockClosure>>on:do: >> BlockClosure>>on:fork: in Block: [Processor terminateActive] > > my bad, I have to finish my Job/ProgressBar refactoring :P

Dec. 1, 2012

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

by StÃ©phane Ducasse

Hi guys just for your information this mailing-list is Pharo-development. You can discuss a lot of topics in Pharo-users but in Pharo-dev we would really appreciate to get a bit focused. I try to read all the mails to be able to help people but it means processing a lot of mails :) and I really have a lot of duties that are not pharo related and I would appreciate to get my pharo time for pharo. Stef On Dec 1, 2012, at 9:52 PM, Alexandre Bergel wrote: >> 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? > > Yes > > Alexandre > >> >> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Dec. 1, 2012

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

by Alexandre Bergel

> 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? Yes Alexandre > > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 1, 2012

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