External projects

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

External projects

Schwab,Wilhelm K
Hello all,

I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode.

When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows.  OS Process did not load cleanly.

Do we have a plan to fix such things?  There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work.  At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo.  PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki??  In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users.

Bill

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: External projects

Stéphane Ducasse
I think that we should have a group of people controling integration.

Stef


> Hello all,
>
> I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode.
>
> When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows.  

apparently this is not pharo's fault.

> OS Process did not load cleanly.

Bill what we are trying to  with metacello is to have configuration of working packages.

> Do we have a plan to fix such things?  There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work.

Yes

Now can you report your problem is a way that we can reproduce them?

>  At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo.  PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki??  In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users.
>
> Bill
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: External projects

Schwab,Wilhelm K
Stef,

An easy one is to try:

ScriptLoader
        loadLatestPackage:'OSProcess' fromSqueaksource:'OSProcess';
        loadLatestPackage:'Tests-OSProcess' fromSqueaksource:'OSProcess';
        loadLatestPackage:'CommandShell' fromSqueaksource:'CommandShell'.


For the full effect, leave deprecation warnings activated; even with these warnings disabled, you should be stopped after just enough time to really whack up an automated load.


Citezen turns out to be more interesting.  The Wiki says to evaluate

  Installer ss project: 'Citezen'; install: 'Citezen-Loader'.

12.2 is missing Installer, which is no doubt in the name of progress.  A quick look at Gofer lead me to try

Gofer new
        squeaksource:'Citezen';
        package:'Citezen-Loader';
        load.

This installs Installer  :)  Now have a look at #newForWin32; note that it answers RioLocalDosExecutive, not RioLocalDosExecutive new.  The last time I tried such an image, I could not get it to load on Windows until I loaded it on another platform, added the #new, and then reloaded it.  The poor folks stuck with Windows have enough to worry about ;)

I realize this is not Pharo's fault, but it is Pharo's problem, and hence **our** problem (aka Error 33).

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Monday, December 28, 2009 9:57 AM
To: [hidden email]
Subject: Re: [Pharo-project] External projects

I think that we should have a group of people controling integration.

Stef


> Hello all,
>
> I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode.
>
> When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows.

apparently this is not pharo's fault.

> OS Process did not load cleanly.

Bill what we are trying to  with metacello is to have configuration of working packages.

> Do we have a plan to fix such things?  There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work.

Yes

Now can you report your problem is a way that we can reproduce them?

>  At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo.  PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki??  In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users.
>
> Bill
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: External projects

Stéphane Ducasse
> Stef,
>
> An easy one is to try:
>
> ScriptLoader
> loadLatestPackage:'OSProcess' fromSqueaksource:'OSProcess';
> loadLatestPackage:'Tests-OSProcess' fromSqueaksource:'OSProcess';
> loadLatestPackage:'CommandShell' fromSqueaksource:'CommandShell'.

in which version are you loading them?
dev-rc1?

I suggest you to publish a metacello configuration and also contact david lewis.
May be the lastest version is not the one to be loaded.
What I do in my code is that I never load the latest versions this way I control other changes
when I'm ready to migrate.

> For the full effect, leave deprecation warnings activated; even with these warnings disabled, you should be stopped after just enough time to really whack up an automated load.
>
>
> Citezen turns out to be more interesting.  The Wiki says to evaluate
>
>  Installer ss project: 'Citezen'; install: 'Citezen-Loader'.
>
> 12.2 is missing Installer, which is no doubt in the name of progress.  A quick look at Gofer lead me to try
>
> Gofer new
> squeaksource:'Citezen';
> package:'Citezen-Loader';
> load.


I should fix the citezen loader....

>
> This installs Installer  :)  Now have a look at #newForWin32; note that it answers RioLocalDosExecutive, not RioLocalDosExecutive new.  The last time I tried such an image, I could not get it to load on Windows until I loaded it on another platform, added the #new, and then reloaded it.  The poor folks stuck with Windows have enough to worry about ;)
>
> I realize this is not Pharo's fault, but it is Pharo's problem, and hence **our** problem (aka Error 33).
>
> Bill
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
> Sent: Monday, December 28, 2009 9:57 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] External projects
>
> I think that we should have a group of people controling integration.
>
> Stef
>
>
>> Hello all,
>>
>> I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode.
>>
>> When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows.
>
> apparently this is not pharo's fault.
>
>> OS Process did not load cleanly.
>
> Bill what we are trying to  with metacello is to have configuration of working packages.
>
>> Do we have a plan to fix such things?  There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work.
>
> Yes
>
> Now can you report your problem is a way that we can reproduce them?
>
>> At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo.  PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki??  In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users.
>>
>> Bill
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: External projects

Schwab,Wilhelm K
Stef,

I used

   http://gforge.inria.fr/frs/download.php/25122/pharo1.0-10502-rc1web09.12.2.zip 


David is aware of the problems.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Monday, December 28, 2009 3:15 PM
To: [hidden email]
Subject: Re: [Pharo-project] External projects

> Stef,
>
> An easy one is to try:
>
> ScriptLoader
> loadLatestPackage:'OSProcess' fromSqueaksource:'OSProcess';
> loadLatestPackage:'Tests-OSProcess' fromSqueaksource:'OSProcess';
> loadLatestPackage:'CommandShell' fromSqueaksource:'CommandShell'.

in which version are you loading them?
dev-rc1?

I suggest you to publish a metacello configuration and also contact david lewis.
May be the lastest version is not the one to be loaded.
What I do in my code is that I never load the latest versions this way I control other changes when I'm ready to migrate.

> For the full effect, leave deprecation warnings activated; even with these warnings disabled, you should be stopped after just enough time to really whack up an automated load.
>
>
> Citezen turns out to be more interesting.  The Wiki says to evaluate
>
>  Installer ss project: 'Citezen'; install: 'Citezen-Loader'.
>
> 12.2 is missing Installer, which is no doubt in the name of progress.  
> A quick look at Gofer lead me to try
>
> Gofer new
> squeaksource:'Citezen';
> package:'Citezen-Loader';
> load.


I should fix the citezen loader....

>
> This installs Installer  :)  Now have a look at #newForWin32; note
> that it answers RioLocalDosExecutive, not RioLocalDosExecutive new.  
> The last time I tried such an image, I could not get it to load on
> Windows until I loaded it on another platform, added the #new, and
> then reloaded it.  The poor folks stuck with Windows have enough to
> worry about ;)
>
> I realize this is not Pharo's fault, but it is Pharo's problem, and hence **our** problem (aka Error 33).
>
> Bill
>
>
> ________________________________________
> From: [hidden email]
> [[hidden email]] On Behalf Of Stéphane
> Ducasse [[hidden email]]
> Sent: Monday, December 28, 2009 9:57 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] External projects
>
> I think that we should have a group of people controling integration.
>
> Stef
>
>
>> Hello all,
>>
>> I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode.
>>
>> When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows.
>
> apparently this is not pharo's fault.
>
>> OS Process did not load cleanly.
>
> Bill what we are trying to  with metacello is to have configuration of working packages.
>
>> Do we have a plan to fix such things?  There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work.
>
> Yes
>
> Now can you report your problem is a way that we can reproduce them?
>
>> At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo.  PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki??  In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users.
>>
>> Bill
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project