January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3560 in pharo: Clean of RML

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3560 by marcus.d...(a)gmail.com: Clean of RML http://code.google.com/p/pharo/issues/detail?id=3560 13005

Jan. 20, 2011

[Pharo-project] [update 1.2] #12314

by Marcus Denker

12314 ----- Issue 3560: Clean of RML -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 20, 2011

Re: [Pharo-project] Issue 3560 in pharo: Clean of RML

by pharo＠googlecode.com

Comment #2 on issue 3560 by marcus.d...(a)gmail.com: Clean of RML http://code.google.com/p/pharo/issues/detail?id=3560 12314 TODO: 1.3

Jan. 20, 2011

Re: [Pharo-project] [squeak-dev] Instruments for headless images

by StÃ©phane Ducasse

there is a DummyManager to control pop up and friends. Stef On Jan 20, 2011, at 9:39 PM, Igor Stasenko wrote: > Hello folks. > > I'd like to ask, if there any 'standartized' instruments for headless > images (or alike). > > I need a simple things: > - redirect all ToolSet/UIManager messages to Transcript > - redirect Transcript logging to file or stdout > > in short, these tools should serve a simple, yet important purpose: > - if image runs in headless mode, it should suppress anything which > expecting user interaction (like showing warnings with 'continue' > button) and either log such messages to file > or simply quit image with error message. > > Without such tool it is quite difficult to monitor, what happens with > your headless image.. unless you have RFB installed.. but that is > different and unrelated story. > > > I did a prototype once for Hydra (you can check it at > SqS/HydraVM/HydraVM.mcz package) > there are two subclasses: > - MorphicUIManager subclass: #HydraUIManager > - StandardToolSet subclass: #HydraDebugToolSet > > and > - WriteStream subclass: #HydraTranscript > > which can be installed as a Transcript. > > And in order to prepare image to run in headless mode, i issued: > ToolSet unregister: StandardToolSet. > ToolSet register: HydraDebugToolSet. > UIManager default: HydraUIManager new. > > Also, HydraTranscript > startUp does something like: > > TranscriptStream > newTranscript: (self basicNew initialize > on: (String new: 1000)) > > > With that i could run the image in headless mode, knowing that in case > of error or warning etc, all will be redirected to transcript, > moreover i even stopped the UI process, so it never run on headless images. > > I wonder if there are other work, which can offer similar, > and is there any way to detect that image are running in headless mode? > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 20, 2011

[Pharo-project] Instruments for headless images

by Igor Stasenko

Hello folks. I'd like to ask, if there any 'standartized' instruments for headless images (or alike). I need a simple things: - redirect all ToolSet/UIManager messages to Transcript - redirect Transcript logging to file or stdout in short, these tools should serve a simple, yet important purpose: - if image runs in headless mode, it should suppress anything which expecting user interaction (like showing warnings with 'continue' button) and either log such messages to file or simply quit image with error message. Without such tool it is quite difficult to monitor, what happens with your headless image.. unless you have RFB installed.. but that is different and unrelated story. I did a prototype once for Hydra (you can check it at SqS/HydraVM/HydraVM.mcz package) there are two subclasses: - MorphicUIManager subclass: #HydraUIManager - StandardToolSet subclass: #HydraDebugToolSet and - WriteStream subclass: #HydraTranscript which can be installed as a Transcript. And in order to prepare image to run in headless mode, i issued: ToolSet unregister: StandardToolSet. ToolSet register: HydraDebugToolSet. UIManager default: HydraUIManager new. Also, HydraTranscript startUp does something like: TranscriptStream newTranscript: (self basicNew initialize on: (String new: 1000)) With that i could run the image in headless mode, knowing that in case of error or warning etc, all will be redirected to transcript, moreover i even stopped the UI process, so it never run on headless images. I wonder if there are other work, which can offer similar, and is there any way to detect that image are running in headless mode? -- Best regards, Igor Stasenko AKA sig.

Jan. 20, 2011

Re: [Pharo-project] Gofer issue

by Lukas Renggli

> however, Â if i open the MC repo browser, it clearly shows that most > recent version is > CMakeVMMaker-Igor.Stasenko.16 Â (at the moment of writing this message) Following the coventions your name is 'Igor' and the package is on the branch 'Stasenko'. Gofer proritizes the main branch. > Gofer new > Â Â Â url: 'http://squeaksource.com/VMMaker'; > Â Â Â package: 'VMMaker-oscog.46'; > Â Â Â load. > > and it barks that given version is not found.. which of course not true. 'VMMaker-oscar.46' is clearly not a package name, use #version: to refer to a specific version. > Actually i surprised that Gofer simply don't reusing the MC package > enumeration logic.. or maybe it does.. but obviously doing it wrong :) Please study the documentation in the class comment of Gofer. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 20, 2011

Re: [Pharo-project] Using AlienOpenGL

by Schwab,Wilhelm K

Not that you are wrong, but how did you choose AlienOpenGL over CroquetGL? IIRC, there is also a 3D project associated with NativeBoost. The latter lives here: http://code.google.com/p/nativeboost/ Just curious. I was originally very disappointed that Croquet was an all-or-nothing proposition. Just studying the code, it had a very nice way of manipulating 3D objects (more than just drawing triangles), but it was part of the 3D operating system, which was not something I could put in front of the end users I had in mind. Here's hoping the nice code is moving toward something that we can use to open 3D views from inside of Pharo. On to your debugging problem, can you tell what Pharo is trying to load? I have resorted to building my own VM to get a look at exactly what paths are used to load libraries. Even a relevant #moduleName return value might help identify the required library. You could be experiencing problems because the library is not present, or because FFI is looking in the wrong place. The Linux VM does not easily give up its secrets. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Ricardo Jacas [ricardo.jacas(a)gmail.com] Sent: Thursday, January 20, 2011 1:44 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Using AlienOpenGL hi, im trying to work with the AlienOpenGL library, in ubuntu, but i cant get even the test to run. it keeps saying i dont have a basic library but i dont have a clue how to get it. i have been all day ready post about it and i simply cant make it. anyone can do a stupid proof guide? Ricardo -- lets reign all together

Jan. 20, 2011

[Pharo-project] Gofer issue

by Igor Stasenko

Hello, Gofer doesn't likes my package naming :( When i use: Gofer new url: 'http://squeaksource.com/VMMaker'; package: 'CMakeVMMaker'; load. it loads the CMakeVMMaker-EstebanLorenzano.15 however, if i open the MC repo browser, it clearly shows that most recent version is CMakeVMMaker-Igor.Stasenko.16 (at the moment of writing this message) which means that Gofer package name/version parsing logic are not in sync with MC. Same applies to VMMaker-oscog.. Tried to do: Gofer new url: 'http://squeaksource.com/VMMaker'; package: 'VMMaker-oscog.46'; load. and it barks that given version is not found.. which of course not true. Actually i surprised that Gofer simply don't reusing the MC package enumeration logic.. or maybe it does.. but obviously doing it wrong :) -- Best regards, Igor Stasenko AKA sig.

Jan. 20, 2011

Re: [Pharo-project] Issue 3560 in pharo: Clean of RML

by pharo＠googlecode.com

Updates: Labels: Milestone-1.2 Milestone-1.3 Comment #1 on issue 3560 by marcus.d...(a)gmail.com: Clean of RML http://code.google.com/p/pharo/issues/detail?id=3560 (No comment was entered for this change.)

Jan. 20, 2011

Re: [Pharo-project] Issue 1426 in pharo: Auto completion does not complete symbols

by pharo＠googlecode.com

Comment #8 on issue 1426 by DVCio...(a)gmail.com: Auto completion does not complete symbols http://code.google.com/p/pharo/issues/detail?id=1426 I can confirm this behaviour in dev 1.2rc1 12311, yet some clarification is needed for proper functioning: #od is taken as a literal symbol, similar to #ev, and have no auto-completion. ##od gives the suggestion for odd because ## is evaluated first to literal symbol and od is then used for auto-completion. 'od' with cursor before closing ' gives auto-completion [od] does not; nor does (od) Since I'm new, which should produce the auto-completion and which shouldn't?

Jan. 20, 2011