February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Usable state PharoMorphicView

by S Krish

Now I hope it should load and work fine for the first look at a simpler morphic UI construction.. Will hunker down and work on a plan.. this point onwards.. There is a bigger pie to cut .. n eat .. this is just a piece in the jigsaw or is replaced by a more competent piece.. but for now this is more complete and workable over the range of need.. http://skrishnamachari.wordpress.com/2012/02/14/pharo-morphic-view-03/ http://skrishnamachari.files.wordpress.com/2012/02/pharomorphicview_02.pdf

Feb. 14, 2012

Re: [Pharo-project] Feedback from lecture :(

by Eliot Miranda

On Tue, Feb 14, 2012 at 11:52 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 February 2012 20:22, Lukas Renggli <renggli(a)gmail.com> wrote: > >>> students in the lecture on windows downloaded cogvm I do not from > whereâ¦ > >>> and used pharo1.3 and > >>> some experienced crashes. > >> > >> This has been reported at least 10 times per week since the last 6 > months. > >> The VMs of the one click are FUC.. old and buggy. If nobody have time to > >> make a new one click (we are all busy), please please please, remove it > from > >> the website. We give so much bad impression. It is worst than having no > one > >> click. > > > > You cannot say that, because I updated the One-Click distribution less > > than a month ago: > > > > > https://github.com/renggli/builder/commit/7623726096db2e3fa58eefe267c62ba17… > > > > People using this code get the latest available CogVM. The problem is > > that Pharo maintains its own unmaintained fork. > > > > Huh? > > See the build history: > https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Unix/ > > last build 26 Jan > > https://ci.lille.inria.fr/pharo/view/Cog/job/StackVM-Mac-Cocoa-blessed/ > again, last build 28 Jan. > > Here just a list of changes in latest builds: > (you can find them here: > > https://ci.lille.inria.fr/pharo/view/Cog/job/Cog%20Git%20Tracker%20%28bless… > ) > Changes > #26 (Jan 26, 2012 5:33:21 PM) > > replaced spaces with tabs â camillobruni / detail > > #25 (Jan 26, 2012 5:18:48 PM) > > added new pharo scropt â camillobruni / detail > - fixed configuraiton to open a Workspace with example > configurations â camillobruni / detail > trying to fix issues with the command line arguments â camillobruni / > detail > more work on the image script and the howto â camillobruni / detail > tried to implemention dir_lookupEntry for Cococa OSX â camillobruni / > detail > extended howto with osx gcc change â camillobruni / detail > fixed back opengl changes â camillobruni / detail > fixed VM path, returning bundlepath with app name â camillobruni / > detail > implemented direEntryLookup and refactored a bit the source code â > camillobruni / detail > more howto â camillobruni / detail > minor change in the HOWTO â camillobruni / detail > undoing accidental changes â camillobruni / detail > > #23 (Jan 25, 2012 8:06:27 PM) > > removed deprecated calls to recordKeystroke â guillermopolito / detail > removed unused comment â guillermopolito / detail > removed old code â guillermopolito / detail > removed dead code â guillermopolito / detail > removed dead code â guillermopolito / detail > removed lot of debug only code â guillermopolito / detail > removed temporal file â guillermopolito / detail > removed more debug printfs â guillermopolito / detail > formatted the code â guillermopolito / detail > little style change â guillermopolito / detail > added mappings to numeric keypad â guillermopolito / detail > added comments to unicode conversion â guillermopolito / detail > more comments â guillermopolito / detail > > For the full list of changes in VM , visit > https://gitorious.org/cogvm/blessed/commits/master > > but just don't say bullshit like unmaintained unmaintained VM. > The substantive change is the ephemeron changes. I'm not convinced that this code is correct. I'm convinced that the approach is wrong. See my postings on using the format word to encode ephemeronness. > > Now if people do not downloading it, do not report problems, and > sticking to Eliot's VMs, it makes no sense > to do anything. > You know well, that we cannot force people to use it or not. > > (i triggered new build now just to check if everything ok). > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Feb. 14, 2012

Re: [Pharo-project] garbage collection

by Igor Stasenko

On 14 February 2012 23:45, Milan Mimica <milan.mimica(a)gmail.com> wrote: > Ah great! I knew something weird was going on. It will be much easier to > detect possible semaphore leakage once the VM itself stops leaking them. > VM cannot leak semaphores because their lifetime are controlled by image. The change i proposing is in image, not VM. Here the small snippet of code i wrote to check if every semaphore registered in external semaphore table belongs to something, but not just held by table itself: | semaphores arr | arr := ExternalSemaphoreTable unprotectedExternalObjects. semaphores := arr reject: #isNil. semaphores collect: [:sema | sema -> (sema pointersTo reject: [:ptr | ptr == arr or: [ptr == semaphores ] ] ) ] Can you try invoking it on your image , look for those who has an empty array, which will mean that there is no references to it except semaphore table itself. > > > On 14 February 2012 22:38, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Just in time. >> >> Before leaving home last week Friday, i sketched things to be checked >> on next week. >> And one of them was: >> Â - turning an external semaphore table to hold semaphores weakly. >> >> The problem that currently a >> Smalltalk externalSemaphoreTable >> is an Array, means that even if in the rest of image nobody points to >> some semaphore in that array, >> it will be not GCed unless someone will cleanup the entry there. >> >> Now the reasons why certain semaphores are leaked (and not cleaned up >> in external semaphore table) >> could be different, like abnormal process termination, forgetting >> putting Â #ensure: etc. >> But by making that array to be weak array we can make sure that it >> won't overflow with garbage which no-one uses. >> >> And of course if it overflows because those semaphores is actually >> used, then its another story. >> >> On 14 February 2012 22:01, Milan Mimica <milan.mimica(a)gmail.com> wrote: >> > This is more of a GC theory question perhaps, but I do have practical >> > problems, so: I'm trying to figure out how come my headless Pharo 1.3 >> > image >> > with fairly recent Cog running Magma ran out of Semaphores. I know there >> > is >> > a fixed limit on number of semaphores Cog can handle, and only Magma and >> > RFB >> > server have been running on this image for two months, and there wasn't >> > any >> > heavy load whatsoever, so something must be leaking semaphores - or more >> > likely - something must be leaking objects having reference(s) to >> > semaphore(s).Â I am not leaking sockets btw. >> > >> > At the moment there is about 1400 instances of Semaphore class, and >> > around >> > 400 after GC. >> > So first question is: Suppose I haven't run GC manually, could the >> > semaphore >> > limit be hit? >> > >> > 400 is still too high for a idling image, don't you think? >> > >> > Anyway, what I try next is to shut down Magma completely and try to >> > clean >> > the memory by hand. I notice some MaServerSockets are still floating >> > around >> > so I track the pointers and I find that all the references are circular! >> > Question two: Does Pharo's GC solve circular references? If yes, how >> > good is >> > it at it? >> > >> > But then, thinking more about it, the whole running image is one big >> > graph >> > of circular references, you wouldn't want the GC to clean that :) So how >> > does it really work? That's my naive view anyway. >> > >> > After I wrote all this I figure I'm better of taking a fresh new image >> > and >> > load what I need into it, even if I have to do it every two months. Not >> > saving the image is also an option. Yeah, I think I'm going to do just >> > that. >> > I found my solution, at least this e-mail served for something. Since I >> > don't have a blog I'll send it anyway. >> > >> > >> > -- >> > Milan Mimica >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Milan Mimica > http://sparklet.sf.net -- Best regards, Igor Stasenko.

Feb. 14, 2012

Re: [Pharo-project] garbage collection

by Milan Mimica

Ah great! I knew something weird was going on. It will be much easier to detect possible semaphore leakage once the VM itself stops leaking them. On 14 February 2012 22:38, Igor Stasenko <siguctua(a)gmail.com> wrote: > Just in time. > > Before leaving home last week Friday, i sketched things to be checked > on next week. > And one of them was: > - turning an external semaphore table to hold semaphores weakly. > > The problem that currently a > Smalltalk externalSemaphoreTable > is an Array, means that even if in the rest of image nobody points to > some semaphore in that array, > it will be not GCed unless someone will cleanup the entry there. > > Now the reasons why certain semaphores are leaked (and not cleaned up > in external semaphore table) > could be different, like abnormal process termination, forgetting > putting #ensure: etc. > But by making that array to be weak array we can make sure that it > won't overflow with garbage which no-one uses. > > And of course if it overflows because those semaphores is actually > used, then its another story. > > On 14 February 2012 22:01, Milan Mimica <milan.mimica(a)gmail.com> wrote: > > This is more of a GC theory question perhaps, but I do have practical > > problems, so: I'm trying to figure out how come my headless Pharo 1.3 > image > > with fairly recent Cog running Magma ran out of Semaphores. I know there > is > > a fixed limit on number of semaphores Cog can handle, and only Magma and > RFB > > server have been running on this image for two months, and there wasn't > any > > heavy load whatsoever, so something must be leaking semaphores - or more > > likely - something must be leaking objects having reference(s) to > > semaphore(s). I am not leaking sockets btw. > > > > At the moment there is about 1400 instances of Semaphore class, and > around > > 400 after GC. > > So first question is: Suppose I haven't run GC manually, could the > semaphore > > limit be hit? > > > > 400 is still too high for a idling image, don't you think? > > > > Anyway, what I try next is to shut down Magma completely and try to clean > > the memory by hand. I notice some MaServerSockets are still floating > around > > so I track the pointers and I find that all the references are circular! > > Question two: Does Pharo's GC solve circular references? If yes, how > good is > > it at it? > > > > But then, thinking more about it, the whole running image is one big > graph > > of circular references, you wouldn't want the GC to clean that :) So how > > does it really work? That's my naive view anyway. > > > > After I wrote all this I figure I'm better of taking a fresh new image > and > > load what I need into it, even if I have to do it every two months. Not > > saving the image is also an option. Yeah, I think I'm going to do just > that. > > I found my solution, at least this e-mail served for something. Since I > > don't have a blog I'll send it anyway. > > > > > > -- > > Milan Mimica > > > > > > -- > Best regards, > Igor Stasenko. > > -- Milan Mimica http://sparklet.sf.net

Feb. 14, 2012

Re: [Pharo-project] garbage collection

by Igor Stasenko

Just in time. Before leaving home last week Friday, i sketched things to be checked on next week. And one of them was: - turning an external semaphore table to hold semaphores weakly. The problem that currently a Smalltalk externalSemaphoreTable is an Array, means that even if in the rest of image nobody points to some semaphore in that array, it will be not GCed unless someone will cleanup the entry there. Now the reasons why certain semaphores are leaked (and not cleaned up in external semaphore table) could be different, like abnormal process termination, forgetting putting #ensure: etc. But by making that array to be weak array we can make sure that it won't overflow with garbage which no-one uses. And of course if it overflows because those semaphores is actually used, then its another story. On 14 February 2012 22:01, Milan Mimica <milan.mimica(a)gmail.com> wrote: > This is more of a GC theory question perhaps, but I do have practical > problems, so: I'm trying to figure out how come my headless Pharo 1.3 image > with fairly recent Cog running Magma ran out of Semaphores. I know there is > a fixed limit on number of semaphores Cog can handle, and only Magma and RFB > server have been running on this image for two months, and there wasn't any > heavy load whatsoever, so something must be leaking semaphores - or more > likely - something must be leaking objects having reference(s) to > semaphore(s).Â I am not leaking sockets btw. > > At the moment there is about 1400 instances of Semaphore class, and around > 400 after GC. > So first question is: Suppose I haven't run GC manually, could the semaphore > limit be hit? > > 400 is still too high for a idling image, don't you think? > > Anyway, what I try next is to shut down Magma completely and try to clean > the memory by hand. I notice some MaServerSockets are still floating around > so I track the pointers and I find that all the references are circular! > Question two: Does Pharo's GC solve circular references? If yes, how good is > it at it? > > But then, thinking more about it, the whole running image is one big graph > of circular references, you wouldn't want the GC to clean that :) So how > does it really work? That's my naive view anyway. > > After I wrote all this I figure I'm better of taking a fresh new image and > load what I need into it, even if I have to do it every two months. Not > saving the image is also an option. Yeah, I think I'm going to do just that. > I found my solution, at least this e-mail served for something. Since I > don't have a blog I'll send it anyway. > > > -- > Milan Mimica > -- Best regards, Igor Stasenko.

Feb. 14, 2012

Re: [Pharo-project] Who can help for the pharo web site

by laurent laffont

Stef, I've added http://www.pharo-project.org/community/how-to-contribute To create a new page in Community, I've selected community block then clic on "insert Subpage" in the top menu. If you don't feel to add it on the website yourself, you can send me the content by mail and I will add it. Laurent On Tue, Feb 14, 2012 at 8:47 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Hi guys > > Adrian left and now I cannot manage the pharo web site. I need help > because I do not understand how to edit it. > Today by accident I removed the (broken) twitter box. So what do we do? > I was thinking to port everything in plain static html so that I can edit > the pages fast and easy. > > I would like to add a how to contribute page. > Our web site does not evolve anymore because nobody cares about it. > So I can try to do it but I will port everything into html. > > Stef (tired to do too many things and fed up about systematic bashing). >

Feb. 14, 2012

Re: [Pharo-project] NB How can I pass a NULL argument?

by Igor Stasenko

On 14 February 2012 22:59, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > I started with a new image and loadedÂ ConfigurationOfNativeBoost. But it's > still not working. > > First I do a call to get a handle: > > "UEnumeration* ucal_openTimeZones(UErrorCode * ec)" > > self nbCall: #( void* ucal_openTimeZones_48( ICUErrorCodeNB* anErrorCode ) ) > module:Â 'libicui18n.dylib' > > This call succeeds. I store the result in a subclass ofÂ NBExternalHandle > using the #value: class method. > > In the second call I want to use the handle to retrieve the next element: > > self nbCall: #( char* uenum_next_48(ICUEnumerationNB* aHandle, int* nil, > ICUErrorCodeNB* anErrorCode ) ) module:Â 'libicuuc.dylib' > > But this call still causes the image to disappear. I think the nil and > errorCode arguments are all right. Is there something wrong with the first > argument? I cannot say precisely, because i don't see a code.. so lets see.. UEnumeration* U_EXPORT2 ucal_openTimeZones ( UErrorCode * ec ) returns a pointer. And you storing the pointer value to instance of ICUEnumerationNB Now i guess that next function should take that pointer value: char* uenum_next_48(ICUEnumerationNB aHandle, int* nil, ICUErrorCodeNB* anErrorCode ) but not a pointer to pointer value, like you wrote: char* uenum_next_48(ICUEnumerationNB* aHandle, int* nil, ICUErrorCodeNB* anErrorCode ) > > Jan. > > > > > > On Tue, Feb 14, 2012 at 11:34 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 13 February 2012 22:40, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: >> > Hello list, >> > >> > I want to call the following C function using NativeBoost: >> > >> > const char* uenum_next(UEnumeration * en, int32_t * resultLength, >> > UErrorCode >> > * status) >> > >> > According to the (icu4c) documentation you can pass NULL for the >> > resultLenth >> > argument [1]. But when I try: >> > >> > self nbCall: #( char* uenum_next_48( self, nil, ICUErrorCodeNB* >> > anErrorCode >> > ) ) module: 'libicuuc.dylib' >> >> should be no problem. >> you can try also to just pass zero, if it make any difference >> >> Â self nbCall: #( char* uenum_next_48( self, 0 , ICUErrorCodeNB* >> anErrorCode ) ) module: 'libicuuc.dylib' >> >> (in fact code generator should produce same code, since nil >> substituted by 0 at the end). >> >> Maybe the problem is not there, but in other arguments you passing. >> >> And, i recommend you to use ConfigurationOfNativeBoost from >> NBInstaller, but not latest packages directly, since Javier put a lot >> of changes lately and some parts might not work properly. >> >> >> > >> > My image craches. Does anyone know what I'm doing wrong? >> > >> > Jan. >> > >> > >> > [1]Â http://icu-project.org/apiref/icu4c/uenum_8h.html#a99298eabaa3874cdfd9793b2… >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Feb. 14, 2012

Re: [Pharo-project] troubles with glamour finder in pharo 1.4

by Benjamin

If you tell me how to load the code easily, and where to have a look, I can do that ;) Ben On Feb 14, 2012, at 9:58 PM, Tudor Girba wrote: > Hi, > > We are almost done with getting Glamour work on 1.4. The model works, and most of the rendering is fine as well. The only major trouble is with the rendering of the finder. In particular, the problem is the scrolling through the panes. > > The scrolling code was basically copied from OB (shamelessly :)). Something must have changed in Pharo 1.4 that disables some of the behavior. Could anyone spare a pair of eyes to look into this :). > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > >

Feb. 14, 2012

Re: [Pharo-project] garbage collection

by Sven Van Caekenberghe

On 14 Feb 2012, at 21:21, Milan Mimica wrote: > On 14 February 2012 21:09, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > There was a semaphore related problem in 1.3 that was fixed some time ago. > Doing regular image saves was one of the factors involved. > Search the mailing list or issues list for semaphore. > > Nah, leaking one semaphore per image save is not a problem. I don't save regularly. The remark on image saving was that when you save the image, you save all the crap that is running, and it accumulates every time. There is no point saving an image in production if you are persisting data externally. > Besides that I don't remember anything related being fixed. These are not necessarily related, but these are some of them: http://code.google.com/p/pharo/issues/detail?id=4910 http://code.google.com/p/pharo/issues/detail?id=4768 http://code.google.com/p/pharo/issues/detail?id=4505

Feb. 14, 2012

Re: [Pharo-project] cannot add repository in monticello

by Fabrizio Perin

Hi, the error described is different but surely related because I loaded the slice and yes, the problem was solved. Thanks Matias. Cheers, Fabrizio 2012/2/14 Matias Garcia Isaia <mgarciaisaia(a)gmail.com> > Fabrizio, > > can you confirm if it's the same issue that happens with > <http://code.google.com/p/pharo/issues/detail?id=5292> ? > > There's a slice there, maybe you can try if that fixes your problem. > > On Tue, Feb 14, 2012 at 3:02 PM, Fabrizio Perin > <fabrizio.perin(a)gmail.com> wrote: > > Hi, > > I just tried to add a new repository in Monticello and I got an error: > > the error is: > > > > MessageNotUndestood: FileDialogWindow>>directoriesFor: > > > > the repository I wanted to add was a directory. It seems to work in the > case > > you want to add a HTTP repository. > > > > The problem happen on the last Moose build (#830) and on a > > Pharo1.4a > > Latest update: #14331 > > > > downloaded from the pharo web site. > > > > Cheers, > > Fabrizio > >

Feb. 14, 2012