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