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

Re: [Pharo-project] What about killing PharoWeb images?

by Dale Henrichs

----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | > 4) Now I created all the Metacello configurations for the PharoDev | image and | > I took me a lot of time. Because I am not the developer of any of | those | > projects. So, I need to understand the dependencies, the order, the | > versions, etc. But why ??? If Seaside people have already done that, | don't | > duplicate efforts. | | There is a configuration for Seaside 3.0 (and probably also Seaside | 2.8). This was probably the first configuration every written. Ask | Dale. Yes Seaside3.0 was one of the original motivations behind Metacello:) There are Seaside3.0, Seaside2.8 and Pier (for Seaside2.8) configurations in the Metacello Repository and these were built based on information Lukas, so they should match pretty closely the web image content. I agree with the notion of one-click for ease of getting started with a particular framework/project. In the GLASS effort I've often outstripped the one-click images (and appliances) and run into support issues as a consequence. Once a developer is comfortable with the technology then they are likely to want to build their own image and if the one-click was built with a know configuration, then the developer has a reasonable chance of duplicating the code in his/her custom image. Dale

Jan. 4, 2010

Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)

by Laval Jannik

Hi, I understand your comments, So: - i will put word size a class var, - this class var will be modify only by systemTracer Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ? Cheers, Jannik On Jan 4, 2010, at 17:39 , David T. Lewis wrote: > On Mon, Jan 04, 2010 at 05:15:28PM +0100, Andreas Raab wrote: >> Hi Jannik - >> >> A couple of comments. First, If wordSize is a constant, put it into a >> class var. That's the best practice pattern for dealing with constants >> and I see no reason why one would opt to use an ivar for a value that >> never changes. See for example the EndianCache in SmalltalkImage and >> other use of constants throughout the system. >> >> As for caching, if I understand your description correctly, then system >> tracer is storing the correct value for the traced image. When the image >> starts, your cache code invalidates the known to be correct value which >> is later lazily filled in with the same value again. So what observable >> effect does your cache invalidation have? >> >> #startUp isn't the first method sent, not by a very long shot - in >> particular when you mess with the execution machinery you have to be >> aware that a method like #initialPC might be called before you ever get >> to the point where you invalidate that cache (I'm not sure if this can >> happen in this concrete case). In any case you should trace through the >> startup sequence to find out just how much other code is executed before >> getting there. > > John and/or Bert previously pointed out that there is no need to ever > set the cached value from the image, so this would be done from a system > tracer only (and yes this should have a comment). > >> My recommendations would be to make WordSize a class variable, leave the >> lazy initialization in (it might be helpful during install etc) but add >> a nice comment explaining that only system tracer ever modifies that >> value when a 32/64 bit image is written. And leave out the pointless >> cache invalidation :-) > > I think that the change set on Mantis 7430 does what you describe. This > puts the class variable in SystemDictionary in order to retain the current > "Smalltalk wordSize" idiom, and uses the original Dan Ingalls #initialPC > implementation from the "dist3" 64-bit image. > > It's a small change, so I'll copy it here: > > 'From Squeak3.10.2 of 16 December 2009 [latest update: #8496] on 18 December 2009 at 6:08:11 pm'! > "Change Set: Smalltalk-wordSize-dtl-M7430 > Date: 18 December 2009 > Author: David T. Lewis > > Cache Smalltalk wordSize in class var in SystemDictionary.. > > Update CompiledMethod>>initialPC to use #wordSize. This is the method as implemented in the original 64-bit image (author di)."! > > IdentityDictionary subclass: #SystemDictionary > instanceVariableNames: 'cachedClassNames' > classVariableNames: 'LastImageName LastQuitLogPosition LowSpaceProcess LowSpaceSemaphore MemoryHogs ShutDownList SpecialSelectors StartUpList StartupStamp SystemChanges WordSize' > poolDictionaries: '' > category: 'System-Support'! > > !CompiledMethod methodsFor: 'accessing' stamp: 'di 6/29/2004 12:28'! > initialPC > "Answer the program counter for the receiver's first bytecode." > > ^ (self numLiterals + 1) * Smalltalk wordSize + 1 > ! ! > > > !SystemDictionary methodsFor: 'sources, change log' stamp: 'dtl 12/18/2009 00:32'! > wordSize > "Answer the size (in bytes) of an object pointer." > "Smalltalk wordSize" > > ^ WordSize ifNil: [WordSize := [SmalltalkImage current vmParameterAt: 40] on: Error do: [4]]! ! > > > >

Jan. 4, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by Mariano Martinez Peck

On Mon, Jan 4, 2010 at 5:22 PM, <csrabak(a)bol.com.br> wrote: > Em 04/01/2010 06:24, Mariano Martinez Peck < marianopeck(a)gmail.com > > escreveu: > > > Please, don't say "NOOOOO!" immediately. Read the mail carefully, > > take a deep breath and think cold. > > After working a couple of weeks in the Metacello configurations and > > now with Damien's scripts to build Dev and Web images, I came to the > > question: Do we really need a PharoWeb image? > > I will give just my opinions of why having PharoWeb images is not > > a good idea anymore > [snipped] > > On the whole I appreciate and agree with the reasoning. > > > > > Here is my proposal: > > 1) Completely remove the idea of PharoWeb image. Remove the links > > from the website and do not create Web images any more. > > +1 > > > 2) In http://www.pharo-project.org/pharo-download add a description > > explaining that now Seaside images are based in Pharo, so you can > > directly download that image. We can even explain a bit about > > seaside, and even if you want you can put a href called "PharoWeb" > > which links to the seaside image. However, I would rather call it > > "PharoSeaside". > > I think here we have to work hard to stress this fact since IIUC the > /piÃ¨ce de rÃ©sistance/ for Pharo is having all production work done by > Seaside. > I am not sure if I understood you correctly. Of course that supports Seaside is one of the most important task in Pharo, but not the only one. I don't know what do you mean with production, but I know few "production" application running in Pharo without Seaside. As Marcus or Gary for example. I really would like Pharo to be the vehicle for all of them: Seaside, AidaWeb, GemTools, Moose, etc. > > > 3) Tomorrow we can have AidaWeb images based in > > pharo (please Janko!!) so we can just do the same and put the link > > to those images. > > While I'm fond of the idea on having AidaWeb very soon as possible, I > also think we should put ourselves in Janko's shoes and understand > that he'll need to master Metacelllo to arrive at the packaging. . . > > Yes, maybe. But that's not in our discussion. I mean, suppose I don't care how Janko builds his images, I really would like that to be also "PharoWeb". So, it that case we just add one link more to our website: "Pharo Web with Seaside" , "Pharo Web with AidaWeb" , "Pharo Client for Gemstone", etc... > > > 4) You may notice that Seaside images are a bit "different" than our > > Dev images. This is mostly due to the preferences, the theme and > > maybe some tools (ECompeltion instead of OCompletion, etc..). So, > > what I suggest is to prepare a little script that can be > > downloadable and those people who want a Seaside image but more > > "similar" to our Dev images, just run that script. > > I would postpone the publishing of these kind of scripts for a much > more stable Pharo and Metacello (or packaging solution ensuing), > otherwise you'll have the same work as testing the scripts means > creating and testing the packages!! > > Good point. If you want we can achieve that later. Even for 1.1. But at least, for the moment, for the newcomers, I doesn't cost anything a little script to at least set the preferences and theme we use in PharoDev (this has nothing to do with the Package Managment). Thanks for giving me your opinion Carlos. Cheers Mariano > > > So...what do you think? I would really like to hear your opinion > > about this. > > my 0.01999999.... > > -- > Cesar Rabak > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 4, 2010

Re: [Pharo-project] [squeak-dev] Re: Mac VM 5.2.b2 ships

by Mariano Martinez Peck

On Mon, Jan 4, 2010 at 3:33 PM, Simon Michael <simon(a)joyful.com> wrote: > John, thanks for the more precise directions (yesterday I gave up in > confusion). To encourage other mac users to switch, here's the exact url: > > > ftp://ftp.smalltalkconsulting.com/experimental/64bit/32bitImage*64bitVM/Squ… > > I've made this my default vm and so far so good (I can open and operate a > bunch of my images). But at the same time??? I cannot open more than one image at the same time with this version. When I try to open the second one, it is not open and even more, no matter what OS windows I have focus, it goes to the first image. It is like if it thinks that it has already opened the image. Cheers Mariano > I'm looking forward to apple-Q, apple-H etc working. > > Thanks for the shiny new vm! > -Simon > > >

Jan. 4, 2010

Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))

by Igor Stasenko

2010/1/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > If the method is installed, I would only store a reference (MyClass>>#myMethod). +1 > That's what is done on Class, they are stored by reference: > > String streamContents: [:strm | Array storeOn: strm] > -> 'Array' > > Otherwise, if the method is not installed, I would not store a trailer > pointing to some source somewhere indeed, but why not a trailer > encoding compressed temp vars or direct source... because you could store the source code instead. > Anyway, is the trailer a relevant point of comparison ? > i am against storing the compiled method in any other form than source code, except referential form, like 'Array >> #at: ' , you mentioned. So, either way, after restoring you getting an already existing CompiledMethod instance, or fresh one, which just compiled from stored source code. We just should not allow a potentially dangerous ways of manipulating a binary data, stored in compiled method, including trailer and bytecodes. Because they are subject of change (if we observe them over long period ;) > Nicolas > > 2010/1/4 Igor Stasenko <siguctua(a)gmail.com>: >> 2010/1/4 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>> >>> On Jan 4, 2010, at 2:45 57AM, Levente Uzonyi wrote: >>> >>>> On Wed, 30 Dec 2009, StÃ©phane Ducasse wrote: >>>> >>>>> BIG THANKS igor!!! >>>>> >>>>> 11127 >>>>> ----- >>>>> >>>>> - Issue 1690: New Method Trailer part 7 (cs 9) >>>> >>>> There are still some issues. Some methods (for example TPureBehavior >> #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) >>>> >>>> >>>> Levente >>> >>> CompiledMethod>>storeOn: also needs to be updated, >>> >>> (Compiler evaluate: aCompiledMethod storeString) does not reconstruct the original trailer. >>> >> >> The only way how you should be allowed to reconstruct a compiled >> method from string, is compilation, otherwise you risking crashing the >> system. >> But compilation _always_ creating a new artifact - a compiled method , >> and picking an appropriate trailer for it. >> >> The way, how CompiledMethod>>storeOn: does, seems an abuse, as to me, >> because i won't bet on safety of keeping a methods in such format, >> even for existing images. >> For instance, you could store a method , then condense changes, and >> then if you attempt to restore it, you will end up with having a >> sourcePointer pointing to >> invalid .changes file location. >> >> So, i rather prefer seeing this method implemented like following: >> >> CompiledMethod>>storeOn: aStream >> Â ^ self shoulNotBeImplemented >> >>> Caught by ArrayTest >> testComplexIsSelfEvaluating, of all places :) >>> >>> Cheers, >>> Henry >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 4, 2010

Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))

by Nicolas Cellier

If the method is installed, I would only store a reference (MyClass>>#myMethod). That's what is done on Class, they are stored by reference: String streamContents: [:strm | Array storeOn: strm] -> 'Array' Otherwise, if the method is not installed, I would not store a trailer pointing to some source somewhere indeed, but why not a trailer encoding compressed temp vars or direct source... Anyway, is the trailer a relevant point of comparison ? Nicolas 2010/1/4 Igor Stasenko <siguctua(a)gmail.com>: > 2010/1/4 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> >> On Jan 4, 2010, at 2:45 57AM, Levente Uzonyi wrote: >> >>> On Wed, 30 Dec 2009, StÃ©phane Ducasse wrote: >>> >>>> BIG THANKS igor!!! >>>> >>>> 11127 >>>> ----- >>>> >>>> - Issue 1690: New Method Trailer part 7 (cs 9) >>> >>> There are still some issues. Some methods (for example TPureBehavior >> #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) >>> >>> >>> Levente >> >> CompiledMethod>>storeOn: also needs to be updated, >> >> (Compiler evaluate: aCompiledMethod storeString) does not reconstruct the original trailer. >> > > The only way how you should be allowed to reconstruct a compiled > method from string, is compilation, otherwise you risking crashing the > system. > But compilation _always_ creating a new artifact - a compiled method , > and picking an appropriate trailer for it. > > The way, how CompiledMethod>>storeOn: does, seems an abuse, as to me, > because i won't bet on safety of keeping a methods in such format, > even for existing images. > For instance, you could store a method , then condense changes, and > then if you attempt to restore it, you will end up with having a > sourcePointer pointing to > invalid .changes file location. > > So, i rather prefer seeing this method implemented like following: > > CompiledMethod>>storeOn: aStream > Â ^ self shoulNotBeImplemented > >> Caught by ArrayTest >> testComplexIsSelfEvaluating, of all places :) >> >> Cheers, >> Henry >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 4, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Alexandre Bergel

Gary, In this email I attached a .st file. Just load it, and it will install the change set to get notifications. A number of people already expressed their need for such an extension. Cheers, Alexandre On 4 Jan 2010, at 17:20, Gary Chambers wrote: > Nothing like that currently or previously AFAIK. > > Regards, Gary > > ----- Original Message ----- > From: "Simon Denier" <Simon.Denier(a)inria.fr> > To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, January 04, 2010 4:00 PM > Subject: [Pharo-project] Notifications of windows opening/closing/ > focus > > >> Hi >> >> How do you get notified of windows opening, closing, or getting >> focus in >> Pharo? Is there some announcements or some older events? >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 4, 2010

Re: [Pharo-project] About moving tmp closer their use

by csrabak＠bol.com.br

Stef, I think that the issue on "readibility" is in the eyes of the beholder (a.k.a. zealot /du jour/). >From a cognitive POV having the variables 'created' and used as near as possible should make the code more understandable than having them all declared at the top of the method and used only (say as a temp variable within a block [worse if the variable is used as temp in two blocks...]). These issues (on readibility) are less strong in Smalltalk than other languages because ST is dynamic typed and the declaration is more often than not just the name of the variable. Also, ST promotes the creation of short methods and in the average we should be able to see more or less the same way the declaration of a variable be it at the top of the method or inside a block. OTOH, while the reality still strikes us with several large methods, then the ideas of having the declaration as near of the as possible are IMO a good move. my 0.019999... -- Cesar Rabak Em 04/01/2010 10:42, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. >From my hackish lisping state of mind I like it now what do you prefer? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 4, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Alexandre Bergel

> How do you get notified of windows opening, closing, or getting > focus in Pharo? Is there some announcements or some older events? Hi Simon, I did something like this for Mondrian. It is based on announcement. For multiple reasons, I haven't got the time to push it into the mainstream. Load Mondrian, and you will find the class: MOMorphicExtensionInstaller When this class is loaded, it installs a changeset defined in a class- side method. Have a look at the class MorphicWindowNotificationTest to see how to use it. I have been using this extension for some time, it is pretty harmless. Maybe I can put it in a dedicated Monticello repository... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 4, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by csrabak＠bol.com.br

Em 04/01/2010 06:24, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: > Please, don't say "NOOOOO!" immediately. Read the mail carefully, > take a deep breath and think cold. > After working a couple of weeks in the Metacello configurations and > now with Damien's scripts to build Dev and Web images, I came to the > question: Do we really need a PharoWeb image? > I will give just my opinions of why having PharoWeb images is not > a good idea anymore [snipped] On the whole I appreciate and agree with the reasoning. > > Here is my proposal: > 1) Completely remove the idea of PharoWeb image. Remove the links > from the website and do not create Web images any more. +1 > 2) In http://www.pharo-project.org/pharo-download add a description > explaining that now Seaside images are based in Pharo, so you can > directly download that image. We can even explain a bit about > seaside, and even if you want you can put a href called "PharoWeb" > which links to the seaside image. However, I would rather call it > "PharoSeaside". I think here we have to work hard to stress this fact since IIUC the /piÃ¨ce de rÃ©sistance/ for Pharo is having all production work done by Seaside. > 3) Tomorrow we can have AidaWeb images based in > pharo (please Janko!!) so we can just do the same and put the link > to those images. While I'm fond of the idea on having AidaWeb very soon as possible, I also think we should put ourselves in Janko's shoes and understand that he'll need to master Metacelllo to arrive at the packaging. . . > 4) You may notice that Seaside images are a bit "different" than our > Dev images. This is mostly due to the preferences, the theme and > maybe some tools (ECompeltion instead of OCompletion, etc..). So, > what I suggest is to prepare a little script that can be > downloadable and those people who want a Seaside image but more > "similar" to our Dev images, just run that script. I would postpone the publishing of these kind of scripts for a much more stable Pharo and Metacello (or packaging solution ensuing), otherwise you'll have the same work as testing the scripts means creating and testing the packages!! > > So...what do you think? I would really like to hear your opinion > about this. my 0.01999999.... -- Cesar Rabak

Jan. 4, 2010