- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [Newbies] squeak locks up on windows / help me debug it...

by Chris Cunningham

---------- Forwarded message ---------- From: Chris Cunningham <cunningham.cb(a)gmail.com> Date: Sat, Jan 10, 2009 at 12:41 AM Subject: Re: [Newbies] squeak locks up on windows / help me debug it... To: "A friendly place to get answers to even the most basic questions about Squeak." <beginners(a)lists.squeakfoundation.org> It is worth noting that Pharo is currently under heavy development. The Pharo team is busy ripping out parts of Squeak they don't want in the base image and adding other parts that they do want. From all reports it is very nice to work in, but it is not a stable release at this point. If you want to keep working with it, be prepared to submit bug reports to that list if you encounter issue like this one. Otherwise, pick up the squeak 3.10, 3.9, or 3.8 to try out the tutorials until Pharo is more stable/released if you don't want to be that involved in the development (or early beta/alpha? testing) of it. On Fri, Jan 9, 2009 at 4:39 PM, Cameron Sanders < csanders.personal(a)functional-analyst.com> wrote: > I thought the Pharo base image (3.10 with a few fonts & Balloon3d added) > running on Windows was looking pretty stable (compared to other images). > But after an hour of editing code on a Vista machine --an hour since the > last saveâSqueak has abandoned me. It is unresponsive. Trying both control > and alt in combination with '.', 'l' (lower case L), 'c', does nothing > apparently useful. > > > > The process stack reported by Vista shows it to be incurring page-faults > like mad. [OK, that has subsided while I typed this email.] My machine has 4 > GB of RAM, I am running two instances of internet-explorer, and I have > turned off the Windows search-indexing service. I know Vista has a > guess-the-next-program pre-loader that could be a little overzealous in > displacing programs from RAMâ¦ but stillâ¦ it seems like this 101MB program > shouldn't generate any page faults when the other two leading memory pigs > are using less than double that much virtual memory. Vista's Resource > Monitor claims I am using only 43% of physical memory. The page-fault count > for Squeak.exe doubled while I typed this message. > > > > When I click the Squeak icon on the window frame of the running copy (upper > left on Windows), I do see the menu for VM Preferences. It shows me the menu > and allows me to invoke actions. It will allow me to toggle the "Show output > console" on and off. The output console shows me changes to memory (as I > have that option checked). I can use my mouse wheel to scroll this console. > Control-'.' and Control-c (and lower case L) in this console do not change > anything. > > > > After mucking around in the console area, I am now getting "WARNING: event > buffer overflow" just moving my mouse around in squeak. After turning the > console off, the pointer is now invisible except when you click. It appears > that the overall squeak window is repainting itself properly. > > > > -- Help me debug it > > > > I have an interest in building a commercial application in Squeak. The FAQs > says squeak is stable. Given the active community of developers (including > The Great Ones), I imagine that it is stable, and that I am just doing > something dumbâ¦ repeatedly. However, for Squeak to be adopted more broadly, > it can't go zombie on users, even when the user does something dumb. That's > an absolute. > > > > What is the longest uptime a squeak image has ever endured (while doing > something useful)? Which version was that and on what platform? > > > > So I am willing to work to help make squeak more robust, but as a complete > newbie with it, I need much guidance. So right now, with this hung-up image, > what should I do? Should I attach to it with gdb? And if so, then what? [If > the internal process control is working, I won't be able to make heads or > tales out of it from gdb, right?] Or can I launch another squeak and send > it a signal in some way [is it listening?]? What is most useful in this > case? > > > > [Is there a way in Windows/Vista to signal an app so as to force a core > dump?] > > > > Thanks in advance, > > Cam > > PS: I want to emphasize that I do not care about the code lost in this > particular instance (it was tutorial code), instead I am looking for a > stable free development environmentâ¦ and I'm willing to help make one. > > > > > > __________ Information from ESET Smart Security, version of virus signature > database 3755 (20090109) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > _______________________________________________ > Beginners mailing list > Beginners(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners > >

Jan. 10, 2009

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

by Bill Schwab

FWIW, Dolphin has an interesting approach to this kind problem. As the image loads, it creates a session manager. There is a hierarchy of such classes for GUI and headless systems. GUI session managers take care of creating and showing the app's main window. I asked a similar question not long ago, and Andreas consisely explained that Squeak just runs, and it picks up where it left off after an image save. I'm genuinely uncertain which is better, but Dolphin seems to have some advantages as a result of the formalism. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 1/9/2009 3:43 PM >>> 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 > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2009

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