- Pharo-dev - lists.pharo.org

[Pharo-project] [COTDC] 94 - AnnouncementSet
by sean＠clipperadams.com Dec. 9, 2011

Dec. 9, 2011

93 classes done 802 classes remaining Continuing in Announcements... Today: AnnouncementSet 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 p.s. this message was sent from a pharo image. Did you know you could easily do that?!

1 0

[Pharo-project] Exception Handling in the Moose Distribution Image
by Mircea Filip Lungu Dec. 9, 2011

Dec. 9, 2011

Hi guys, This is a bug report I got from one of my students and replicated by myself: In the Moose 4.6 image downloaded from moosetechnology.org, if I execute the following code | c | c := Collection new. c add: 1. the image seems to freeze, although what I would expect is that SubclassResponsibility exception to be raised. This has been observed on Windows and Mac. Do you know about this? Thanks, M. -- Dr. Mircea Lungu Researcher Software Composition Group University of Bern -- Dr. Mircea Lungu Researcher Software Composition Group University of Bern

2 1

[Pharo-project] RB AST Rewriter to eliminate/consoliate temporary variables?
by Stefan Marr Dec. 9, 2011

Dec. 9, 2011

Hi all, Hi Lukas: Do you know if anyone ever implemented a rewriter for the RB AST that reduces the amount of temporary variables if possible? I have a naive rewriting step that creates too many temps, but some of them are not strictly necessary. However, currently, I run into 'Cannot compile -- stack including temps is too deep' which is, well, ehm, not so nice. In case anyone has something in that direction, I would be interested. Thanks 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

2 5

Re: [Pharo-project] Exception Handling in the Moose Distribution Image
by Marcus Denker Dec. 9, 2011

Dec. 9, 2011

On Dec 9, 2011, at 4:25 PM, Mircea Filip Lungu wrote: > Hi guys, > > This is a bug report I got from one of my students and replicated by myself: > > In the Moose 4.6 image downloaded from moosetechnology.org, if I > execute the following code > > | c | > c := Collection new. > c add: 1. > > the image seems to freeze, although what I would expect is that > SubclassResponsibility > exception to be raised. This has been observed on Windows and Mac. > > Do you know about this? > This has been fixed in 1.4 last week... as a workaround, I think filing in this should work: -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] NBOpenGL
by Fernando Olivero Dec. 9, 2011

Dec. 9, 2011

Thanks Henrik for the info, now's its clear to me. Igor, excellent news! i was struggling with NativeBoost, almost have a working version of CGL, but i'm eager to see your implementation. Yes, CGL only provide either fullscreen of offscreen contexts. Cocoa (and Carbon) adds the windowing layer on top of CGL. I'll analyze how to overcome this problem now, cause i want to start rendering with Cairo ASAP! Fernando On Fri, Dec 9, 2011 at 3:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > (resending message due to mailer problem) > > Since it works now only for Windows, Â i didn't thought a lot about > platform-neutral stuff. > Creating and initializing an opengl context is platform-specific, and > it is hard to tell what you may need to create it. > > Regarding opengl on mac: > - i just uploaded the initial snapshot of opengl bindings for mac, see > NBOpenGL-Mac package. > it can create a context using > NBMacContextManager new createContext > > but i am a bit puzzled what to do next, because it looks like CGL > library allows you to create only a fullscreen contexts, > and only Carbon/Cocoa frameworks allowing you to make a windowed > context by attaching context to specific 'drawable'. > So, Fernando (or others), if you know more, take a look what can be done. > Maybe it was a mistake to use CGL interface for it, maybe i should > write bindings using Carbon interface, but > since it promised by apple to be deprecated and removed from system, i > don't know what to do (and Cocoa is an Objective-C, > and making calls to Objective-C code is completely different story). > > On 9 December 2011 11:34, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 09.12.2011 11:27, Henrik Sperre Johansen wrote: >>> >>> >>> That's not specific to offscreen rendering contexts though, (nor >>> pixelformats, another windows artifact) >> >> I should perhaps say; they're not Windows specific as such, but the >> implementation in NBOpenGL is. >> Personally, I'd rather have createContext: taking a crossplatform >> pixel/buffer format as argument, the platform context transcribe that into >> the native object needed as parameter for context creation, and some sort of >> way to check if the context created actually matched your specification. >> Makes the whole "Your context was invalid for those operations" class of >> errors a lot more transparent, which I've found to be the source of trouble >> multiple times at least. >> >> Cheers, >> Henry >> > > > > -- > Best regards, > Igor Stasenko. >

1 0

Re: [Pharo-project] GUI Testing Library
by Marcus Denker Dec. 9, 2011

Dec. 9, 2011

On Dec 9, 2011, at 4:08 PM, Tudor Girba wrote: > Btw, I think these should get in the Pharo distribution because they > are just too valuable. > Yes! > Doru > > > On Fri, Dec 9, 2011 at 4:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Thanks a lot, Sean! >> >> It works just great with BDDExtensions and Keymapping-Shortcuts. >> >> Cheers, >> Doru >> >> >> On Thu, Dec 8, 2011 at 3:35 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Tudor Girba-2 wrote >>>> >>>> Would it be possible to simulate keys with modifiers without Keymapping >>>> present? >>>> >>> >>> I think I only used Keymapping for the modifier key syntax, but looking at >>> its repository, the shortcuts are packaged separately. So you could try only >>> loading Keymapping-Shortcuts, which does not hook into the system (so >>> shouldn't break anything) and will add #command, $shift, etc. Let me know if >>> that works for you. >>> >>> Sean >>> >>> -- >>> View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4172952.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] NativeBoost and C++ libraries
by Pavel Krivanek Dec. 9, 2011

Dec. 9, 2011

Hi Igor, do you have some experiences with NativeBoost bindings to C++ libraries (with classes)? I have seen that Ruby has some interface generators for that purpose (Rice, rb++). Cheers, -- Pavel

2 1

[Pharo-project] NBOpenGL
by Igor Stasenko Dec. 9, 2011

Dec. 9, 2011

(resending message due to mailer problem) Since it works now only for Windows, Â i didn't thought a lot about platform-neutral stuff. Creating and initializing an opengl context is platform-specific, and it is hard to tell what you may need to create it. Regarding opengl on mac: - i just uploaded the initial snapshot of opengl bindings for mac, see NBOpenGL-Mac package. it can create a context using NBMacContextManager new createContext but i am a bit puzzled what to do next, because it looks like CGL library allows you to create only a fullscreen contexts, and only Carbon/Cocoa frameworks allowing you to make a windowed context by attaching context to specific 'drawable'. So, Fernando (or others), if you know more, take a look what can be done. Maybe it was a mistake to use CGL interface for it, maybe i should write bindings using Carbon interface, but since it promised by apple to be deprecated and removed from system, i don't know what to do (and Cocoa is an Objective-C, and making calls to Objective-C code is completely different story). On 9 December 2011 11:34, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 09.12.2011 11:27, Henrik Sperre Johansen wrote: >> >> >> That's not specific to offscreen rendering contexts though, (nor >> pixelformats, another windows artifact) > > I should perhaps say; they're not Windows specific as such, but the > implementation in NBOpenGL is. > Personally, I'd rather have createContext: taking a crossplatform > pixel/buffer format as argument, the platform context transcribe that into > the native object needed as parameter for context creation, and some sort of > way to check if the context created actually matched your specification. > Makes the whole "Your context was invalid for those operations" class of > errors a lot more transparent, which I've found to be the source of trouble > multiple times at least. > > Cheers, > Henry > -- Best regards, Igor Stasenko.

1 0

Re: [Pharo-project] NBOpenGL
by Henrik Sperre Johansen Dec. 9, 2011

Dec. 9, 2011

On 09.12.2011 11:27, Henrik Sperre Johansen wrote: > > That's not specific to offscreen rendering contexts though, (nor > pixelformats, another windows artifact) I should perhaps say; they're not Windows specific as such, but the implementation in NBOpenGL is. Personally, I'd rather have createContext: taking a crossplatform pixel/buffer format as argument, the platform context transcribe that into the native object needed as parameter for context creation, and some sort of way to check if the context created actually matched your specification. Makes the whole "Your context was invalid for those operations" class of errors a lot more transparent, which I've found to be the source of trouble multiple times at least. Cheers, Henry

1 0

Re: [Pharo-project] NBOpenGL
by Fernando Olivero Dec. 9, 2011

Dec. 9, 2011

the formatting of the "uml" is wrong! On Fri, Dec 9, 2011 at 10:46 AM, fernando.olivero(a)usi.ch <fernando.olivero(a)usi.ch> wrote: > Hi Igor, i have a question regarding the design of NBOpenGL. > > Why does the following offscreen method, deals with windows? > > NBOffscreenDisplay >>createOpenGLContext > Â Â Â Â ctx := NBHostWindowContext createSpecificForPlatform. > Â Â Â Â ctx createWindow: extent. > Â Â Â Â ctx createContext: ctx defaultPixelFormat. > > I'm trying to include in the framework, support for MacOSX, starting > with offscreen drawables support using CGL, therefore i would like to > modify it to: > > > NBOffscreenDisplay >>createOpenGLContext > Â Â Â Â ctx := NBDisplayContext createSpecificForPlatform. > Â Â Â Â ctx createContext: ctx defaultPixelFormat. > > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â NBGLDisplay > > NBDisplayContext > NBOffscreenDisplay Â Â Â Â Â Â Â Â Â Â NBWindowedDisplay > Â Â Â Â Â Â Â NBWinContext Â Â Â Â Â Â Â NBUnixContext > NBMacOSXContext > > > What do you think? > Fernando >

2 1