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

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Sean P. DeNigris

Norbert Hartl wrote > > Trying to recover the image was not important for me but for pharo. I just > liked to participate in solving a problem that is hard to debug. > Right on, Norbert!! Thank you for doing that. This already happened to me twice and it is a difficult and important problem for us. Sean -- View this message in context: http://forum.world.st/How-to-resurrect-an-unrepsonsive-image-tp4168518p4177… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2011

[Pharo-project] RB AST Rewriter to eliminate/consoliate temporary variables?

by Stefan Marr

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

Dec. 9, 2011

Re: [Pharo-project] NBOpenGL

by Fernando Olivero

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. >

Dec. 9, 2011

[Pharo-project] Exception Handling in the Moose Distribution Image

by Mircea Filip Lungu

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

Dec. 9, 2011

Re: [Pharo-project] GUI Testing Library

by Marcus Denker

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

Dec. 9, 2011

Re: [Pharo-project] GUI Testing Library

by Tudor Girba

Btw, I think these should get in the Pharo distribution because they are just too valuable. 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"

Dec. 9, 2011

Re: [Pharo-project] GUI Testing Library

by Tudor Girba

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"

Dec. 9, 2011

Re: [Pharo-project] NativeBoost and C++ libraries

by Igor Stasenko

On 9 December 2011 11:10, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 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++). No. In C++ things are different (mangled function names, thiscall calling convertion etc). I think it is possible to make FFI to C++ libs, by studying the C++ ABI :) -- Best regards, Igor Stasenko.

Dec. 9, 2011

[Pharo-project] NBOpenGL

by Igor Stasenko

(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.

Dec. 9, 2011

Re: [Pharo-project] NBOpenGL

by Henrik Sperre Johansen

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

Dec. 9, 2011