- Pharo-dev - lists.pharo.org

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

On 8 October 2010 19:54, Alexander LazareviÄ <laza(a)blobworks.com> wrote: > Igor, > > maybe this just passed me by, but is this supposed to work only with > some finalization support in the vm? So is PharoCore1.2 only usable > with a very recent vm? Which VMMaker version is needed or what does > your squeak -version say? > In that case I did not say a word! ;) > nope, it should work w/o problems with older vms. It runs w/o problems in windoze with following vms: Smalltalk vmVersion 'Squeak3.10.2 of 11 February 2010 [latest update: #9314]' WeakFinalizationList hasNewFinalization false Smalltalk vmVersion 'Squeak4.1 of 17 April 2010 [latest update: #9957]' WeakFinalizationList hasNewFinalization true > Alex > > 2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: >> 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. >> >> _______________________________________________ >> 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] 12186 image quit problem

by Alexander LazareviÄ

Igor, maybe this just passed me by, but is this supposed to work only with some finalization support in the vm? So is PharoCore1.2 only usable with a very recent vm? Which VMMaker version is needed or what does your squeak -version say? In that case I did not say a word! ;) Alex 2010/10/8 Igor Stasenko <siguctua(a)gmail.com>: > 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. > > _______________________________________________ > 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] DejaVu vs Bitmap DejaVu / missing fonts folder

by Alain Plantec

Maybe you can make it work with TT fonts. In order to install them, open the Settings browser then Under Appearance/Standard Fonts, click on the Launch button of "Update font from system" and then choose another font. Cheers Alain Le 08/10/2010 18:40, Alain Plantec a Ã©crit : > Le 08/10/2010 14:37, Veronica Isabel Uquillas Gomez a Ã©crit : >> Hi, >> >> I would like to know if i am the only one having the indentation >> problem when using bitmap fonts. >> >> The Torch dashboard makes use of small and big DejaVu Sans fonts. For >> configuring it the fonts folder is needed (that now is gone in the >> last version pharo 1.1.1 dev, why?). >> Got the suggestion of using the new DejaVu package and I tried... >> However, they are Bitmap DejaVu fonts and I have the problem of text >> indentation. >> I show the changed source code in popup views. With DejaVu sans fonts >> the text appears as it is written (first image), but with Bitmap >> fonts not -- all is aligned to the left, and it is impossible to read >> a method like that (second image). >> >> Do I need to set something else for those fonts to work? > Hi Veronica, > > After the loading, to install them: > DejaVuHolder installFull. > or > DejaVuHolder installSizes: #(5 7 8 9 10 11 24) > if you only want a subset > >> Any idea why do I have this problem? > I've tried with the 1.1.1 version on Linux and the indentation seems > ok also with small fonts (5, 6, 7). > See the screenshot. > > Cheers > Alain > >> Can the fonts folder be include again in the distribution? >> >> Best regards, >> Veronica Uquillas >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Schwab,Wilhelm K

Not sure I follow. Is this saying that one chooses between the default console output and printAllStacks(), or is it making printAllStacks() happen in response to the signal and leaving the usual output in place too? I guess another option might be that all stacks get printed instead of just the active process?? ________________________________________ 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 12:12 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem On Fri, 8 Oct 2010, Alexander LazareviÄ wrote: > 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 Indeed. Thanks for clarifying. Levente > > Alex > > _______________________________________________ > 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] DejaVu vs Bitmap DejaVu / missing fonts folder

by Alain Plantec

Le 08/10/2010 14:37, Veronica Isabel Uquillas Gomez a Ã©crit : > Hi, > > I would like to know if i am the only one having the indentation problem when using bitmap fonts. > > The Torch dashboard makes use of small and big DejaVu Sans fonts. For configuring it the fonts folder is needed (that now is gone in the last version pharo 1.1.1 dev, why?). > Got the suggestion of using the new DejaVu package and I tried... However, they are Bitmap DejaVu fonts and I have the problem of text indentation. > I show the changed source code in popup views. With DejaVu sans fonts the text appears as it is written (first image), but with Bitmap fonts not -- all is aligned to the left, and it is impossible to read a method like that (second image). > > Do I need to set something else for those fonts to work? Hi Veronica, After the loading, to install them: DejaVuHolder installFull. or DejaVuHolder installSizes: #(5 7 8 9 10 11 24) if you only want a subset > Any idea why do I have this problem? > I've tried with the 1.1.1 version on Linux and the indentation seems ok also with small fonts (5, 6, 7). See the screenshot. Cheers Alain > Can the fonts folder be include again in the distribution? > > Best regards, > Veronica Uquillas > > > > > > > > > > > > > > > > > _______________________________________________ > 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] Seaside and KomHttpServer in Pharo 1.2

by Dale Henrichs

Hi Torsten, I have started on the update process for the Seaside configs. I got hung up for a day or two, since recent changes to Grease for Pharo1.1 compat broke Seaside3.0 on Pharo1.0... I will get back on the horse next week and finish up new revs for the Seaside configs Thanks for the gentle reminder:) Dale On 10/08/2010 02:38 AM, Torsten Bergmann wrote: > Hi Dale, > > again I typically use my MetaSource application to > see if one can bootstrap a full seaside app in Pharo using > Metacello: > > -------------------------------------------------------------------------- > Gofer new > squeaksource: 'MetaSource'; > package: 'ConfigurationOfMetaSource'; > load. > > ((Smalltalk at: #ConfigurationOfMetaSource) project version: '1.4') load > -------------------------------------------------------------------------- > > Works well in "Pharo 1.1." but not in "PharoCore 1.2": > > In Pharo 1.2 some methods are deprecated and Seaside 3.0 still > uses ConfigurationOfKomHttpServer 1.3 instead of the newer 1.5. > > So the question is: is it planned to use the newer KomHttpServer > packages in the near future for Seaside 3.0 so I can switch to > Pharo 1.2 early? Or is this planned when Pharo 1.2 is mature and > released. > > Thx > Torsten > >

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Levente Uzonyi

On Fri, 8 Oct 2010, Alexander LazareviÄ wrote: > 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 Indeed. Thanks for clarifying. Levente > > Alex > > _______________________________________________ > 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 Levente Uzonyi

On Fri, 8 Oct 2010, Igor Stasenko wrote: > 2010/10/8 Levente Uzonyi <leves(a)elte.hu>: > 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. > whatever.. config fails to locate this file. Its not my fault :) Maybe I wasn't clear. I tried to say that the configuration should be fixed, because it contains a typo. FFI-Pools.em.2 doesn't exist, it should be FFI-Pools.eem.2. Levente > > 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 > _______________________________________________ > 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] UUID and Cog?

by Levente Uzonyi

On Fri, 8 Oct 2010, David T. Lewis wrote: > 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. AFAIK 64-bit versions of Ubuntu 8.04, 8.10 and Debian 5.0 don't have a 32-bit package for libuuid. A relevant bug report can be found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540014 Levente > > Thanks! > > Dave > > > _______________________________________________ > 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] Cmd-t in OB?

by Tudor Girba

Hi, To me this discussion again raises the point of what I call the "default" case for development :). Lukas, the simplest thing that you can do at this moment is to introduce a "default" version (see those in the ConfigurationOfGlamour/Mondrian/Moose...). This is nothing but your order of packages. Afterwards, you just load that one. When someone wants to hardcode a version, you just spawn this version with the package versions you have in the image. Like this, you have best of both worlds: (1) lightweight management for development, and (2) controlled versioning for releases. Cheers, Doru On 8 Oct 2010, at 17:25, Lukas Renggli wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "One cannot do more than one can do."

Oct. 8, 2010