- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Great slowness for install CLFramework.

by Mariano Martinez Peck

On Mon, Feb 28, 2011 at 2:05 PM, nullPointer <epicfan(a)gmail.com> wrote: > I have a problem when install CLFramework package on Pharo 1.* in Windows > OS. > I get many slowness. First appears messages saying the installation is > running. And later the World freeze, a few minutes, without mouse and > keyboard events. I donÂ´t know whatÂ´s doing in that moment. > > The package is big, almost 3MB, but that I believe donÂ´t explain that > behavior. > > That behavior is more significatively on Windows. In MAC OSX is slow too, > but much more fast. > > Somebody have a similar problem? > yes, the problem can be the antivirus. Check in the archives of the mailing list or even: http://www.pharo-project.org/documentation/faq question "Pharo on Windows is terribly slow. What's wrong?" BTW, Adrian, can we create links for each question? thanks Mariano > > > Regards. > > -- > View this message in context: > http://forum.world.st/Great-slowness-for-install-CLFramework-tp3327888p3327… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Feb. 28, 2011

[Pharo-project] Great slowness for install CLFramework.

by nullPointer

I have a problem when install CLFramework package on Pharo 1.* in Windows OS. I get many slowness. First appears messages saying the installation is running. And later the World freeze, a few minutes, without mouse and keyboard events. I donÂ´t know whatÂ´s doing in that moment. The package is big, almost 3MB, but that I believe donÂ´t explain that behavior. That behavior is more significatively on Windows. In MAC OSX is slow too, but much more fast. Somebody have a similar problem? Regards. -- View this message in context: http://forum.world.st/Great-slowness-for-install-CLFramework-tp3327888p3327… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 28, 2011

Re: [Pharo-project] Metacello Configuration Pharo1.2 solo sprint ... status

by Miguel CobÃ¡

Loads correctly on: Pharo1.2rc2 Latest update: #12336 Test results: 10761 run, 10691 passes, 65 expected failures, 3 failures, 1 errors, 1 unexpected passes OS: Debian GNU/Linux 6.0 64 bits. VM: 4.0.3-2202 #1 XShm Tue Apr 13 11:56:47 PDT 2010 gcc 4.3.2 Linux vps2.piumarta.com 2.6.18-028stab053.10-ent #1 SMP Thu Feb 28 20:34:08 MSK 2008 i686 GNU/Linux plugin path: /opt/Squeak-4.0.3.2202-linux_i386/lib/squeak/4.0.3-2202/ [default: /opt/Squeak-4.0.3.2202-linux_i386/lib/squeak/4.0.3-2202/] Thanks Dale El lun, 28-02-2011 a las 08:12 +0100, StÃ©phane Ducasse escribiÃ³: > thanks! > > On Feb 28, 2011, at 6:51 AM, Dale Henrichs wrote: > > > I've just finished copying the cleaned up configurations up to MetacelloRepository. > > > > All of the configurations that are referenced in ConfigurationOfPharo validate clean ... > > > > I loaded the config into a PHaroCore image, but had a number of failed tests, but I am running on a mac and I seem to remember that there were still some failing tests on the mac ... > > > > I'll check on the hudson results first thing tomorrow morning to double check .. > > > > Dale > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Feb. 28, 2011

Re: [Pharo-project] [COTDC] 19 - NaturalLanguageFormTranslator

by laurent laffont

Sometimes I would like to write a program to dump Gary's brain into a HelpSystem book :) Laurent On Mon, Feb 28, 2011 at 12:59 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Provides support for looking up Forms by name for presentation in the UI. > Different forms can be registered for a name for different locales allowing > images presented in the UI to be localised. > > Typically used where images contain language dependent text. > > E.g. > > buttonForm := (NaturalLanguageFormTranslator localeID: Locale current > localeID) > translate: 'submit button' > > > Form translations are added like so: > > (NaturalLanguageFormTranslator isoLanguage: 'en' isoCountry: 'gb') > name: 'submit button' form: aForm > > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" < > stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 26, 2011 5:56 PM > Subject: Re: [Pharo-project] [COTDC] 19 - NaturalLanguageFormTranslator > > > > this is a funny one > Looks like a monty python one. ") > On Feb 25, 2011, at 9:08 PM, laurent laffont wrote: > > I don't know why I'm here. >> >> Laurent. >> >> On Thu, Feb 24, 2011 at 8:55 PM, laurent laffont < >> laurent.laffont(a)gmail.com> wrote: >> Today: NaturalLanguageFormTranslator >> >> >> Comment Of The Day Contest - One Day One Comment >> Rules: >> #1: Each day a not commented class is elected. Each day the best comment >> will be integrated with name of the author(s). >> #2: If you cannot comment it, deprecate it. >> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> Laurent >> >> > > >

Feb. 28, 2011

Re: [Pharo-project] Azul Pauseless GC

by Stefan Marr

Hi Andres: On 28 Feb 2011, at 11:20, Andres Valloud wrote: > Oh, ok. With such huge images, the likelyhood of any page being accessed must not be overly high. I suspect they may have to have some sort of "mark stack" that cannot be paged out to make that possible. Here you can hear Cliff bragging about some details: http://www.infoq.com/interviews/click-gc-azul Other than that, the linked article and the VEE'05 paper should cover the details better than I could. Best regards Stefan > > Andres. > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Feb. 28, 2011

Re: [Pharo-project] [COTDC] 19 - NaturalLanguageFormTranslator

by Gary Chambers

Provides support for looking up Forms by name for presentation in the UI. Different forms can be registered for a name for different locales allowing images presented in the UI to be localised. Typically used where images contain language dependent text. E.g. buttonForm := (NaturalLanguageFormTranslator localeID: Locale current localeID) translate: 'submit button' Form translations are added like so: (NaturalLanguageFormTranslator isoLanguage: 'en' isoCountry: 'gb') name: 'submit button' form: aForm Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 26, 2011 5:56 PM Subject: Re: [Pharo-project] [COTDC] 19 - NaturalLanguageFormTranslator this is a funny one Looks like a monty python one. ") On Feb 25, 2011, at 9:08 PM, laurent laffont wrote: > I don't know why I'm here. > > Laurent. > > On Thu, Feb 24, 2011 at 8:55 PM, laurent laffont > <laurent.laffont(a)gmail.com> wrote: > Today: NaturalLanguageFormTranslator > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

Feb. 28, 2011

Re: [Pharo-project] [update 1.2] #12339

by Francisco Ortiz PeÃ±aloza

i'd latest shout loaded and updated the image from System>Software update, you're right if i load latest shout again it works but would like to understand why an update broke shout maybe there are changes to integrate to shout. Thanks On Mon, Feb 28, 2011 at 5:05 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > How do you update? > Because I took 12339 and loaded ConfigurationOfShout and it works > I did the same with configurationOfPhaor and it works. > > >> Hi, >> >> after updating to this version, Shout starts to fail sendind DNU >> everywere. One of the things i detect was this update loads in my >> image a Shout package signed markus.denker.1... >> >> Is there a way to see what're the changes on an update? >> >> Thanks, >> Francisco >> >> On Sun, Feb 27, 2011 at 11:49 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> 12339 >>> ----- >>> >>> Issue 3575: Â Â [Failing Tests] Obsolete classes after tests (workaround) >>> -- >>> Marcus Denker Â -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> >> > > >

Feb. 28, 2011

Re: [Pharo-project] Azul Pauseless GC

by Andres Valloud

>> What kind of documentation do you mean? > A paper about the GC algorithm, the name of the algorithm? There are some docs that state what happens, the docs come with the VM sources. But, basically, when the IGC is marking, then writes into marked objects mark objects. This allows mark stack consistency. You can mark incrementally until the mark stack is empty. Then you can zero out weak references that are gone (and deal with ephemerons). After that, you can also sweep dead object bodies and put them back into the corresponding free block "lists". The VisualWorks implementation is somewhat complex because there are many moving parts. The IGC marks whatever is in old space. Perm space ("permanent" old objects) are assumed to never be garbage, so they aren't even marked. New objects are not marked either because they are managed more efficiently by the new space scavenger. There are remember tables that allow you to do all of this effectively. Special care must be taken when tenuring new objects into old space if they were referenced from a marked object in the remember table for new space. In 64 bit systems, the class table is weak so you have to treat it as a special case. Etcetera :)... > Their target is/was mainly financial/trade applications huge heaps, > on huge and expensive custom hardware. Order of 1000 cores per box > with a 54-core custom chip. Wow... I wonder what happens when (not if) it crashes. > I guess it is some variation of a three-color incremental mark/sweep? IIRC, "three-color" refers to "not marked, marked, and scanned". If so, yes, it's sort of like that. > One of the tricks they are pulling for that is that they return the > memory page to the OS, and thus, they run into a trap when ever > someone is referring to an old object address. Then, when that > occurs they just fix the address to the new one. (as far as I > remember...) Oh, ok. With such huge images, the likelyhood of any page being accessed must not be overly high. I suspect they may have to have some sort of "mark stack" that cannot be paged out to make that possible. Andres.

Feb. 28, 2011

Re: [Pharo-project] Azul Pauseless GC

by Stefan Marr

Hi Andres: On 28 Feb 2011, at 09:41, Andres Valloud wrote: >> Is VisualWorks' GC documented somewhere? > > What kind of documentation do you mean? A paper about the GC algorithm, the name of the algorithm? > >> However, you might want to read the VEE'05 paper directly, the GC >> they use is 'nothing-like' a typical incremental GC. The read-barrier >> is the key here, and that is a rather exotic approach due to its >> constant overhead on standard systems. > > I thought they get away with the extra expenditure because they can hide it under a multicore CPU (with the associated mutex section overhead etc), and because they have a compacting IGC that allows their very large images to run. Probably it's a design decision to support huge apps. Their target is/was mainly financial/trade applications hugh heaps, on hugh and expensive custom hardware. Order of 1000cores per box with a 54-core custom chip. >> So, just in case VisualWorks is actually using something similar, a >> reference to a paper or some such would be great. > > VisualWorks' IGC can mark and sweep incrementally. It does not compact incrementally, either. Somewhere in the source documentation there's an assertion that the read barriers to do that would be painful, so compaction is left to the stop-the-world GC. The rest is pretty similar, including things like the targeted pause times (I'm almost done with an overhaul of that bit of the IGC implementation, actually). I guess it is some variation of a three-color incremental mark/sweep? > Now, if you had a read check to see whether the object body was forwarded or not, then you could also compact incrementally. Unfortunately, checking before every read would probably cost you performance wise (plus: what happens when you want to forward an object body referenced by another thread in registers in the middle of an optimized section?). That is the whole point of their design. They have a hardware read barrier, and they use traps do make that possible. One of the tricks they are pulling for that is that they return the memory page to the OS, and thus, they run into a trap when ever someone is referring to an old object address. Then, when that occurs they just fix the address to the new one. (as far as I remember...) > So, depending on the application, it might be better to avoid stopping the world, while in other cases it might be preferable to skip the IGC completely and using the stop-the-world GC. As I said, they are after big financial and commerce applications, the stories Cliff Click is usually telling is that if they would need to do a GC in pre-Christmas load situations their customers would lose a lot of sales... Everything is plain old Java, no idea what kind of custom solutions those companies built on top of that. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Feb. 28, 2011

Re: [Pharo-project] Azul Pauseless GC

by Andres Valloud

> Is VisualWorks' GC documented somewhere? What kind of documentation do you mean? > However, you might want to read the VEE'05 paper directly, the GC > they use is 'nothing-like' a typical incremental GC. The read-barrier > is the key here, and that is a rather exotic approach due to its > constant overhead on standard systems. I thought they get away with the extra expenditure because they can hide it under a multicore CPU (with the associated mutex section overhead etc), and because they have a compacting IGC that allows their very large images to run. Probably it's a design decision to support huge apps. > So, just in case VisualWorks is actually using something similar, a > reference to a paper or some such would be great. VisualWorks' IGC can mark and sweep incrementally. It does not compact incrementally, either. Somewhere in the source documentation there's an assertion that the read barriers to do that would be painful, so compaction is left to the stop-the-world GC. The rest is pretty similar, including things like the targeted pause times (I'm almost done with an overhaul of that bit of the IGC implementation, actually). Now, if you had a read check to see whether the object body was forwarded or not, then you could also compact incrementally. Unfortunately, checking before every read would probably cost you performance wise (plus: what happens when you want to forward an object body referenced by another thread in registers in the middle of an optimized section?). So, depending on the application, it might be better to avoid stopping the world, while in other cases it might be preferable to skip the IGC completely and using the stop-the-world GC. Finally, I am curious as to what kind of applications need on the order of 1TB of address space in a single "image". Those image scales impose specific performance penalties e.g.: the IGC has to be more complex. I wonder if those apps couldn't be written in a more "agent-like" manner to substitute controlled inter-image communication for the IGC complexities that affect the runtime in a pervasive way. Do you know what kind of apps are those? Andres.

Feb. 28, 2011