[Pharo-project] Pharo VMs should be more Pharo-like
Hi, Currently, we are linking official VMs for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). I think this is a temporal solution, we need something better: 1) Pharo VMs should have Pharo Icons. 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) 4) We should include a LICENCE.txt file with all licence information. ... I think that's all :) I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :) All agree? Should I create a ticket? Cheers, Esteban pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files)
2011/11/29 Esteban Lorenzano <estebanlm@gmail.com>
pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files)
+1
Hi Esteban, 2011/11/29 Esteban Lorenzano <estebanlm@gmail.com>
Hi,
Currently, we are linking official VMs for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). I think this is a temporal solution, we need something better:
1) Pharo VMs should have Pharo Icons. 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) 4) We should include a LICENCE.txt file with all licence information.
... I think that's all :)
I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :)
All agree? Should I create a ticket?
I completly agree.
Cheers, Esteban
pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files)
I understand but on the other hand it is great to have the same package which contains everything and runs everywhere. Luc
On Tue, Nov 29, 2011 at 8:07 AM, Luc Fabresse <luc.fabresse@gmail.com>
pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files)
I understand but on the other hand it is great to have the same package which contains everything and runs everywhere.
I have a bizarre, but maybe related use-case. I work in OS X and tried to setup my dev environment such that my one-click app was in a DropBox folder so I would never have to worry about backups and, theoretically, would be able to switch at any time to work from my other macs. (I put my local montecello repository in the same folder.) Unfortunately, it didn't work. Clicking the app resulted in a 'can't find image' error. I didn't look into it further but assumed that either there was a non-relative path setting, or that the image was actually not in the package contents hidden by the app. If the app packaging could be tweaked so this use-case worked it would be a nice, flexible (and free) model for working across different machines and having constant , effortless backup of the working environment. - Larry
Luc
EstebanLM wrote
All agree? Should I create a ticket?
+1. All the little things make a difference, especially to newbies that may have misconceptions/doubts about Smalltalk. EstebanLM wrote
pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files)
I think they are both valuable. For me, the one-click is great to showcase Smalltalk's ability to run on any mainstream OS. I think the idea that in one operation I can drag my Smalltalk world onto a USB stick, plug it into any computer I may find, and have everything work is pretty cool. OTOH, for a dedicated use, like a web app on a unix server, the cleaner platform-specific approach seems better. -- View this message in context: http://forum.world.st/Pharo-VMs-should-be-more-Pharo-like-tp4119042p4119166.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I'm not sure having a VM with a different name is so confusing. Cog is a VM for more than one project, it's got its own identity and that is a good thing to me. Very much like V8 is not called javascriptvm or chromevm to the best of my knowledge. I'd say Pharo uses Cog, not that Cog is Pharo, and there's nothing wrong with that. Cheers. r. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Esteban Lorenzano Sent: 29 November 2011 12:46 To: Pharo Development Subject: [Pharo-project] Pharo VMs should be more Pharo-like Hi, Currently, we are linking official VMs for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). I think this is a temporal solution, we need something better: 1) Pharo VMs should have Pharo Icons. 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) 4) We should include a LICENCE.txt file with all licence information. ... I think that's all :) I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :) All agree? Should I create a ticket? Cheers, Esteban pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files) This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
On Nov 29, 2011, at 1:46 PM, Esteban Lorenzano wrote: > Hi, > > Currently, we are linking official VMs for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). > I think this is a temporal solution, we need something better: > > 1) Pharo VMs should have Pharo Icons. +1 > 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. + 1 > 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) +1 > 4) We should include a LICENCE.txt file with all licence information. + 1 > > ... I think that's all :) > > I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :) > > All agree? Should I create a ticket? YES! > > Cheers, > Esteban > > pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files) Yes :)
Yes, we need branded VM. For that i made a branch on gitorious , named pharo-vm http://gitorious.org/+pharo-developers/cogvm/pharo-vm it should be branding version of original cog vm (with pharo icons , names etc). we made a 1-click for 1.3 with Marcus manually, but we should automate it to build on jenkins. On 29 November 2011 16:43, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: > > On Nov 29, 2011, at 1:46 PM, Esteban Lorenzano wrote: > >> Hi, >> >> Currently, we are linking official VMs  for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). >> I think this is a temporal solution, we need something better: >> >> 1) Pharo VMs should have Pharo Icons. > +1 > >> 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. > + 1 > >> 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) > > +1 >> 4) We should include a LICENCE.txt file with all licence information. > > + 1 >> >> ... I think that's all :) >> >> I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :) >> >> All agree? Should I create a ticket? > > YES! > >> >> Cheers, >> Esteban >> >> pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files) > > Yes :) > > > -- Best regards, Igor Stasenko.
On Tue, Nov 29, 2011 at 9:46 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Currently, we are linking official VMs  for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). I think this is a temporal solution, we need something better:
1) Pharo VMs should have Pharo Icons. 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) 4) We should include a LICENCE.txt file with all licence information.
... I think that's all :)
I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :)
All agree? Should I create a ticket?
Yes, nobody could disagree with that ;-)
Cheers, Esteban
pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files)
Most of the time, i'm using One-click images. This is really convenient to move images between machines and give them to friends. If the process of creating releases is automated, both can be provided. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Hi, So, I took "the bull by the horns" and hacked a jenkins job to do a Pharo app. I also created a new squeaksource project (PharoVM) to keep the specific configurations for Pharo. Right now, I made it just for Macs, but if everything is ok, I'll add a job for Linux and when windows slave is working, also for windows. Take a look: https://ci.lille.inria.fr/pharo/view/VM/job/Pharo-Mac-Cocoa/ Cheers, Esteban El 29/11/2011, a las 9:56p.m., Serge Stinckwich escribió:
On Tue, Nov 29, 2011 at 9:46 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Currently, we are linking official VMs for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). I think this is a temporal solution, we need something better:
1) Pharo VMs should have Pharo Icons. 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) 4) We should include a LICENCE.txt file with all licence information.
... I think that's all :)
I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :)
All agree? Should I create a ticket?
Yes, nobody could disagree with that ;-)
Cheers, Esteban
pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files)
Most of the time, i'm using One-click images. This is really convenient to move images between machines and give them to friends. If the process of creating releases is automated, both can be provided. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Hi Esteban: On 04 Dec 2011, at 00:19, Esteban Lorenzano wrote:
Take a look: https://ci.lille.inria.fr/pharo/view/VM/job/Pharo-Mac-Cocoa/
Looks good. But I noticed two things: 1. there is still the SqueakOSXApp string all over the menu (CogVM [..] 32bits). 2. Is it possible to have a 'smart' version of the fullscreen feature, at least on Snow Leopard? Currently, it is blanking out my second screen. I read that VMware Fusion introduce such a 'smart' full screen functionality, that does not blank out the other screens. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi, El 03/12/2011, a las 9:38p.m., Stefan Marr escribió:
1. there is still the SqueakOSXApp string all over the menu (CogVM [..] 32bits).
yeah... I will solve that soon :)
2. Is it possible to have a 'smart' version of the fullscreen feature, at least on Snow Leopard? Currently, it is blanking out my second screen. I read that VMware Fusion introduce such a 'smart' full screen functionality, that does not blank out the other screens.
I don't understand this... what you mean? there is a full-screen mode already in latest builds... and it is working fine for me. best, Esteban
EstebanLM wrote
2. Is it possible to have a 'smart' version of the fullscreen feature, at least on Snow Leopard? Currently, it is blanking out my second screen. I read that VMware Fusion introduce such a 'smart' full screen functionality, that does not blank out the other screens.
I don't remember about Snow Leopard, but this is how Lion's fullscreen mode (stupidly) works. -- View this message in context: http://forum.world.st/Pharo-VMs-should-be-more-Pharo-like-tp4119042p4156011.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi: On 04 Dec 2011, at 03:47, Esteban Lorenzano wrote:
2. Is it possible to have a 'smart' version of the fullscreen feature, at least on Snow Leopard? Currently, it is blanking out my second screen. I read that VMware Fusion introduce such a 'smart' full screen functionality, that does not blank out the other screens.
I don't understand this... what you mean? there is a full-screen mode already in latest builds... and it is working fine for me.
There seem to be people who agree that making all other displays just black is not a useful feature. See what they advertise for 4.1: http://blogs.vmware.com/teamfusion/2011/11/weekly-tips-and-tricks-whats-new-... Being able to use the second screen for something is something I care about. And it was possible with the old fullscreen mode. Thus, I consider the new behavior a bug that is worthwhile to be fixed. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
participants (10)
-
Diaz Trepat, Ramiro -
Esteban Lorenzano -
Germán Arduino -
Igor Stasenko -
Larry White -
Luc Fabresse -
Sean P. DeNigris -
Serge Stinckwich -
Stefan Marr -
Stéphane Ducasse