And that not depends on HTTPLoader please!!!! On Wed, Jan 20, 2010 at 3:22 PM, Stéphane Ducasse <[email protected] > wrote:
> 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 <[email protected]> > 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 <[email protected]>: > > > > > > > > > On Tue, Jan 19, 2010 at 6:12 PM, Michael Roberts <[email protected]> > 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 <[email protected]>: > > >> > 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 > > >> > <[email protected]> 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 > > >> >> >> [email protected] > > >> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> >> > > > >> >> > -- > > >> >> > > > >> >> > > > >> >> > > =========================================================================== > > >> >> > John M. McIntosh <[email protected]> Twitter: > > >> >> > squeaker68882 > > >> >> > Corporate Smalltalk Consulting Ltd. > > >> >> > http://www.smalltalkconsulting.com > > >> >> > > > >> >> > > > >> >> > > =========================================================================== > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > _______________________________________________ > > >> >> > Pharo-project mailing list > > >> >> > [email protected] > > >> >> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> >> > > >> >> > > >> >> _______________________________________________ > > >> >> Pharo-project mailing list > > >> >> [email protected] > > >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > >> > > > >> > _______________________________________________ > > >> > Pharo-project mailing list > > >> > [email protected] > > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> [email protected] > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > [email protected] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
