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
