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

Re: [Pharo-project] We remove CodeLoader ?? [WAS] Presenter and Project will die aren't they ?

by StÃ©phane Ducasse

Yes this would be good to have a clean ScriptExecuter class. Stef On Jan 20, 2010, at 9:48 AM, Mariano Martinez Peck wrote: > > > On Wed, Jan 20, 2010 at 9:13 AM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > if you follow the send into CodeLoader you will see fileIn sent at the > end of installSourceFile:. All the security manager stuff and request > stuff can be dropped so just try and copy the minimum that you need > into the class. > > Yes, I thought the same. > > Also, the startup at login can be dropped as well, > since the class can be activated or deactivated by removing it from > the startup list. > > ahh cool :) > > I'll take a look later on. > > > Excellent. I created http://code.google.com/p/pharo/issues/detail?id=1854 > I wanted to put you in cc but I didn't find you in the list :( > > Thanks > > Mariano > > > cheers, > Mike > > 2010/1/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Tue, Jan 19, 2010 at 6:12 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > >> > >> we can remove it but we need to keep the ability to load scripts from > >> the command line. > >> > > > > Mike: Thanks for you answer. I really don't know too much of CodeLoader, > > that's why I ask. I checked that about running from command line. You are > > right. > > > > > >> > >> so, your code is fine but you can't zap CodeLoader since it's still > >> referenced for the load. It would be easier just to make a new class > >> that only loads scripts from the command line, and zap the rest. > >> > > > > Yes, maybe that's a better idea. However, I think that maybe we even don't > > need a new class. Maybe we can do something like this: > > > > startUpAfterLogin > > | scriptName loader isUrl | > > self readDocumentAtStartup ifTrue: [ > > scriptName := (SmalltalkImage current getSystemAttribute: 2) > > ifNil:['']. > > scriptName := scriptName convertFromSystemString.. > > ] > > ifFalse: [ scriptName := '' ]. > > > > scriptName isEmptyOrNil > > ifTrue:[^ self]. > > > > self loadAndInstallSources: scriptName. > > > > > > And then, we define ProjectLauncher >> loadAndInstallSources: aScriptName > > > > Here we should do a fileIn, but I am not sure how to do that. Can you help > > me ? > > > > What do you think ? Is it worth this or keep CodeLoader ? I reall don't > > LIKE AT ALL to use something that depends on HTTPLoader to do that...wtf > > ??? Look CodeLoader >> createRequestFor: > > > > Please, take into account I am very newbie with this stuff, so maybe there > > are a lot of problems I am not seeing. I just asked :) > > > > Cheers > > > > Mariano > > > > > >> cheers > >> Mike > >> > >> 2010/1/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > So....we will remove CodeLoader then ? This is the moment to speak :) > >> > > >> > I ask about this because I am trying to analize who uses ImageSegments > >> > and > >> > all that stuff in the code and see how easily or good is to remove > >> > ImageSegment to a separate package. And, CodeLoader uses ImageSegment. > >> > > >> > As far as I looked, the only user or CodeLoader, as Michael said is > >> > ProjectLauncher >> startUpAfterLogin > >> > Which....I think it will also die in a moment if Project will die > >> > too.... > >> > > >> > Anyway, but do you think about changing startUpAfterLogin to this: > >> > > >> > startUpAfterLogin > >> > | scriptName loader isUrl | > >> > self readDocumentAtStartup ifTrue: [ > >> > scriptName := (SmalltalkImage current getSystemAttribute: 2) > >> > ifNil:['']. > >> > scriptName := scriptName convertFromSystemString. > >> > scriptName isEmpty ifFalse:[ > >> > "figure out if script name is a URL by itself" > >> > isUrl := (scriptName asLowercase beginsWith:'http://') or:[ > >> > (scriptName asLowercase beginsWith:'file://') or:[ > >> > (scriptName asLowercase beginsWith:'ftp://')]]. > >> > isUrl ifFalse:[scriptName := 'file:',scriptName]]. > >> > . ] > >> > ifFalse: [ scriptName := '' ]. > >> > > >> > scriptName isEmptyOrNil > >> > ifTrue:[^ self]. > >> > loader := CodeLoader new. > >> > loader loadSourceFiles: (Array with: scriptName). > >> > loader installSourceFiles. > >> > > >> > > >> > > >> > On Tue, Jan 12, 2010 at 9:56 AM, StÃ©phane Ducasse > >> > <stephane.ducasse(a)inria.fr> wrote: > >> >> > >> >> ok we got convinced :) > >> >> > >> >> On Jan 12, 2010, at 8:20 AM, John M McIntosh wrote: > >> >> > >> >> > Ah well yes Michael suffered thru managing, testing, and working with > >> >> > all those browsers & plugins. > >> >> > I suffered thru trying to figure out how it all worked... At least > >> >> > on > >> >> > the mac. > >> >> > > >> >> > Here's the current issue, because: > >> >> > > >> >> > Microsoft shafted netscape by abandoning the netscape API, then > >> >> > shafted > >> >> > apple by not providing an alternative > >> >> > we had the strange mixture of a solution for os-x, windows, X11. > >> >> > Then > >> >> > of course Microsoft IE on macintosh > >> >> > would change behaviour from version to version to screw with FireFox > >> >> > & > >> >> > Mozilla etc. Let alone worrying about Opera which > >> >> > kinda worked. Fortunately Microsoft abandon the Mac browser market, > >> >> > and Apple introduced Safari which again was slightly different. > >> >> > > >> >> > Now on 10.6 we had this problem an abandon API for plugins, that > >> >> > needed > >> >> > to move forward, also into the 64bit world. > >> >> > So Apple changed things again to either let you run Safari in 32bit > >> >> > using old plugins (busted), or using a modified 64bit plugins api, > >> >> > but > >> >> > not both at the same time. > >> >> > > >> >> > The words busted, non-existant, abandon, (implied ugly), appear > >> >> > quite a > >> >> > few times in the sentences above. Also on every > >> >> > browser version change, or operating system major version change > >> >> > something was just slightly funky enough to bring down > >> >> > the house of cards. > >> >> > > >> >> > So, time is better spent in getting 64bit squeak working, since there > >> >> > is > >> >> > plenty of hours still needed to fixup all the plugins, > >> >> > and check that the VM is actually sane... > >> >> > > >> >> > > >> >> > On 2010-01-11, at 1:59 PM, Michael Rueger wrote: > >> >> > > >> >> >> On 1/11/2010 10:58 PM, Michael Rueger wrote: > >> >> >> > >> >> >>> forget squeak/pharo in the browser. > >> >> >> > >> >> >> for those not in the know: > >> >> >> I'm one of the poor guys who actually spent a *lot* of time making > >> >> >> it > >> >> >> possible ;-) > >> >> >> > >> >> >> Michael > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Pharo-project mailing list > >> >> >> Pharo-project(a)lists.gforge.inria.fr > >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> >> > > >> >> > -- > >> >> > > >> >> > > >> >> > =========================================================================== > >> >> > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > >> >> > squeaker68882 > >> >> > Corporate Smalltalk Consulting Ltd. > >> >> > http://www.smalltalkconsulting.com > >> >> > > >> >> > > >> >> > =========================================================================== > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > 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 > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] Nabble

by StÃ©phane Ducasse

Indeed. Stef > Mind you, I would like to add that I would prefer to see "Seaside" (and > AIDAWeb for that matter) to see under "Smalltalk" rather than "Squeak

Jan. 20, 2010

Re: [Pharo-project] Scripts that should be run after a slice and ScriptLoader

by StÃ©phane Ducasse

Mariano when you need extend the scriptlOader with a method forSLICE- in scriptloader and mention it in the slice comments. Stef On Jan 20, 2010, at 11:29 AM, Mariano Martinez Peck wrote: > Hi: I found that several times, we need to run some piece of code after a slide. The only way I see doing this is to write it in a txt , and, hopefully (many times, the commiter or the integrator forget about it), remember to put that in the email or issue, when I let you know the fix is ready. Is there a better way ? > > What about having a method in ScriptLoader where we can commit that together with the slice? Then when someone integrates that, it will see that, and will move that piece of code, from there, to the update or script methods. > > I don't know. What do you think ? > > Would be cool, maybe, to reify the "slice" concept, where you can have: pre-doits, a collections of "pieces of code" (several times we have, part1, part2, tc), post-doits, etc...But I guess that requires a lot of effort. > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] Scripts that should be run after a slice and ScriptLoader

by StÃ©phane Ducasse

not that I know. Since I never used it I do not know if they were working or not. Probably keith fixed that in MC1.5 Stef >> >>> Hi: I found that several times, we need to run some piece of code after a slide. The only way I see doing this is to write it in a txt , and, hopefully (many times, the commiter or the integrator forget about it), remember to put that in the email or issue, when I let you know the fix is ready. Is there a better way ? >>> >>> What about having a method in ScriptLoader where we can commit that together with the slice? Then when someone integrates that, it will see that, and will move that piece of code, from there, to the update or script methods. >>> >>> I don't know. What do you think ? >> >> >> If I understood correctly, Monticello already has this feature for package so I guess it should work for slices. >> >> Click on a package in MC browser, then click on the 'Scripts' button in the toolbar, you get menu to edit the preamble, postscript, as well as preambleOfRemoval and postscriptOfRemoval > > Preamble/Postscripts don't work anymore in Pharo though, following the procedure you outlined I get a DNU when selecting the script I want to edit. > Not sure when they were removed, but probably it was part of some PackageInfo cleaning. > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] What are Owners ???

by StÃ©phane Ducasse

I do not know did you check in CUIS. It may be a leftover from one experiments or Etoys. Stef > Also, can I remove Morph >> allOwners ? I checked and it has no sender neither in: Dev, Moose, Seaside, Pier... > > > > On Wed, Jan 20, 2010 at 1:26 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I checked in squeak 2.6, 3.9 and 3.10. What is that class ? > > They have references in PharoCore. For example, look ImageSegment >> findOwnersOutPtrs > > I will probably remove that method, but I want to learn what Owners are/were. > > Does someone know ? > > Thanks > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] Looking for your license agreement.

by StÃ©phane Ducasse

sure to me :) and I like also nice stamp. Stef On Jan 20, 2010, at 1:34 PM, George Herolyants wrote: > Hi > > Is it allowed to send you scanned agreement by email? > > 2010/1/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi guys >> >> do not forget to send your license agreement. >> We want to stay clean. >> >> Stef >> >> _______________________________________________ >> 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

Jan. 20, 2010

Re: [Pharo-project] Something I don't understand with Method Finder

by StÃ©phane Ducasse

this is strange. We will have to clean the MethodFinder. Normally it gets all the selector the receiver class, remove some destructruring and execute eveyrhitng with the arguments you passed. Stef > Hi folks! If you look for example "gently" in Method Finder, you will see that it lists, for example, "enableGently:" and "disableGently:" > However, those methods are not implemented, there are no senders, and I even did a "method source with it " and I found nothing. > > In my final shut, I read the .changes and I found: > "Preferences class removeSelector: #enableGently:!" > > Now I wonder...is this a feature of Method Finder to look also in .changes or it is a bug ? Anyway, it is not clear when you find a message but you don't have implementros or senders, it means that it was in .changes. > > What do you think? > > Thanks > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] Scripts that should be run after a slice and ScriptLoader

by Simon Denier

On 20 janv. 2010, at 14:09, Mariano Martinez Peck wrote: > > > On Wed, Jan 20, 2010 at 1:25 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > > On 20 janv. 2010, at 11:29, Mariano Martinez Peck wrote: > > > Hi: I found that several times, we need to run some piece of code after a slide. The only way I see doing this is to write it in a txt , and, hopefully (many times, the commiter or the integrator forget about it), remember to put that in the email or issue, when I let you know the fix is ready. Is there a better way ? > > > > What about having a method in ScriptLoader where we can commit that together with the slice? Then when someone integrates that, it will see that, and will move that piece of code, from there, to the update or script methods. > > > > I don't know. What do you think ? > > > If I understood correctly, Monticello already has this feature for package so I guess it should work for slices. > > Click on a package in MC browser, then click on the 'Scripts' button in the toolbar, you get menu to edit the preamble, postscript, as well as preambleOfRemoval and postscriptOfRemoval > > > Thanks Simon. I wasn't aware of that. However, I think it doesn't fix completely what I mean. Suppose an integrator load that slice. Ok, the script will be automatically run, BUT in his PC. Then, suppose he load some others scripts and he finally do a new release. If WE want to update trough the update stream to the image, it won't work. That's why we have the update methods in ScriptLoader (I think). So, in such case, they have to put it there also, I they have to be aware of that. OK, I didn't understand your case in the first place then. > > > > > > > Would be cool, maybe, to reify the "slice" concept, where you can have: pre-doits, a collections of "pieces of code" (several times we have, part1, part2, tc), post-doits, etc...But I guess that requires a lot of effort. > > > > Cheers > > > > Mariano > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > 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 -- Simon

Jan. 20, 2010

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Mariano Martinez Peck

> Martin and I had been working towards the idea that ImageSegments should > never create non-Canonical symbols, and the user should not have to use > manual techniques to preserve symbols they are interested in keeping alive. > > I ended up getting stuck however, in trying to discover what process > ImageSegment > goes through while it is installing objects - ImageSegment #install has a > call to an > unimplemented method #readFromFileWithSymbols which it seems it should > be > using, but isn't....(wha' the?) > > Do you believe me if I told you that I checked in squeak 2.6 and the method (readFromFileWithSymbols) is still not implemented ? I think it never was hahahah

Jan. 20, 2010

Re: [Pharo-project] Scripts that should be run after a slice and ScriptLoader

by Simon Denier

On 20 janv. 2010, at 14:02, Henrik Johansen wrote: > > On Jan 20, 2010, at 1:25 09PM, Simon Denier wrote: > >> >> On 20 janv. 2010, at 11:29, Mariano Martinez Peck wrote: >> >>> Hi: I found that several times, we need to run some piece of code after a slide. The only way I see doing this is to write it in a txt , and, hopefully (many times, the commiter or the integrator forget about it), remember to put that in the email or issue, when I let you know the fix is ready. Is there a better way ? >>> >>> What about having a method in ScriptLoader where we can commit that together with the slice? Then when someone integrates that, it will see that, and will move that piece of code, from there, to the update or script methods. >>> >>> I don't know. What do you think ? >> >> >> If I understood correctly, Monticello already has this feature for package so I guess it should work for slices. >> >> Click on a package in MC browser, then click on the 'Scripts' button in the toolbar, you get menu to edit the preamble, postscript, as well as preambleOfRemoval and postscriptOfRemoval > > Preamble/Postscripts don't work anymore in Pharo though, following the procedure you outlined I get a DNU when selecting the script I want to edit. > Not sure when they were removed, but probably it was part of some PackageInfo cleaning. Ah, actually I have never used the feature, but I thought some people used it for some packages (typically requiring to clean stuff in globals). Maybe someone else can help? -- Simon

Jan. 20, 2010