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

Re: [Pharo-project] OpenGL in Pharo?

by StÃ©phane Ducasse

What I want for January: Igor knows it. I told him weekly if not daily. one single 100% fully working solution on all platforms (Callback+ Threaded + DOCUMENTTION) : let us called it Spock Probably - FFI/Alien for solution where code cannot be generated (but we want one name) - NativeBoost Stef On Nov 17, 2011, at 11:55 PM, Pavel Krivanek wrote: > I would like to ask on the future of FFI technologies in Pharo. What will be the prefered project? Alien, NativeBoost or both? That means what projects will have support in the "official" VM for all main platforms? > > Some week ago I played with FFI calls on Linux and the only project that worked well was NativeBoost. The Alien failed to locate the libraries (it was 32bit VM on 64bit system, possible source of complacations). > > Cheers > -- Pavel > > > > 17.11.2011 v 18:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Hi michele >> >> Do not expect something like Jun because this is 10 or 15 years. Now I saw today a cairo graphics displayed on the machine of Javier :). >> This is an example for the Alien chapter of the new pharo book (quite draft). >> >> I hope that I will get somebody will work on a minimal code city for moose based on a opengl solution. >> Now if people have more cycles it will go faster. I hope igor will release soon the opengl binding for mac. >> >> Stef >> <alien.pdf> >> >> >> On Nov 17, 2011, at 8:52 AM, Michele Lanza wrote: >> >>> Dear all, >>> I wanted to ask whether there are some news I missed with respect to having a decent OpenGL framework in Pharo. I checked the following page: >>> >>> http://book.pharo-project.org/book/LanguageAndLibraries/3DGraphicsAndOpenGL/ >>> >>> ..but it sounds all a bit outdated and not something I can rely on in the long run. Ideally there should be something like the Jun framework (available for VisualWorks), but when I met the Jun maker at ICSE and I asked him whether there were any plans of porting Jun to Pharo he told me that it was not in their plans. Long talk, short sense: Is anyone working on OpenGL for Pharo? >>> >>> Cheers >>> >>> Michele >> >

Nov. 18, 2011

Re: [Pharo-project] scripting a package backup

by jannik.laval

Hi Lukas, I tried: === RPackageOrganizer packageInfoNames do:[:e | Gofer new directory: '/Users/janniklaval/Desktop/MCPackages'; package: e; push. ] === but if the package was not modified, it does not copy the source files. Jannik On Nov 18, 2011, at 10:38 , Lukas Renggli wrote: > It would be trivial with Gofer: > > Gofer new > squeaksource: 'backupproject'; > package: 'P1'; > package: 'P2'; > package: 'P3'; > push > > Now of course you can find your script a working script in the class GoferPush. > > Lukas > > On 18 November 2011 10:03, jannik.laval <jannik.laval(a)gmail.com> wrote: >> Hi Pharoers, >> >> I would like to backup my packages in a repository with a script. >> I have one constraint: I need to use Monticello (eg, not gofer or metacello). >> And I do not want to have a version incrementation. >> >> Does someone have any script or any way to do that ? >> >> Cheers, >> Jannik >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > --- Jannik Laval

Nov. 18, 2011

Re: [Pharo-project] scripting a package backup

by Lukas Renggli

It would be trivial with Gofer: Gofer new squeaksource: 'backupproject'; package: 'P1'; package: 'P2'; package: 'P3'; push Now of course you can find your script a working script in the class GoferPush. Lukas On 18 November 2011 10:03, jannik.laval <jannik.laval(a)gmail.com> wrote: > Hi Pharoers, > > I would like to backup my packages in a repository with a script. > I have one constraint: I need to use Monticello (eg, not gofer or metacello). > And I do not want to have a version incrementation. > > Does someone have any script or any way to do that ? > > Cheers, > Jannik > > > > -- Lukas Renggli www.lukas-renggli.ch

Nov. 18, 2011

[Pharo-project] scripting a package backup

by jannik.laval

Hi Pharoers, I would like to backup my packages in a repository with a script. I have one constraint: I need to use Monticello (eg, not gofer or metacello). And I do not want to have a version incrementation. Does someone have any script or any way to do that ? Cheers, Jannik

Nov. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Henrik Sperre Johansen

On 18.11.2011 05:32, Sean P. DeNigris wrote: > Igor Stasenko wrote: >> virtually nowhere :) >> > Should the non-weak version be removed and replaced by the weak version > (renamed to remove the weak specification)? Or some other consolidation... > > -- > View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082112.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > No. It is valuable whenever you need to deterministically unsubscribe a subscriber at some point. If using weak subscribers, bugs related to not doing so can be hard to track down. (mainly when that point somewhat coincides to when the object also loses its last reference) Second, if you do need to unsubscribe them at some set point in the programs execution, also having it registered for weak cleanup only introduces additional overhead. Third, for the moment at least, when:do: anActionBlock subscription does not work weakly, you are constrained to when:send:to. Cheers, Henry

Nov. 18, 2011

Re: [Pharo-project] OpenGL in Pharo?

by Igor Stasenko

2011/11/18 Levente Uzonyi <leves(a)elte.hu>: > > > On Fri, 18 Nov 2011, Igor Stasenko wrote: > >> 2011/11/18 Levente Uzonyi <leves(a)elte.hu>: >>> >>> On Thu, 17 Nov 2011, Javier PimÃ¡s wrote: >>> >>>> We are advancing on making OpenGL work with NativeBoost right now. If >>>> you >>>> have to write an app >>>> that uses OpenGL now, I would strongly recommend you to use NBOpenGL. >>>> It's >>> >>> I see the hype about NBOpenGL, but I don't see how is it better than the >>> FFI >>> based OpenGL implementation. Can someone shed some light on it? >>> >> >> The marshalling code is faster. It also deals nice with per-context > > Why is it faster? Can you give me some pointers? > it is faster because marshalling code generated for each concrete call. if your function expects int agrument, then it will generate code for converting smalltalk object to int. FFI plugin, however first have to read the function signature(s) and only then pick appropriate conversion. >> feature availability (depending on context you created, some functions >> may be availabale, some not). >> And it contains a lot of extensions (over 3000 OpenGL functions), up >> to version 3.1 , because all functions are automatically generated >> from specs taken from >> official source. >> A future versions of OpenGL is easy to use: you just regenerate >> sources from specs. >> >> I also plan to integrate it with JIT, so when you invoking a method >> with native code, it will just run this code without extra checks and >> popping out of 'jit' mode. > > It seems to me that besides the marshalling part, everything can/could be > done with FFI too. Am I right? > maybe. with even more expense. Imagine that you have two instances of OpenGLApi, where one should fail on some functions and don't try to call them (because it could lead to crash), while other not. > > Levente > -- Best regards, Igor Stasenko.

Nov. 18, 2011

Re: [Pharo-project] OpenGL in Pharo?

by Levente Uzonyi

On Fri, 18 Nov 2011, Igor Stasenko wrote: > 2011/11/18 Levente Uzonyi <leves(a)elte.hu>: >> On Thu, 17 Nov 2011, Javier PimÃ¡s wrote: >> >>> We are advancing on making OpenGL work with NativeBoost right now. If you >>> have to write an app >>> that uses OpenGL now, I would strongly recommend you to use NBOpenGL. It's >> >> I see the hype about NBOpenGL, but I don't see how is it better than the FFI >> based OpenGL implementation. Can someone shed some light on it? >> > > The marshalling code is faster. It also deals nice with per-context Why is it faster? Can you give me some pointers? > feature availability (depending on context you created, some functions > may be availabale, some not). > And it contains a lot of extensions (over 3000 OpenGL functions), up > to version 3.1 , because all functions are automatically generated > from specs taken from > official source. > A future versions of OpenGL is easy to use: you just regenerate > sources from specs. > > I also plan to integrate it with JIT, so when you invoking a method > with native code, it will just run this code without extra checks and > popping out of 'jit' mode. It seems to me that besides the marshalling part, everything can/could be done with FFI too. Am I right? Levente > >> >> Levente > > -- > Best regards, > Igor Stasenko. > >

Nov. 18, 2011

Re: [Pharo-project] how to get a string read stream from filesystem

by Max Leske

Hi Doru The last time I used FS that was the way to do it. Maybe what you want could be accomplished by adding convenience methods to FSReadStream like #stringContents or something. Anyway, I agree with Norbert that a ByteArray is really the data structure that you should expect to get from a file. Cheers, Max On 17.11.2011, at 22:01, Tudor Girba wrote: > Hi, > > I am using Filesystem, and I would like to get a read stream that provides a string instead of bytes. > > If I do "aReference readStream", I get a FSReadStream which is a byte stream. > > To get to the string, I now do the ugly: "aReference readStream contents asString" > > Is there a cleverer way? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "What we can governs what we wish." > > > >

Nov. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Igor Stasenko

On 18 November 2011 06:32, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote: >> >> virtually nowhere :) >> > > Should the non-weak version be removed and replaced by the weak version > (renamed to remove the weak specification)? Or some other consolidation... > Why? Strong subscriptions may be desirable at some point. I imagine, that some models may need to not let subsribers die, even if the only reference to subscriber is strong subscription itself. IMO, it is unusual, since Announcements framework serves as a nice decoupling scheme, which means that in most cases, you want subscription to live as long as subscriber lives and not a bit longer. > -- > View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082112.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.

Nov. 18, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Sean P. DeNigris

Igor Stasenko wrote: > > virtually nowhere :) > Should the non-weak version be removed and replaced by the weak version (renamed to remove the weak specification)? Or some other consolidation... -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082112.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 18, 2011