January 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Check if you launch Pharo without display

by StÃ©phane Ducasse

Yes but gwenael needs to know when the image is headless from the image if it was launched as headless. stef On Jan 9, 2009, at 9:40 PM, Brian Brown wrote: > Well, there is the -headless switch you can pass to the VM on startup. > > > hth, > > - Brian > > On Jan 8, 2009, at 9:17 AM, Gwenael Casaccio wrote: > >> Hi, >> >> I'm working on saphir (a scripting engine for Pharo) and >> I would like to know is there is a standard way to know if you >> launch Pharo without a display >> >> Gwenael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Brian Brown > CTO > AbleLink Technologies, Inc. > http://www.ablelinktech.com > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 9, 2009

Re: [Pharo-project] Check if you launch Pharo without display

by Brian Brown

Well, there is the -headless switch you can pass to the VM on startup. hth, - Brian On Jan 8, 2009, at 9:17 AM, Gwenael Casaccio wrote: > Hi, > > I'm working on saphir (a scripting engine for Pharo) and > I would like to know is there is a standard way to know if you > launch Pharo without a display > > Gwenael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Brian Brown CTO AbleLink Technologies, Inc. http://www.ablelinktech.com

Jan. 9, 2009

Re: [Pharo-project] Very strange behavior with MC

by Adrian Lienhard

Yes, I can do it on the weekend. Adrian On Jan 9, 2009, at 17:07 , StÃ©phane Ducasse wrote: > > On Jan 9, 2009, at 4:26 PM, Adrian Lienhard wrote: > >> No I didn't. >> >> But maybe we better recreate an image from the last version that >> didn't have this setting? I don't think it was introduced by a change >> because in my images that I updated myself the setting was not >> changed. > > Ok so may be we should redo a new core starting from the version you > mentioned was > not having such behavior. Do you do it? > > Stef > >> >> >> Adrian >> >> On Jan 9, 2009, at 16:15 , StÃ©phane Ducasse wrote: >> >>> adrian >>> >>> did you use the cleaning expression of alex in your release? >>> >>> Stef >>> >>> On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: >>> >>>> Dear List, >>>> >>>> I dug in the Monticello melting-pot to find where the strange >>>> behavior >>>> some of you are encountering comes from. >>>> >>>> **The problem** >>>> The bug come from the "diffy versions". MC tries to save in >>>> PharoInbox >>>> a "diffy" version of your package. As far as I understood, a >>>> "diffy" >>>> version is a version of your package that contains just a delta >>>> from >>>> an ancestor. In theory this looks nice, but for some reasons it >>>> behaves incorrectly (the zip file is not probably created, it >>>> cannot >>>> be decompressed) >>>> >>>> **How to solve it** >>>> Recently (since 10183), the http repository for PharoInbox is set >>>> to >>>> store version in a diffy mode. You can identity http repository >>>> that >>>> are set that way: >>>> MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs] >>>> >>>> The problem I mentioned in my previous email disappear symply by >>>> doing >>>> (MCHttpRepository allInstances select: [:mc | mc >>>> alwaysStoreDiffs]) >>>> do: [:mc | mc doNotAlwaysStoreDiffs] >>>> >>>> After having executed the last snippet, storing packages in >>>> PharoInbox >>>> will not appear empty. >>>> >>>> What is left to be done, is why this diffy mechanism does not work >>>> as >>>> expected. But I feel that we should not use it anyway since the >>>> ancestor link is not alway kept and is incorrectly handled (e.g., >>>> cross-repository ancestors) and MC2 is now in the pipeline. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 6 Jan 2009, at 15:26, Alexandre Bergel wrote: >>>> >>>>> Dear all, >>>>> >>>>> I just save a new version in PharoInbox, but this version appears >>>>> to >>>>> be empty. I checked on squeaksource [*]. >>>>> In Pharo, it seems that two files are being saved (.143(142).mcd >>>>> and .143.mcz) [**]. >>>>> when I browse .143(142).mcd I see all the content (probably >>>>> because >>>>> it is local to my machine). >>>>> When I browse .143.mcz it is empty. >>>>> >>>>> What this .mcd file is about? >>>>> I am not the only one to experience this. Anyone had an idea >>>>> what's >>>>> going on? >>>>> I haven't closely followed the list of changes that were included >>>>> in >>>>> Pharo. >>>>> >>>>> Alexandre >>>>> >>>>> [*] http://bergel.eu/EmptyVersion.png >>>>> [**] http://bergel.eu/TwoSavedVersions.png >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 9, 2009

Re: [Pharo-project] Very strange behavior with MC

by StÃ©phane Ducasse

On Jan 9, 2009, at 4:26 PM, Adrian Lienhard wrote: > No I didn't. > > But maybe we better recreate an image from the last version that > didn't have this setting? I don't think it was introduced by a change > because in my images that I updated myself the setting was not > changed. Ok so may be we should redo a new core starting from the version you mentioned was not having such behavior. Do you do it? Stef > > > Adrian > > On Jan 9, 2009, at 16:15 , StÃ©phane Ducasse wrote: > >> adrian >> >> did you use the cleaning expression of alex in your release? >> >> Stef >> >> On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: >> >>> Dear List, >>> >>> I dug in the Monticello melting-pot to find where the strange >>> behavior >>> some of you are encountering comes from. >>> >>> **The problem** >>> The bug come from the "diffy versions". MC tries to save in >>> PharoInbox >>> a "diffy" version of your package. As far as I understood, a "diffy" >>> version is a version of your package that contains just a delta from >>> an ancestor. In theory this looks nice, but for some reasons it >>> behaves incorrectly (the zip file is not probably created, it cannot >>> be decompressed) >>> >>> **How to solve it** >>> Recently (since 10183), the http repository for PharoInbox is set to >>> store version in a diffy mode. You can identity http repository that >>> are set that way: >>> MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs] >>> >>> The problem I mentioned in my previous email disappear symply by >>> doing >>> (MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs]) >>> do: [:mc | mc doNotAlwaysStoreDiffs] >>> >>> After having executed the last snippet, storing packages in >>> PharoInbox >>> will not appear empty. >>> >>> What is left to be done, is why this diffy mechanism does not work >>> as >>> expected. But I feel that we should not use it anyway since the >>> ancestor link is not alway kept and is incorrectly handled (e.g., >>> cross-repository ancestors) and MC2 is now in the pipeline. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 6 Jan 2009, at 15:26, Alexandre Bergel wrote: >>> >>>> Dear all, >>>> >>>> I just save a new version in PharoInbox, but this version appears >>>> to >>>> be empty. I checked on squeaksource [*]. >>>> In Pharo, it seems that two files are being saved (.143(142).mcd >>>> and .143.mcz) [**]. >>>> when I browse .143(142).mcd I see all the content (probably because >>>> it is local to my machine). >>>> When I browse .143.mcz it is empty. >>>> >>>> What this .mcd file is about? >>>> I am not the only one to experience this. Anyone had an idea what's >>>> going on? >>>> I haven't closely followed the list of changes that were included >>>> in >>>> Pharo. >>>> >>>> Alexandre >>>> >>>> [*] http://bergel.eu/EmptyVersion.png >>>> [**] http://bergel.eu/TwoSavedVersions.png >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 9, 2009

Re: [Pharo-project] Platform class

by StÃ©phane Ducasse

Ok BTW I tried to load the second version of packages you published and I got problem with MC loading related to some network methods. I have to redo it calmly and check if this is not necessary to load first the first version. Did you try to load your package in Pharo? Stef On Jan 9, 2009, at 4:30 PM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: >> I like that >> I really think that we need to have infrastructure support to control >> the complexity. >> I like the OBPlatform idea. After the question is how much layers do >> we need. >> I imagine that we should not have that much one this is well done. >> Does the Platform code you suggest conflicts with some existing ones >> that could be merged/migrated into. > > OBPlatform seems to try to abstract the "Smalltalk platform", whereas > the platform class I had in mind abstracts the Hardware/OS platform. > > Using a similar name certainly will lead to confusion, so the question > is what else to call an OS abstraction layer. Other than > OSAbstractionLayer ;-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 9, 2009

Re: [Pharo-project] Platform class

by Damien Cassou

On Fri, Jan 9, 2009 at 4:30 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Using a similar name certainly will lead to confusion, so the question > is what else to call an OS abstraction layer. Other than > OSAbstractionLayer ;-) OperatingSystem? -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 9, 2009

Re: [Pharo-project] Platform class

by Michael Rueger

StÃ©phane Ducasse wrote: > I like that > I really think that we need to have infrastructure support to control > the complexity. > I like the OBPlatform idea. After the question is how much layers do > we need. > I imagine that we should not have that much one this is well done. > Does the Platform code you suggest conflicts with some existing ones > that could be merged/migrated into. OBPlatform seems to try to abstract the "Smalltalk platform", whereas the platform class I had in mind abstracts the Hardware/OS platform. Using a similar name certainly will lead to confusion, so the question is what else to call an OS abstraction layer. Other than OSAbstractionLayer ;-) Michael

Jan. 9, 2009

Re: [Pharo-project] Very strange behavior with MC

by Adrian Lienhard

No I didn't. But maybe we better recreate an image from the last version that didn't have this setting? I don't think it was introduced by a change because in my images that I updated myself the setting was not changed. Adrian On Jan 9, 2009, at 16:15 , StÃ©phane Ducasse wrote: > adrian > > did you use the cleaning expression of alex in your release? > > Stef > > On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: > >> Dear List, >> >> I dug in the Monticello melting-pot to find where the strange >> behavior >> some of you are encountering comes from. >> >> **The problem** >> The bug come from the "diffy versions". MC tries to save in >> PharoInbox >> a "diffy" version of your package. As far as I understood, a "diffy" >> version is a version of your package that contains just a delta from >> an ancestor. In theory this looks nice, but for some reasons it >> behaves incorrectly (the zip file is not probably created, it cannot >> be decompressed) >> >> **How to solve it** >> Recently (since 10183), the http repository for PharoInbox is set to >> store version in a diffy mode. You can identity http repository that >> are set that way: >> MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs] >> >> The problem I mentioned in my previous email disappear symply by >> doing >> (MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs]) >> do: [:mc | mc doNotAlwaysStoreDiffs] >> >> After having executed the last snippet, storing packages in >> PharoInbox >> will not appear empty. >> >> What is left to be done, is why this diffy mechanism does not work as >> expected. But I feel that we should not use it anyway since the >> ancestor link is not alway kept and is incorrectly handled (e.g., >> cross-repository ancestors) and MC2 is now in the pipeline. >> >> Cheers, >> Alexandre >> >> >> On 6 Jan 2009, at 15:26, Alexandre Bergel wrote: >> >>> Dear all, >>> >>> I just save a new version in PharoInbox, but this version appears to >>> be empty. I checked on squeaksource [*]. >>> In Pharo, it seems that two files are being saved (.143(142).mcd >>> and .143.mcz) [**]. >>> when I browse .143(142).mcd I see all the content (probably because >>> it is local to my machine). >>> When I browse .143.mcz it is empty. >>> >>> What this .mcd file is about? >>> I am not the only one to experience this. Anyone had an idea what's >>> going on? >>> I haven't closely followed the list of changes that were included in >>> Pharo. >>> >>> Alexandre >>> >>> [*] http://bergel.eu/EmptyVersion.png >>> [**] http://bergel.eu/TwoSavedVersions.png >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 9, 2009

Re: [Pharo-project] Breakpoints (was [OT] Great job guys)

by StÃ©phane Ducasse

one of the point about breakpoint is that they should not get the method dirty. I know that some breakpoint code has been harvested but I do not remember how to use it. Stef On Jan 9, 2009, at 10:27 AM, Janko MivÅ¡ek wrote: > Dale Henrichs wrote: >> ----- "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> wrote: >> >> | And when you are already doing that, introduce also breakpoints >> back in >> | Pharo as they are on GLASS GemTools. Very intuitive and the same >> as on >> | most other Smalltalks. If they can be supported in GemTools, why >> | aren't yet in Pharo? Any technical reason? >> >> Breakpoints in GLASS/GemTools are taking advantage of the >> breakpoint feature in the GemStone/S VM. Remember, Squeak/Pharo are >> used as an OmniBrowser client for GLASS -- the debugger is running >> in a GemStone vm and the UI is running in the Squeak/Pharo vm. > > What I like about breakpoints in GemTools is the simplicity from > usability standpoint. And similarity of use to other Smalltaltalks. > > And because their UI part is implemented in OmniBrowser on GemTools, > they should be easily ported back to Pharo OmniBrowser, even that > breakpoints in GS/S are implemented differently than in Squeak. > > In other words, let we port the UI for breakpoints first, on top of > whatever Squeak supports for breakpoints currently. Later breakpoints > can be enhanced on VM level as well. > > Janko > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 9, 2009

Re: [Pharo-project] Very strange behavior with MC

by StÃ©phane Ducasse

adrian did you use the cleaning expression of alex in your release? Stef On Jan 7, 2009, at 3:08 PM, Alexandre Bergel wrote: > Dear List, > > I dug in the Monticello melting-pot to find where the strange behavior > some of you are encountering comes from. > > **The problem** > The bug come from the "diffy versions". MC tries to save in PharoInbox > a "diffy" version of your package. As far as I understood, a "diffy" > version is a version of your package that contains just a delta from > an ancestor. In theory this looks nice, but for some reasons it > behaves incorrectly (the zip file is not probably created, it cannot > be decompressed) > > **How to solve it** > Recently (since 10183), the http repository for PharoInbox is set to > store version in a diffy mode. You can identity http repository that > are set that way: > MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs] > > The problem I mentioned in my previous email disappear symply by doing > (MCHttpRepository allInstances select: [:mc | mc alwaysStoreDiffs]) > do: [:mc | mc doNotAlwaysStoreDiffs] > > After having executed the last snippet, storing packages in PharoInbox > will not appear empty. > > What is left to be done, is why this diffy mechanism does not work as > expected. But I feel that we should not use it anyway since the > ancestor link is not alway kept and is incorrectly handled (e.g., > cross-repository ancestors) and MC2 is now in the pipeline. > > Cheers, > Alexandre > > > On 6 Jan 2009, at 15:26, Alexandre Bergel wrote: > >> Dear all, >> >> I just save a new version in PharoInbox, but this version appears to >> be empty. I checked on squeaksource [*]. >> In Pharo, it seems that two files are being saved (.143(142).mcd >> and .143.mcz) [**]. >> when I browse .143(142).mcd I see all the content (probably because >> it is local to my machine). >> When I browse .143.mcz it is empty. >> >> What this .mcd file is about? >> I am not the only one to experience this. Anyone had an idea what's >> going on? >> I haven't closely followed the list of changes that were included in >> Pharo. >> >> Alexandre >> >> [*] http://bergel.eu/EmptyVersion.png >> [**] http://bergel.eu/TwoSavedVersions.png >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 9, 2009