- Pharo-dev - lists.pharo.org

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

also, it 'hangs' because InputEventSensor>>shutdown runs before MCMethodDefinition>>shutdown So, you can't interrupt it with alt-. , because nobody handles it anymore. On 8 October 2010 18:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> Hi Marcus, >> is that really all what happened between 12172 and 12186? >> >> update12186 >> Issue 3071: fixing timestamp tests >> Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning >> Issue 3063: removing explain >> Issue 3039: There should not be any configuration on Core >> It doesn't explain the problems with VM versions and in 12186 I cannot build >> the PharoKernel (it hangs without error in unload phase) >> -- Pavel >> > please , tell me if it keep hanging after you doing: > > WeakArray restartFinalizationProcess. > > it seems like a deadlock with WeakArray's FinalizationLock or > FinalizationSemaphore. > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] Cmd-t in OB?

by Miguel CobÃ¡

El vie, 08-10-2010 a las 09:56 -0400, Alexandre Bergel escribiÃ³: > > ConfigurationOfOmnibrowser project load@*%$LatestCode > > better in my opinion: ConfigurationOfOmnibrowser loadLastVersion > > As a metathough, I think we need a unification of how Configuration are defined and used. > We have loadDefault in Moose. I often do a ConfigurationOfXX project lastVersion load. You can directly load the baseline. I know this has been discussed many times. But we really need to come up with a simple and efficient way to use configuration. > > I would also like to have ConfigurationOfXX forEachVersionsLoadAndDo: [:v | ... ], versionsSelect: [:v | ... ], ... > > Alexandre There is a long thread in the metacello mailing list where those topics are being discussed and Dale is right now working in the new code to support them. So if you want to be heard please propose those guidelines there so they are taken in account. Cheers > -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 8, 2010

Re: [Pharo-project] Cmd-t in OB?

by Miguel CobÃ¡

El vie, 08-10-2010 a las 15:22 +0200, Lukas Renggli escribiÃ³: > I don't know, I do not maintain them. > > I just realize that people often report bugs that have been fixed a > long time ago. > > I suggest that you always load the latest code using the following script: > > "Refactoring" > Gofer new > squeaksource: 'rb'; > package: 'AST-Core'; > package: 'AST-Semantic'; > package: 'Refactoring-Core'; > package: 'Refactoring-Changes'; > package: 'Refactoring-Critics'; > package: 'Refactoring-Environment'; > package: 'Refactoring-Spelling'; > load. > ! > "OmniBrowser" > Gofer new > renggli: 'omnibrowser'; > package: 'OmniBrowser'; > package: 'OB-Standard'; > package: 'OB-Morphic'; > package: 'OB-Shout'; > package: 'OB-Refactory'; > package: 'OB-Regex'; > package: 'OB-SUnitIntegration'; > load. > ! > "Tools" > Gofer new > renggli: 'unsorted'; > package: 'Shout'; > package: 'ShoutWorkspace'; > package: 'RoelTyper'; > package: 'ECompletion'; > package: 'ECompletionOmniBrowser'; > load. > ! > "Select Tools" > SystemBrowser default: (Smalltalk at: #OBSystemBrowserAdaptor). Please don't. This is not the way to go. That is the reason of Metacello and the correct way is to ask the maintainer of the Configuration to update it. This kind of scripts are good in the short term but in the long term they are bad for the users themselves and for the developers. Why? Because this script will work for the pharo that is current right now. Even so, it couldnt work in other pharo versions that are in the wild now like Pharo 1.0. When Pharo 1.9 is out and some newbie search the lists, he/she will try blindly to evaluate that code and more surely won't work, because it will be diverged a lot between now and Pharo 1.9. That is exactly the same what happens in Squeak, where the list is plaged with hundreds of such scripts that aren't working anymore in the newest Squeak versions. Dale is working in providing a standardized #bleedingEdge functionality to the Metacello configs, so that there is a explicit way to ask for the very latest package of a given software, while, at the same time, permiting to designate stable and functional versions for each Pharo release. TL;DR :) Use it just for getting the very last version of OB but don't think that this will always work for every Pharo release in the future. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 8, 2010

Re: [Pharo-project] Cmd-t in OB?

by Alexandre Bergel

>> better in my opinion: ConfigurationOfOmnibrowser loadLastVersion > > I think the indirection through project to preserve backwards > compatibility and to avoid generating lots of boilerplate in the > configuration classes is worth it. Could be, even though I do not immediately see if this implies really a lot of boilerplate code. I usually only want to load the last version or a particular version of an application. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi Marcus, > is that really all what happened between 12172 and 12186? > > update12186 > Issue 3071: fixing timestamp tests > Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning > Issue 3063: removing explain > Issue 3039: There should not be any configuration on Core > It doesn't explain the problems with VM versions and in 12186 I cannot build > the PharoKernel (it hangs without error in unload phase) > -- Pavel > please , tell me if it keep hanging after you doing: WeakArray restartFinalizationProcess. it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore. -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] Cmd-t in OB?

by Lukas Renggli

On 8 October 2010 15:56, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> ConfigurationOfOmnibrowser project load@*%$LatestCode > > better in my opinion: ConfigurationOfOmnibrowser loadLastVersion I think the indirection through project to preserve backwards compatibility and to avoid generating lots of boilerplate in the configuration classes is worth it. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

2010/10/8 Alexander LazareviÄ <laza(a)blobworks.com>: > This is reproducible for me if I do: > > Gofer new > Â squeaksource: 'MetacelloRepository'; > Â package: 'ConfigurationOfExternalWebBrowser'; > Â load. > > Â (Smalltalk at: #ConfigurationOfExternalWebBrowser) load > > Find the error log attached. During load , it says that FFI-Pools.em.2 does not exists. But i picked ar.1 version and continued, that save&quit everything works well > > Alex > > 2010/10/8 Alexander LazareviÄ <laza(a)blobworks.com>: >> Just when I was about to test drive Torstens configuration of >> ExternalWebBrowser, the image hangs somewhere while loading. I'm able >> to abort it and find myself in some ensure block of an crticial >> section of WeakArray finalization?! Trying to quit just hangs the >> image for good. >> BTW, this is on Windows. >> >> Alex >> >> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> Strange... >>> Linux VM 4.0.3.2202 from squeakvm.org worked well and your prebuilt image >>> works with all this three virtual machines. Any idea why? >>> -- Pavel >>> >>> On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>>> >>>> On Oct 8, 2010, at 10:39 AM, Pavel Krivanek wrote: >>>> >>>> > Hmm, this is the result for Linux and >>>> > cogvm 3.9-7 and pharovm 3.10-3 >>>> > >>>> > >>>> >>>> can you try: >>>> >>>> https://gforge.inria.fr/frs/download.php/27589/PharoCore-1.2-12186.zip >>>> >>>> >>>> -- >>>> Marcus Denker Â -- http://www.marcusdenker.de >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>>> >>>> _______________________________________________ >>>> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010

Re: [Pharo-project] WebBrowser

by Marcus Denker

> > It's part of the class creation template. The only useful aspect of its existence was that you got a warning if you forgot to change the name of the subclass in the template. > -> It was part of a test package. Test packages only contain tests and artefacts used *by tests*. -> The class has no class comment. My theory is it was just the *result* of someone forgetting to change the name of the subclass in the template, not an intended mechanism. The error message would be very strange, too. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Schwab,Wilhelm K

Levente, This was several years ago in the Windows VM. I recall both shouting at the rain with no echo at the time, and years later seeing something very close to what I had done. At the time, printAllStacks() existed (which was why I had a prayer of succeeding), but produced a very jumbled mess with linefeeds in the wrong places. I did something with adding a feed or two outside of a loop over semaphores and then adding conditionals to the feeds inside the loop. More or less; it's been a while. Great news that the vm offers a ready way to trigger printAllStacks(); there are times when it is VERY useful, and if I'm right about what started this discussion, this will be one of them. It can't hurt much if I'm wrong - the double #critical:/#wait pattern would simply not appear and we would then know something that isn't causing it :) About SIGUSR1 on Linux, is the idea to open a terminal and send kill with SIGUSR 1 to the correct process ID? Where does the dump go? I'm guessing it goes to stdout of the vm, not to the terminal that sent the signal?? That would mean that one would need to have run the vm from a terminal or otherwise have arranged in advance to capture the output. So far at least, I tend to use a terminal to launch Pharo only when I expect to want trace info (such as when debugging one of my numerical .so functions) or when I have a reproducible badness (which this appears to be). Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Friday, October 08, 2010 9:44 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem On Fri, 8 Oct 2010, Schwab,Wilhelm K wrote: > That's good to know. It probably should be a lot easier than that. At least in the Windows vm, there is/was a debug menu (part of the vm's system menu) that would dump the stack for the active process; I hacked it to dump all of them rather than just one, fixed printAllStacks() along the way, and found my problem. Think of an end user machine; you don't want to have to, or might not be able to, install development tools just to get this type of basic information. It might simply be a way of ruling out problems, but it could be very important. It's a lot easier than that. On windows just select the appropriate menu item "Dump all processes" instead of "Dump call stack". On un*x you can send SIGUSR1 to the process of the VM to make it print all stacks. IIRC Cog uses this signal for another purpose, so it doesn't work with Cog. What was the problem with printAllStacks() that you had to fix? Levente > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Adrian Lienhard [adi(a)netstyle.ch] > Sent: Friday, October 08, 2010 8:21 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 12186 image quit problem > > You can attach gdb to the VM and then call printAllStacks(). > > HTH, > Adrian > > On Oct 8, 2010, at 14:07 , Schwab,Wilhelm K wrote: > >> Do you have access to anything that will dump the callstacks for "all" processes? One of my first encounters with the Squeak update streams was trying to provide patches to the dump code... Similar features appeared years later, I suspect unrelated to my efforts. What I did was hack the VM such that the dump (on the vm menu) gave all (non-dead IIRC) processes rather than just that for the active process; for it to be readable required some changes to when the dump adds a line feed. >> >> Seeing which threads are waiting on semaphores wrapped in critical sections can be a huge help in finding deadlocks. Get it to lock up, then ask the vm for the dump and look for the offenders. If we don't have this, we should. >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alexander LazareviÄ [laza(a)blobworks.com] >> Sent: Friday, October 08, 2010 5:06 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] 12186 image quit problem >> >> Just when I was about to test drive Torstens configuration of >> ExternalWebBrowser, the image hangs somewhere while loading. I'm able >> to abort it and find myself in some ensure block of an crticial >> section of WeakArray finalization?! Trying to quit just hangs the >> image for good. >> BTW, this is on Windows. >> >> Alex >> >> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> Strange... >>> Linux VM 4.0.3.2202 from squeakvm.org worked well and your prebuilt image >>> works with all this three virtual machines. Any idea why? >>> -- Pavel >>> >>> On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>>> >>>> On Oct 8, 2010, at 10:39 AM, Pavel Krivanek wrote: >>>> >>>>> Hmm, this is the result for Linux and >>>>> cogvm 3.9-7 and pharovm 3.10-3 >>>>> >>>>> >>>> >>>> can you try: >>>> >>>> https://gforge.inria.fr/frs/download.php/27589/PharoCore-1.2-12186.zip >>>> >>>> >>>> -- >>>> Marcus Denker -- http://www.marcusdenker.de >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>>> >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > 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 >

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > On Fri, Oct 8, 2010 at 12:43 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> On Oct 8, 2010, at 12:39 PM, Pavel Krivanek wrote: >> >> > Hi Marcus, >> > >> > is that really all what happened between 12172 and 12186? >> > >> > update12186 >> > Issue 3071: Â fixing timestamp tests >> > Issue 3068: Â Non portable SmalltalkImage>>platformName >> > deprecationWarning >> > Issue 3063: Â removing explain >> > Issue 3039: Â There should not be any configuration on Core >> > >> > It doesn't explain the problems with VM versions and in 12186 I cannot >> > build the PharoKernel (it hangs without error in unload phase) >> > >> No, we loaded: >> >> Issue 3002: Â Â A new finalization code ready for integration in Pharo >> http://code.google.com/p/pharo/issues/detail?id=3002 > > ok, can you reproduce this on your VM? > - take prebuilt 12186 > - run the image with a file as argument that contains: > Â SmalltalkImage current snapshot: true andQuit: true. > -Â run the image with a file as argument that contains: > 5 timesRepeat: [Smalltalk garbageCollect]. > SmalltalkImage current snapshot: false andQuit: true. > The problem is in MCMethodDefinition>>shutdown. Saving works, if i change it to: shutDown " WeakArray removeWeakDependent: Definitions." Definitions := nil. Not sure what happens there.. Also, it runs without fix, if i do: WeakArray restartFinalizationProcess. 5 timesRepeat: [Smalltalk garbageCollect]. SmalltalkImage current snapshot: false andQuit: true. > -- Pavel > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 8, 2010