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

Re: [Pharo-project] OpenGL in pharo?

by Fernando olivero

Hola Javier, on top of AlienOpenGL , which is just an interface to OpenGL, i've built a 3d framework with better abstractions called Lumiere. (http://www.inf.usi.ch/phd/olivero/LumierePage.html (A little bit outdated...i've added a couple of more things recently..) In this paper that we presented at the last ESUG/IWST 09 , with also did brief survey of OpenGL in smalltalk. (www.esug.org/data/ESUG2009/IWST/iwst09_submission_6.pd) If there's a plugin for AlienFFI for Linux i'm not sure. But have you tried the FFI binding of OGL of Croquet? That one works in Linux. Look in squeaksource, because i remember someone decoupled the OGL wrapper from Croquet and put it there. I dont know if June ( for visual works) works in linux, but you could take a look of it. Saludos, Fernando On Feb 10, 2010, at 3:01 AM, Javier PimÃ¡s wrote: > Hi, I've been browsing the different ways to use OpenGL in pharo and squeak. Here is a log of the results: > > 1 - Baloon3D - It looks like a layer on which squeaksource.com/OpenGL stands, so to use opengl you load balloon3d, then opengl and if you have the Balloon3dPlugin available then you can use OpenGL. This seems to include code dated from 2007/before. It loads fine in Squeak but in pharo I get many errors (load balloon3d-all in pharo1.0 rc2). > > 2 - GLMorphic - It uses FFI, so no plugin is needed, but it seems to be programmed only for windows, and I'm working in linux now. > > 3 - AlienOpenGL - It uses the new Alien FFI, which is only available in Mac platform. > > So, the question is: is there any way to play with OpenGL in pharo on linux platform ? > > Regards, > Javier. > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > <ATT00001..txt>

Feb. 10, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Luc Fabresse

Ok done in Kernel-LucFabresse.578 (PharoInbox). BlockContext>>fixTemps and BlockClosure>>fixTemps have been deprecated. Issue: http://code.google.com/p/pharo/issues/detail?id=1947 Luc 2010/2/9 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> >> >> 2010/2/9 Eliot Miranda <eliot.miranda(a)gmail.com> >> >> >>> >>> 2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> >>>> >>>> 2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> >>>> >>>> Hi all, >>>>> >>>>> I wonder why BlockContext>>fixTemps is still in PharoCore. >>>>> I guess that it should be removed, isn't it? >>>>> >>>> >>>> I would like to remove them. >>>> >>>> >>>>> It has only one sender. >>>>> >>>> >>>> Yes, in the core ;) But the problem is that Seaside (I think only >>>> 2.8.4 as 3.0 seems to fixed that) or KomHttpServer are still using it. >>>> >>>> Of course, we can just remove it and assume that those external packages >>>> should be fixed to run on Pharo. Squeak trunk also has closures...so.. >>>> >>>> >>>>> Morever, should the BlockContext class be removed too? >>>>> >>>> >>>> I would like, too. The only problem is the "compatibility". What maybe >>>> can be done is to remove the class but do something like >>>> >>>> Smalltalk at: #BlockContext put: #BlockClosure >>>> >>> >>> I think this is a really bad idea. Imagine loading something that adds >>> functionality to BlockContext that simply makes no sense in BlockClosure or >>> breaks when compiled on BlockClosure. Best live with the differences and >>> upgrade than introduce a horrible hack that pretends to do >>> backwards-compatibility but actually confuses the hell out of people. >>> >>> >> :( So...what do you recommend us Eliot ? >> > > Leave BlockContext there for now. Port functionality in BlockContext to > BlockClosure as required. In a few months (or perhaps even now) mark > BlockClosure>>fixTemps and BlockContext protocol as deprecated so that uses > of fixTemps and BlockContext generate warnings e.g. in the Transcript. In a > few years get rid of BlockContext. > > > Right now all we're talking about is having a null implementation of > fixTemps in BlockClosure. Marking this deprecated seems to be adequate. Or > am I not understanding your concerns? > > Later on, in synchrony with Squeak and eToys I would like us to consider > whether it is worth-while collapsing ContextPart and MethodContext into a > single class called something like Context or SmalltalkExecutionContext or > ExecutionContext or ThisContext. > > >> >> HTH >>> >>> >>>> >>>> But I have no idea the impact of this.... >>>> >>> >>> which is one really good reason /not/ to do it :) >>> >> >> ahahhaha that's true :) >> >> >>> >>> best >>> Eliot >>> >>>> >>>> >>>>> >>>>> Depending on answers, I will write a bug report. >>>>> >>>>> Luc >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 10, 2010

[Pharo-project] OpenGL in pharo?

by Javier PimÃ¡s

Hi, I've been browsing the different ways to use OpenGL in pharo and squeak. Here is a log of the results: 1 - Baloon3D - It looks like a layer on which squeaksource.com/OpenGLstands, so to use opengl you load balloon3d, then opengl and if you have the Balloon3dPlugin available then you can use OpenGL. This seems to include code dated from 2007/before. It loads fine in Squeak but in pharo I get many errors (load balloon3d-all in pharo1.0 rc2). 2 - GLMorphic - It uses FFI, so no plugin is needed, but it seems to be programmed only for windows, and I'm working in linux now. 3 - AlienOpenGL - It uses the new Alien FFI, which is only available in Mac platform. So, the question is: is there any way to play with OpenGL in pharo on linux platform ? Regards, Javier. -- Javier PimÃ¡s Ciudad de Buenos Aires

Feb. 10, 2010

[Pharo-project] Force the focus of a panel for start to listen key press events.

by nullPointer

Well, I decided let the optimization and threads load for later, my knowledge is poor, and see that very complicated :| Now my main problem is the navigation through cells of grid. All cells have a "value control" (currently a label) where is viewed the value data. I need when a TAB key is pressed the current cell pass to next cell. My question: -How I can "focus" morph (the cell) for begin to listen the key presses events? that morph is really only a PanelMorph subclass. Really I understand than need the behavior of list widgets or textboxes for that cell, force the focus of some way. Regards and thanks for the answers. -- View this message in context: http://n4.nabble.com/Conseils-for-develop-a-grid-tp1299737p1475136.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Eliot Miranda

2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/2/9 Eliot Miranda <eliot.miranda(a)gmail.com> > > >> >> 2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> >>> >>> 2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> >>> >>> Hi all, >>>> >>>> I wonder why BlockContext>>fixTemps is still in PharoCore. >>>> I guess that it should be removed, isn't it? >>>> >>> >>> I would like to remove them. >>> >>> >>>> It has only one sender. >>>> >>> >>> Yes, in the core ;) But the problem is that Seaside (I think only 2.8.4 >>> as 3.0 seems to fixed that) or KomHttpServer are still using it. >>> >>> Of course, we can just remove it and assume that those external packages >>> should be fixed to run on Pharo. Squeak trunk also has closures...so.. >>> >>> >>>> Morever, should the BlockContext class be removed too? >>>> >>> >>> I would like, too. The only problem is the "compatibility". What maybe >>> can be done is to remove the class but do something like >>> >>> Smalltalk at: #BlockContext put: #BlockClosure >>> >> >> I think this is a really bad idea. Imagine loading something that adds >> functionality to BlockContext that simply makes no sense in BlockClosure or >> breaks when compiled on BlockClosure. Best live with the differences and >> upgrade than introduce a horrible hack that pretends to do >> backwards-compatibility but actually confuses the hell out of people. >> >> > :( So...what do you recommend us Eliot ? > Leave BlockContext there for now. Port functionality in BlockContext to BlockClosure as required. In a few months (or perhaps even now) mark BlockClosure>>fixTemps and BlockContext protocol as deprecated so that uses of fixTemps and BlockContext generate warnings e.g. in the Transcript. In a few years get rid of BlockContext. Right now all we're talking about is having a null implementation of fixTemps in BlockClosure. Marking this deprecated seems to be adequate. Or am I not understanding your concerns? Later on, in synchrony with Squeak and eToys I would like us to consider whether it is worth-while collapsing ContextPart and MethodContext into a single class called something like Context or SmalltalkExecutionContext or ExecutionContext or ThisContext. > > HTH >> >> >>> >>> But I have no idea the impact of this.... >>> >> >> which is one really good reason /not/ to do it :) >> > > ahahhaha that's true :) > > >> >> best >> Eliot >> >>> >>> >>>> >>>> Depending on answers, I will write a bug report. >>>> >>>> Luc >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Mariano Martinez Peck

2010/2/9 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > > >> >> 2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> >> >> Hi all, >>> >>> I wonder why BlockContext>>fixTemps is still in PharoCore. >>> I guess that it should be removed, isn't it? >>> >> >> I would like to remove them. >> >> >>> It has only one sender. >>> >> >> Yes, in the core ;) But the problem is that Seaside (I think only 2.8.4 >> as 3.0 seems to fixed that) or KomHttpServer are still using it. >> >> Of course, we can just remove it and assume that those external packages >> should be fixed to run on Pharo. Squeak trunk also has closures...so.. >> >> >>> Morever, should the BlockContext class be removed too? >>> >> >> I would like, too. The only problem is the "compatibility". What maybe can >> be done is to remove the class but do something like >> >> Smalltalk at: #BlockContext put: #BlockClosure >> > > I think this is a really bad idea. Imagine loading something that adds > functionality to BlockContext that simply makes no sense in BlockClosure or > breaks when compiled on BlockClosure. Best live with the differences and > upgrade than introduce a horrible hack that pretends to do > backwards-compatibility but actually confuses the hell out of people. > > :( So...what do you recommend us Eliot ? HTH > > >> >> But I have no idea the impact of this.... >> > > which is one really good reason /not/ to do it :) > ahahhaha that's true :) > > best > Eliot > >> >> >>> >>> Depending on answers, I will write a bug report. >>> >>> Luc >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 9, 2010

[Pharo-project] [update 1.1] #11199

by StÃ©phane Ducasse

11199 ----- - Issue 1927: SocketStream>>peekFor: fixes. - Issue 1925: expected: requires a string not a block

Feb. 9, 2010

[Pharo-project] [update 1.1] #11198

by StÃ©phane Ducasse

11198 ----- - Issue 1935: MenuMorph enhancement - Deprecated fasterKeys.

Feb. 9, 2010

[Pharo-project] OT: compressing log files

by Eliot Miranda

Hi All, I've just needed to make sense of a very long log file generated by strace. The log file is full of entries like: --- SIGALRM (Alarm clock) @ 0 (0) --- gettimeofday({1265744804, 491238}, NULL) = 0 sigreturn() = ? (mask now []) ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 and my workspace script reduces these to e.g. --- SIGALRM (Alarm clock) @ 0 (0) --- gettimeofday({1265744797, 316183}, NULL) = 0 sigreturn() = ? (mask now []) NEXT 2 LINES REPEAT 715 TIMES ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 --- SIGALRM (Alarm clock) @ 0 (0) --- gettimeofday({1265744797, 317189}, NULL) = 0 sigreturn() = ? (mask now []) My question is has anyone looked at this issue in any depth and perhaps come up with something not as crude as the below and possibly even recursive. i.e. the above would ideally be reduced to e.g. NEXT 7 LINES REPEAT 123456 TIMES --- SIGALRM (Alarm clock) @ 0 (0) --- gettimeofday({1265744797, 316183}, NULL) = 0 sigreturn() = ? (mask now []) NEXT 2 LINES REPEAT BETWEEN 500 AND 800 TIMES ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 ioctl(8, 0x80045530, 0xbfd4fe70) = 0 ioctl(8, 0xc1205531, 0xbfd4fb80) = 0 --- SIGALRM (Alarm clock) @ 0 (0) --- gettimeofday({1265744797, 317189}, NULL) = 0 sigreturn() = ? (mask now []) Here's my quick hack that I ran in vw7.7nc: | f o lines maxrun repeats range | f := '../Cog/squeak.strace.log' asFilename readStream. o := 'compressed.log' asFilename writeStream. lines := OrderedCollection new. maxrun := 50. repeats := 0. range := nil. [[f atEnd] whileFalse: [lines size > maxrun ifTrue: [repeats > 0 ifTrue: [1 to: range first - 1 do: [:i| o nextPutAll: (lines at: i); cr]. o nextPutAll: 'NEXT '; print: range size; nextPutAll: ' LINES REPEAT '; print: repeats + 1; nextPutAll: ' TIMES'; cr. range do: [:i| o nextPutAll: (lines at: i); cr]. lines removeFirst: range last. repeats := 0] ifFalse: [o nextPutAll: lines removeFirst; cr; flush]. range := nil]. lines addLast: (f upTo: Character cr). [:exit| 1 to: lines size do: [:i| | line repeat | line := lines at: i. repeat := lines nextIndexOf: line from: i + 1 to: lines size. (repeat ~~ nil and: [lines size >= (repeat - i * 2 + i) and: [(i to: repeat - 1) allSatisfy: [:j| (lines at: j) = (lines at: j - i + repeat)]]]) ifTrue: [repeats := repeats + 1. range isNil ifTrue: [range := i to: repeat - 1] ifFalse: [range = (i to: repeat - 1) ifTrue: [range do: [:ignore| lines removeAtIndex: repeat]. exit value]]]]] valueWithExit]] ensure: [f close. o close]. repeats Forgive the cross post. I expect deep expertise in each newsgroup posted to. best Eliot

Feb. 9, 2010

[Pharo-project] [update 1.1] #11197

by StÃ©phane Ducasse

11197 ----- - Issue 1932: UTF8TextConverter ?? - Issue 1941: Issue 1880 broke ImageSegment

Feb. 9, 2010