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

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by Lukas Renggli

Ahh, looks like SimpleMorphic has some (probably unintentional) overrides of core methods. Unloading the package pretty much breaks everything :-( Lukas On 18 March 2011 07:02, Lukas Renggli <renggli(a)gmail.com> wrote: >> Very good! We then can release the 1.2 Full soon, too. >> I wonder if we should adopt your OB codebase for that? Or do >> we wait for 1.2.1? > > I would wait a bit. I noticed that the debugger is quite broken. I > only get the pre-debug window, but clicking on any button opens > another pre-debug window. I don't have time to investigate, is this > also in core or some side-effect of loading/unloading packages? The > method #topView seems to be missing. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

March 18, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by Lukas Renggli

> Very good! We then can release the 1.2 Full soon, too. > I wonder if we should adopt your OB codebase for that? Or do > we wait for 1.2.1? I would wait a bit. I noticed that the debugger is quite broken. I only get the pre-debug window, but clicking on any button opens another pre-debug window. I don't have time to investigate, is this also in core or some side-effect of loading/unloading packages? The method #topView seems to be missing. Lukas -- Lukas Renggli www.lukas-renggli.ch

March 18, 2011

Re: [Pharo-project] Pharo in San Martin University

by Esteban Lorenzano

Sorry, I forget to answer this. The university link is: http://www.unsam.edu.ar/ Btw, the "professor in charge of the course" (I don't know what's the name in english) is NicolÃ¡s Passerini, and also Javier Fernandez is giving the lectures with us. Cheers, Esteban El 16/03/2011, a las 1:58p.m., StÃ©phane Ducasse escribiÃ³: > Great! > do you have a link for the pharo web site? > Stef > > >> Hi, >> I want to announce that yesterday I started teaching Pharo at University San Martin, so this university is now a proud member of the growing list of universities using this great environment for teaching purposes. One interesting thing is that we are going to explore some not-so-commonly taught capabilities, like Traits and the reflection api :) >> >> Cheers, >> Esteban > >

March 18, 2011

[Pharo-project] Porting Visual Works to Pharo

by Guillermo Polito

Maybe this question is out of the scope of this list, but probably someone can help :). As described in some threads, I want to use what's described in: http://scg.unibe.ch/wiki/howtos/portingfromvisualworkstosqueak But when I try to load FileOut30 It doesn't load the Squeak Compatibility classes because it seems I lack the refactoring browser. I've already tried to load some Refactoring Browser from different stores, but it screws my image :). I'm using the community edition of Visual works in windowze. Can someone point me in the right direction? (Let's say I'm not very used to VisualWorks) Thanks! Guille

March 18, 2011

[Pharo-project] Where is squeaksource sources?

by Igor Stasenko

I think i know what is wrong with it. When you uploading a file, it instead of closing connection and saying bye.. starts processing input without releasing other end.. which is simply stupid. I just uploaded VMMaker package.. and now my image freezed, waiting till SqS will calculate diffs and then send mail with it to mailing list.. :( -- Best regards, Igor Stasenko AKA sig.

March 18, 2011

[Pharo-project] Issue 3822 in pharo: [Glamoroust] MessageNotUnderstood: receiver of "fullBounds" is nil

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3822 by vonbecm...(a)gmail.com: [Glamoroust] MessageNotUnderstood: receiver of "fullBounds" is nil http://code.google.com/p/pharo/issues/detail?id=3822 Pharo image: Pharo1.2rc2#12324 Virtual machine used: Squeak4.1 of 17 April 2010 [latest update: #9957] Platform Name: unix Class browser used (if applicable): OBSystemBrowserAdaptor Steps to reproduce: 1. open workspace and do Gofer it squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. 2. open another workspace and do GTClassicCoder open 3. select package AST-Core 4. select class Behavior 5. select category *System-Object Storage 6. MNU Paste or attach stack trace if applicable (look at the file PharoDebug.log located in the same directory as your image): Attachments: PharoDebug.log 118 KB PharoScreenshot.1.png 159 KB

March 18, 2011

Re: [Pharo-project] Cog/FFI Return Values

by Eliot Miranda

Hi Ken, On Thu, Mar 17, 2011 at 5:38 PM, Ken Treis <ken(a)miriamtech.com> wrote: > See attached for changes vs VMMaker-oscog.40. I added a couple of simple > test methods to the preamble and used them in my test cases. > > The push/popRemappableOop stuff is over my head. I basically cloned the > code quoted below, but I had to introduce a temporary variable. I'm guessing > that it doesn't need the same treatment, but no doubt you can clean that up > for me if needs be. > > With this change, GemTools work in Cog for me. Thanks for the guidance and > encouragement. > woot! Thanks so much for this Ken! Welcome to the Cog team!! > > > Ken > > On Mar 16, 2011, at 4:45 PM, Eliot Miranda wrote: > > > > On Wed, Mar 16, 2011 at 4:25 PM, Ken Treis <ken(a)miriamtech.com> wrote: > >> On Mar 15, 2011, at 3:36 PM, Eliot Miranda wrote: >> >> > I expect that if the standard FFI plugin answers an instance of >> OopType64 then you've found a bug in the ReentrantFFIPlugin. If you're >> brave you'll have a look at both plugins and try and verify that that's the >> case. But I have to say that the FFI plugins are not simple. >> >> Brave, yes. Smart, no. Here's what it looks like to my untrained eye: >> >> 1. When the ExternalFunction is compiled, the return argType is not >> flagged as a structure. So the primitives, old and new, see this as a >> regular non-struct callout, but with return class = OopType64. So far, so >> good. >> >> 2. The old plugin had this one-slot "wrapping" capability at the bottom of >> #ffiCreateReturn: (which is called only for non-pointer, non-structure >> functions): >> >> ffiRetClass := interpreterProxy popRemappableOop. >> ffiRetClass == interpreterProxy nilObject ifTrue:[ >> "Just return oop" >> ^interpreterProxy push: retOop]. >> "Otherwise create an instance of external structure and store the >> return oop" >> interpreterProxy pushRemappableOop: retOop. >> retOop := interpreterProxy instantiateClass: ffiRetClass >> indexableSize: 0. >> oop := interpreterProxy popRemappableOop. >> interpreterProxy storePointer: 0 ofObject: retOop withValue: oop. >> ^interpreterProxy push: retOop. >> >> 3. There's some very similar code in FFIPlugin>>ffiCreateReturnStruct and >> ReentrantIA32FFIPlugin>>ffiReturnStruct:ofType:in: -- the main difference is >> a memcpy(). >> >> Am I on the right track? If so, how would you like to see the code >> structured to get this feature restored? We could add a new >> wrap-if-necessary return method, or we could try to reuse >> #ffiReturnStruct:ofType:in: if we guarded the memcpy() with a flag check for >> FFIFlagStructure. >> > > If you're happy producing a fix I'll take whatever works, a test case and > the I can always muck it up if I disapprove :) > > >> >> Or maybe there's a cleaner solution that's beyond my hazy view at the >> moment. >> > > I think you're on the right track. I probably misread when I wrote my > first cut. Apologies. > > best > Eliot > > >> >> -- >> Ken Treis >> Miriam Technologies, Inc. >> >> > > -- > Ken Treis > Miriam Technologies, Inc. > > >

March 18, 2011

Re: [Pharo-project] Cog/FFI Return Values

by Ken Treis

See attached for changes vs VMMaker-oscog.40. I added a couple of simple test methods to the preamble and used them in my test cases. The push/popRemappableOop stuff is over my head. I basically cloned the code quoted below, but I had to introduce a temporary variable. I'm guessing that it doesn't need the same treatment, but no doubt you can clean that up for me if needs be. With this change, GemTools work in Cog for me. Thanks for the guidance and encouragement. Ken On Mar 16, 2011, at 4:45 PM, Eliot Miranda wrote: > > > On Wed, Mar 16, 2011 at 4:25 PM, Ken Treis <ken(a)miriamtech.com> wrote: > On Mar 15, 2011, at 3:36 PM, Eliot Miranda wrote: > > > I expect that if the standard FFI plugin answers an instance of OopType64 then you've found a bug in the ReentrantFFIPlugin. If you're brave you'll have a look at both plugins and try and verify that that's the case. But I have to say that the FFI plugins are not simple. > > Brave, yes. Smart, no. Here's what it looks like to my untrained eye: > > 1. When the ExternalFunction is compiled, the return argType is not flagged as a structure. So the primitives, old and new, see this as a regular non-struct callout, but with return class = OopType64. So far, so good. > > 2. The old plugin had this one-slot "wrapping" capability at the bottom of #ffiCreateReturn: (which is called only for non-pointer, non-structure functions): > > ffiRetClass := interpreterProxy popRemappableOop. > ffiRetClass == interpreterProxy nilObject ifTrue:[ > "Just return oop" > ^interpreterProxy push: retOop]. > "Otherwise create an instance of external structure and store the return oop" > interpreterProxy pushRemappableOop: retOop. > retOop := interpreterProxy instantiateClass: ffiRetClass indexableSize: 0. > oop := interpreterProxy popRemappableOop. > interpreterProxy storePointer: 0 ofObject: retOop withValue: oop. > ^interpreterProxy push: retOop. > > 3. There's some very similar code in FFIPlugin>>ffiCreateReturnStruct and ReentrantIA32FFIPlugin>>ffiReturnStruct:ofType:in: -- the main difference is a memcpy(). > > Am I on the right track? If so, how would you like to see the code structured to get this feature restored? We could add a new wrap-if-necessary return method, or we could try to reuse #ffiReturnStruct:ofType:in: if we guarded the memcpy() with a flag check for FFIFlagStructure. > > If you're happy producing a fix I'll take whatever works, a test case and the I can always muck it up if I disapprove :) > > > Or maybe there's a cleaner solution that's beyond my hazy view at the moment. > > I think you're on the right track. I probably misread when I wrote my first cut. Apologies. > > best > Eliot > > > -- > Ken Treis > Miriam Technologies, Inc. > > -- Ken Treis Miriam Technologies, Inc.

March 18, 2011

[Pharo-project] GSOC 2010 results

by Torsten Bergmann

While reading about the last GSOC 2010 at: http://code.google.com/p/google-summer-of-code-2010-esug/downloads/list I wonder what happened to the results. Are they just available to play with them in private. Or will Pharo/the overall Smalltalk community profit from them since they can be usefull for the next step. Therefore especially two questions: 1. Is the Namespace code conceptually the one we want to have for Pharo and if so are there any plans to integrate it (Pharo 1.3/1.4./... ?) 2. Is the code from Cross-Dialect Smalltalk FFI ready or what is the state/strategy for Alien/FFI these days. Thx T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

March 17, 2011

Re: [Pharo-project] [ANN 1.2] prebuilt core 1.2 final

by Marcus Denker

On Mar 17, 2011, at 7:13 PM, Lukas Renggli wrote: > I've got my complete Jenkins server building on Pharo 1.2 now: > > http://jenkins.lukas-renggli.ch/ > > Some stuff is still a bit broken, but it looks good so far. > Very good! We then can release the 1.2 Full soon, too. I wonder if we should adopt your OB codebase for that? Or do we wait for 1.2.1? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 17, 2011