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

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

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

by Mariano Martinez Peck

On Fri, Oct 8, 2010 at 5:25 PM, Lukas Renggli <renggli(a)gmail.com> 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?): > Yes, Esteban: http://www.smallworks.com.ar/en/community/GoferProjectLoader > > 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 > > it does all that. > 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) > > this can be discussed with dale. > 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 >

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

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 :) > > 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.

Oct. 8, 2010

Re: [Pharo-project] 12186 image quit problem

by Alexander LazareviÄ

.. or you have a very recent OSProcessPlugin and activate SIGUSR1 2010/10/8 Alexander LazareviÄ <laza(a)blobworks.com>: > 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