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.

�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.

� I'll take a look later on.

cheers,
Mike

2010/1/19 Mariano Martinez Peck <marianopeck@gmail.com>:
>
>
> On Tue, Jan 19, 2010 at 6:12 PM, Michael Roberts <mike@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@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@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@lists.gforge.inria.fr
>> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >> >
>> >> > --
>> >> >
>> >> >
>> >> > ===========================================================================
>> >> > John M. McIntosh <johnmci@smalltalkconsulting.com> � Twitter:
>> >> > �squeaker68882
>> >> > Corporate Smalltalk Consulting Ltd.
>> >> > �http://www.smalltalkconsulting.com
>> >> >
>> >> >
>> >> > ===========================================================================
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Pharo-project mailing list
>> >> > Pharo-project@lists.gforge.inria.fr
>> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >>
>> >>
>> >> _______________________________________________
>> >> Pharo-project mailing list
>> >> Pharo-project@lists.gforge.inria.fr
>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > Pharo-project@lists.gforge.inria.fr
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project