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

Re: [Pharo-project] garbage collection

by Milan Mimica

On 14 February 2012 23:54, Milan Mimica <milan.mimica(a)gmail.com> wrote: > On 14 February 2012 22:55, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> 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. >> > > There is 69 of such semaphores, out of hundreds in total. Not much :-/ > On a normal image there is only a few. > Should say that the 69 leaked semaphores are probably there because of the bug that leaks a semaphore on each image save. Still, that should be causing major problems in my case. -- Milan Mimica http://sparklet.sf.net

Feb. 20, 2012

Re: [Pharo-project] Nautilus Refactorings

by Sven Van Caekenberghe

On 20 Feb 2012, at 16:01, Benjamin wrote: >> Also, the window about menu displays the class comment of NautilusUI, maybe you can make it a bit more sexy. > > I do not get it, sorry OK ;-) Now gives: While it should be more like: ;-)

Feb. 20, 2012

Re: [Pharo-project] Script for building 1-click images

by Marcus Denker

On Feb 20, 2012, at 4:27 PM, StÃ©phane Ducasse wrote: > > On Feb 20, 2012, at 11:03 AM, Martin Sandiford wrote: > >> On Monday, February 20, 2012, Sven Van Caekenberghe wrote: >> But I believe the general feeling is that the VM included in the 1.3 One-Click is not the most up to date one, maybe someone else can give a definitive answer of what should be done best to make the most up to date One-Click. >> >> The script fetches the latest successful CogVM build from Jenkins for Linux and MacOS. If there is a better source, then it should not be too hard to change. >> >> Would also appreciate any info on the best source for a Windows VM tooâ¦ > > we have some problems of stability with the Windows jenkins slave. But lots of progress lately... thanks to Christophe. 32 win slave is up and connected to https://ci.lille.inria.fr/pharo/computer/pharo-build-732.lille.inria.fr/ Next steps: -> Win VM Build setup there -> Pharo setup so we can run the tests. After that: -> Win 64bit slave -> Linux 64bit slave -- Marcus Denker -- http://marcusdenker.de

Feb. 20, 2012

Re: [Pharo-project] [update 1.3] #13323

by StÃ©phane Ducasse

>> -- >> Marcus Denker -- http://marcusdenker.de > > Thank you ! No you thank you :) > > Sven >

Feb. 20, 2012

Re: [Pharo-project] garbage collection

by StÃ©phane Ducasse

For your information igor and marcus fixed the interrupt handler in pharo1.4 nd now you can avoid dot kill the finalize process. Stef >>> Very strange. Shortly after I read your post I opened a unresponsive image >>> myself. In the process stack I saw that magma was the culprit (didn't remember >>> I have it installed in that image). However the problem was that I moved my >>> directory and magma was looking for the old path. I didn't investigate further but >>> it seems that the MagmaRepositoryController>>#open (called on startUp) is >>> able to block the UI thread. In the same image I could use seaside still although >>> the UI was frozen. >> >> Hi. Based on your description, it sounds like Magma hit its warning >> condition check that it found a file named "_open" in the repository >> directory, indicating it thinks another process has it open. This can >> occur if the server image did not shut down properly last time. >> >> Before starting the image, see if there is a file called "_open" and, >> if there is, delete it. The image should start normally now. >> > The directory wasn't there anymore where magma was looking for it. Does magma look in other directories as well. The magma/ Folder was still in the same directory as the image. But I thought magma is looking for the absolute path because that's what I can see in the debug log. Anyway there was a file called _open in that directory. So either magma didn't find the directory or it was locked by the _open. > >> This is something that has annoyed me at least a couple of times as >> well. I'm not sure what the UI process was doing in your case, but >> Alt+. should allow you to interrupt it and see the stacks.. My >> suspicion is that something in the image wanted a MagmaSession to do >> something, but since the server was waiting for you to respond to the >> Warning about "_open" it wouldn't return... >> > Alt+. did not work. It was not reacting to anything. The warning about _open would have been a dialog? > >> The confusing part for me is, the image startup code runs in the UI >> process doesn't it? So why were there two Processes to possibly get >> into a deadlock? > > Well, I don't have enough knowledge but I would say in pharo it isn't impossible that there are more than one thread being involved. > > Norbert

Feb. 20, 2012

Re: [Pharo-project] Updated Pharo HTTP Server Single Command Line Demo

by Sven Van Caekenberghe

Damien, On 20 Feb 2012, at 16:00, Damien Cassou wrote: > Hi Sven, > > On Mon, Feb 20, 2012 at 3:08 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> In well under a minute, you can browse http://localhost:1701 and all this with less than 20Mb being downloaded. > > I don't get it. What is this server serving exactly? Where are the served files? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry Glad you asked ;-) It is an HTTP server, not necessarily a static file server (but it could be an elementary one, given proper configuration, see ZnStaticFileServerDelegate). What you see, is what ZnServer exposes by default, as implemented by ZnDefaultServerDelegate, which is just some friendly welcome page (like when you install an unconfigured Apache) combined with somewhat hidden test functionality. From the class comment: --- I am ZnDefaultServerDelegate. I function as a delegate for ZnServer, implementing #handleRequest: I implement responses to the following prefixes: /echo - an echo text of request information for debugging purposes /dw-bench - a dynamic html page for benchmarking purposes /unicode - a unicode test page /random - a random string (/random/32 for a specific size) /bytes - bytes according to a pattern (/bytes/32 for a specific size) /favicon.ico - a Zn favicon /status - a server status page /help - lists all page prefixes / - an html welcome page Without any matches, I respond with a page not found. Part of Zinc HTTP Components. --- Sven PS: Other interesting delegates are ZnDispatcherDelegate as well as ZnMonticelloServerDelegate. The pages at http://zn.stfx.eu and in particular http://zn.stfx.eu/help serve this live, with the following config: ZnServer startDefaultOn: 8080. ! | staticFileServer | (staticFileServer := ZnStaticFileServerDelegate new) prefixFromString: 'zn'; directory: (FileDirectory on: '/home/ubuntu/zn'). ZnServer default delegate prefixMap at: 'zn' put: [ :request | staticFileServer handleRequest: request ]; at: 'redirect-to-zn' put: [ :request | ZnResponse redirect: '/zn/index.html' ]; at: '/' put: 'redirect-to-zn'.

Feb. 20, 2012

Re: [Pharo-project] Script for building 1-click images

by StÃ©phane Ducasse

On Feb 20, 2012, at 11:03 AM, Martin Sandiford wrote: > On Monday, February 20, 2012, Sven Van Caekenberghe wrote: > But I believe the general feeling is that the VM included in the 1.3 One-Click is not the most up to date one, maybe someone else can give a definitive answer of what should be done best to make the most up to date One-Click. > > The script fetches the latest successful CogVM build from Jenkins for Linux and MacOS. If there is a better source, then it should not be too hard to change. > > Would also appreciate any info on the best source for a Windows VM tooâ¦ we have some problems of stability with the Windows jenkins slave. > > Cheers, > Martin

Feb. 20, 2012

Re: [Pharo-project] Nautilus Refactorings

by Benjamin

On Feb 20, 2012, at 10:46 AM, Sven Van Caekenberghe wrote: > Ben, > > On 19 Feb 2012, at 20:51, Benjamin wrote: > >> This method is actually defined in AbstractTool in the package Tool, so I have proposed a slice :) >> Now waiting for the integrators :) > > Yeah, these integrators are so slow, they take at least a day before integrating anything ;-) Yeah, shame on them LOL > Anyway the breakpoints are working now, super ! Cool > I noticed that the menu item text changes, cool, maybe add one of your nice icons too ?? I could, but making icons is boring lol Nut I will asap (or open a bug entry, like that I will not forget ;) ) > > BTW, please add the nautilus icon in the world menu, it is well deserved. I tried, and it should, but I must miss something, I will try again :) > Also, the window about menu displays the class comment of NautilusUI, maybe you can make it a bit more sexy. I do not get it, sorry > > Sven Thanks for your feedback, Ben

Feb. 20, 2012

Re: [Pharo-project] Updated Pharo HTTP Server Single Command Line Demo

by Damien Cassou

Hi Sven, On Mon, Feb 20, 2012 at 3:08 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > In well under a minute, you can browse http://localhost:1701 and all this with less than 20Mb being downloaded. I don't get it. What is this server serving exactly? Where are the served files? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Feb. 20, 2012

Re: [Pharo-project] syntax error in StartupLoader script

by Camillo Bruni

you can try to load SLICE-Issue-5290-Cleanup-Startup-Error-Handling-CamilloBruni.2 from the pharoInbox which will significantly improve the error responses during startup. best cami On 2012-02-18, at 00:19, Ben Coman wrote: > When using the following StartupLoader script > > StartupLoader default executeAtomicItems: { > StartupAction name: 'Shared Package Cache' code: [ MCCacheRepository default directory setPathName: 'C:\Apps\Smalltalk\!Shared-Package-Cache'.]. > }. > > I was getting a "syntax error in startup" that I could not identify (is it obvious to others?) > This was due to the debugger not opening at the point of error since SmalltalkImage>>executeDeferredStartupActions catches the errors. So I hacked this as follows... > deferredStartupActions do: [:each | > [ each cull: resuming ] value. > "btcdebug > on: Halt > do: [ :err| > Smalltalk > logError: '==== Startup Error: ', err description > inContext: err signalerContext. > errors add: err]"]. > > and then after a quit and restart the dialog "Syntax error: Unmatched string quote" appeared with... > StartupLoader default executeAtomicItems: { > StartupAction name: 'Shared Package Cache' code: [ MCCacheRepository default directory setPathName: _Unmatched string quote_ -> 'C:\Apps\Smalltalk\ > > So after removing "!" from the folder name the syntax error went away. > > So now a few questions... > > 1. Is there a simpler way to debug the startup scripts that I have missed? > If not, can a StartupLoader>>test or similar be implemented which runs the same as at image start time but without the error catching in executeDeferredStartupActions, rather than needing to hack executeDeferredStartupActions as I did. > > 2. Is it reasonable to set a shared package cache in the startup like I have? Or are there some obvious problems with this that I don't see? > I would like to avoid downloading all packages every time unzip a fresh image for testing. > > 3. Is the invalid "!" fixable (though of course I've worked around it)? > > I'll open any required bug entries. This was with Pharo-14333 / cogwin_r2522.zip / Windows 7. > > cheers, -ben > > >

Feb. 20, 2012