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

Re: [Pharo-project] [update 1.4] #14287

by StÃ©phane Ducasse

Excellent! Mariano is a bull (like me) and this is good that other people like henrik guides us :). Stef > >> >> - Issue 5005: #cleanUpForRelease is broken: MessageNotUnderstood: ByteSymbol>>run:with:in:. Thanks Henrik and Mariano. >> http://code.google.com/p/pharo/issues/detail?id=5005. > > My build now completes with no aborts or test failures. > It's great that fixes can be pushed out so fast. > >

Jan. 19, 2012

Re: [Pharo-project] about push up IV

by Lukas Renggli

>> On 18 January 2012 21:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Ok I see I should select the variable >>> but if I select the class I do not need to see superclass variables because I should not been able to >>> push them. >> >> I find it convenient to be able to push up any variable in the >> hierarchy from any subclass ... So this is intentional. > > Ok I see so this is push from your place to superclass. No, it always pushes up to the superclass of where the class is defined in. > What I got is that doing a pull and after the inverse the class var was lost. > I did not try to reproduce it but I added at end. Pull down is not the inverse of push up, because it only adds it to the subclasses where the variable is actually needed. >>> BTW I thought about one cool refactoring this is push as subclassResponsibility :). >> >> Refactor class > Realize > > I would call it abstractize because in general I have the concrete method. and Realize does not says that. Not sure if such a word exists at all? Also the refactoring does the opposite: it makes an abstract class real, that is it implements all the abstract methods of the superclasses (see the explanation in the tooltip help). Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 19, 2012

[Pharo-project] [update 1.4] #14288

by stephane ducasse

14288 ----- - Issue 5163: Bug in #pointsTo: Thanks Mariano Martinez-Peck, Levente Uzonyi and Henrik Johansen http://code.google.com/p/pharo/issues/detail?id=5163 - Issue 5116: Reintroduce the new MethodDictionary >> rehash since it is working Thanks Mariano Martinez-Peck and Henrik Johansen http://code.google.com/p/pharo/issues/detail?id=5116 Stef

Jan. 19, 2012

Re: [Pharo-project] about push up IV

by StÃ©phane Ducasse

On Jan 18, 2012, at 9:30 PM, Lukas Renggli wrote: > On 18 January 2012 21:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Ok I see I should select the variable >> but if I select the class I do not need to see superclass variables because I should not been able to >> push them. > > I find it convenient to be able to push up any variable in the > hierarchy from any subclass ... So this is intentional. Ok I see so this is push from your place to superclass. What I got is that doing a pull and after the inverse the class var was lost. I did not try to reproduce it but I added at end. > >> BTW I thought about one cool refactoring this is push as subclassResponsibility :). > > Refactor class > Realize I would call it abstractize because in general I have the concrete method. and Realize does not says that. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 19, 2012

[Pharo-project] LanguageEnvironment caching behavior

by Camillo Bruni

Does anyone know the reason why LanguageEnvironment doesn't cache the ver instances of the converters but only the classes? I would expect that the instances are mostly functional i.e. do not change state hence they could be cached without side-effects. best cami

Jan. 18, 2012

Re: [Pharo-project] Misc. newbie questions

by Frank Shearar

On 18 January 2012 11:07, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 18 January 2012 10:29, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> On Sat, Jan 7, 2012 at 10:28 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 7 January 2012 15:11, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> 2012/1/7 Frank Shearar <frank.shearar(a)gmail.com>: >>>>> On 7 January 2012 14:14, Nicolas Cellier >>>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>> 2012/1/6 Lukas Renggli <renggli(a)gmail.com>: >>>>>>> On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: >>>>>>>> On 6 jan 2012, at 06:41, "Gerry Weaver" <gerryw(a)compvia.com> wrote: >>>>>>>> >>>>>>>> 2. There appear to be some tool choices in the Pharo image. I would like to >>>>>>>> be able to create a class and it's methods in an editor in one go. I like >>>>>>>> being able to see all of the class code at once. Is there a way to do this? >>>>>>>> Â I just want to be able to type it all in and accept (evaluate?) all at >>>>>>>> once. >>>>>>>> >>>>>>>> This is an interesting question to me personally. After 15 years of working >>>>>>>> exclusively in Smalltalk I've recently been forced to start programming in >>>>>>>> Java, where the source code is always (as far as I know) arranged in the way >>>>>>>> you describe. >>>>>>>> >>>>>>>> This organization just emphasizes the dead and compiled nature of Java (and >>>>>>>> similar languages), compared to the living objects of Smalltalk, where even >>>>>>>> methods are objects, created by sending messages to other objects. Source >>>>>>>> code is relegated to being a mere artifact, which can be saved and organized >>>>>>>> in any way one wishes, and preferably never shows its ugly face to the coder >>>>>>>> :-p >>>>>>> >>>>>>> Which of course is no argument why Smalltalk code could not be >>>>>>> displayed in a more programmer friendly way as a continuous block of >>>>>>> text. There is no technical reason why source ranges in text box >>>>>>> couldn't correspond to life method objects. Compared to other >>>>>>> languages it is extremely tedious in Smalltalk to get an overview over >>>>>>> a project, a package, or even a single class or to navigate between >>>>>>> entities. >>>>>>> >>>>>>>> And yes, I really *really* miss a good, object oriented class browser! >>>>>>> >>>>>>> Eclipse is pretty good, especially with the Java Browsing Perspective. >>>>>>> >>>>>>> Lukas >>>>>>> >>>>>> >>>>>> As soon as you would display the code for many methods in a single text pane, >>>>>> you will find file-based-educated people making large refactorings in >>>>>> a single pass... >>>>>> Imagine this leads to many syntax errors, they will soon be willing to >>>>>> save their changes for a later rework... >>>>>> This would be a complete change in programming flow and if we really >>>>>> want to support this, we would have to: >>>>>> - add a way to save syntactically incorrect code >>>>>> - let IDE tools work on partially correct code (syntax highlighting, >>>>>> navigation, etc...) >>>>>> >>>>>> IMHO, these features add a lot of complexity... Is it really worth? >>>>>> I like the discipline of focusing on a single method until it is at >>>>>> least syntactically correct. >>>>> >>>>> The Pharo community has extremely limited resources so it seems quite >>>>> fair to me for Pharo to say "yes, but it's up to you because we have >>>>> no time". It _is_ very useful to be able to see and edit long reams of >>>>> text: my favourite text editor's been beaten on since the late 70s. It >>>>> is now very, very good at manipulating text, in multiple programming >>>>> languages, in multiple human languages, on many platforms. That I >>>>> can't use this text editor to manipulate a textual representation of >>>>> my favourite language is extremely annoying! >>>>> >>>>> frank >>>> >>>> Yeah, but my take was that re-inventing a very narrow subset of these >>>> 40 years old text editors in Smalltalk would likely be a failure... >>>> (or a big project) >>> >>> It would be a fairlly big piece of work although we do have lots of >>> pieces lying around: >>> * Coral's working on a scripting/REPL-like interface, >>> * the Common Lisp community has been using SLIME to provide a REPL to >>> a running image for years while also using files to store their code, >>> * we have Gitocello (which also translates Squeak/Pharo to gst), >>> * we have LanguageBoxes (*) allowing us to permit craziness like >>> storing code outside the image in one format without affecting the >>> entire language (letting us store Smalltalk code in something other >>> than chunk format) >>> >>> (*) watch this space: I'm making progress on breaking up the Helvetia >>> image into a bootstrappable bunch of packages >> >> Did you commit your code somewhere ? > > Not yet: what I have at the moment is a Squeak Installer script to > bootstrap a vanilla 4.3 image up to the point where I can start > loading Cutie-Helvetia, the first of the LanguageBoxes packages, > dependency-wise, together with a few shims necessary to add some > Pharo-specific bits to Squeak. Those shims are as yet unpublished, > just because I haven't taken the time to put them anywhere. > > It's still very much in hack form, but you can see what I have so far > at https://gist.github.com/1632449. > > Right now I'm trying to figure out how to load Cutie-Helvetia: it > occurred to me late last night that Monticello can't load the > non-Smalltalk methods because it's trying to use the image's compiler > rather than the class-specific parser. I don't yet have a solution: I > need the class-side methods compiled and loaded before I can try > compile the instance-side methods, and right now Monticello compiles > everything before installing anything. I guess a custom loader's what > I need. Update: I've made a dumping ground for all my interim work - http://ss3.gemstone.com/ss/Scratchpad-fbs - which _should_ be exhaustive. I have yet to solve the loading problem I mentioned, though. > frank > >> >> Regards, >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Matsuno Laboratory, Kyoto University, Japan (until 12/2011) >> http://www.mechatronics.me.kyoto-u.ac.jp/ >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >>

Jan. 18, 2012

Re: [Pharo-project] Importing and exporting packages with Fuel [WAS] Re: [Seaside] Seaside not loading css styles (but our fault)

by Mariano Martinez Peck

On Sat, Sep 24, 2011 at 9:01 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Well...Martin and I have been working a little bit this week and here is a > post explaining it: > http://marianopeck.wordpress.com/2011/09/24/importing-and-exporting-package… > > Well...I have just tried with Fuel 1.8 (will be released soon) but with a nice experiment: we also store source code in CompiledMethods :) So...the files increased like 50% (because of the source code), but the good news is that now we can load and have the sources as well. The load process took me now 14 seconds rather than 7. This is because of the source code but also because in this last version we also do system notifications of class creations, etc... Cheers > Cheers > > On Fri, Sep 23, 2011 at 12:09 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > >> >> On 23 Sep 2011, at 11:47, Mariano Martinez Peck wrote: >> >> > Cool Martin. Now I could do it as well. I have exported the groups >> 'Core', 'Tests' and 'Zinc-Seaside'. >> > Then I materialize it a clean image and all tests (1567) are green. And >> it only takes 7 seconds :) >> >> Great ! >> >> I want to try this myself soon. >> >> Sven >> >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Jan. 18, 2012

Re: [Pharo-project] [update 1.4] #14287

by Yanni Chiu

On 18/01/12 3:23 PM, StÃ©phane Ducasse wrote: > > - Issue 5005: #cleanUpForRelease is broken: MessageNotUnderstood: ByteSymbol>>run:with:in:. Thanks Henrik and Mariano. > http://code.google.com/p/pharo/issues/detail?id=5005. My build now completes with no aborts or test failures. It's great that fixes can be pushed out so fast.

Jan. 18, 2012

Re: [Pharo-project] Saga of trying to integrate IDE with OpenGL continuesRe:

by Lawson English

sigh, I'm getting disk access constantly when my little GUI opengl thingie runs. The max FPS is 10ish. Package is: OpenGL-Tutorial-LDE.32 in monticello repository: 'http://croquet-src-01.oit.duke.edu:8886/Contributions' suggestions? Thanks. L.

Jan. 18, 2012

Re: [Pharo-project] about push up IV

by Lukas Renggli

On 18 January 2012 21:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok I see I should select the variable > but if I select the class I do not need to see superclass variables because I should not been able to > push them. I find it convenient to be able to push up any variable in the hierarchy from any subclass ... So this is intentional. > BTW I thought about one cool refactoring this is push as subclassResponsibility :). Refactor class > Realize Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 18, 2012