October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] 12186 image quit problem

by Alexander LazareviÄ

2010/10/8 Levente Uzonyi <leves(a)elte.hu>: > 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. I think it's like that: On a vanilla/standard unix vm SIGUSR1 just terminates the vm. With a cog vm you trigger a printAllStacks with that Signal. http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html Alex

Oct. 8, 2010

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

by Alexandre Bergel

> 4. loading should not require to additional infrastructure to be > loaded into a Pharo image (I imagine a server that has all > configurations preloaded and that returns Gofer scripts that can be > executed in the target image) Let's be imaginative. I want the server to return an image segment that I can directly install in my image :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 8, 2010

Re: [Pharo-project] UUID and Cog?

by David T. Lewis

Moving to vm-dev list for follow up related to the UUIDPlugin. On Wed, Oct 06, 2010 at 04:37:00AM +0200, Levente Uzonyi wrote: > On Tue, 5 Oct 2010, David T. Lewis wrote: <unrelated discussion of Cog configurations snipped> > >As far as I know, there have been no reports of libuuid failures on > >the Unix VMs since Ian changed to using an internal UUIDPlugin, so > >this is an easy fix if it works for Cog also. > > If libuuid is not available, the internally built UUIDPlugin crashes the > VM. > > Levente Levente, thanks for identifying this. I was able to reproduce this on my system by removing the libuuid libraries, after which a VM with internal UUIDPlugin refuses to load: /usr/local/lib/squeak/4.3.4-2316/squeakvm: error while loading shared libraries: libuuid.so.1: cannot open shared object file: No such file or directory I reopened the issue on Mantis http://bugs.squeak.org/view.php?id=7358 with the following explanation: > Changing status from resolved back to acknowledged. Levente Uzonyi > reports that the plugin, if built internally, will crash the VM if > the target system does not have libuuid installed. > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-October/033760.ht… [^] > > I reproduced this by removing the libuuid libraries from my Linux system. > The result is that the VM fails to load due to the missing library. It > never reaches main(), so this is not something that can be addressed in > the code. Presumably a static linked VM would work, but this would > probably lead to problems elsewhere. > > Summary: Building UUIDPlugin internally is a workaround for the libuuid > bug that is present on some systems, but it results in an unusable VM for > people who do not have the uuid library installed with their OS. Levente, can you say anything about what OS platforms would not have libuuid installed? I am guessing that it is a scenario involving a 64-bit OS for which some of the 32-bit runtime libraries were not installed, but if you can clarify this it would be helpful. Thanks! Dave

Oct. 8, 2010

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

by Alexandre Bergel

> 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. Yep, I know the value of a mailing list for a community. However, I simply cannot afford to spend hours reading all (very long) the emails on that topic. Once a Pharo community will be bootstrapped in Chile, then I will be more able to participate on topics that do not directly matter for the university, my employer. Writing a six-lines email is as valuable as writing a method of six-line of code, at least to me :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 8, 2010

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

by Lukas Renggli

Yeah, I agree, there is definitely a need for Metacello. I suggest to make it easier to use, faster and more lightweight. Currently it is more the opposite. I propose something along Gofer, but for Metacello (I believe somebody already did something like this?): 1. loading the latest stable version must be dead simple Metacello new project: 'OB'; loadStable 2. loading the latest development version must be dead simple Metacello new project: 'OB'; loadDevelopment 3. specifying what groups to load must be dead simple Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load 4. loading should not require to additional infrastructure to be loaded into a Pharo image (I imagine a server that has all configurations preloaded and that returns Gofer scripts that can be executed in the target image) Lukas On 8 October 2010 17:15, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch

Oct. 8, 2010

Re: [Pharo-project] WebBrowser

by Miguel CobÃ¡

El vie, 08-10-2010 a las 09:06 +0200, Marcus Denker escribiÃ³: > The nice thing is: we can put things back, easily. I think it's better > to remove and put back than to never change anything because > someone might need it. + 100 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Levente Uzonyi

On Fri, 8 Oct 2010, Igor Stasenko wrote: > 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 It should be FFI-Pools.eem.2. Levente > > 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. _______________________________________________ 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

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