- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Unsubscribing for Announcements

by Igor Stasenko

On 18 November 2011 04:06, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote: >> >> This works since quite a while. I use it in Glamour extensively. >> > > Cool! Is it working well in 1.3 rc? > > Also, why do we still have the non-weak version? When would that be > preferred? > virtually nowhere :) > Sean > > -- > View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4081871.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

Tudor Girba-2 wrote: > > This works since quite a while. I use it in Glamour extensively. > Cool! Is it working well in 1.3 rc? Also, why do we still have the non-weak version? When would that be preferred? Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4081871.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 18, 2011

Re: [Pharo-project] WideString performance

by Dennis Schetinin

Great! This one works (with just renaming separator to delimiter; had also to replace *stream* upTo: $" with *line* upTo: $" in previous code) and improves reading time drastically: from many-many-many-many minutes to about 30 seconds! Thank you very much once again! :) 2011/11/18 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > | row char line nextValue noValue | > line := stream nextLine reading. > row := OrderedCollection new. > nextValue := (WideString new: 32) writing. > noValue := true. > > [[[(char := line get) isSeparator] whileTrue. > noValue := false. > char = $" ifTrue: > [[nextValue write: (line ending: $") rest. > (char := line get) = $"] whileTrue: > [nextValue put: $"]. > [char = separator] whileFalse: [char := line get]]. > [char = separator] > whileFalse: > [nextValue put: char. > char := line get]. > row add: nextValue conclusion. > nextValue := (WideString new: 32) writing] repeat] > on: Incomplete do: [:exc | ]. > > noValue ifFalse: [row add: nextValue conclusion]. > ^row > -- Dennis Schetinin

Nov. 18, 2011

Re: [Pharo-project] OpenGL in Pharo?

by Igor Stasenko

On 18 November 2011 03:00, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > On Fri, Nov 18, 2011 at 9:54 AM, Igor Stasenko <siguctua(a)gmail.com> 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 >> 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. > > Looks great Igor ! > > I'm a bit curious, how this generation is automatically done ? > Could you use the same technique for others C librairies ? Well, it parsing the spec files , which having special format and of course has nothing to do with other C libraries. There is a project i seen on last ESUG conference, which using GCC compiler to automatically generate bindings to libraries. But still do not think that you can avoid manual work: if you care about quality and comprehensiveness of the code, you have to get your hands dirty, involving creating different classes to represent various abstractions provided by library, add a convenience layer etc etc. > Regards, > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Matsuno Laboratory, Kyoto University, Japan (until 12/2011) > http://www.mechatronics.me.kyoto-u.ac.jp/ > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > -- Best regards, Igor Stasenko.

Nov. 18, 2011

Re: [Pharo-project] OpenGL in Pharo?

by Igor Stasenko

On 18 November 2011 00:55, Pavel Krivanek <pavel.krivanek(a)gmail.com> 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? > I think both. On some platforms you cannot afford to run dynamically generated code, and NativeBoost doesn't supports ARM. So, a C implementation may serve as a way to have FFI, when you constrained. > 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). > Well, the problem with locating libraries is same in NB, since by default it using same library lookup as FFI (it just calls a VM function for that). So, i actually surprised why it worked with NB, and not with FFI. Of course with NB, you are free to change the way you search for library, in case of need. > 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 >> > > -- Best regards, Igor Stasenko.

Nov. 18, 2011