[Pharo-project] We remove CodeLoader ?? [WAS] Presenter and Project will die aren't they ?
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
we can remove it but we need to keep the ability to load scripts from the command line. 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. 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
the loading script on the command line should be cleaned and this is really important. On Jan 19, 2010, at 6:12 PM, Michael Roberts wrote:
we can remove it but we need to keep the ability to load scripts from the command line.
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.
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
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
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
On Wed, Jan 20, 2010 at 9:13 AM, Michael Roberts <mike@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@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
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@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@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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
And that not depends on HTTPLoader please!!!! On Wed, Jan 20, 2010 at 3:22 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
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 <mike@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@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
_______________________________________________ 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
participants (3)
-
Mariano Martinez Peck -
Michael Roberts -
Stéphane Ducasse