November 2013 - Pharo-users

Re: [Pharo-users] Nautilus + Periscope

by Juraj Kubelka

Thank you, I will have a look on it and I will try to fix it during the next mini sprint. Cheers, Jura El 16-11-2013, a las 14:25, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > The main problem is in dynamic UI generation for plugins and own Morphic binding. It was done using several hacks that do not work in the recent Spec version. Some information are here: > http://forum.world.st/update-3-0-30448-td4712466.html > > -- Pavel > > > 2013/11/15 Juraj Kubelka <juraj.kubelka(a)gmail.com> > Hi Pavel, > > I finally installed in Pharo 2.0. I did not know I have a different image.Thanks for your help and thanks also for the configuration script :-) > > I would like to use Periscope in Pharo 3.0. Do you have an idea what is necessary to change? > I am willing to help with it, but I need some support. First likely I have to learn Spec framework. > Right now I have just a white window like in the attachment. > > Cheers, > Jura > > <Captura de pantalla 2013-11-15 a la(s) 13.07.31.png> > > El 14-11-2013, a las 17:40, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > >> Yes, it works on the edge of Spec capabilities and it needs to use >> some hacks that are not possible in the recent Spec version. >> >> -- Pavel >> >> 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >>> Thanks, I will try it. >>> >>> Are there some changes in Pharo 3, that does not allow to use it in Pharo 3? >>> >>> Cheers, >>> Jura >>> >>> El 14-11-2013, a las 16:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: >>> >>>> I fixed the recent experiments with the new Spec versions so now it >>>> should work in Pharo 2.0. It really needs a configuration :-) >>>> >>>> Gofer new >>>> smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; >>>> package: 'Periscope'; >>>> load. >>>> >>>> Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} >>>> >>>> -- Pavel >>>> >>>> 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >>>>> Hi! >>>>> >>>>> Today StÃ©phane mentioned project Periscope (Universal Navigation Sidebar for Nautilus). >>>>> >>>>> Does anyone use it or maintain it? It looks like it does not work. >>>>> >>>>> Links: >>>>> - http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautil… >>>>> - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope >>>>> >>>>> Cheers, >>>>> Jura >>>> >>> >>> >> > >

Nov. 16, 2013

Re: [Pharo-users] Nautilus + Periscope

by Pavel Krivanek

The main problem is in dynamic UI generation for plugins and own Morphic binding. It was done using several hacks that do not work in the recent Spec version. Some information are here: http://forum.world.st/update-3-0-30448-td4712466.html -- Pavel 2013/11/15 Juraj Kubelka <juraj.kubelka(a)gmail.com> > Hi Pavel, > > I finally installed in Pharo 2.0. I did not know I have a different > image.Thanks for your help and thanks also for the configuration script :-) > > I would like to use Periscope in Pharo 3.0. Do you have an idea what is > necessary to change? > I am willing to help with it, but I need some support. First likely I have > to learn Spec framework. > Right now I have just a white window like in the attachment. > > Cheers, > Jura > > > El 14-11-2013, a las 17:40, Pavel Krivanek <pavel.krivanek(a)gmail.com> > escribiÃ³: > > Yes, it works on the edge of Spec capabilities and it needs to use > some hacks that are not possible in the recent Spec version. > > -- Pavel > > 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > > Thanks, I will try it. > > Are there some changes in Pharo 3, that does not allow to use it in Pharo > 3? > > Cheers, > Jura > > El 14-11-2013, a las 16:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> > escribiÃ³: > > I fixed the recent experiments with the new Spec versions so now it > should work in Pharo 2.0. It really needs a configuration :-) > > Gofer new > smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; > package: 'Periscope'; > load. > > Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). > #none} > > -- Pavel > > 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > > Hi! > > Today StÃ©phane mentioned project Periscope (Universal Navigation Sidebar > for Nautilus). > > Does anyone use it or maintain it? It looks like it does not work. > > Links: > - > http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautil… > - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope > > Cheers, > Jura > > > > > > >

Nov. 16, 2013

Finding references to traits

by btc＠openinworld.com

If I come in cold to a system and see some class using trait, and then I want to find all classes that use that trait. I have tried a few ways but failed to work it out. The most obvious action "Extended search > references of it" doesn't show them, and neither does any other action I try. How is this done? cheers -ben

Nov. 16, 2013

Re: [Pharo-users] [Spec] How to adding my scroll bar

by Gisela Decuzzi

Thanks for the answer, I will try it. 2013/11/15 Ignacio MatÃas Sniechowski <0800nacho(a)gmail.com> > Hello Gisela, > I've been searching for a way to do that using Spec in Pharo 2.0 seems a > tricky one. In Pharo 3 is a lot easier. > One alternative solution, though not very nice, is to use a Slider with a > vertical layout.... > saludos > Nacho > > > > *Lic. Ignacio Sniechowski, MBA* > > > > > > > On Fri, Nov 15, 2013 at 12:00 PM, Gisela Decuzzi <giseladecuzzi(a)gmail.com>wrote: > >> Hello, I have a component that basically contains lot of widgets and I >> want to add a scroll bar to it. >> But I didn't find a way to do this. >> I'm using Pharo 2.0 (I know 3.0 is better but I needed something stable). >> >> My spec is a ColumnLayout with lot of rows. Maybe I should use another? >> Can someone point me where to look at? >> >> >

Nov. 16, 2013

Re: [Pharo-users] [Spec] How to adding my scroll bar

by HernÃ¡n Morales Durand

I did it but not Spec. Let me know if you need some hints. HernÃ¡n El 15/11/2013 12:00, Gisela Decuzzi escribiÃ³: > Hello, I have a component that basically contains lot of widgets and I > want to add a scroll bar to it. > But I didn't find a way to do this. > I'm using Pharo 2.0 (I know 3.0 is better but I needed something stable). > > My spec is a ColumnLayout with lot of rows. Maybe I should use another? > Can someone point me where to look at? >

Nov. 16, 2013

Re: [Pharo-users] [Spec] How to adding my scroll bar

by Ignacio MatÃas Sniechowski

Hello Gisela, I've been searching for a way to do that using Spec in Pharo 2.0 seems a tricky one. In Pharo 3 is a lot easier. One alternative solution, though not very nice, is to use a Slider with a vertical layout.... saludos Nacho *Lic. Ignacio Sniechowski, MBA* On Fri, Nov 15, 2013 at 12:00 PM, Gisela Decuzzi <giseladecuzzi(a)gmail.com>wrote: > Hello, I have a component that basically contains lot of widgets and I > want to add a scroll bar to it. > But I didn't find a way to do this. > I'm using Pharo 2.0 (I know 3.0 is better but I needed something stable). > > My spec is a ColumnLayout with lot of rows. Maybe I should use another? > Can someone point me where to look at? > >

Nov. 15, 2013

Re: [Pharo-users] Nautilus + Periscope

by Juraj Kubelka

Hi Pavel, I finally installed in Pharo 2.0. I did not know I have a different image.Thanks for your help and thanks also for the configuration script :-) I would like to use Periscope in Pharo 3.0. Do you have an idea what is necessary to change? I am willing to help with it, but I need some support. First likely I have to learn Spec framework. Right now I have just a white window like in the attachment. Cheers, Jura El 14-11-2013, a las 17:40, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > Yes, it works on the edge of Spec capabilities and it needs to use > some hacks that are not possible in the recent Spec version. > > -- Pavel > > 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >> Thanks, I will try it. >> >> Are there some changes in Pharo 3, that does not allow to use it in Pharo 3? >> >> Cheers, >> Jura >> >> El 14-11-2013, a las 16:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: >> >>> I fixed the recent experiments with the new Spec versions so now it >>> should work in Pharo 2.0. It really needs a configuration :-) >>> >>> Gofer new >>> smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; >>> package: 'Periscope'; >>> load. >>> >>> Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} >>> >>> -- Pavel >>> >>> 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >>>> Hi! >>>> >>>> Today StÃ©phane mentioned project Periscope (Universal Navigation Sidebar for Nautilus). >>>> >>>> Does anyone use it or maintain it? It looks like it does not work. >>>> >>>> Links: >>>> - http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautil… >>>> - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope >>>> >>>> Cheers, >>>> Jura >>> >> >> >

Nov. 15, 2013

[Spec] How to adding my scroll bar

by Gisela Decuzzi

Hello, I have a component that basically contains lot of widgets and I want to add a scroll bar to it. But I didn't find a way to do this. I'm using Pharo 2.0 (I know 3.0 is better but I needed something stable). My spec is a ColumnLayout with lot of rows. Maybe I should use another? Can someone point me where to look at?

Nov. 15, 2013

Re: [Pharo-users] i18n - Where to start?

by Stephan Eggermont

Here is a demo of the i18n support in QCMagritte. It supports live editing of the languages and strings used in your application. youtu.be/cTut44Xs3_U Stephan

Nov. 15, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by StÃ©phane Ducasse

> Hi > > Wanted to let you know that the GLTTRenderingDemo is working again on Windows. > Thanks a lot for your effort! Ricky Now you should really think that JB is doing that on his free time. He is not payed for doing that. We should work on Python security and Moose Python. So what I want to say is that you should consider that Pharo is YOURS and that NBOpenGL too. So let, and if you do not know, learn. JB learned openGL to do something fun during his PhD but it has nothing to do to 3D. It is about security and dynamic language. Help yourself to build a great system. Stef > > Ricky > > > On Thu, Nov 14, 2013 at 6:14 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks a lot for looking into this. We will check tomorrow when we are back in front of a Windows machine, and let you know how it works. > > Cheers, > Doru > > > On Thu, Nov 14, 2013 at 4:57 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > Good news everyone: > bug fixed and integrated in 3,0 573 > I am open for new feedback. > > > On Nov 14, 2013, at 2:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 14 November 2013 14:25, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >> Yes the fix is not integrated yet. >> NBWndClassEx should not be a variable subclass anymore. This part should be checked with Igor. >> >> NBWndClassEx>>#initialize >> self cbSize: (self class instanceSize). >> and not self basicSize. >> >> ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize >> was always == instanceSize, but now it is no longer like that and >> you need to use longer expression e.g. (self class instanceSize) >> >> You can rebuildField accessor too (class side on every NBExternalStructure). >> >> Do this change and your image should work. (with the last openGL-Win) >> I can take you a picture of my computer. >> >> For more accurate answer I need the crash.dump >> >> >> On Nov 14, 2013, at 1:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> As I understand there are still some things to be integrated in NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of NBOpenGL crashes the VM (on Win 7) when doing: >>> GLTTRenderingDemo new openInWorld. >>> >>> Could you point us to the NativeBoost fix to see if it works? >>> >>> Doru >>> >>> >>> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >>> Should work after integration. >>> Configuration updated. >>> Need fix review for integration in nativeBoost, will do that with igor this afternoon. >>> >>> >>> On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >>> >>>> ok I have openGL work on my windows 7 machine. >>>> I will update the configuration. But I need to publish also a fix in NativeBoost win. >>>> This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] NBOpenGL VM crash. >>>> >>>> I open a bug entry. When It will be integrated. >>>> Window should work well. But if you have any trouble, give me feedback. >>>> >>>> >>>> On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> so richie >>>>> >>>>> have a look at the repository and load the latest version to see if they work (not using the configuration). >>>>> This is what we will try here (chile). >>>>> >>>>> Stef >>>>> >>>>> On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: >>>>> >>>>>> Thanks everyone! That would be great. >>>>>> Looking forward to having NBOpenGL up and running again. >>>>>> >>>>>> Cheers >>>>>> Ricky >>>>>> >>>>>> >>>>>> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>>> >>>>>>>> Right now it cannot even be loaded into 3.0. >>>>>>>> But update is simple (i think JB did that already, just not published?). >>>>>>> Grrr, all my code are published ^^. >>>>>> >>>>>> Where? When did you announce it? >>>>>> Sorry but how can you expect guys from the other part of the planet to know it. >>>>>> Communication in open-source is important because people do not know what others >>>>>> are doing. >>>>>> You know richie asked and ronie too and they are smart guys. But they cannot guess. >>>>>> >>>>>>> For mac: >>>>>>> I do the change for mac last month because I needed it, it is integrated. >>>>>> >>>>>> ah ok this is why it is working on mac. >>>>>> >>>>>>> For linux: >>>>>>> I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. >>>>>>> On my roommate computer that work (ubuntu ). >>>>>>> But I need feedback. >>>>>> >>>>>> oki we will check that tomorrow I hope. >>>>>> >>>>>>> For windows: >>>>>>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. >>>>>>> I was planned to go test and debug on my home computer (window 7, 64), tomorrow. >>>>>> >>>>>> Ok we can say it to ronie to have a look. >>>>>> >>>>>>> So, you can expect a fix integrated soon. >>>>>>> >>>>>>> And having a working OpenGL, exactly as it work in pharo 2.0. >>>>>> >>>>>> Excellent. >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. >>>>>>>> >>>>>>>> Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). >>>>>>>> Because Roassal 3d should not be about shadder but about 3D. >>>>>>>> >>>>>>>>> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). >>>>>>>> >>>>>>>> Yes they changed the API and deprecated the old way of doing it. >>>>>>> >>>>>>> I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. >>>>>>> >>>>>>> >>>>>>>>> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. >>>>>>>> >>>>>>>> See below >>>>>>>> >>>>>>>>> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. >>>>>>>> >>>>>>> >>>>>>>> Three remarks: >>>>>>>> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL >>>>>>> >>>>>>> Shader part are done for now. >>>>>>> >>>>>>>> - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying >>>>>>>> on other people and probably frustrated when things are not working. >>>>>>> + 1 >>>>>>> >>>>>>>> - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) >>>>>>>> a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you >>>>>>>> can get >>>>>>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>>>>>> >>>>>>>> >>>>>>> >>>>>>> yes, my bad. >>>>>>> >>>>>>>> Now again if nobody builds a jun like library in Pharo it will not exist. >>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Ricky >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >>>>>>>>> >>>>>>>>> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>>>> Richard >>>>>>>>> >>>>>>>>> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >>>>>>>>> and his code should be split in two and one part should go to NBOpenGL. >>>>>>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>>>>>> >>>>>>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >>>>>>>>> he does not have fun there). >>>>>>>>> >>>>>>>>> So it is important that you help because we are FULL >>>>>>>>> and sorry about that but really FULL. >>>>>>>>> >>>>>>>>> Ronie will visit us in January and share an office with igor. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> > Hi >>>>>>>>> > >>>>>>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>>>>>> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >>>>>>>>> > >>>>>>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >>>>>>>>> > >>>>>>>>> > GLTTRenderingDemo new openInWorld. >>>>>>>>> > >>>>>>>>> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >>>>>>>>> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >>>>>>>>> > >>>>>>>>> > Cheers >>>>>>>>> > Ricky >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com >>>>>>>>> >>>>>>>>> "Every thing has its own flow" >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko. >>>>>>> >>>>>>> Best Regards >>>>>>> Jean Baptiste Arnaud >>>>>>> jbaptiste.arnaud(a)gmail.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> Best Regards >>>> Jean Baptiste Arnaud >>>> jbaptiste.arnaud(a)gmail.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 15, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Richard Wettel

Hi Wanted to let you know that the GLTTRenderingDemo is working again on Windows. Thanks a lot for your effort! Ricky On Thu, Nov 14, 2013 at 6:14 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks a lot for looking into this. We will check tomorrow when we are > back in front of a Windows machine, and let you know how it works. > > Cheers, > Doru > > > On Thu, Nov 14, 2013 at 4:57 PM, Jean Baptiste Arnaud < > jbaptiste.arnaud(a)gmail.com> wrote: > >> Good news everyone: >> bug fixed and integrated in 3,0 573 >> I am open for new feedback. >> >> >> On Nov 14, 2013, at 2:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> >> On 14 November 2013 14:25, Jean Baptiste Arnaud < >> jbaptiste.arnaud(a)gmail.com> wrote: >> >>> Yes the fix is not integrated yet. >>> NBWndClassEx should not be a variable subclass anymore. This part should >>> be checked with Igor. >>> >>> NBWndClassEx>>#initialize >>> self cbSize: (self class instanceSize). >>> and not self basicSize. >>> >>> ah, yes, of couse since before NBWndClassEx was var-byte and its >> basicSize >> was always == instanceSize, but now it is no longer like that and >> you need to use longer expression e.g. (self class instanceSize) >> >> >>> You can rebuildField accessor too (class side on every >>> NBExternalStructure). >>> >>> Do this change and your image should work. (with the last openGL-Win) >>> I can take you a picture of my computer. >>> >>> For more accurate answer I need the crash.dump >>> >>> >>> On Nov 14, 2013, at 1:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> As I understand there are still some things to be integrated in >>> NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of >>> NBOpenGL crashes the VM (on Win 7) when doing: >>> GLTTRenderingDemo new openInWorld. >>> >>> Could you point us to the NativeBoost fix to see if it works? >>> >>> Doru >>> >>> >>> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud < >>> jbaptiste.arnaud(a)gmail.com> wrote: >>> >>>> Should work after integration. >>>> Configuration updated. >>>> Need fix review for integration in nativeBoost, will do that with igor >>>> this afternoon. >>>> >>>> >>>> On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud < >>>> jbaptiste.arnaud(a)gmail.com> wrote: >>>> >>>> ok I have openGL work on my windows 7 machine. >>>> I will update the configuration. But I need to publish also a fix in >>>> NativeBoost win. >>>> This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] >>>> NBOpenGL VM crash. >>>> >>>> I open a bug entry. When It will be integrated. >>>> Window should work well. But if you have any trouble, give me feedback. >>>> >>>> >>>> On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse < >>>> stephane.ducasse(a)inria.fr> wrote: >>>> >>>> so richie >>>> >>>> have a look at the repository and load the latest version to see if >>>> they work (not using the configuration). >>>> This is what we will try here (chile). >>>> >>>> Stef >>>> >>>> On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: >>>> >>>> Thanks everyone! That would be great. >>>> Looking forward to having NBOpenGL up and running again. >>>> >>>> Cheers >>>> Ricky >>>> >>>> >>>> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse < >>>> stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> >>>>>> Right now it cannot even be loaded into 3.0. >>>>> But update is simple (i think JB did that already, just not >>>>> published?). >>>>> >>>>> Grrr, all my code are published ^^. >>>>> >>>>> >>>>> Where? When did you announce it? >>>>> Sorry but how can you expect guys from the other part of the planet to >>>>> know it. >>>>> Communication in open-source is important because people do not know >>>>> what others >>>>> are doing. >>>>> You know richie asked and ronie too and they are smart guys. But they >>>>> cannot guess. >>>>> >>>>> For mac: >>>>> I do the change for mac last month because I needed it, it is >>>>> integrated. >>>>> >>>>> >>>>> ah ok this is why it is working on mac. >>>>> >>>>> For linux: >>>>> I fix, published, tested and updated the configuration for linux 2 >>>>> days ago, because Alex ask me. >>>>> On my roommate computer that work (ubuntu ). >>>>> But I need feedback. >>>>> >>>>> >>>>> oki we will check that tomorrow I hope. >>>>> >>>>> For windows: >>>>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 >>>>> but I do not update configuration because I cannot test it. >>>>> I was planned to go test and debug on my home computer (window 7, 64), >>>>> tomorrow. >>>>> >>>>> >>>>> Ok we can say it to ronie to have a look. >>>>> >>>>> So, you can expect a fix integrated soon. >>>>> >>>>> And having a working OpenGL, exactly as it work in pharo 2.0. >>>>> >>>>> >>>>> Excellent. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> I have already looked at Roassal 3d, but it was not easy to >>>>>> separate the API from the code. >>>>>> >>>>>> >>>>>> Strange because even me I could see that the shadder code should not >>>>>> be in Roassal 3D but in NBOpenGL :). >>>>>> Because Roassal 3d should not be about shadder but about 3D. >>>>>> >>>>> >>>>>> And it is something completely different than what I have been using >>>>>> (and SourceCity, too), because Roassal 3d is using the modern OpenGL >>>>>> methodology (with FBOs and stuff). >>>>>> >>>>>> >>>>>> Yes they changed the API and deprecated the old way of doing it. >>>>>> >>>>> >>>>> I will also publish some example (using shadder) that I wrote but it >>>>> is still not yet user friendly. >>>>> >>>>> >>>>> So, I would really appreciate if that API would find its way from >>>>>> Roassal to NBOpenGL and I could use it for CodeCity. >>>>>> >>>>>> >>>>>> See below >>>>>> >>>>> >>>>>> Unfortunately I am able to help a lot with that, because I know very >>>>>> little about this and I also don't have enough time (I am doing CodeCity in >>>>>> my spare time). But, if you have concrete things that I can do, I'd be >>>>>> happy to help. >>>>>> >>>>>> >>>>>> Three remarks: >>>>>> - I know that jean-baptiste worked on moving part of roassal3d to >>>>>> NBOpenGL >>>>>> >>>>> >>>>> Shader part are done for now. >>>>> >>>>> - I'm not sure that doing 3d without investing a bit in the >>>>>> underlying technology is wise. Because you will be always relying >>>>>> on other people and probably frustrated when things are not working. >>>>>> >>>>> + 1 >>>>> >>>>> - Since JB does not know how to communicate here is what he did for >>>>>> fun instead of pushing MoosePython :) >>>>>> >>>>> a renderer to video to videos stream for openGL -> MKV, mp4 based >>>>>> one ffmpeg). The code is openGL extra. As an example you >>>>>> can get >>>>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>>>>> >>>>> >>>>>> >>>>> yes, my bad. >>>>> >>>>> Now again if nobody builds a jun like library in Pharo it will not >>>>>> exist. >>>>>> >>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> Cheers >>>>>> Ricky >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I guess that what Ricky is asking is what changed between NBOpenGL >>>>>>> 2.0 and 3.0 such that this does not work anymore on Windows. The fact that >>>>>>> he mentioned 64 bits is not relevant for this discussion :). >>>>>>> >>>>>>> I also guess he wants to put some effort into understanding this as >>>>>>> well but he needs a bit of guidance. Right Ricky? >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse < >>>>>>> stephane.ducasse(a)inria.fr> wrote: >>>>>>> >>>>>>>> Richard >>>>>>>> >>>>>>>> you should have a look at ROASSAL 3d because ronie improved the >>>>>>>> shadder part (no more assembler) >>>>>>>> and his code should be split in two and one part should go to >>>>>>>> NBOpenGL. >>>>>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>>>>> >>>>>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy >>>>>>>> finishing the texteditor (and I can tell you that >>>>>>>> he does not have fun there). >>>>>>>> >>>>>>>> So it is important that you help because we are FULL >>>>>>>> and sorry about that but really FULL. >>>>>>>> >>>>>>>> Ronie will visit us in January and share an office with igor. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> > Hi >>>>>>>> > >>>>>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>>>>> > I'd like to start working on it using Pharo 3, but it seems that >>>>>>>> NBOpenGL does not work yet with Pharo 3.0. >>>>>>>> > >>>>>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried >>>>>>>> to execute the following code on Windows 7, 64 bits: >>>>>>>> > >>>>>>>> > GLTTRenderingDemo new openInWorld. >>>>>>>> > >>>>>>>> > but I get a 'No suitable implementation found for initializing >>>>>>>> OpenGL context for your platform'. >>>>>>>> > It seems that NBGLContextDriver does not have a subclass for >>>>>>>> Windows 64bits. Did I omit something? >>>>>>>> > >>>>>>>> > Cheers >>>>>>>> > Ricky >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Every thing has its own flow" >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>>> Best Regards >>>>> Jean Baptiste Arnaud >>>>> jbaptiste.arnaud(a)gmail.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> Best Regards >>>> Jean Baptiste Arnaud >>>> jbaptiste.arnaud(a)gmail.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Best Regards >>>> Jean Baptiste Arnaud >>>> jbaptiste.arnaud(a)gmail.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 15, 2013

Re: [Pharo-users] Arduino package extra files

by Bernat Romagosa

Thanks Camille, I just asked Ricardo for the files :) 2013/11/15 Camille Teruel <camille.teruel(a)gmail.com> > Hello Bernat, > > You should ask directly the developers of this project. Maybe they are not > registered to this mailing list. > You should find their mail addresses on the squeaksource page of this > project. > > > > On 15 nov. 2013, at 10:47, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > wrote: > > bump? > > > 2013/10/25 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > >> Hi list, >> >> After successfully installing the Arduino package, I noticed this Getting >> Started text: >> >> *After installing the Arduino packages by evaluating...* >> >> * ConfigurationOfArduino load.* >> *...you'll need a couple extra support files in order to be able to >> upload programs to your Arduino board. You can download them from here:* >> * http://www.mediafire.com/?1rep41uygl4rpf1 >> <http://www.mediafire.com/?1rep41uygl4rpf1>* >> *Extract the contents of that file in the same directory where you have >> your Pharo image.* >> >> >> But the mediafire link is broken. >> >> Where can I get the extra support files? >> >> Thanks! >> >> Bernat. >> >> -- >> Bernat Romagosa. >> > > > > -- > Bernat Romagosa. > > > -- Bernat Romagosa.

Nov. 15, 2013

Re: [Pharo-users] Arduino package extra files

by Camille Teruel

Hello Bernat, You should ask directly the developers of this project. Maybe they are not registered to this mailing list. You should find their mail addresses on the squeaksource page of this project. On 15 nov. 2013, at 10:47, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > bump? > > > 2013/10/25 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > Hi list, > > After successfully installing the Arduino package, I noticed this Getting Started text: > > After installing the Arduino packages by evaluating... > > ConfigurationOfArduino load. > > ...you'll need a couple extra support files in order to be able to upload programs to your Arduino board. You can download them from here: > > http://www.mediafire.com/?1rep41uygl4rpf1 > > Extract the contents of that file in the same directory where you have your Pharo image. > > But the mediafire link is broken. > > Where can I get the extra support files? > > Thanks! > > Bernat. > > -- > Bernat Romagosa. > > > > -- > Bernat Romagosa.

Nov. 15, 2013

Re: [Pharo-users] Arduino package extra files

by Bernat Romagosa

bump? 2013/10/25 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > Hi list, > > After successfully installing the Arduino package, I noticed this Getting > Started text: > > *After installing the Arduino packages by evaluating...* > > * ConfigurationOfArduino load.* > *...you'll need a couple extra support files in order to be able to > upload programs to your Arduino board. You can download them from here:* > * http://www.mediafire.com/?1rep41uygl4rpf1 > <http://www.mediafire.com/?1rep41uygl4rpf1>* > *Extract the contents of that file in the same directory where you have > your Pharo image.* > > > But the mediafire link is broken. > > Where can I get the extra support files? > > Thanks! > > Bernat. > > -- > Bernat Romagosa. > -- Bernat Romagosa.

Nov. 15, 2013

Re: [Pharo-users] [Athens] Finding if a line passes through a specific pixel .

by kilon alios

Libraries have no job. They have no obligations. No things they should or must do. They have methods that define what they can do. So there is nothing stopping Athens from having such a feature. Hence my question. But I found the formula for this, looks like i will be learning linear algebra and geometry. Good thing I love math :D Î£ÏÎ¹Ï 15 ÎÎ¿Îµ 2013 6:24 Ï.Î¼., Î¿ ÏÏÎ®ÏÏÎ·Ï "Dennis Schetinin" <chaetal(a)gmail.com> ÎÎ³ÏÎ±ÏÎµ: > Why do you think it's a job for Athens? Shouldn't it be in a geometry lib? > > > -- > > Best regards, > > > Dennis Schetinin > > > 2013/11/15 kilon alios <kilon.alios(a)gmail.com> > >> So here we are with my first challenge. I am making Hyperion, a vector >> graphics editor using Athens , so far I have a nice line with several >> segments, I have added nice handlers to allow me to move the points (start >> and end of each segment) of the line around with the mouse, but now I want >> each time I click on a segment itself to create a new point.This way I will >> create more points with the mouse and bring more detail to the shape of the >> line / path. >> >> In order to do that I will have to check that the line passes through a >> specific pixel. Or to be more correct that the place that mouse has clicked >> is where my path passes through. How I do that ? Can Athens do that ? Can >> athens tell me which pixels my path passes through ? >> >> At first I thought to return the Athens surface as a Form but the form >> will give me back the colors of each pixel on a specific place, but that >> does not guarantee that my line / path passes through those pixels. >> > >

Nov. 15, 2013

Re: [Pharo-users] [Athens] Finding if a line passes through a specific pixel .

by Dennis Schetinin

Why do you think it's a job for Athens? Shouldn't it be in a geometry lib? -- Best regards, Dennis Schetinin 2013/11/15 kilon alios <kilon.alios(a)gmail.com> > So here we are with my first challenge. I am making Hyperion, a vector > graphics editor using Athens , so far I have a nice line with several > segments, I have added nice handlers to allow me to move the points (start > and end of each segment) of the line around with the mouse, but now I want > each time I click on a segment itself to create a new point.This way I will > create more points with the mouse and bring more detail to the shape of the > line / path. > > In order to do that I will have to check that the line passes through a > specific pixel. Or to be more correct that the place that mouse has clicked > is where my path passes through. How I do that ? Can Athens do that ? Can > athens tell me which pixels my path passes through ? > > At first I thought to return the Athens surface as a Form but the form > will give me back the colors of each pixel on a specific place, but that > does not guarantee that my line / path passes through those pixels. >

Nov. 15, 2013

Re: [Pharo-users] Nautilus + Periscope

by Pavel Krivanek

Hi Torsten, thank you very much. Everything is done. Now Periscope can be loaded using Configuration Browser into Pharo 2.0. Cheers, -- Pavel 2013/11/14 Torsten Bergmann <astares(a)gmx.de>: > Pavel wrote: >>I fixed the recent experiments with the new Spec versions so now it >>should work in Pharo 2.0. It really needs a configuration :-) > > You mean a configuration like the one I attached :) > > Did you notice the new "Config+" button on the metacello browser - it > helps creating new configs. I also added a postload for plugin registration. > > Feel free to use and put into your STHub repo. > > > I found two bugs in Periscope using Pharo2.0 #20627: > > 1. When one enters "Obj" to search for object it crashes in the spotlight > 2. When one opens tools like the Configuration browser they show up inside > of the area of Periscope... > > If this gets fixed and config gets usable for Pharo 2.0 then do not forget to > add the updated config also to "MetaRepoForPharo20" on SS3. This way it will > show up in the config browser and can easily be loaded. > > Thx > T.

Nov. 14, 2013

Re: [Pharo-users] Nautilus + Periscope

by Pavel Krivanek

Yes, it works on the edge of Spec capabilities and it needs to use some hacks that are not possible in the recent Spec version. -- Pavel 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > Thanks, I will try it. > > Are there some changes in Pharo 3, that does not allow to use it in Pharo 3? > > Cheers, > Jura > > El 14-11-2013, a las 16:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > >> I fixed the recent experiments with the new Spec versions so now it >> should work in Pharo 2.0. It really needs a configuration :-) >> >> Gofer new >> smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; >> package: 'Periscope'; >> load. >> >> Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} >> >> -- Pavel >> >> 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >>> Hi! >>> >>> Today StÃ©phane mentioned project Periscope (Universal Navigation Sidebar for Nautilus). >>> >>> Does anyone use it or maintain it? It looks like it does not work. >>> >>> Links: >>> - http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautil… >>> - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope >>> >>> Cheers, >>> Jura >> > >

Nov. 14, 2013

Nautilus + Periscope

by Torsten Bergmann

Pavel wrote: >I fixed the recent experiments with the new Spec versions so now it >should work in Pharo 2.0. It really needs a configuration :-) You mean a configuration like the one I attached :) Did you notice the new "Config+" button on the metacello browser - it helps creating new configs. I also added a postload for plugin registration. Feel free to use and put into your STHub repo. I found two bugs in Periscope using Pharo2.0 #20627: 1. When one enters "Obj" to search for object it crashes in the spotlight 2. When one opens tools like the Configuration browser they show up inside of the area of Periscope... If this gets fixed and config gets usable for Pharo 2.0 then do not forget to add the updated config also to "MetaRepoForPharo20" on SS3. This way it will show up in the config browser and can easily be loaded. Thx T.

Nov. 14, 2013

Re: [Pharo-users] Nautilus + Periscope

by Juraj Kubelka

Thanks, I will try it. Are there some changes in Pharo 3, that does not allow to use it in Pharo 3? Cheers, Jura El 14-11-2013, a las 16:57, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > I fixed the recent experiments with the new Spec versions so now it > should work in Pharo 2.0. It really needs a configuration :-) > > Gofer new > smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; > package: 'Periscope'; > load. > > Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} > > -- Pavel > > 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: >> Hi! >> >> Today StÃ©phane mentioned project Periscope (Universal Navigation Sidebar for Nautilus). >> >> Does anyone use it or maintain it? It looks like it does not work. >> >> Links: >> - http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautil… >> - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope >> >> Cheers, >> Jura >

Nov. 14, 2013

Re: [Pharo-users] [Pharo-dev] State of Flamel?

by StÃ©phane Ducasse

We should change that and use the properties of the node. Stef On Nov 14, 2013, at 8:52 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 14 nov. 2013, at 19:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Gisela is busy preparing a workshop in argentina and working. >> Now did you try to load it? >> I do not know if there is an automated jenkins build. > > Gisela contacted me, and I managed to load the newest version. > AST-Core is changed in Flamel by adding instance variables to RBProgramNode. > That breaks each time AST-Core changes in Pharo. > Still 2 failing tests (already on Trello), and the transformation needs work. > > Stephan > >

Nov. 14, 2013

[Athens] Finding if a line passes through a specific pixel .

by kilon alios

So here we are with my first challenge. I am making Hyperion, a vector graphics editor using Athens , so far I have a nice line with several segments, I have added nice handlers to allow me to move the points (start and end of each segment) of the line around with the mouse, but now I want each time I click on a segment itself to create a new point.This way I will create more points with the mouse and bring more detail to the shape of the line / path. In order to do that I will have to check that the line passes through a specific pixel. Or to be more correct that the place that mouse has clicked is where my path passes through. How I do that ? Can Athens do that ? Can athens tell me which pixels my path passes through ? At first I thought to return the Athens surface as a Form but the form will give me back the colors of each pixel on a specific place, but that does not guarantee that my line / path passes through those pixels.

Nov. 14, 2013

Re: [Pharo-users] [Pharo-dev] State of Flamel?

by Gisela Decuzzi

Hi Stephan, thanks for testing it, when I have some time I will work in the transformation because is a big missing feature. If you want to contribute with the project tell me your smalltalkhub user to add you :) Sorry for the lack of support, as Stef said I'm in the middle of a workshop planning for this saturday. 2013/11/14 Stephan Eggermont <stephan(a)stack.nl> > > On 14 nov. 2013, at 19:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Gisela is busy preparing a workshop in argentina and working. > > Now did you try to load it? > > I do not know if there is an automated jenkins build. > > Gisela contacted me, and I managed to load the newest version. > AST-Core is changed in Flamel by adding instance variables to > RBProgramNode. > That breaks each time AST-Core changes in Pharo. > Still 2 failing tests (already on Trello), and the transformation needs > work. > > Stephan > > > >

Nov. 14, 2013

Re: [Pharo-users] Nautilus + Periscope

by Pavel Krivanek

I fixed the recent experiments with the new Spec versions so now it should work in Pharo 2.0. It really needs a configuration :-) Gofer new smalltalkhubUser: 'PavelKrivanek' project: 'Periscope'; package: 'Periscope'; load. Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none} -- Pavel 2013/11/14 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > Hi! > > Today StÃ©phane mentioned project Periscope (Universal Navigation Sidebar for Nautilus). > > Does anyone use it or maintain it? It looks like it does not work. > > Links: > - http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautil… > - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope > > Cheers, > Jura

Nov. 14, 2013

Re: [Pharo-users] [Pharo-dev] State of Flamel?

by Stephan Eggermont

On 14 nov. 2013, at 19:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Gisela is busy preparing a workshop in argentina and working. > Now did you try to load it? > I do not know if there is an automated jenkins build. Gisela contacted me, and I managed to load the newest version. AST-Core is changed in Flamel by adding instance variables to RBProgramNode. That breaks each time AST-Core changes in Pharo. Still 2 failing tests (already on Trello), and the transformation needs work. Stephan

Nov. 14, 2013

Nautilus + Periscope

by Juraj Kubelka

Hi! Today StÃ©phane mentioned project Periscope (Universal Navigation Sidebar for Nautilus). Does anyone use it or maintain it? It looks like it does not work. Links: - http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautil… - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope Cheers, Jura

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Tudor Girba

Thanks a lot for looking into this. We will check tomorrow when we are back in front of a Windows machine, and let you know how it works. Cheers, Doru On Thu, Nov 14, 2013 at 4:57 PM, Jean Baptiste Arnaud < jbaptiste.arnaud(a)gmail.com> wrote: > Good news everyone: > bug fixed and integrated in 3,0 573 > I am open for new feedback. > > > On Nov 14, 2013, at 2:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > On 14 November 2013 14:25, Jean Baptiste Arnaud < > jbaptiste.arnaud(a)gmail.com> wrote: > >> Yes the fix is not integrated yet. >> NBWndClassEx should not be a variable subclass anymore. This part should >> be checked with Igor. >> >> NBWndClassEx>>#initialize >> self cbSize: (self class instanceSize). >> and not self basicSize. >> >> ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize > was always == instanceSize, but now it is no longer like that and > you need to use longer expression e.g. (self class instanceSize) > > >> You can rebuildField accessor too (class side on every >> NBExternalStructure). >> >> Do this change and your image should work. (with the last openGL-Win) >> I can take you a picture of my computer. >> >> For more accurate answer I need the crash.dump >> >> >> On Nov 14, 2013, at 1:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> As I understand there are still some things to be integrated in >> NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of >> NBOpenGL crashes the VM (on Win 7) when doing: >> GLTTRenderingDemo new openInWorld. >> >> Could you point us to the NativeBoost fix to see if it works? >> >> Doru >> >> >> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud < >> jbaptiste.arnaud(a)gmail.com> wrote: >> >>> Should work after integration. >>> Configuration updated. >>> Need fix review for integration in nativeBoost, will do that with igor >>> this afternoon. >>> >>> >>> On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud < >>> jbaptiste.arnaud(a)gmail.com> wrote: >>> >>> ok I have openGL work on my windows 7 machine. >>> I will update the configuration. But I need to publish also a fix in >>> NativeBoost win. >>> This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] >>> NBOpenGL VM crash. >>> >>> I open a bug entry. When It will be integrated. >>> Window should work well. But if you have any trouble, give me feedback. >>> >>> >>> On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> >>> so richie >>> >>> have a look at the repository and load the latest version to see if they >>> work (not using the configuration). >>> This is what we will try here (chile). >>> >>> Stef >>> >>> On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: >>> >>> Thanks everyone! That would be great. >>> Looking forward to having NBOpenGL up and running again. >>> >>> Cheers >>> Ricky >>> >>> >>> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>>> Right now it cannot even be loaded into 3.0. >>>> But update is simple (i think JB did that already, just not published?). >>>> >>>> Grrr, all my code are published ^^. >>>> >>>> >>>> Where? When did you announce it? >>>> Sorry but how can you expect guys from the other part of the planet to >>>> know it. >>>> Communication in open-source is important because people do not know >>>> what others >>>> are doing. >>>> You know richie asked and ronie too and they are smart guys. But they >>>> cannot guess. >>>> >>>> For mac: >>>> I do the change for mac last month because I needed it, it is >>>> integrated. >>>> >>>> >>>> ah ok this is why it is working on mac. >>>> >>>> For linux: >>>> I fix, published, tested and updated the configuration for linux 2 days >>>> ago, because Alex ask me. >>>> On my roommate computer that work (ubuntu ). >>>> But I need feedback. >>>> >>>> >>>> oki we will check that tomorrow I hope. >>>> >>>> For windows: >>>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 >>>> but I do not update configuration because I cannot test it. >>>> I was planned to go test and debug on my home computer (window 7, 64), >>>> tomorrow. >>>> >>>> >>>> Ok we can say it to ronie to have a look. >>>> >>>> So, you can expect a fix integrated soon. >>>> >>>> And having a working OpenGL, exactly as it work in pharo 2.0. >>>> >>>> >>>> Excellent. >>>> >>>> >>>> >>>> >>>> >>>>> I have already looked at Roassal 3d, but it was not easy to separate >>>>> the API from the code. >>>>> >>>>> >>>>> Strange because even me I could see that the shadder code should not >>>>> be in Roassal 3D but in NBOpenGL :). >>>>> Because Roassal 3d should not be about shadder but about 3D. >>>>> >>>> >>>>> And it is something completely different than what I have been using >>>>> (and SourceCity, too), because Roassal 3d is using the modern OpenGL >>>>> methodology (with FBOs and stuff). >>>>> >>>>> >>>>> Yes they changed the API and deprecated the old way of doing it. >>>>> >>>> >>>> I will also publish some example (using shadder) that I wrote but it is >>>> still not yet user friendly. >>>> >>>> >>>> So, I would really appreciate if that API would find its way from >>>>> Roassal to NBOpenGL and I could use it for CodeCity. >>>>> >>>>> >>>>> See below >>>>> >>>> >>>>> Unfortunately I am able to help a lot with that, because I know very >>>>> little about this and I also don't have enough time (I am doing CodeCity in >>>>> my spare time). But, if you have concrete things that I can do, I'd be >>>>> happy to help. >>>>> >>>>> >>>>> Three remarks: >>>>> - I know that jean-baptiste worked on moving part of roassal3d to >>>>> NBOpenGL >>>>> >>>> >>>> Shader part are done for now. >>>> >>>> - I'm not sure that doing 3d without investing a bit in the >>>>> underlying technology is wise. Because you will be always relying >>>>> on other people and probably frustrated when things are not working. >>>>> >>>> + 1 >>>> >>>> - Since JB does not know how to communicate here is what he did for >>>>> fun instead of pushing MoosePython :) >>>>> >>>> a renderer to video to videos stream for openGL -> MKV, mp4 based >>>>> one ffmpeg). The code is openGL extra. As an example you >>>>> can get >>>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>>>> >>>> >>>>> >>>> yes, my bad. >>>> >>>> Now again if nobody builds a jun like library in Pharo it will not >>>>> exist. >>>>> >>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> Cheers >>>>> Ricky >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I guess that what Ricky is asking is what changed between NBOpenGL >>>>>> 2.0 and 3.0 such that this does not work anymore on Windows. The fact that >>>>>> he mentioned 64 bits is not relevant for this discussion :). >>>>>> >>>>>> I also guess he wants to put some effort into understanding this as >>>>>> well but he needs a bit of guidance. Right Ricky? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse < >>>>>> stephane.ducasse(a)inria.fr> wrote: >>>>>> >>>>>>> Richard >>>>>>> >>>>>>> you should have a look at ROASSAL 3d because ronie improved the >>>>>>> shadder part (no more assembler) >>>>>>> and his code should be split in two and one part should go to >>>>>>> NBOpenGL. >>>>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>>>> >>>>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy >>>>>>> finishing the texteditor (and I can tell you that >>>>>>> he does not have fun there). >>>>>>> >>>>>>> So it is important that you help because we are FULL >>>>>>> and sorry about that but really FULL. >>>>>>> >>>>>>> Ronie will visit us in January and share an office with igor. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> > Hi >>>>>>> > >>>>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>>>> > I'd like to start working on it using Pharo 3, but it seems that >>>>>>> NBOpenGL does not work yet with Pharo 3.0. >>>>>>> > >>>>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried >>>>>>> to execute the following code on Windows 7, 64 bits: >>>>>>> > >>>>>>> > GLTTRenderingDemo new openInWorld. >>>>>>> > >>>>>>> > but I get a 'No suitable implementation found for initializing >>>>>>> OpenGL context for your platform'. >>>>>>> > It seems that NBGLContextDriver does not have a subclass for >>>>>>> Windows 64bits. Did I omit something? >>>>>>> > >>>>>>> > Cheers >>>>>>> > Ricky >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>>> Best Regards >>>> Jean Baptiste Arnaud >>>> jbaptiste.arnaud(a)gmail.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> >> > > > -- > Best regards, > Igor Stasenko. > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Jean Baptiste Arnaud

On Nov 14, 2013, at 5:39 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Still having problems with NBOpenGL under Linux. > > First I'm getting a message not understood for NativeBoostConstants mac32PlaformId under NBMacGLContextDriver>>supportsCurrentPlatform. Its fixed by adding the missing 't' to mac32PlaformId, becoming mac32PlatformId. I think your image is outdated ... That is a really old bug. " Name: NBOpenGL-Mac-IgorStasenko.3 Author: IgorStasenko Time: 14 March 2013, 4:16:19.35 pm UUID: d0575b2c-ffc1-4cce-ac2a-3215ae53c599 Ancestors: NBOpenGL-Mac-IgorStasenko.2 - fix typo with mac32PlaformId => mac32PlatformId " But check your openGL version maybe not the right one. How do you load openGL ? ConfigurationOfOpenGL project load: '3.0' ? ==> you should use this one. > Then, after changing that I'm receiving a "function unavailable" error. Looking at the code I notice that it looks for libGL.so under /usr/lib/libGL.so. In modern versions of 64 bits Ubuntu, and Linux Mint which is derived from Ubuntu, libGL.so is not placed under /usr/lib, instead is placed in a driver dependent folder, which is referenced by a config file in /etc/ld.so.conf.d/ . With a mesa driver, the OpenGL library is at /usr/lib/i386-linux-gnu/mesa/libGL.so.1 , so the driver shared object path cannot be hardcoded. The path problem is a know issue, yes. If you have a good solution. But yes basically you have to update manually the pass in the moduleName variable. > Changing the module name for 'libGL.so.1', doesn't work, but changing it for '/usr/lib/i386-linux-gnu/mesa/libGL.so.1' gives me an 'unable to resolve external type: GLXDrawable', adding NBGLXTypes into the pool dictionaries of NBGlxAPI solves it. I fix that too. > After changing that, it tries to create a multisampled framebuffer, however it doesn't check the maximum number of samples supported. My machine reports GL_EXT_framebuffer_multisample as supported, but the FBO created is not complete. I modified the creation code to use only 1 sample for multisampling and its works. > Using those hacks makes it work under a 64 bits Linux. Still, whenever I run an example, I'm getting a top level window that doesn't does nothing, which is annoying. Closing the windows doesn't break the running OpenGL application. > > Greetings, > Ronie Salgado > > > 2013/11/14 Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> > Good news everyone: > bug fixed and integrated in 3,0 573 > I am open for new feedback. > > > On Nov 14, 2013, at 2:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 14 November 2013 14:25, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >> Yes the fix is not integrated yet. >> NBWndClassEx should not be a variable subclass anymore. This part should be checked with Igor. >> >> NBWndClassEx>>#initialize >> self cbSize: (self class instanceSize). >> and not self basicSize. >> >> ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize >> was always == instanceSize, but now it is no longer like that and >> you need to use longer expression e.g. (self class instanceSize) >> >> You can rebuildField accessor too (class side on every NBExternalStructure). >> >> Do this change and your image should work. (with the last openGL-Win) >> I can take you a picture of my computer. >> >> For more accurate answer I need the crash.dump >> >> >> On Nov 14, 2013, at 1:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> As I understand there are still some things to be integrated in NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of NBOpenGL crashes the VM (on Win 7) when doing: >>> GLTTRenderingDemo new openInWorld. >>> >>> Could you point us to the NativeBoost fix to see if it works? >>> >>> Doru >>> >>> >>> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >>> Should work after integration. >>> Configuration updated. >>> Need fix review for integration in nativeBoost, will do that with igor this afternoon. >>> >>> >>> On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >>> >>>> ok I have openGL work on my windows 7 machine. >>>> I will update the configuration. But I need to publish also a fix in NativeBoost win. >>>> This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] NBOpenGL VM crash. >>>> >>>> I open a bug entry. When It will be integrated. >>>> Window should work well. But if you have any trouble, give me feedback. >>>> >>>> >>>> On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> so richie >>>>> >>>>> have a look at the repository and load the latest version to see if they work (not using the configuration). >>>>> This is what we will try here (chile). >>>>> >>>>> Stef >>>>> >>>>> On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: >>>>> >>>>>> Thanks everyone! That would be great. >>>>>> Looking forward to having NBOpenGL up and running again. >>>>>> >>>>>> Cheers >>>>>> Ricky >>>>>> >>>>>> >>>>>> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>>> >>>>>>>> Right now it cannot even be loaded into 3.0. >>>>>>>> But update is simple (i think JB did that already, just not published?). >>>>>>> Grrr, all my code are published ^^. >>>>>> >>>>>> Where? When did you announce it? >>>>>> Sorry but how can you expect guys from the other part of the planet to know it. >>>>>> Communication in open-source is important because people do not know what others >>>>>> are doing. >>>>>> You know richie asked and ronie too and they are smart guys. But they cannot guess. >>>>>> >>>>>>> For mac: >>>>>>> I do the change for mac last month because I needed it, it is integrated. >>>>>> >>>>>> ah ok this is why it is working on mac. >>>>>> >>>>>>> For linux: >>>>>>> I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. >>>>>>> On my roommate computer that work (ubuntu ). >>>>>>> But I need feedback. >>>>>> >>>>>> oki we will check that tomorrow I hope. >>>>>> >>>>>>> For windows: >>>>>>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. >>>>>>> I was planned to go test and debug on my home computer (window 7, 64), tomorrow. >>>>>> >>>>>> Ok we can say it to ronie to have a look. >>>>>> >>>>>>> So, you can expect a fix integrated soon. >>>>>>> >>>>>>> And having a working OpenGL, exactly as it work in pharo 2.0. >>>>>> >>>>>> Excellent. >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. >>>>>>>> >>>>>>>> Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). >>>>>>>> Because Roassal 3d should not be about shadder but about 3D. >>>>>>>> >>>>>>>>> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). >>>>>>>> >>>>>>>> Yes they changed the API and deprecated the old way of doing it. >>>>>>> >>>>>>> I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. >>>>>>> >>>>>>> >>>>>>>>> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. >>>>>>>> >>>>>>>> See below >>>>>>>> >>>>>>>>> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. >>>>>>>> >>>>>>> >>>>>>>> Three remarks: >>>>>>>> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL >>>>>>> >>>>>>> Shader part are done for now. >>>>>>> >>>>>>>> - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying >>>>>>>> on other people and probably frustrated when things are not working. >>>>>>> + 1 >>>>>>> >>>>>>>> - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) >>>>>>>> a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you >>>>>>>> can get >>>>>>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>>>>>> >>>>>>>> >>>>>>> >>>>>>> yes, my bad. >>>>>>> >>>>>>>> Now again if nobody builds a jun like library in Pharo it will not exist. >>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Ricky >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >>>>>>>>> >>>>>>>>> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>>>> Richard >>>>>>>>> >>>>>>>>> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >>>>>>>>> and his code should be split in two and one part should go to NBOpenGL. >>>>>>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>>>>>> >>>>>>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >>>>>>>>> he does not have fun there). >>>>>>>>> >>>>>>>>> So it is important that you help because we are FULL >>>>>>>>> and sorry about that but really FULL. >>>>>>>>> >>>>>>>>> Ronie will visit us in January and share an office with igor. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> > Hi >>>>>>>>> > >>>>>>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>>>>>> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >>>>>>>>> > >>>>>>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >>>>>>>>> > >>>>>>>>> > GLTTRenderingDemo new openInWorld. >>>>>>>>> > >>>>>>>>> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >>>>>>>>> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >>>>>>>>> > >>>>>>>>> > Cheers >>>>>>>>> > Ricky >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com >>>>>>>>> >>>>>>>>> "Every thing has its own flow" >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko. >>>>>>> >>>>>>> Best Regards >>>>>>> Jean Baptiste Arnaud >>>>>>> jbaptiste.arnaud(a)gmail.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> Best Regards >>>> Jean Baptiste Arnaud >>>> jbaptiste.arnaud(a)gmail.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Nov. 14, 2013

NBOpenGL on Pharo 3.0

by Torsten Bergmann

Jean Baptiste Arnaud wrote >Good news everyone: > bug fixed and integrad I also merged the #12161 issue that is now also in Pharo 3.0#30573 into the official "NativeBoost-Win32" package on STHub so it will not appear again when next NB version comes out or is loaded into the image. Thx T.

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Jean Baptiste Arnaud

Good news everyone: bug fixed and integrated in 3,0 573 I am open for new feedback. On Nov 14, 2013, at 2:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 14 November 2013 14:25, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > Yes the fix is not integrated yet. > NBWndClassEx should not be a variable subclass anymore. This part should be checked with Igor. > > NBWndClassEx>>#initialize > self cbSize: (self class instanceSize). > and not self basicSize. > > ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize > was always == instanceSize, but now it is no longer like that and > you need to use longer expression e.g. (self class instanceSize) > > You can rebuildField accessor too (class side on every NBExternalStructure). > > Do this change and your image should work. (with the last openGL-Win) > I can take you a picture of my computer. > > For more accurate answer I need the crash.dump > > > On Nov 14, 2013, at 1:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> As I understand there are still some things to be integrated in NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of NBOpenGL crashes the VM (on Win 7) when doing: >> GLTTRenderingDemo new openInWorld. >> >> Could you point us to the NativeBoost fix to see if it works? >> >> Doru >> >> >> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >> Should work after integration. >> Configuration updated. >> Need fix review for integration in nativeBoost, will do that with igor this afternoon. >> >> >> On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >> >>> ok I have openGL work on my windows 7 machine. >>> I will update the configuration. But I need to publish also a fix in NativeBoost win. >>> This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] NBOpenGL VM crash. >>> >>> I open a bug entry. When It will be integrated. >>> Window should work well. But if you have any trouble, give me feedback. >>> >>> >>> On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> so richie >>>> >>>> have a look at the repository and load the latest version to see if they work (not using the configuration). >>>> This is what we will try here (chile). >>>> >>>> Stef >>>> >>>> On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: >>>> >>>>> Thanks everyone! That would be great. >>>>> Looking forward to having NBOpenGL up and running again. >>>>> >>>>> Cheers >>>>> Ricky >>>>> >>>>> >>>>> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>> >>>>>>> Right now it cannot even be loaded into 3.0. >>>>>>> But update is simple (i think JB did that already, just not published?). >>>>>> Grrr, all my code are published ^^. >>>>> >>>>> Where? When did you announce it? >>>>> Sorry but how can you expect guys from the other part of the planet to know it. >>>>> Communication in open-source is important because people do not know what others >>>>> are doing. >>>>> You know richie asked and ronie too and they are smart guys. But they cannot guess. >>>>> >>>>>> For mac: >>>>>> I do the change for mac last month because I needed it, it is integrated. >>>>> >>>>> ah ok this is why it is working on mac. >>>>> >>>>>> For linux: >>>>>> I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. >>>>>> On my roommate computer that work (ubuntu ). >>>>>> But I need feedback. >>>>> >>>>> oki we will check that tomorrow I hope. >>>>> >>>>>> For windows: >>>>>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. >>>>>> I was planned to go test and debug on my home computer (window 7, 64), tomorrow. >>>>> >>>>> Ok we can say it to ronie to have a look. >>>>> >>>>>> So, you can expect a fix integrated soon. >>>>>> >>>>>> And having a working OpenGL, exactly as it work in pharo 2.0. >>>>> >>>>> Excellent. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. >>>>>>> >>>>>>> Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). >>>>>>> Because Roassal 3d should not be about shadder but about 3D. >>>>>>> >>>>>>>> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). >>>>>>> >>>>>>> Yes they changed the API and deprecated the old way of doing it. >>>>>> >>>>>> I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. >>>>>> >>>>>> >>>>>>>> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. >>>>>>> >>>>>>> See below >>>>>>> >>>>>>>> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. >>>>>>> >>>>>> >>>>>>> Three remarks: >>>>>>> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL >>>>>> >>>>>> Shader part are done for now. >>>>>> >>>>>>> - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying >>>>>>> on other people and probably frustrated when things are not working. >>>>>> + 1 >>>>>> >>>>>>> - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) >>>>>>> a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you >>>>>>> can get >>>>>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>>>>> >>>>>>> >>>>>> >>>>>> yes, my bad. >>>>>> >>>>>>> Now again if nobody builds a jun like library in Pharo it will not exist. >>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Cheers >>>>>>>> Ricky >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >>>>>>>> >>>>>>>> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>>> Richard >>>>>>>> >>>>>>>> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >>>>>>>> and his code should be split in two and one part should go to NBOpenGL. >>>>>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>>>>> >>>>>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >>>>>>>> he does not have fun there). >>>>>>>> >>>>>>>> So it is important that you help because we are FULL >>>>>>>> and sorry about that but really FULL. >>>>>>>> >>>>>>>> Ronie will visit us in January and share an office with igor. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> > Hi >>>>>>>> > >>>>>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>>>>> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >>>>>>>> > >>>>>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >>>>>>>> > >>>>>>>> > GLTTRenderingDemo new openInWorld. >>>>>>>> > >>>>>>>> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >>>>>>>> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >>>>>>>> > >>>>>>>> > Cheers >>>>>>>> > Ricky >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> >>>>>>>> "Every thing has its own flow" >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko. >>>>>> >>>>>> Best Regards >>>>>> Jean Baptiste Arnaud >>>>>> jbaptiste.arnaud(a)gmail.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > > > > -- > Best regards, > Igor Stasenko. Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Nov. 14, 2013

Re: [Pharo-users] i18n - Where to start?

by Stephan Eggermont

With the QCMagritte image (from the pharo contributions ci). That has build-in support for translations. Just start it and open the web demo Stephan

Nov. 14, 2013

Re: [Pharo-users] i18n - Where to start?

by ClÃ©ment Bera

Hello, So there is 2 frameworks to do multi language UI in Pharo (but I don't know if one of them is i18n). One framework is in the image, does not work very well and no one use it seemingly. So I don't recommend it. The other one is the one everyone use, so I recommend it, I'm not sure but I think it is named getText and you can find here: http://smalltalkhub.com/#!/~PharoExtras/Gettext Seemingly it has been ported to Pharo 2.0 recently. Therefore it should work *nearly* out of the box. Regards, 2013/11/14 Bahman Movaqar <Bahman(a)bahmanm.com> > Hi all, > > Would anyone share a pionter to how to do i18n in Pharo for translating > the messages used in a Pharo application (web or desktop)? > > TIA, > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 14, 2013

Re: [Pharo-users] Current 3.0 download is broken

by Johan Fabry

I guess this one fell through the cracks, so https://pharo.fogbugz.com/f/cases/12164/One-Click-on-Mac-is-broken-due-to-n… On Nov 10, 2013, at 12:48 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > On principle, a big +1 on going forward on the PhD! :-) > > But, the one-click download Pharo3.0-mac.zip being broken is an important issue that should be addressed fairly quickly in my opinion. As I said, the sources file should be moved out of Contents/Resources and moved into Contents/MacOS. Then the one-click also runs. > > On Nov 10, 2013, at 10:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Nov 10, 2013, at 2:05 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> It did not solve the issue yet :/, I will have to look into it next week. >> >> Don't ;) >> You should not touch Pharo related things and start use pomodoroes to blast your phd >> >> Stef >>> In any case, I think it would be unrelated to a bootstrap since FileLocator >>> is already lazily initialized. There is just the typical problem on how and >>> when to update a singletonâ¦ >> Ok so this is good then. >> >>> >>> I should reopen the issue since the problem persists. > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Nov. 14, 2013

i18n - Where to start?

by Bahman Movaqar

Hi all, Would anyone share a pionter to how to do i18n in Pharo for translating the messages used in a Pharo application (web or desktop)? TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by Igor Stasenko

On 14 November 2013 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: > Reading this code, made me wonder what operations are actually atomic. > Anyone having a good explanation? > > Stephan > > AtomicQueueItem>makeCircular > "Make a receiver circular, i.e. point to itself, > answer the old value of next variable. > Note, this operation should be atomic" > > | temp | > > " atomic swap here" > temp := next. > next := self. > > ^ temp > > imagine that i rewrite it with following: temp := self. temp <=> next. ^ temp here the <=> is a special 'atomic swap' operation which atomically swaps values of two variables. The best way to do that is to introduce a special bytecode in VM, which either swaps values of two temps or swaps values of temp and instance variable. If we could have such bytecode, then we would have a strong guarantee from VM about atomicity of certain operations, but since we don't have it yet, right now it is just (ab)uses the intrinsic behavior of VM, knowing that it never interrupts between two simple assignments. -- Best regards, Igor Stasenko.

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Igor Stasenko

On 14 November 2013 14:25, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com>wrote: > Yes the fix is not integrated yet. > NBWndClassEx should not be a variable subclass anymore. This part should > be checked with Igor. > > NBWndClassEx>>#initialize > self cbSize: (self class instanceSize). > and not self basicSize. > > ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize was always == instanceSize, but now it is no longer like that and you need to use longer expression e.g. (self class instanceSize) > You can rebuildField accessor too (class side on every > NBExternalStructure). > > Do this change and your image should work. (with the last openGL-Win) > I can take you a picture of my computer. > > For more accurate answer I need the crash.dump > > > On Nov 14, 2013, at 1:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > As I understand there are still some things to be integrated in > NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of > NBOpenGL crashes the VM (on Win 7) when doing: > GLTTRenderingDemo new openInWorld. > > Could you point us to the NativeBoost fix to see if it works? > > Doru > > > On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud < > jbaptiste.arnaud(a)gmail.com> wrote: > >> Should work after integration. >> Configuration updated. >> Need fix review for integration in nativeBoost, will do that with igor >> this afternoon. >> >> >> On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud < >> jbaptiste.arnaud(a)gmail.com> wrote: >> >> ok I have openGL work on my windows 7 machine. >> I will update the configuration. But I need to publish also a fix in >> NativeBoost win. >> This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] >> NBOpenGL VM crash. >> >> I open a bug entry. When It will be integrated. >> Window should work well. But if you have any trouble, give me feedback. >> >> >> On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> so richie >> >> have a look at the repository and load the latest version to see if they >> work (not using the configuration). >> This is what we will try here (chile). >> >> Stef >> >> On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: >> >> Thanks everyone! That would be great. >> Looking forward to having NBOpenGL up and running again. >> >> Cheers >> Ricky >> >> >> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> >>>> Right now it cannot even be loaded into 3.0. >>> But update is simple (i think JB did that already, just not published?). >>> >>> Grrr, all my code are published ^^. >>> >>> >>> Where? When did you announce it? >>> Sorry but how can you expect guys from the other part of the planet to >>> know it. >>> Communication in open-source is important because people do not know >>> what others >>> are doing. >>> You know richie asked and ronie too and they are smart guys. But they >>> cannot guess. >>> >>> For mac: >>> I do the change for mac last month because I needed it, it is >>> integrated. >>> >>> >>> ah ok this is why it is working on mac. >>> >>> For linux: >>> I fix, published, tested and updated the configuration for linux 2 days >>> ago, because Alex ask me. >>> On my roommate computer that work (ubuntu ). >>> But I need feedback. >>> >>> >>> oki we will check that tomorrow I hope. >>> >>> For windows: >>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 >>> but I do not update configuration because I cannot test it. >>> I was planned to go test and debug on my home computer (window 7, 64), >>> tomorrow. >>> >>> >>> Ok we can say it to ronie to have a look. >>> >>> So, you can expect a fix integrated soon. >>> >>> And having a working OpenGL, exactly as it work in pharo 2.0. >>> >>> >>> Excellent. >>> >>> >>> >>> >>> >>>> I have already looked at Roassal 3d, but it was not easy to separate >>>> the API from the code. >>>> >>>> >>>> Strange because even me I could see that the shadder code should not be >>>> in Roassal 3D but in NBOpenGL :). >>>> Because Roassal 3d should not be about shadder but about 3D. >>>> >>> >>>> And it is something completely different than what I have been using >>>> (and SourceCity, too), because Roassal 3d is using the modern OpenGL >>>> methodology (with FBOs and stuff). >>>> >>>> >>>> Yes they changed the API and deprecated the old way of doing it. >>>> >>> >>> I will also publish some example (using shadder) that I wrote but it is >>> still not yet user friendly. >>> >>> >>> So, I would really appreciate if that API would find its way from >>>> Roassal to NBOpenGL and I could use it for CodeCity. >>>> >>>> >>>> See below >>>> >>> >>>> Unfortunately I am able to help a lot with that, because I know very >>>> little about this and I also don't have enough time (I am doing CodeCity in >>>> my spare time). But, if you have concrete things that I can do, I'd be >>>> happy to help. >>>> >>>> >>>> Three remarks: >>>> - I know that jean-baptiste worked on moving part of roassal3d to >>>> NBOpenGL >>>> >>> >>> Shader part are done for now. >>> >>> - I'm not sure that doing 3d without investing a bit in the underlying >>>> technology is wise. Because you will be always relying >>>> on other people and probably frustrated when things are not working. >>>> >>> + 1 >>> >>> - Since JB does not know how to communicate here is what he did for >>>> fun instead of pushing MoosePython :) >>>> >>> a renderer to video to videos stream for openGL -> MKV, mp4 based >>>> one ffmpeg). The code is openGL extra. As an example you >>>> can get >>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>>> >>> >>>> >>> yes, my bad. >>> >>> Now again if nobody builds a jun like library in Pharo it will not >>>> exist. >>>> >>> >>>> Stef >>>> >>>> >>>> >>>> Cheers >>>> Ricky >>>> >>>> >>>> >>>> >>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >>>> >>>>> Hi, >>>>> >>>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 >>>>> and 3.0 such that this does not work anymore on Windows. The fact that he >>>>> mentioned 64 bits is not relevant for this discussion :). >>>>> >>>>> I also guess he wants to put some effort into understanding this as >>>>> well but he needs a bit of guidance. Right Ricky? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse < >>>>> stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> Richard >>>>>> >>>>>> you should have a look at ROASSAL 3d because ronie improved the >>>>>> shadder part (no more assembler) >>>>>> and his code should be split in two and one part should go to >>>>>> NBOpenGL. >>>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>>> >>>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy >>>>>> finishing the texteditor (and I can tell you that >>>>>> he does not have fun there). >>>>>> >>>>>> So it is important that you help because we are FULL >>>>>> and sorry about that but really FULL. >>>>>> >>>>>> Ronie will visit us in January and share an office with igor. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> > Hi >>>>>> > >>>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>>> > I'd like to start working on it using Pharo 3, but it seems that >>>>>> NBOpenGL does not work yet with Pharo 3.0. >>>>>> > >>>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried >>>>>> to execute the following code on Windows 7, 64 bits: >>>>>> > >>>>>> > GLTTRenderingDemo new openInWorld. >>>>>> > >>>>>> > but I get a 'No suitable implementation found for initializing >>>>>> OpenGL context for your platform'. >>>>>> > It seems that NBGLContextDriver does not have a subclass for >>>>>> Windows 64bits. Did I omit something? >>>>>> > >>>>>> > Cheers >>>>>> > Ricky >>>>>> > >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > -- Best regards, Igor Stasenko.

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by Johan Fabry

On Nov 14, 2013, at 7:29 AM, jtuchel(a)objektfabrik.de wrote: >> Unless my understanding of the proposal is way off, you would just add "poolDictionaries: 'whatever'" before "category:". No horrible breaking of anything would happen. >> >> Cheers, >> Sergi > I disagree ;-) > I find it hard to remember the ordering of these parameters. I sometimes have this problem with classInstVars in VAST. > > But you are right in that using a simpler template as the default won't remove the whole feature. And if you don't remember the ordering, just browse the implementer of the message in the template, you will find other variants right next to it :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Jean Baptiste Arnaud

Yes the fix is not integrated yet. NBWndClassEx should not be a variable subclass anymore. This part should be checked with Igor. NBWndClassEx>>#initialize self cbSize: (self class instanceSize). and not self basicSize. You can rebuildField accessor too (class side on every NBExternalStructure). Do this change and your image should work. (with the last openGL-Win) I can take you a picture of my computer. For more accurate answer I need the crash.dump On Nov 14, 2013, at 1:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > As I understand there are still some things to be integrated in NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of NBOpenGL crashes the VM (on Win 7) when doing: > GLTTRenderingDemo new openInWorld. > > Could you point us to the NativeBoost fix to see if it works? > > Doru > > > On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > Should work after integration. > Configuration updated. > Need fix review for integration in nativeBoost, will do that with igor this afternoon. > > > On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > >> ok I have openGL work on my windows 7 machine. >> I will update the configuration. But I need to publish also a fix in NativeBoost win. >> This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] NBOpenGL VM crash. >> >> I open a bug entry. When It will be integrated. >> Window should work well. But if you have any trouble, give me feedback. >> >> >> On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> so richie >>> >>> have a look at the repository and load the latest version to see if they work (not using the configuration). >>> This is what we will try here (chile). >>> >>> Stef >>> >>> On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: >>> >>>> Thanks everyone! That would be great. >>>> Looking forward to having NBOpenGL up and running again. >>>> >>>> Cheers >>>> Ricky >>>> >>>> >>>> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> >>>>>> Right now it cannot even be loaded into 3.0. >>>>>> But update is simple (i think JB did that already, just not published?). >>>>> Grrr, all my code are published ^^. >>>> >>>> Where? When did you announce it? >>>> Sorry but how can you expect guys from the other part of the planet to know it. >>>> Communication in open-source is important because people do not know what others >>>> are doing. >>>> You know richie asked and ronie too and they are smart guys. But they cannot guess. >>>> >>>>> For mac: >>>>> I do the change for mac last month because I needed it, it is integrated. >>>> >>>> ah ok this is why it is working on mac. >>>> >>>>> For linux: >>>>> I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. >>>>> On my roommate computer that work (ubuntu ). >>>>> But I need feedback. >>>> >>>> oki we will check that tomorrow I hope. >>>> >>>>> For windows: >>>>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. >>>>> I was planned to go test and debug on my home computer (window 7, 64), tomorrow. >>>> >>>> Ok we can say it to ronie to have a look. >>>> >>>>> So, you can expect a fix integrated soon. >>>>> >>>>> And having a working OpenGL, exactly as it work in pharo 2.0. >>>> >>>> Excellent. >>>> >>>>> >>>>> >>>>>> >>>>>>> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. >>>>>> >>>>>> Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). >>>>>> Because Roassal 3d should not be about shadder but about 3D. >>>>>> >>>>>>> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). >>>>>> >>>>>> Yes they changed the API and deprecated the old way of doing it. >>>>> >>>>> I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. >>>>> >>>>> >>>>>>> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. >>>>>> >>>>>> See below >>>>>> >>>>>>> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. >>>>>> >>>>> >>>>>> Three remarks: >>>>>> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL >>>>> >>>>> Shader part are done for now. >>>>> >>>>>> - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying >>>>>> on other people and probably frustrated when things are not working. >>>>> + 1 >>>>> >>>>>> - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) >>>>>> a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you >>>>>> can get >>>>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>>>> >>>>>> >>>>> >>>>> yes, my bad. >>>>> >>>>>> Now again if nobody builds a jun like library in Pharo it will not exist. >>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>>> Cheers >>>>>>> Ricky >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >>>>>>> >>>>>>> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>> Richard >>>>>>> >>>>>>> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >>>>>>> and his code should be split in two and one part should go to NBOpenGL. >>>>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>>>> >>>>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >>>>>>> he does not have fun there). >>>>>>> >>>>>>> So it is important that you help because we are FULL >>>>>>> and sorry about that but really FULL. >>>>>>> >>>>>>> Ronie will visit us in January and share an office with igor. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> > Hi >>>>>>> > >>>>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>>>> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >>>>>>> > >>>>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >>>>>>> > >>>>>>> > GLTTRenderingDemo new openInWorld. >>>>>>> > >>>>>>> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >>>>>>> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >>>>>>> > >>>>>>> > Cheers >>>>>>> > Ricky >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Every thing has its own flow" >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>> >>>>> Best Regards >>>>> Jean Baptiste Arnaud >>>>> jbaptiste.arnaud(a)gmail.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by Johan Fabry

Note that I'm not advocating removing PoolDictionaries. Just to have the subclassing template not mention them. I would leave the subclassing message with the poolDictionaries: argument in the system for people to use it if they want to. On Nov 14, 2013, at 7:02 AM, jtuchel(a)objektfabrik.de wrote: > Hi, > > I'd like to draw your attention to something else: consistency. > > I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. > And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. > > And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? > A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it. > > Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors? > > Just my 2 cents > > Joachim ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Nov. 14, 2013

Settings > Network > Blab email

by btc＠openinworld.com

In Settings I just noticed Network > Blab email. The description is not very description-able. What is it? cheers -ben

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Tudor Girba

Hi, As I understand there are still some things to be integrated in NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of NBOpenGL crashes the VM (on Win 7) when doing: GLTTRenderingDemo new openInWorld. Could you point us to the NativeBoost fix to see if it works? Doru On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud < jbaptiste.arnaud(a)gmail.com> wrote: > Should work after integration. > Configuration updated. > Need fix review for integration in nativeBoost, will do that with igor > this afternoon. > > > On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud < > jbaptiste.arnaud(a)gmail.com> wrote: > > ok I have openGL work on my windows 7 machine. > I will update the configuration. But I need to publish also a fix in > NativeBoost win. > This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] > NBOpenGL VM crash. > > I open a bug entry. When It will be integrated. > Window should work well. But if you have any trouble, give me feedback. > > > On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > so richie > > have a look at the repository and load the latest version to see if they > work (not using the configuration). > This is what we will try here (chile). > > Stef > > On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: > > Thanks everyone! That would be great. > Looking forward to having NBOpenGL up and running again. > > Cheers > Ricky > > > On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >>> Right now it cannot even be loaded into 3.0. >> But update is simple (i think JB did that already, just not published?). >> >> Grrr, all my code are published ^^. >> >> >> Where? When did you announce it? >> Sorry but how can you expect guys from the other part of the planet to >> know it. >> Communication in open-source is important because people do not know what >> others >> are doing. >> You know richie asked and ronie too and they are smart guys. But they >> cannot guess. >> >> For mac: >> I do the change for mac last month because I needed it, it is integrated. >> >> >> ah ok this is why it is working on mac. >> >> For linux: >> I fix, published, tested and updated the configuration for linux 2 days >> ago, because Alex ask me. >> On my roommate computer that work (ubuntu ). >> But I need feedback. >> >> >> oki we will check that tomorrow I hope. >> >> For windows: >> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 >> but I do not update configuration because I cannot test it. >> I was planned to go test and debug on my home computer (window 7, 64), >> tomorrow. >> >> >> Ok we can say it to ronie to have a look. >> >> So, you can expect a fix integrated soon. >> >> And having a working OpenGL, exactly as it work in pharo 2.0. >> >> >> Excellent. >> >> >> >> >> >>> I have already looked at Roassal 3d, but it was not easy to separate >>> the API from the code. >>> >>> >>> Strange because even me I could see that the shadder code should not be >>> in Roassal 3D but in NBOpenGL :). >>> Because Roassal 3d should not be about shadder but about 3D. >>> >> >>> And it is something completely different than what I have been using >>> (and SourceCity, too), because Roassal 3d is using the modern OpenGL >>> methodology (with FBOs and stuff). >>> >>> >>> Yes they changed the API and deprecated the old way of doing it. >>> >> >> I will also publish some example (using shadder) that I wrote but it is >> still not yet user friendly. >> >> >> So, I would really appreciate if that API would find its way from Roassal >>> to NBOpenGL and I could use it for CodeCity. >>> >>> >>> See below >>> >> >>> Unfortunately I am able to help a lot with that, because I know very >>> little about this and I also don't have enough time (I am doing CodeCity in >>> my spare time). But, if you have concrete things that I can do, I'd be >>> happy to help. >>> >>> >>> Three remarks: >>> - I know that jean-baptiste worked on moving part of roassal3d to >>> NBOpenGL >>> >> >> Shader part are done for now. >> >> - I'm not sure that doing 3d without investing a bit in the underlying >>> technology is wise. Because you will be always relying >>> on other people and probably frustrated when things are not working. >>> >> + 1 >> >> - Since JB does not know how to communicate here is what he did for fun >>> instead of pushing MoosePython :) >>> >> a renderer to video to videos stream for openGL -> MKV, mp4 based >>> one ffmpeg). The code is openGL extra. As an example you >>> can get >>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>> >> >>> >> yes, my bad. >> >> Now again if nobody builds a jun like library in Pharo it will not >>> exist. >>> >> >>> Stef >>> >>> >>> >>> Cheers >>> Ricky >>> >>> >>> >>> >>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >>> >>>> Hi, >>>> >>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 >>>> and 3.0 such that this does not work anymore on Windows. The fact that he >>>> mentioned 64 bits is not relevant for this discussion :). >>>> >>>> I also guess he wants to put some effort into understanding this as >>>> well but he needs a bit of guidance. Right Ricky? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse < >>>> stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> Richard >>>>> >>>>> you should have a look at ROASSAL 3d because ronie improved the >>>>> shadder part (no more assembler) >>>>> and his code should be split in two and one part should go to NBOpenGL. >>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>> >>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy >>>>> finishing the texteditor (and I can tell you that >>>>> he does not have fun there). >>>>> >>>>> So it is important that you help because we are FULL >>>>> and sorry about that but really FULL. >>>>> >>>>> Ronie will visit us in January and share an office with igor. >>>>> >>>>> Stef >>>>> >>>>> >>>>> > Hi >>>>> > >>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>> > I'd like to start working on it using Pharo 3, but it seems that >>>>> NBOpenGL does not work yet with Pharo 3.0. >>>>> > >>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to >>>>> execute the following code on Windows 7, 64 bits: >>>>> > >>>>> > GLTTRenderingDemo new openInWorld. >>>>> > >>>>> > but I get a 'No suitable implementation found for initializing >>>>> OpenGL context for your platform'. >>>>> > It seems that NBGLContextDriver does not have a subclass for Windows >>>>> 64bits. Did I omit something? >>>>> > >>>>> > Cheers >>>>> > Ricky >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> >> >> > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Jean Baptiste Arnaud

Should work after integration. Configuration updated. Need fix review for integration in nativeBoost, will do that with igor this afternoon. On Nov 14, 2013, at 12:58 PM, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > ok I have openGL work on my windows 7 machine. > I will update the configuration. But I need to publish also a fix in NativeBoost win. > This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] NBOpenGL VM crash. > > I open a bug entry. When It will be integrated. > Window should work well. But if you have any trouble, give me feedback. > > > On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> so richie >> >> have a look at the repository and load the latest version to see if they work (not using the configuration). >> This is what we will try here (chile). >> >> Stef >> >> On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: >> >>> Thanks everyone! That would be great. >>> Looking forward to having NBOpenGL up and running again. >>> >>> Cheers >>> Ricky >>> >>> >>> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> Right now it cannot even be loaded into 3.0. >>>>> But update is simple (i think JB did that already, just not published?). >>>> Grrr, all my code are published ^^. >>> >>> Where? When did you announce it? >>> Sorry but how can you expect guys from the other part of the planet to know it. >>> Communication in open-source is important because people do not know what others >>> are doing. >>> You know richie asked and ronie too and they are smart guys. But they cannot guess. >>> >>>> For mac: >>>> I do the change for mac last month because I needed it, it is integrated. >>> >>> ah ok this is why it is working on mac. >>> >>>> For linux: >>>> I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. >>>> On my roommate computer that work (ubuntu ). >>>> But I need feedback. >>> >>> oki we will check that tomorrow I hope. >>> >>>> For windows: >>>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. >>>> I was planned to go test and debug on my home computer (window 7, 64), tomorrow. >>> >>> Ok we can say it to ronie to have a look. >>> >>>> So, you can expect a fix integrated soon. >>>> >>>> And having a working OpenGL, exactly as it work in pharo 2.0. >>> >>> Excellent. >>> >>>> >>>> >>>>> >>>>>> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. >>>>> >>>>> Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). >>>>> Because Roassal 3d should not be about shadder but about 3D. >>>>> >>>>>> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). >>>>> >>>>> Yes they changed the API and deprecated the old way of doing it. >>>> >>>> I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. >>>> >>>> >>>>>> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. >>>>> >>>>> See below >>>>> >>>>>> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. >>>>> >>>> >>>>> Three remarks: >>>>> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL >>>> >>>> Shader part are done for now. >>>> >>>>> - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying >>>>> on other people and probably frustrated when things are not working. >>>> + 1 >>>> >>>>> - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) >>>>> a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you >>>>> can get >>>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>>> >>>>> >>>> >>>> yes, my bad. >>>> >>>>> Now again if nobody builds a jun like library in Pharo it will not exist. >>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>>> Cheers >>>>>> Ricky >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >>>>>> >>>>>> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> Richard >>>>>> >>>>>> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >>>>>> and his code should be split in two and one part should go to NBOpenGL. >>>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>>> >>>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >>>>>> he does not have fun there). >>>>>> >>>>>> So it is important that you help because we are FULL >>>>>> and sorry about that but really FULL. >>>>>> >>>>>> Ronie will visit us in January and share an office with igor. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> > Hi >>>>>> > >>>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>>> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >>>>>> > >>>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >>>>>> > >>>>>> > GLTTRenderingDemo new openInWorld. >>>>>> > >>>>>> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >>>>>> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >>>>>> > >>>>>> > Cheers >>>>>> > Ricky >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>> >>>> Best Regards >>>> Jean Baptiste Arnaud >>>> jbaptiste.arnaud(a)gmail.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by Camille Teruel

On 14 nov. 2013, at 12:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > You should look in VM code clement / eliot can reply more precisely > but the idea is to see when do you accept to suspend a computation. > In Smalltlak this is after each message. Except for #== and inlined message like #ifTrue:ifFalse: , #to:do: , etc... See http://forum.world.st/About-and-td3898409.html for more details > Stef > >> Stef, >> >> Am 14.11.2013 um 12:10 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> Note that it would be good to have a special syntactic construct for that because now >>> we rely on the way the compiler works to ensure such properties and it means that >>> an accessor and a direct access are not semantically equals. >>> >> I was asking for pointers/locations where to look at. I like to wrap my head around it in order to understand how it works and thus figuring out where and when there is a problem. >> >> Norbert >>> >>> Stef >>> >>> >>>>> On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>>> >>>>>> Reading this code, made me wonder what operations are actually atomic. >>>>>> Anyone having a good explanation? >>>>>> >>>>>> Stephan >>>>>> >>>>>> AtomicQueueItem>makeCircular >>>>>> "Make a receiver circular, i.e. point to itself, >>>>>> answer the old value of next variable. >>>>>> Note, this operation should be atomic" >>>>>> >>>>>> | temp | >>>>>> >>>>>> " atomic swap here" >>>>>> temp := next. >>>>>> next := self. >>>>>> >>>>>> ^ temp >>>>>> >>>>> -> no message send >>>>> -> no back jump bytecode >>>>> >>>>> therefore it can not be interrupted and process switches can not happen between the statements. >>>> >>>> Thanks, I learn something new every day. Iâve never thought about the condition when a process switch can happen. Can you say in short when a switch of processes is checked? Because I think I wonât finding it in a reasonable time looking myself. >>>> >>>> Norbert >>>> >>>> >>> >>> >> >> > >

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by phil＠highoctane.be

Clement also told me that the VM only checked for Cmd-. breaks on back jumps. Phil On Thu, Nov 14, 2013 at 11:16 AM, jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > Hi Norbert, > > I couldn't have said it any better. For me, this also was interesting, > because I first thought: "Heck, how would I make anything atomic anyways?". > And that question still stands: is there a way to make something atomic > that includes message sends? I guess #critical is not the solution, is it? > > Joachim > > Am 14.11.13 11:12, schrieb Norbert Hartl: > >> Am 14.11.2013 um 10:25 schrieb Marcus Denker <marcus.denker(a)inria.fr>: >> >> On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> Reading this code, made me wonder what operations are actually atomic. >>>> Anyone having a good explanation? >>>> >>>> Stephan >>>> >>>> AtomicQueueItem>makeCircular >>>> "Make a receiver circular, i.e. point to itself, >>>> answer the old value of next variable. >>>> Note, this operation should be atomic" >>>> >>>> | temp | >>>> >>>> " atomic swap here" >>>> temp := next. >>>> next := self. >>>> >>>> ^ temp >>>> >>>> -> no message send >>> -> no back jump bytecode >>> >>> therefore it can not be interrupted and process switches can not happen >>> between the statements. >>> >> Thanks, I learn something new every day. Iâve never thought about the >> condition when a process switch can happen. Can you say in short when a >> switch of processes is checked? Because I think I wonât finding it in a >> reasonable time looking myself. >> >> Norbert >> >> >> >> > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > >

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Jean Baptiste Arnaud

ok I have openGL work on my windows 7 machine. I will update the configuration. But I need to publish also a fix in NativeBoost win. This bug is the same related to the VM crash in Pharo dev : [Pharo-dev] NBOpenGL VM crash. I open a bug entry. When It will be integrated. Window should work well. But if you have any trouble, give me feedback. On Nov 14, 2013, at 12:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > so richie > > have a look at the repository and load the latest version to see if they work (not using the configuration). > This is what we will try here (chile). > > Stef > > On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: > >> Thanks everyone! That would be great. >> Looking forward to having NBOpenGL up and running again. >> >> Cheers >> Ricky >> >> >> On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> Right now it cannot even be loaded into 3.0. >>>> But update is simple (i think JB did that already, just not published?). >>> Grrr, all my code are published ^^. >> >> Where? When did you announce it? >> Sorry but how can you expect guys from the other part of the planet to know it. >> Communication in open-source is important because people do not know what others >> are doing. >> You know richie asked and ronie too and they are smart guys. But they cannot guess. >> >>> For mac: >>> I do the change for mac last month because I needed it, it is integrated. >> >> ah ok this is why it is working on mac. >> >>> For linux: >>> I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. >>> On my roommate computer that work (ubuntu ). >>> But I need feedback. >> >> oki we will check that tomorrow I hope. >> >>> For windows: >>> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. >>> I was planned to go test and debug on my home computer (window 7, 64), tomorrow. >> >> Ok we can say it to ronie to have a look. >> >>> So, you can expect a fix integrated soon. >>> >>> And having a working OpenGL, exactly as it work in pharo 2.0. >> >> Excellent. >> >>> >>> >>>> >>>>> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. >>>> >>>> Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). >>>> Because Roassal 3d should not be about shadder but about 3D. >>>> >>>>> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). >>>> >>>> Yes they changed the API and deprecated the old way of doing it. >>> >>> I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. >>> >>> >>>>> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. >>>> >>>> See below >>>> >>>>> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. >>>> >>> >>>> Three remarks: >>>> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL >>> >>> Shader part are done for now. >>> >>>> - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying >>>> on other people and probably frustrated when things are not working. >>> + 1 >>> >>>> - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) >>>> a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you >>>> can get >>>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >>> >>>> >>> >>> yes, my bad. >>> >>>> Now again if nobody builds a jun like library in Pharo it will not exist. >>> >>>> >>>> Stef >>>> >>>> >>>> >>>>> Cheers >>>>> Ricky >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> Hi, >>>>> >>>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >>>>> >>>>> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Richard >>>>> >>>>> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >>>>> and his code should be split in two and one part should go to NBOpenGL. >>>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>>> >>>>> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >>>>> he does not have fun there). >>>>> >>>>> So it is important that you help because we are FULL >>>>> and sorry about that but really FULL. >>>>> >>>>> Ronie will visit us in January and share an office with igor. >>>>> >>>>> Stef >>>>> >>>>> >>>>> > Hi >>>>> > >>>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>>> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >>>>> > >>>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >>>>> > >>>>> > GLTTRenderingDemo new openInWorld. >>>>> > >>>>> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >>>>> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >>>>> > >>>>> > Cheers >>>>> > Ricky >>>>> > >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >> >> > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by kilon alios

just for the record, I am no old timer Smalltalker, I come from python just introduced the past year to pharo. I dont pay attention to the poolDictionaries , I have seen it used as concept by NBOpenGL , looks like a fan idea, it does not distract me from my coding, I am glad its there because one day I may need it. So for now I just ignore it and I see no side effect. One thing to make clear here is that its normal not to use or need stuff from a language. As I said I come from python , python comes with enormous standard library with tons of features, If you install cpython which is the most popular python implementation (by far) you install also its standard library. Its unrealistic to expect the average python coder to use more than 10% from that and 10% maybe be even optimistic. The tricky part is that each coder uses a different 10% . There is no such thing as a majority, a majority is a collection of minorities that are in some form of agreement. Each coder has different goals and different ways of coding. But thats is what it makes a language great, when a specific problem arises the language will provide an easy solution however exotic / rare the problem is, it wont reply to you "wait that thing you ask is kinda rare, so I dont care" because you wont care about the language as well. Someone could bring forth the argument that these things should go to third party libraries , but again there is a problem here. How you inform the users about these libraries ? How you guarantee that these libraries will keep being maintaine ?. So its no concidence that python comes with an enormous standard library and there are many coders that code in python and never use any third library and they love python or be precise cpython for that. Java is a similar story too. So I think the question "who uses poolDictionaries " is one those mirage questions that from far make perfect sense but the closer you come to the problem they make less and less sense . Of course about having a message that containes no poolDictionaries as argument, its makes perfect sense. Things should always be as simple as possible, but not more simple. Making a nice gui has little to do with the API itself. You dont want your API to depend on the GUI , you want the GUI to depend on the API. The API should make the life easy, the GUI should make the lifer easier. On Thu, Nov 14, 2013 at 1:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Nov 14, 2013, at 11:21 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > > On 14 Nov 2013, at 11:10, jtuchel(a)objektfabrik.de wrote: > > > >> Yuri, > >> > >> Okay, so why not go one step further and kill PoolDictionaries? > >> I mean, if no one uses them and you'd like to hide them from the users, > they obviously are unnecessary. That would be a real cleanup, right? > > > > Yes it would, the thing is that I had no idea what they do. And other > guys from my team had no idea. And as far as I know a lot of people are not > aware of them. So for me itâs ok to hide PoolDictionaries. Maybe in future > they will become obsolete because of the features that Slots can provide. > Maybe they will come back to life. > > > Yuriy have a look at Pharo by example. They should be explain. > PoolDictionaries (as in Pharo) refers to special classes holding > classvariables so that these variables can be statically shared (know at > compiled time) between different hierarchies. For example Cr is directly > used instead of having to type Text cr everywhere. > > > As for me, the class creation is wrong. We are not creating a method > like: > > Object compile: > > 'class > > "Primitive. Answer the object which is the receiver''s class. > Essential. See > > Object documentation whatIsAPrimitive." > > > > <primitive: 111> > > self primitiveFailedâ > > > > classified: #'class membership' > > > > we just type a method. > > > > Iâd like something user friendly for cass like: > > - select a superclass > > - give your class a name > > - add instance variable > > * name variable > > * choose variable type > > - add class variableâ¦ > > - add pool dictionary > > > > I think that you get the idea > > > >> > >> PoolDictionaries are potentially dangerous, because you can put things > there that make Images harder to reproduce if you don't put the code to > fill the Dictionaries into some script that will be run in the right > situations (places like #loaded in envy). > >> > >> Joachim > >> > >> Am 14.11.13 11:05, schrieb Yuriy Tymchuk: > >>> On 14 Nov 2013, at 11:02, jtuchel(a)objektfabrik.de wrote: > >>> > >>>> Hi, > >>>> > >>>> I'd like to draw your attention to something else: consistency. > >>>> > >>>> I remember the days when Cincom added Namespaces to classes and the > class definition template changed drastically. It took me quite a while to > get used to that. > >>>> And there is this other aspect in the consistency field: most > Smalltalk literature will include and address that line. If you learn > Smalltalk, such small differences can cause trouble. > >>> Is anything mentioning PoolDictionaries? I have no idea what it is. > >>> > >>> The other thing is that we should go from text for class creation to > nice ui, but itâs a long term goal. > >>> > >>>> And what if I need PoolDictionaries? How hard will it be to find the > place to add my reference to them? > >>>> A fair amount of Pharo code may not make much use of > PoolDictionaries, but other dialects do. I know Pharo has the concept of > "never look back" and it is good to be prepared to cut off old strings. But > there is a price to it. > >>>> > >>>> Seaside, apart from being a great web framework, has achieved > something that was excellent and helped the whole Smalltalk universe make a > leap forward: all Smalltalk dialects moved closer together and honestly > worked on being more compatible. Suggestions like this may not break much > of this per se, but many such cracks make a wide canyon. I find the > argument that a certain line of code may irritate students a bit weak. It > may make their life harder once they read code from other dialects. Should > we remove class browsers because students are used to use text editors? > >>>> > >>>> Just my 2 cents > >>>> > >>>> Joachim > >>>> > >>>> Am 14.11.13 10:49, schrieb Martin Dias: > >>>>> +10 > >>>>> > >>>>> > >>>>> On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse > >>>>> <stephane.ducasse(a)inria.fr> wrote: > >>>>>> +1 > >>>>>> > >>>>>> On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> > wrote: > >>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> I am preparing slides for a course. I came to the typical: > >>>>>>> > >>>>>>> Number subclass: #Complex > >>>>>>> instanceVariableNames: 'real imaginary' > >>>>>>> classVariableNames: '' > >>>>>>> poolDictionaries: '' > >>>>>>> category: 'ComplexNumbers' > >>>>>>> > >>>>>>> Which made me think: Who uses poolDictionaries? I suspect > extremely few of us. > >>>>>>> > >>>>>>> Why not add this to Class: > >>>>>>> Class>>subclass: aSymbol instanceVariableNames: instVarNames > classVariableNames: classVarNames category: aSymbol > >>>>>>> ^self subclass: aSymbol > >>>>>>> instanceVariableNames: instVarNames > >>>>>>> classVariableNames: classVarNames > >>>>>>> poolDictionaries: '' > >>>>>>> category: aSymbol > >>>>>>> > >>>>>>> And have the new class template as follows? > >>>>>>> > >>>>>>> Object subclass: #NameOfSubclass > >>>>>>> instanceVariableNames: '' > >>>>>>> classVariableNames: '' > >>>>>>> category: 'Kernel-Classes' > >>>>>>> > >>>>>>> It would be a bit cleaner. I know us old timers don't even see the > poolDictionaries: line anymore, but I dislike having to explain it to > students. > >>>>>>> > >>>>>>> Greetings, > >>>>>>> > >>>>>>> ---> Save our in-boxes! http://emailcharter.org <--- > >>>>>>> > >>>>>>> Johan Fabry - http://pleiad.cl/~jfabry > >>>>>>> PLEIAD lab - Computer Science Department (DCC) - University of > Chile > >>>>>>> > >>>>>>> > >>>> > >>>> -- > >>>> > ----------------------------------------------------------------------- > >>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > >>>> Fliederweg 1 http://www.objektfabrik.de > >>>> D-71640 Ludwigsburg > http://joachimtuchel.wordpress.com > >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >>>> > >>>> > >>> > >>> > >> > >> > >> -- > >> ----------------------------------------------------------------------- > >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > >> Fliederweg 1 http://www.objektfabrik.de > >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >> > >> > > > > > > >

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by StÃ©phane Ducasse

You should look in VM code clement / eliot can reply more precisely but the idea is to see when do you accept to suspend a computation. In Smalltlak this is after each message. Stef > Stef, > > Am 14.11.2013 um 12:10 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Note that it would be good to have a special syntactic construct for that because now >> we rely on the way the compiler works to ensure such properties and it means that >> an accessor and a direct access are not semantically equals. >> > I was asking for pointers/locations where to look at. I like to wrap my head around it in order to understand how it works and thus figuring out where and when there is a problem. > > Norbert >> >> Stef >> >> >>>> On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>>> Reading this code, made me wonder what operations are actually atomic. >>>>> Anyone having a good explanation? >>>>> >>>>> Stephan >>>>> >>>>> AtomicQueueItem>makeCircular >>>>> "Make a receiver circular, i.e. point to itself, >>>>> answer the old value of next variable. >>>>> Note, this operation should be atomic" >>>>> >>>>> | temp | >>>>> >>>>> " atomic swap here" >>>>> temp := next. >>>>> next := self. >>>>> >>>>> ^ temp >>>>> >>>> -> no message send >>>> -> no back jump bytecode >>>> >>>> therefore it can not be interrupted and process switches can not happen between the statements. >>> >>> Thanks, I learn something new every day. Iâve never thought about the condition when a process switch can happen. Can you say in short when a switch of processes is checked? Because I think I wonât finding it in a reasonable time looking myself. >>> >>> Norbert >>> >>> >> >> > >

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by Norbert Hartl

Stef, Am 14.11.2013 um 12:10 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Note that it would be good to have a special syntactic construct for that because now > we rely on the way the compiler works to ensure such properties and it means that > an accessor and a direct access are not semantically equals. > I was asking for pointers/locations where to look at. I like to wrap my head around it in order to understand how it works and thus figuring out where and when there is a problem. Norbert > > Stef > > >>> On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>>> Reading this code, made me wonder what operations are actually atomic. >>>> Anyone having a good explanation? >>>> >>>> Stephan >>>> >>>> AtomicQueueItem>makeCircular >>>> "Make a receiver circular, i.e. point to itself, >>>> answer the old value of next variable. >>>> Note, this operation should be atomic" >>>> >>>> | temp | >>>> >>>> " atomic swap here" >>>> temp := next. >>>> next := self. >>>> >>>> ^ temp >>>> >>> -> no message send >>> -> no back jump bytecode >>> >>> therefore it can not be interrupted and process switches can not happen between the statements. >> >> Thanks, I learn something new every day. Iâve never thought about the condition when a process switch can happen. Can you say in short when a switch of processes is checked? Because I think I wonât finding it in a reasonable time looking myself. >> >> Norbert >> >> > >

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by StÃ©phane Ducasse

On Nov 14, 2013, at 11:21 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 14 Nov 2013, at 11:10, jtuchel(a)objektfabrik.de wrote: > >> Yuri, >> >> Okay, so why not go one step further and kill PoolDictionaries? >> I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right? > > Yes it would, the thing is that I had no idea what they do. And other guys from my team had no idea. And as far as I know a lot of people are not aware of them. So for me itâs ok to hide PoolDictionaries. Maybe in future they will become obsolete because of the features that Slots can provide. Maybe they will come back to life. Yuriy have a look at Pharo by example. They should be explain. PoolDictionaries (as in Pharo) refers to special classes holding classvariables so that these variables can be statically shared (know at compiled time) between different hierarchies. For example Cr is directly used instead of having to type Text cr everywhere. > As for me, the class creation is wrong. We are not creating a method like: > Object compile: > 'class > "Primitive. Answer the object which is the receiver''s class. Essential. See > Object documentation whatIsAPrimitive." > > <primitive: 111> > self primitiveFailedâ > > classified: #'class membership' > > we just type a method. > > Iâd like something user friendly for cass like: > - select a superclass > - give your class a name > - add instance variable > * name variable > * choose variable type > - add class variableâ¦ > - add pool dictionary > > I think that you get the idea > >> >> PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy). >> >> Joachim >> >> Am 14.11.13 11:05, schrieb Yuriy Tymchuk: >>> On 14 Nov 2013, at 11:02, jtuchel(a)objektfabrik.de wrote: >>> >>>> Hi, >>>> >>>> I'd like to draw your attention to something else: consistency. >>>> >>>> I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. >>>> And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. >>> Is anything mentioning PoolDictionaries? I have no idea what it is. >>> >>> The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal. >>> >>>> And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? >>>> A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it. >>>> >>>> Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors? >>>> >>>> Just my 2 cents >>>> >>>> Joachim >>>> >>>> Am 14.11.13 10:49, schrieb Martin Dias: >>>>> +10 >>>>> >>>>> >>>>> On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>> +1 >>>>>> >>>>>> On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I am preparing slides for a course. I came to the typical: >>>>>>> >>>>>>> Number subclass: #Complex >>>>>>> instanceVariableNames: 'real imaginary' >>>>>>> classVariableNames: '' >>>>>>> poolDictionaries: '' >>>>>>> category: 'ComplexNumbers' >>>>>>> >>>>>>> Which made me think: Who uses poolDictionaries? I suspect extremely few of us. >>>>>>> >>>>>>> Why not add this to Class: >>>>>>> Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol >>>>>>> ^self subclass: aSymbol >>>>>>> instanceVariableNames: instVarNames >>>>>>> classVariableNames: classVarNames >>>>>>> poolDictionaries: '' >>>>>>> category: aSymbol >>>>>>> >>>>>>> And have the new class template as follows? >>>>>>> >>>>>>> Object subclass: #NameOfSubclass >>>>>>> instanceVariableNames: '' >>>>>>> classVariableNames: '' >>>>>>> category: 'Kernel-Classes' >>>>>>> >>>>>>> It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. >>>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> ---> Save our in-boxes! http://emailcharter.org <--- >>>>>>> >>>>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>>>> PLEIAD lab - Computer Science Department (DCC) - University of Chile >>>>>>> >>>>>>> >>>> >>>> -- >>>> ----------------------------------------------------------------------- >>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>> Fliederweg 1 http://www.objektfabrik.de >>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>>> >>>> >>> >>> >> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> > >

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by StÃ©phane Ducasse

Note that it would be good to have a special syntactic construct for that because now we rely on the way the compiler works to ensure such properties and it means that an accessor and a direct access are not semantically equals. Stef >> On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >>> Reading this code, made me wonder what operations are actually atomic. >>> Anyone having a good explanation? >>> >>> Stephan >>> >>> AtomicQueueItem>makeCircular >>> "Make a receiver circular, i.e. point to itself, >>> answer the old value of next variable. >>> Note, this operation should be atomic" >>> >>> | temp | >>> >>> " atomic swap here" >>> temp := next. >>> next := self. >>> >>> ^ temp >>> >> -> no message send >> -> no back jump bytecode >> >> therefore it can not be interrupted and process switches can not happen between the statements. > > Thanks, I learn something new every day. Iâve never thought about the condition when a process switch can happen. Can you say in short when a switch of processes is checked? Because I think I wonât finding it in a reasonable time looking myself. > > Norbert > >

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by StÃ©phane Ducasse

so richie have a look at the repository and load the latest version to see if they work (not using the configuration). This is what we will try here (chile). Stef On Nov 14, 2013, at 9:58 AM, Richard Wettel <wettel(a)gmail.com> wrote: > Thanks everyone! That would be great. > Looking forward to having NBOpenGL up and running again. > > Cheers > Ricky > > > On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> Right now it cannot even be loaded into 3.0. >>> But update is simple (i think JB did that already, just not published?). >> Grrr, all my code are published ^^. > > Where? When did you announce it? > Sorry but how can you expect guys from the other part of the planet to know it. > Communication in open-source is important because people do not know what others > are doing. > You know richie asked and ronie too and they are smart guys. But they cannot guess. > >> For mac: >> I do the change for mac last month because I needed it, it is integrated. > > ah ok this is why it is working on mac. > >> For linux: >> I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. >> On my roommate computer that work (ubuntu ). >> But I need feedback. > > oki we will check that tomorrow I hope. > >> For windows: >> I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. >> I was planned to go test and debug on my home computer (window 7, 64), tomorrow. > > Ok we can say it to ronie to have a look. > >> So, you can expect a fix integrated soon. >> >> And having a working OpenGL, exactly as it work in pharo 2.0. > > Excellent. > >> >> >>> >>>> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. >>> >>> Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). >>> Because Roassal 3d should not be about shadder but about 3D. >>> >>>> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). >>> >>> Yes they changed the API and deprecated the old way of doing it. >> >> I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. >> >> >>>> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. >>> >>> See below >>> >>>> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. >>> >> >>> Three remarks: >>> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL >> >> Shader part are done for now. >> >>> - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying >>> on other people and probably frustrated when things are not working. >> + 1 >> >>> - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) >>> a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you >>> can get >>> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >> >>> >> >> yes, my bad. >> >>> Now again if nobody builds a jun like library in Pharo it will not exist. >> >>> >>> Stef >>> >>> >>> >>>> Cheers >>>> Ricky >>>> >>>> >>>> >>>> >>>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> Hi, >>>> >>>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >>>> >>>> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Richard >>>> >>>> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >>>> and his code should be split in two and one part should go to NBOpenGL. >>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>> >>>> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >>>> he does not have fun there). >>>> >>>> So it is important that you help because we are FULL >>>> and sorry about that but really FULL. >>>> >>>> Ronie will visit us in January and share an office with igor. >>>> >>>> Stef >>>> >>>> >>>> > Hi >>>> > >>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >>>> > >>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >>>> > >>>> > GLTTRenderingDemo new openInWorld. >>>> > >>>> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >>>> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >>>> > >>>> > Cheers >>>> > Ricky >>>> > >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> > >

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by ClÃ©ment Bera

2013/11/14 jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> > Yuri, > > Okay, so why not go one step further and kill PoolDictionaries? > This was done in OOVM / Resilient Smalltalk. And it was clean and worked well. > I mean, if no one uses them and you'd like to hide them from the users, > they obviously are unnecessary. That would be a real cleanup, right? > Definitely. lots of pool dictionaries has already been removed from Pharo (some of them were put into class variable, other really removed). But removing this feature is not possible because frameworks as seaside or moose may use them, and most Pharo users program with Pharo because of these frameworks. Hiding it from the user is a good solution to me. It means their usage is disapproved. Therefore new users will not use them. However old school guys and frameworks may use it, they know how to add them. We already have "uses:" for Traits that is a hidden selectorPart by default, and everyone's happy with it. > > PoolDictionaries are potentially dangerous, because you can put things > there that make Images harder to reproduce if you don't put the code to > fill the Dictionaries into some script that will be run in the right > situations (places like #loaded in envy). > > Joachim > > Am 14.11.13 11:05, schrieb Yuriy Tymchuk: > > On 14 Nov 2013, at 11:02, jtuchel(a)objektfabrik.de wrote: >> >> Hi, >>> >>> I'd like to draw your attention to something else: consistency. >>> >>> I remember the days when Cincom added Namespaces to classes and the >>> class definition template changed drastically. It took me quite a while to >>> get used to that. >>> And there is this other aspect in the consistency field: most Smalltalk >>> literature will include and address that line. If you learn Smalltalk, such >>> small differences can cause trouble. >>> >> Is anything mentioning PoolDictionaries? I have no idea what it is. >> >> The other thing is that we should go from text for class creation to nice >> ui, but itâs a long term goal. >> >> And what if I need PoolDictionaries? How hard will it be to find the >>> place to add my reference to them? >>> A fair amount of Pharo code may not make much use of PoolDictionaries, >>> but other dialects do. I know Pharo has the concept of "never look back" >>> and it is good to be prepared to cut off old strings. But there is a price >>> to it. >>> >>> Seaside, apart from being a great web framework, has achieved something >>> that was excellent and helped the whole Smalltalk universe make a leap >>> forward: all Smalltalk dialects moved closer together and honestly worked >>> on being more compatible. Suggestions like this may not break much of this >>> per se, but many such cracks make a wide canyon. I find the argument that a >>> certain line of code may irritate students a bit weak. It may make their >>> life harder once they read code from other dialects. Should we remove class >>> browsers because students are used to use text editors? >>> >>> Just my 2 cents >>> >>> Joachim >>> >>> Am 14.11.13 10:49, schrieb Martin Dias: >>> >>>> +10 >>>> >>>> >>>> On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> +1 >>>>> >>>>> On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>>>> >>>>> Hi all, >>>>>> >>>>>> I am preparing slides for a course. I came to the typical: >>>>>> >>>>>> Number subclass: #Complex >>>>>> instanceVariableNames: 'real imaginary' >>>>>> classVariableNames: '' >>>>>> poolDictionaries: '' >>>>>> category: 'ComplexNumbers' >>>>>> >>>>>> Which made me think: Who uses poolDictionaries? I suspect extremely >>>>>> few of us. >>>>>> >>>>>> Why not add this to Class: >>>>>> Class>>subclass: aSymbol instanceVariableNames: instVarNames >>>>>> classVariableNames: classVarNames category: aSymbol >>>>>> ^self subclass: aSymbol >>>>>> instanceVariableNames: instVarNames >>>>>> classVariableNames: classVarNames >>>>>> poolDictionaries: '' >>>>>> category: aSymbol >>>>>> >>>>>> And have the new class template as follows? >>>>>> >>>>>> Object subclass: #NameOfSubclass >>>>>> instanceVariableNames: '' >>>>>> classVariableNames: '' >>>>>> category: 'Kernel-Classes' >>>>>> >>>>>> It would be a bit cleaner. I know us old timers don't even see the >>>>>> poolDictionaries: line anymore, but I dislike having to explain it to >>>>>> students. >>>>>> >>>>>> Greetings, >>>>>> >>>>>> ---> Save our in-boxes! http://emailcharter.org <--- >>>>>> >>>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>>> PLEIAD lab - Computer Science Department (DCC) - University of >>>>>> Chile >>>>>> >>>>>> >>>>>> >>> -- >>> ----------------------------------------------------------------------- >>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>> Fliederweg 1 http://www.objektfabrik.de >>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>> >>> >>> >> >> > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by jtuchel＠objektfabrik.de

Am 14.11.13 11:23, schrieb Sergi Reyner: > 2013/11/14 jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de> > <jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de>> > > > And what if I need PoolDictionaries? > > > Unless my understanding of the proposal is way off, you would just add > "poolDictionaries: 'whatever'" before "category:". No horrible > breaking of anything would happen. > > Cheers, > Sergi I disagree ;-) I find it hard to remember the ordering of these parameters. I sometimes have this problem with classInstVars in VAST. But you are right in that using a simpler template as the default won't remove the whole feature. Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by jtuchel＠objektfabrik.de

Yuri, the GUI idea has an up and a down side. The up side is that it's much easier to use. The down side is that there is no way to ex- and import a class definition without a proper syntax. So what is needed is both: a proper syntax and some way to make things easier for the mousey people. Maybe the tools aspect is what Johan initially was talking about: why not make the class creations (let's call it) snippet exchangeable for certain user groups. A setting that says: "include Pool Dictionaries in default class creation template", Right? If so, we should also be able to choose if we want class inst vars (does Pharo support them?) and class variables. Who uses class vars anyways ;-) Joachim Am 14.11.13 11:21, schrieb Yuriy Tymchuk: > On 14 Nov 2013, at 11:10, jtuchel(a)objektfabrik.de wrote: > >> Yuri, >> >> Okay, so why not go one step further and kill PoolDictionaries? >> I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right? > Yes it would, the thing is that I had no idea what they do. And other guys from my team had no idea. And as far as I know a lot of people are not aware of them. So for me itâs ok to hide PoolDictionaries. Maybe in future they will become obsolete because of the features that Slots can provide. Maybe they will come back to life. > > As for me, the class creation is wrong. We are not creating a method like: > Object compile: > 'class > "Primitive. Answer the object which is the receiver''s class. Essential. See > Object documentation whatIsAPrimitive." > > <primitive: 111> > self primitiveFailedâ > > classified: #'class membership' > > we just type a method. > > Iâd like something user friendly for cass like: > - select a superclass > - give your class a name > - add instance variable > * name variable > * choose variable type > - add class variableâ¦ > - add pool dictionary > > I think that you get the idea > >> PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy). >> >> Joachim >> >> Am 14.11.13 11:05, schrieb Yuriy Tymchuk: >>> On 14 Nov 2013, at 11:02, jtuchel(a)objektfabrik.de wrote: >>> >>>> Hi, >>>> >>>> I'd like to draw your attention to something else: consistency. >>>> >>>> I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. >>>> And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. >>> Is anything mentioning PoolDictionaries? I have no idea what it is. >>> >>> The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal. >>> >>>> And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? >>>> A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it. >>>> >>>> Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors? >>>> >>>> Just my 2 cents >>>> >>>> Joachim >>>> >>>> Am 14.11.13 10:49, schrieb Martin Dias: >>>>> +10 >>>>> >>>>> >>>>> On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>> +1 >>>>>> >>>>>> On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I am preparing slides for a course. I came to the typical: >>>>>>> >>>>>>> Number subclass: #Complex >>>>>>> instanceVariableNames: 'real imaginary' >>>>>>> classVariableNames: '' >>>>>>> poolDictionaries: '' >>>>>>> category: 'ComplexNumbers' >>>>>>> >>>>>>> Which made me think: Who uses poolDictionaries? I suspect extremely few of us. >>>>>>> >>>>>>> Why not add this to Class: >>>>>>> Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol >>>>>>> ^self subclass: aSymbol >>>>>>> instanceVariableNames: instVarNames >>>>>>> classVariableNames: classVarNames >>>>>>> poolDictionaries: '' >>>>>>> category: aSymbol >>>>>>> >>>>>>> And have the new class template as follows? >>>>>>> >>>>>>> Object subclass: #NameOfSubclass >>>>>>> instanceVariableNames: '' >>>>>>> classVariableNames: '' >>>>>>> category: 'Kernel-Classes' >>>>>>> >>>>>>> It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. >>>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> ---> Save our in-boxes! http://emailcharter.org <--- >>>>>>> >>>>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>>>> PLEIAD lab - Computer Science Department (DCC) - University of Chile >>>>>>> >>>>>>> >>>> -- >>>> ----------------------------------------------------------------------- >>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>>> Fliederweg 1 http://www.objektfabrik.de >>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>>> >>>> >>> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by Sergi Reyner

2013/11/14 jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> > > And what if I need PoolDictionaries? Unless my understanding of the proposal is way off, you would just add "poolDictionaries: 'whatever'" before "category:". No horrible breaking of anything would happen. Cheers, Sergi

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by jtuchel＠objektfabrik.de

Am 14.11.13 11:19, schrieb Norbert Hartl: > Am 14.11.2013 um 11:16 schrieb jtuchel(a)objektfabrik.de: > >> Hi Norbert, >> >> I couldn't have said it any better. For me, this also was interesting, because I first thought: "Heck, how would I make anything atomic anyways?". >> And that question still stands: is there a way to make something atomic that includes message sends? I guess #critical is not the solution, is it? >> > No, because then it isnât lock free anymore ;) > > Norbert I knew I was typing something stupid ;-) But you are of course right. #critical's whole concept is locking, of course ;-) >> >> -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by Yuriy Tymchuk

On 14 Nov 2013, at 11:10, jtuchel(a)objektfabrik.de wrote: > Yuri, > > Okay, so why not go one step further and kill PoolDictionaries? > I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right? Yes it would, the thing is that I had no idea what they do. And other guys from my team had no idea. And as far as I know a lot of people are not aware of them. So for me itâs ok to hide PoolDictionaries. Maybe in future they will become obsolete because of the features that Slots can provide. Maybe they will come back to life. As for me, the class creation is wrong. We are not creating a method like: Object compile: 'class "Primitive. Answer the object which is the receiver''s class. Essential. See Object documentation whatIsAPrimitive." <primitive: 111> self primitiveFailedâ classified: #'class membership' we just type a method. Iâd like something user friendly for cass like: - select a superclass - give your class a name - add instance variable * name variable * choose variable type - add class variableâ¦ - add pool dictionary I think that you get the idea > > PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy). > > Joachim > > Am 14.11.13 11:05, schrieb Yuriy Tymchuk: >> On 14 Nov 2013, at 11:02, jtuchel(a)objektfabrik.de wrote: >> >>> Hi, >>> >>> I'd like to draw your attention to something else: consistency. >>> >>> I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. >>> And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. >> Is anything mentioning PoolDictionaries? I have no idea what it is. >> >> The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal. >> >>> And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? >>> A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it. >>> >>> Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors? >>> >>> Just my 2 cents >>> >>> Joachim >>> >>> Am 14.11.13 10:49, schrieb Martin Dias: >>>> +10 >>>> >>>> >>>> On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> +1 >>>>> >>>>> On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I am preparing slides for a course. I came to the typical: >>>>>> >>>>>> Number subclass: #Complex >>>>>> instanceVariableNames: 'real imaginary' >>>>>> classVariableNames: '' >>>>>> poolDictionaries: '' >>>>>> category: 'ComplexNumbers' >>>>>> >>>>>> Which made me think: Who uses poolDictionaries? I suspect extremely few of us. >>>>>> >>>>>> Why not add this to Class: >>>>>> Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol >>>>>> ^self subclass: aSymbol >>>>>> instanceVariableNames: instVarNames >>>>>> classVariableNames: classVarNames >>>>>> poolDictionaries: '' >>>>>> category: aSymbol >>>>>> >>>>>> And have the new class template as follows? >>>>>> >>>>>> Object subclass: #NameOfSubclass >>>>>> instanceVariableNames: '' >>>>>> classVariableNames: '' >>>>>> category: 'Kernel-Classes' >>>>>> >>>>>> It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. >>>>>> >>>>>> Greetings, >>>>>> >>>>>> ---> Save our in-boxes! http://emailcharter.org <--- >>>>>> >>>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>>> PLEIAD lab - Computer Science Department (DCC) - University of Chile >>>>>> >>>>>> >>> >>> -- >>> ----------------------------------------------------------------------- >>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >>> Fliederweg 1 http://www.objektfabrik.de >>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >>> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >>> >>> >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

Nov. 14, 2013

Lock free structures in Pharo

by Stephan Eggermont

Marcus wrote: >-> no message send >-> no back jump bytecode > >therefore it can not be interrupted and process switches can not happen between the statements. Ok, thatâs not too difficult. Thank you Stephan

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by Norbert Hartl

Am 14.11.2013 um 11:16 schrieb jtuchel(a)objektfabrik.de: > Hi Norbert, > > I couldn't have said it any better. For me, this also was interesting, because I first thought: "Heck, how would I make anything atomic anyways?". > And that question still stands: is there a way to make something atomic that includes message sends? I guess #critical is not the solution, is it? > No, because then it isnât lock free anymore ;) Norbert > > Am 14.11.13 11:12, schrieb Norbert Hartl: >> Am 14.11.2013 um 10:25 schrieb Marcus Denker <marcus.denker(a)inria.fr>: >> >>> On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>>> Reading this code, made me wonder what operations are actually atomic. >>>> Anyone having a good explanation? >>>> >>>> Stephan >>>> >>>> AtomicQueueItem>makeCircular >>>> "Make a receiver circular, i.e. point to itself, >>>> answer the old value of next variable. >>>> Note, this operation should be atomic" >>>> >>>> | temp | >>>> >>>> " atomic swap here" >>>> temp := next. >>>> next := self. >>>> >>>> ^ temp >>>> >>> -> no message send >>> -> no back jump bytecode >>> >>> therefore it can not be interrupted and process switches can not happen between the statements. >> Thanks, I learn something new every day. Iâve never thought about the condition when a process switch can happen. Can you say in short when a switch of processes is checked? Because I think I wonât finding it in a reasonable time looking myself. >> >> Norbert >> >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

Nov. 14, 2013

Re: [Pharo-users] State of Flamel?

by Stephan Eggermont

Anyone?

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by jtuchel＠objektfabrik.de

Hi Norbert, I couldn't have said it any better. For me, this also was interesting, because I first thought: "Heck, how would I make anything atomic anyways?". And that question still stands: is there a way to make something atomic that includes message sends? I guess #critical is not the solution, is it? Joachim Am 14.11.13 11:12, schrieb Norbert Hartl: > Am 14.11.2013 um 10:25 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > >> On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >>> Reading this code, made me wonder what operations are actually atomic. >>> Anyone having a good explanation? >>> >>> Stephan >>> >>> AtomicQueueItem>makeCircular >>> "Make a receiver circular, i.e. point to itself, >>> answer the old value of next variable. >>> Note, this operation should be atomic" >>> >>> | temp | >>> >>> " atomic swap here" >>> temp := next. >>> next := self. >>> >>> ^ temp >>> >> -> no message send >> -> no back jump bytecode >> >> therefore it can not be interrupted and process switches can not happen between the statements. > Thanks, I learn something new every day. Iâve never thought about the condition when a process switch can happen. Can you say in short when a switch of processes is checked? Because I think I wonât finding it in a reasonable time looking myself. > > Norbert > > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by Norbert Hartl

Am 14.11.2013 um 10:25 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Reading this code, made me wonder what operations are actually atomic. >> Anyone having a good explanation? >> >> Stephan >> >> AtomicQueueItem>makeCircular >> "Make a receiver circular, i.e. point to itself, >> answer the old value of next variable. >> Note, this operation should be atomic" >> >> | temp | >> >> " atomic swap here" >> temp := next. >> next := self. >> >> ^ temp >> > -> no message send > -> no back jump bytecode > > therefore it can not be interrupted and process switches can not happen between the statements. Thanks, I learn something new every day. Iâve never thought about the condition when a process switch can happen. Can you say in short when a switch of processes is checked? Because I think I wonât finding it in a reasonable time looking myself. Norbert

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by jtuchel＠objektfabrik.de

Yuri, Okay, so why not go one step further and kill PoolDictionaries? I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right? PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy). Joachim Am 14.11.13 11:05, schrieb Yuriy Tymchuk: > On 14 Nov 2013, at 11:02, jtuchel(a)objektfabrik.de wrote: > >> Hi, >> >> I'd like to draw your attention to something else: consistency. >> >> I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. >> And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. > Is anything mentioning PoolDictionaries? I have no idea what it is. > > The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal. > >> And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? >> A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it. >> >> Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors? >> >> Just my 2 cents >> >> Joachim >> >> Am 14.11.13 10:49, schrieb Martin Dias: >>> +10 >>> >>> >>> On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> +1 >>>> >>>> On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am preparing slides for a course. I came to the typical: >>>>> >>>>> Number subclass: #Complex >>>>> instanceVariableNames: 'real imaginary' >>>>> classVariableNames: '' >>>>> poolDictionaries: '' >>>>> category: 'ComplexNumbers' >>>>> >>>>> Which made me think: Who uses poolDictionaries? I suspect extremely few of us. >>>>> >>>>> Why not add this to Class: >>>>> Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol >>>>> ^self subclass: aSymbol >>>>> instanceVariableNames: instVarNames >>>>> classVariableNames: classVarNames >>>>> poolDictionaries: '' >>>>> category: aSymbol >>>>> >>>>> And have the new class template as follows? >>>>> >>>>> Object subclass: #NameOfSubclass >>>>> instanceVariableNames: '' >>>>> classVariableNames: '' >>>>> category: 'Kernel-Classes' >>>>> >>>>> It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. >>>>> >>>>> Greetings, >>>>> >>>>> ---> Save our in-boxes! http://emailcharter.org <--- >>>>> >>>>> Johan Fabry - http://pleiad.cl/~jfabry >>>>> PLEIAD lab - Computer Science Department (DCC) - University of Chile >>>>> >>>>> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by Yuriy Tymchuk

On 14 Nov 2013, at 11:02, jtuchel(a)objektfabrik.de wrote: > Hi, > > I'd like to draw your attention to something else: consistency. > > I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. > And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. Is anything mentioning PoolDictionaries? I have no idea what it is. The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal. > > And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? > A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it. > > Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors? > > Just my 2 cents > > Joachim > > Am 14.11.13 10:49, schrieb Martin Dias: >> +10 >> >> >> On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> +1 >>> >>> On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>> >>>> Hi all, >>>> >>>> I am preparing slides for a course. I came to the typical: >>>> >>>> Number subclass: #Complex >>>> instanceVariableNames: 'real imaginary' >>>> classVariableNames: '' >>>> poolDictionaries: '' >>>> category: 'ComplexNumbers' >>>> >>>> Which made me think: Who uses poolDictionaries? I suspect extremely few of us. >>>> >>>> Why not add this to Class: >>>> Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol >>>> ^self subclass: aSymbol >>>> instanceVariableNames: instVarNames >>>> classVariableNames: classVarNames >>>> poolDictionaries: '' >>>> category: aSymbol >>>> >>>> And have the new class template as follows? >>>> >>>> Object subclass: #NameOfSubclass >>>> instanceVariableNames: '' >>>> classVariableNames: '' >>>> category: 'Kernel-Classes' >>>> >>>> It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. >>>> >>>> Greetings, >>>> >>>> ---> Save our in-boxes! http://emailcharter.org <--- >>>> >>>> Johan Fabry - http://pleiad.cl/~jfabry >>>> PLEIAD lab - Computer Science Department (DCC) - University of Chile >>>> >>>> >>> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by jtuchel＠objektfabrik.de

Hi, I'd like to draw your attention to something else: consistency. I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it. Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors? Just my 2 cents Joachim Am 14.11.13 10:49, schrieb Martin Dias: > +10 > > > On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> +1 >> >> On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> >>> Hi all, >>> >>> I am preparing slides for a course. I came to the typical: >>> >>> Number subclass: #Complex >>> instanceVariableNames: 'real imaginary' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'ComplexNumbers' >>> >>> Which made me think: Who uses poolDictionaries? I suspect extremely few of us. >>> >>> Why not add this to Class: >>> Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol >>> ^self subclass: aSymbol >>> instanceVariableNames: instVarNames >>> classVariableNames: classVarNames >>> poolDictionaries: '' >>> category: aSymbol >>> >>> And have the new class template as follows? >>> >>> Object subclass: #NameOfSubclass >>> instanceVariableNames: '' >>> classVariableNames: '' >>> category: 'Kernel-Classes' >>> >>> It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. >>> >>> Greetings, >>> >>> ---> Save our in-boxes! http://emailcharter.org <--- >>> >>> Johan Fabry - http://pleiad.cl/~jfabry >>> PLEIAD lab - Computer Science Department (DCC) - University of Chile >>> >>> >> > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 14, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by Martin Dias

+10 On Tue, Nov 12, 2013 at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > +1 > > On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > >> Hi all, >> >> I am preparing slides for a course. I came to the typical: >> >> Number subclass: #Complex >> instanceVariableNames: 'real imaginary' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'ComplexNumbers' >> >> Which made me think: Who uses poolDictionaries? I suspect extremely few of us. >> >> Why not add this to Class: >> Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol >> ^self subclass: aSymbol >> instanceVariableNames: instVarNames >> classVariableNames: classVarNames >> poolDictionaries: '' >> category: aSymbol >> >> And have the new class template as follows? >> >> Object subclass: #NameOfSubclass >> instanceVariableNames: '' >> classVariableNames: '' >> category: 'Kernel-Classes' >> >> It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. >> >> Greetings, >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >> > >

Nov. 14, 2013

Re: [Pharo-users] Lock free structures in Pharo

by Marcus Denker

On 14 Nov 2013, at 10:15, Stephan Eggermont <stephan(a)stack.nl> wrote: > Reading this code, made me wonder what operations are actually atomic. > Anyone having a good explanation? > > Stephan > > AtomicQueueItem>makeCircular > "Make a receiver circular, i.e. point to itself, > answer the old value of next variable. > Note, this operation should be atomic" > > | temp | > > " atomic swap here" > temp := next. > next := self. > > ^ temp > -> no message send -> no back jump bytecode therefore it can not be interrupted and process switches can not happen between the statements. Marcus

Nov. 14, 2013

Lock free structures in Pharo

by Stephan Eggermont

Reading this code, made me wonder what operations are actually atomic. Anyone having a good explanation? Stephan AtomicQueueItem>makeCircular "Make a receiver circular, i.e. point to itself, answer the old value of next variable. Note, this operation should be atomic" | temp | " atomic swap here" temp := next. next := self. ^ temp

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Richard Wettel

Thanks everyone! That would be great. Looking forward to having NBOpenGL up and running again. Cheers Ricky On Thu, Nov 14, 2013 at 2:29 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > >> Right now it cannot even be loaded into 3.0. > But update is simple (i think JB did that already, just not published?). > > Grrr, all my code are published ^^. > > > Where? When did you announce it? > Sorry but how can you expect guys from the other part of the planet to > know it. > Communication in open-source is important because people do not know what > others > are doing. > You know richie asked and ronie too and they are smart guys. But they > cannot guess. > > For mac: > I do the change for mac last month because I needed it, it is integrated. > > > ah ok this is why it is working on mac. > > For linux: > I fix, published, tested and updated the configuration for linux 2 days > ago, because Alex ask me. > On my roommate computer that work (ubuntu ). > But I need feedback. > > > oki we will check that tomorrow I hope. > > For windows: > I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but > I do not update configuration because I cannot test it. > I was planned to go test and debug on my home computer (window 7, 64), > tomorrow. > > > Ok we can say it to ronie to have a look. > > So, you can expect a fix integrated soon. > > And having a working OpenGL, exactly as it work in pharo 2.0. > > > Excellent. > > > > > >> I have already looked at Roassal 3d, but it was not easy to separate the >> API from the code. >> >> >> Strange because even me I could see that the shadder code should not be >> in Roassal 3D but in NBOpenGL :). >> Because Roassal 3d should not be about shadder but about 3D. >> > >> And it is something completely different than what I have been using (and >> SourceCity, too), because Roassal 3d is using the modern OpenGL methodology >> (with FBOs and stuff). >> >> >> Yes they changed the API and deprecated the old way of doing it. >> > > I will also publish some example (using shadder) that I wrote but it is > still not yet user friendly. > > > So, I would really appreciate if that API would find its way from Roassal >> to NBOpenGL and I could use it for CodeCity. >> >> >> See below >> > >> Unfortunately I am able to help a lot with that, because I know very >> little about this and I also don't have enough time (I am doing CodeCity in >> my spare time). But, if you have concrete things that I can do, I'd be >> happy to help. >> >> >> Three remarks: >> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL >> > > Shader part are done for now. > > - I'm not sure that doing 3d without investing a bit in the underlying >> technology is wise. Because you will be always relying >> on other people and probably frustrated when things are not working. >> > + 1 > > - Since JB does not know how to communicate here is what he did for fun >> instead of pushing MoosePython :) >> > a renderer to video to videos stream for openGL -> MKV, mp4 based one >> ffmpeg). The code is openGL extra. As an example you >> can get >> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ >> > >> > yes, my bad. > > Now again if nobody builds a jun like library in Pharo it will not exist. >> > >> Stef >> >> >> >> Cheers >> Ricky >> >> >> >> >> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >> >>> Hi, >>> >>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 >>> and 3.0 such that this does not work anymore on Windows. The fact that he >>> mentioned 64 bits is not relevant for this discussion :). >>> >>> I also guess he wants to put some effort into understanding this as well >>> but he needs a bit of guidance. Right Ricky? >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> >>>> Richard >>>> >>>> you should have a look at ROASSAL 3d because ronie improved the shadder >>>> part (no more assembler) >>>> and his code should be split in two and one part should go to NBOpenGL. >>>> Now he is experiencing some problem with NBOpenGL on windows as you. >>>> >>>> NativeBoost does not work on 64 bits. Yet but igor is really busy >>>> finishing the texteditor (and I can tell you that >>>> he does not have fun there). >>>> >>>> So it is important that you help because we are FULL >>>> and sorry about that but really FULL. >>>> >>>> Ronie will visit us in January and share an office with igor. >>>> >>>> Stef >>>> >>>> >>>> > Hi >>>> > >>>> > CodeCity, the project I am working on is based on NBOpenGL. >>>> > I'd like to start working on it using Pharo 3, but it seems that >>>> NBOpenGL does not work yet with Pharo 3.0. >>>> > >>>> > I downloaded from jenkins the latest image with Pharo 3 and tried to >>>> execute the following code on Windows 7, 64 bits: >>>> > >>>> > GLTTRenderingDemo new openInWorld. >>>> > >>>> > but I get a 'No suitable implementation found for initializing OpenGL >>>> context for your platform'. >>>> > It seems that NBGLContextDriver does not have a subclass for Windows >>>> 64bits. Did I omit something? >>>> > >>>> > Cheers >>>> > Ricky >>>> > >>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >> > > > -- > Best regards, > Igor Stasenko. > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > > >

Nov. 14, 2013

Re: [Pharo-users] Thread safe queue like collection

by GÃ¶ran Krampe

On 11/13/2013 08:30 PM, Sven Van Caekenberghe wrote: > Yes, I have used it, even extended it. > It looks thread safe, so it should be enough to get started. If you are after something that is more like an in memory SocketStream then you have the SharedStreams package which I wrote a long time ago, it is actually pretty cool: http://map.squeak.org/packagebyname/sharedstreams I recall that we did find several "holes" in SharedQueue at the time. SharedStreams also use more fitting prims for characters/bytes. regards, GÃ¶ran

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by StÃ©phane Ducasse

>> >> Right now it cannot even be loaded into 3.0. >> But update is simple (i think JB did that already, just not published?). > Grrr, all my code are published ^^. Where? When did you announce it? Sorry but how can you expect guys from the other part of the planet to know it. Communication in open-source is important because people do not know what others are doing. You know richie asked and ronie too and they are smart guys. But they cannot guess. > For mac: > I do the change for mac last month because I needed it, it is integrated. ah ok this is why it is working on mac. > For linux: > I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. > On my roommate computer that work (ubuntu ). > But I need feedback. oki we will check that tomorrow I hope. > For windows: > I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. > I was planned to go test and debug on my home computer (window 7, 64), tomorrow. Ok we can say it to ronie to have a look. > So, you can expect a fix integrated soon. > > And having a working OpenGL, exactly as it work in pharo 2.0. Excellent. > > >> >>> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. >> >> Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). >> Because Roassal 3d should not be about shadder but about 3D. >> >>> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). >> >> Yes they changed the API and deprecated the old way of doing it. > > I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. > > >>> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. >> >> See below >> >>> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. >> > >> Three remarks: >> - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL > > Shader part are done for now. > >> - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying >> on other people and probably frustrated when things are not working. > + 1 > >> - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) >> a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you >> can get >> https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ > >> > > yes, my bad. > >> Now again if nobody builds a jun like library in Pharo it will not exist. > >> >> Stef >> >> >> >>> Cheers >>> Ricky >>> >>> >>> >>> >>> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi, >>> >>> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >>> >>> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Richard >>> >>> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >>> and his code should be split in two and one part should go to NBOpenGL. >>> Now he is experiencing some problem with NBOpenGL on windows as you. >>> >>> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >>> he does not have fun there). >>> >>> So it is important that you help because we are FULL >>> and sorry about that but really FULL. >>> >>> Ronie will visit us in January and share an office with igor. >>> >>> Stef >>> >>> >>> > Hi >>> > >>> > CodeCity, the project I am working on is based on NBOpenGL. >>> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >>> > >>> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >>> > >>> > GLTTRenderingDemo new openInWorld. >>> > >>> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >>> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >>> > >>> > Cheers >>> > Ricky >>> > >>> >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > >

Nov. 14, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Jean Baptiste Arnaud

On Nov 13, 2013, at 2:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 13 November 2013 11:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > JB can you read and reply to this mail? > >> Hi >> >> What Doru wrote pretty much sums it up. >> >> CodeCity under VW was based on JUN, which provided a programmer-friendly API built on top of OpenGL. Since there is no such thing under Pharo, when I later started to work on CodeCity under Pharo, I needed to learn about how to program directly to OpenGL. And the only example I had for that was SourceCity. In the meantime I manage to get a grip on my basic needs and was ready to move forward to implementing CodeCity. Now that does not work anymore in Pharo 3.0 so I am stuck. I could continue to program under Pharo 2.0, but what's the point? > > for now probably, because if you that is the one the most interested guy in that does not have the time to understand why others that > do not need 3D should do it. NBOpenGL was a side project to give a try of busy people too. I'm sorry to say that > but we cannot be on all fronts especially when they are changing. > > So can you tell us if you see what changed between 2 and 3. I have no idea. > > > NBOpenGL needs to be updated to sync with changes in NB about NBExternalStructure. The problem of openGL on pharo 3 is exactly what Igor says. But Montecello should be able to manage that. + small update of the code for linux and windows (maybe maybe not, I will see tomorrow). > Right now it cannot even be loaded into 3.0. > But update is simple (i think JB did that already, just not published?). Grrr, all my code are published ^^. For mac: I do the change for mac last month because I needed it, it is integrated. For linux: I fix, published, tested and updated the configuration for linux 2 days ago, because Alex ask me. On my roommate computer that work (ubuntu ). But I need feedback. For windows: I publish a fix for window yesterday:NBOpenGL-Win-jeanbaptistearnaud.9 but I do not update configuration because I cannot test it. I was planned to go test and debug on my home computer (window 7, 64), tomorrow. So, you can expect a fix integrated soon. And having a working OpenGL, exactly as it work in pharo 2.0. > >> I have already looked at Roassal 3d, but it was not easy to separate the API from the code. > > Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). > Because Roassal 3d should not be about shadder but about 3D. > >> And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). > > Yes they changed the API and deprecated the old way of doing it. I will also publish some example (using shadder) that I wrote but it is still not yet user friendly. >> So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. > > See below > >> Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. > > Three remarks: > - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL Shader part are done for now. > - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying > on other people and probably frustrated when things are not working. + 1 > - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) > a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you > can get > https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk \ > yes, my bad. > Now again if nobody builds a jun like library in Pharo it will not exist. > > Stef > > > >> Cheers >> Ricky >> >> >> >> >> On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). >> >> I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? >> >> Cheers, >> Doru >> >> >> >> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Richard >> >> you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) >> and his code should be split in two and one part should go to NBOpenGL. >> Now he is experiencing some problem with NBOpenGL on windows as you. >> >> NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that >> he does not have fun there). >> >> So it is important that you help because we are FULL >> and sorry about that but really FULL. >> >> Ronie will visit us in January and share an office with igor. >> >> Stef >> >> >> > Hi >> > >> > CodeCity, the project I am working on is based on NBOpenGL. >> > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. >> > >> > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: >> > >> > GLTTRenderingDemo new openInWorld. >> > >> > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. >> > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? >> > >> > Cheers >> > Ricky >> > >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > > -- > Best regards, > Igor Stasenko. Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Nov. 14, 2013

Re: [Pharo-users] PetitParser and external streams

by Norbert Hartl

> Am 13.11.2013 um 18:19 schrieb "Sean P. DeNigris" <sean(a)clipperadams.com>: > > Norbert Hartl wrote >> Producing the output immediately often has the drawback that it is hard to >> alter the stream in between... > > I've had success outputting-as-I-go in the ==> block, instead of, or in > addition to returning the token... > > Can you provide an example? Because I can not imagine how you can determine that you can output something to stream before knowing if the combined expression levels higher matches at all. norbert > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/PetitParser-and-external-streams-tp4721440p4721814.ht… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Nov. 13, 2013

Re: [Pharo-users] Message naming

by StÃ©phane Ducasse

> Kilon, great reflection. > We should have Pharo display Pharo Zen as exposed in Pharo Vision: :) > Pharo Zen > > Our values and convictions are condensed in this simple list. > > Easy to understand, easy to learn from, easy to change. Objects all the way down. > Examples to learn from. > Fully dynamic and malleable. > > Beauty in the code, beauty in the comments. > Simplicity is the ultimate elegance. > Better a set of small polymorphic classes than a large ugly one. Classes structure our vocabulary. > Messages are our vocabulary. > Polymorphism is our esperanto. > Abstraction and composition are our friends. > Tests are important but can be changed. > Explicit is better than implicit. > Magic only at the right place. > One step at a time. > There is no unimportant fix. > Learning from mistakes. > Perfection can kill movement. > Quality is a emerging property. > Simple processes to support progress. > Communication is key. > A system with robust abstractions that a single person can understand. > > > > :D > > best > > nacho > > > > Lic. Ignacio Sniechowski, MBA > > > > > > > > On Wed, Nov 13, 2013 at 11:57 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > I dont know exactly what you mean by eforced OOP by design. Pharo design principles are not written in stone, just good habits people picked along the way and they are to be found in python as well. Python actually takes OO very deply , sure if , else, while are language constructs but rest assured that everything else is an object. For example unlike Pharo , python allows to do procedural programming , but python functions are objects in disguise . You could say that python functions work similarly (but not the same , since closures are not supported in python) to Pharo blocks. > > Ruby is even closer to Pharo, supporting blocks, message passing etc. Also those kind of languages take clean design in code, very seriously. Just go to python interpreter console and do "import this" and you will see the zen of python unfold before your eyes emphasizing the good design principles you will find many smalltalkers talking about. Another language taking these principles very seriously is Lisp, actually Smalltalk took a lot from lisp in terms of overall design and direction. > > Of course clean code in the end is a choice , there is no enforcement, you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no capital punishment for coders that don't follow these principles. Many coders care only for getting the job done and feel like they dont have time to worry about how clean their code is. Its a free world, or so we hope. > > On the other hand everything should be put into context and never taken as the Holy Bible or Holy Grail. > > > On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > @Sven > > There is not necessarily a right and a wrong way. Design is hard to > > explain, I am not going to try. Sorry ;-) > > Of course! I was just trying to find out the design *norm* for a small > problem; to become familiar with the popular way of thought among > Smalltalk'ers. > > @kilon > Thanks. I think that may be what I need: real world examples. > > As I have already admitted, I am not used to Smalltalk way of thinking. > This is the first language I know, that enforces OOP by design, none of > Java, Python, C++ or Scala does. It's ironic; OOP concepts and > techniques were among the first things I was taught back in University > but now the more I think about Smalltalk's syntax and design, the more I > get closer to the conclusion that I didn't use pure OOP many times > during my career. And, I believe, it was simply because the development > platforms never enforced it the way Smalltalk does: in a clever and > camouflaged way. > > > But please do have a look at the Chronos library, it even has a > PersianCalender, among many others. > > I knew about Chronos. Someone here, kindly suggested it about 6 months > ago when I asked about such a thing. I'm not trying to re-write > something like Chronos rather I'm trying to get my hands dirty with > Pharo and also re-visit my OOP skills. Thanks. > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > > > > > >

Nov. 13, 2013

Re: [Pharo-users] A question concerning fonts

by Sven Van Caekenberghe

For an example: http://forum.world.st/Unicode-Fonts-tc4654865.html On 13 Nov 2013, at 20:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Mateusz, > > On 13 Nov 2013, at 20:17, Mateusz Grotek <unoduetre(a)poczta.onet.pl> wrote: > >> Hi, >> Is it possible to use nonascii/nonenglish characters in a workspace and >> browser. I have changed the font, but I still get question marks... >> >> Pharo1.3 >> Latest update: #13327 >> >> Seaside 3.07 One-Click image from here: >> http://www.seaside.st/distributions/Seaside-3.0.7-OneClick.zip >> >> Mateusz Grotek > > You can try enabling FreeType fonts and selecting a font that can display more characters, like Arial Unicode MS. > > HTH, > > Sven >

Nov. 13, 2013

Re: [Pharo-users] A question concerning fonts

by Sven Van Caekenberghe

Hi Mateusz, On 13 Nov 2013, at 20:17, Mateusz Grotek <unoduetre(a)poczta.onet.pl> wrote: > Hi, > Is it possible to use nonascii/nonenglish characters in a workspace and > browser. I have changed the font, but I still get question marks... > > Pharo1.3 > Latest update: #13327 > > Seaside 3.07 One-Click image from here: > http://www.seaside.st/distributions/Seaside-3.0.7-OneClick.zip > > Mateusz Grotek You can try enabling FreeType fonts and selecting a font that can display more characters, like Arial Unicode MS. HTH, Sven

Nov. 13, 2013

Re: [Pharo-users] Thread safe queue like collection

by Sven Van Caekenberghe

Yes, I have used it, even extended it. It looks thread safe, so it should be enough to get started. On 13 Nov 2013, at 20:08, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I guess SharedQueue will do it, have you (or anybody) tested it in the context of real multi threaded use? > > It is too soon for me to think of a real MQ (with STOMP). > > Regards! > > Esteban A. Maringolo > > > 2013/11/13 Sven Van Caekenberghe <sven(a)stfx.eu> > SharedQueue ? > > On 13 Nov 2013, at 19:16, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > Hi, > > > > Do Pharo 2 have some sort of queue like collection, where different threads (coming mostly from a Multithread Zinc Server) can push objects into it safely, while a service on the other end can consume the queue? > > > > Regards, > > > > Esteban A. Maringolo > > >

Nov. 13, 2013

A question concerning fonts

by Mateusz Grotek

Hi, Is it possible to use nonascii/nonenglish characters in a workspace and browser. I have changed the font, but I still get question marks... Pharo1.3 Latest update: #13327 Seaside 3.07 One-Click image from here: http://www.seaside.st/distributions/Seaside-3.0.7-OneClick.zip Mateusz Grotek

Nov. 13, 2013

Re: [Pharo-users] Thread safe queue like collection

by Esteban A. Maringolo

I guess SharedQueue will do it, have you (or anybody) tested it in the context of real multi threaded use? It is too soon for me to think of a real MQ (with STOMP). Regards! Esteban A. Maringolo 2013/11/13 Sven Van Caekenberghe <sven(a)stfx.eu> > SharedQueue ? > > On 13 Nov 2013, at 19:16, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > Hi, > > > > Do Pharo 2 have some sort of queue like collection, where different > threads (coming mostly from a Multithread Zinc Server) can push objects > into it safely, while a service on the other end can consume the queue? > > > > Regards, > > > > Esteban A. Maringolo > > >

Nov. 13, 2013

Re: [Pharo-users] Thread safe queue like collection

by Sven Van Caekenberghe

SharedQueue ? On 13 Nov 2013, at 19:16, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Hi, > > Do Pharo 2 have some sort of queue like collection, where different threads (coming mostly from a Multithread Zinc Server) can push objects into it safely, while a service on the other end can consume the queue? > > Regards, > > Esteban A. Maringolo

Nov. 13, 2013

Thread safe queue like collection

by Esteban A. Maringolo

Hi, Do Pharo 2 have some sort of queue like collection, where different threads (coming mostly from a Multithread Zinc Server) can push objects into it safely, while a service on the other end can consume the queue? Regards, Esteban A. Maringolo

Nov. 13, 2013

Re: [Pharo-users] PetitParser and external streams

by Sean P. DeNigris

Norbert Hartl wrote > Producing the output immediately often has the drawback that it is hard to > alter the stream in between... I've had success outputting-as-I-go in the ==> block, instead of, or in addition to returning the token... ----- Cheers, Sean -- View this message in context: http://forum.world.st/PetitParser-and-external-streams-tp4721440p4721814.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 13, 2013

Re: [Pharo-users] Message naming

by kilon alios

What I tried to say here was that it was a mistake to blame the language itself for code design. Sure a language may have some ugly sides to it, it may even make it not so easy to create clean code but in the end of the day clean and readable code is up to the coder at least 90% . I would not say that there are subtle differences between Python and Java , Ruby and Scala just by themselves. The differences are quite big actually. My point was that good design is something that many if not most languages promote. Why ? Because nobody likes ugly code. Actually most java developers hate long names for methods, there is even a quora question on the subject that many Java coders express their frustration on the subject. For example your naming issues is pretty much the foundation of design of Python's Standard Library , one of the most respected included libraries in the programming world. This is the zen of python : Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! As you can see obviously from this Zen , long names and monolithic approaches are out of the door. So if you think that python would motivate you to use long names for methods , then you are easily mistaken and you better ask some python coders what they think a "pythonic" code really looks like. You will be suprized how much common ground you will find with Pharo people. I am willing to bet Ruby folks will be even more inclined to follow smalltalk values since their language was largely based on smalltalk. Ignacio, I think its a great idea to have a Zen as a community. In the python world its started as a joke, then it was viewed as a serious joke, currently is viewed as something so serious, that if a library does not follow it its regarded as "unpythonic" and believe me no python coder wants his code to be called unpythonic. So even though the zen is not very specific I think it clearly shows the direction of what python community considers as good code. Should Pharo have something similar ? its certainly should have. I think its important to have values, to aspire to create better designed code, to not repeat the mistakes of the past or mistakes of others, to pass knowledge and experience around. The trend for modern coding is to move closer to this area, smaller libraries are in favor instead of large libs, documentation plays a much more important role, OO mixed with other paradigms like functional programming etc gives even more freedom of choice, the rule of least surprise is followed more and more. Where some see smalltalk as a dead or niche language, I see it being used everywhere and by everyone to lesser or bigger degree. This is is our future. On Wed, Nov 13, 2013 at 5:29 PM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > Kilon, I believe there's a subtle difference between Python, Java, Ruby > and Scala on one side and Smalltalk on the other: > All those 4 languages are more or less implemented as OO languages with > the famous statement "everything is an object". However they are > syntactically and semantically designed in a way that they allow a not OO > design to be coded. Just imagine the small problem I shared in this > thread; in any of those languages I can do it with one class and a couple > of static methods and the code will definitely *read and work naturally > correct*. > > On the other hand, consider Smalltalk: "everything is an object", but the > syntax and semantics of the language is different. Yes, it allows a not OO > design to be coded but there's a difference: think about my small problem > again. The moment I thought about coding it the old style (single class > with static methods) something started to smell. It smelled so bad that I > had to consult you folks. > > That's what I'm talking about: a tiny but subtle and well thought out > difference in the syntax and semantics and it makes a huge difference. > > Another example: > I -like all of you- had studied, heard, read and practiced bottom-to-top > design and I thought I knew what it meant. However, the moment I started > coding in Lisp I found out I knew little about that paradigm. The natural > subtle semantic design of Lisp made it a natural bottom-to-top platform > nothing like any other platform I had seen until then. > > > > On 11/13/2013 18:27, kilon alios wrote: > > I dont know exactly what you mean by eforced OOP by design. Pharo design > principles are not written in stone, just good habits people picked along > the way and they are to be found in python as well. Python actually takes > OO very deply , sure if , else, while are language constructs but rest > assured that everything else is an object. For example unlike Pharo , > python allows to do procedural programming , but python functions are > objects in disguise . You could say that python functions work similarly > (but not the same , since closures are not supported in python) to Pharo > blocks. > > Ruby is even closer to Pharo, supporting blocks, message passing etc. > Also those kind of languages take clean design in code, very seriously. > Just go to python interpreter console and do "import this" and you will see > the zen of python unfold before your eyes emphasizing the good design > principles you will find many smalltalkers talking about. Another language > taking these principles very seriously is Lisp, actually Smalltalk took a > lot from lisp in terms of overall design and direction. > > Of course clean code in the end is a choice , there is no enforcement, > you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There > is no capital punishment for coders that don't follow these principles. > Many coders care only for getting the job done and feel like they dont have > time to worry about how clean their code is. Its a free world, or so we > hope. > > On the other hand everything should be put into context and never taken > as the Holy Bible or Holy Grail. > > > On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com>wrote: > >> @Sven >> > There is not necessarily a right and a wrong way. Design is hard to >> > explain, I am not going to try. Sorry ;-) >> >> Of course! I was just trying to find out the design *norm* for a small >> problem; to become familiar with the popular way of thought among >> Smalltalk'ers. >> >> @kilon >> Thanks. I think that may be what I need: real world examples. >> >> As I have already admitted, I am not used to Smalltalk way of thinking. >> This is the first language I know, that enforces OOP by design, none of >> Java, Python, C++ or Scala does. It's ironic; OOP concepts and >> techniques were among the first things I was taught back in University >> but now the more I think about Smalltalk's syntax and design, the more I >> get closer to the conclusion that I didn't use pure OOP many times >> during my career. And, I believe, it was simply because the development >> platforms never enforced it the way Smalltalk does: in a clever and >> camouflaged way. >> >> > But please do have a look at the Chronos library, it even has a >> PersianCalender, among many others. >> >> I knew about Chronos. Someone here, kindly suggested it about 6 months >> ago when I asked about such a thing. I'm not trying to re-write >> something like Chronos rather I'm trying to get my hands dirty with >> Pharo and also re-visit my OOP skills. Thanks. >> >> > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 13, 2013

Re: [Pharo-users] Add menu item to Nautilus context menu on selected packages?

by Benjamin

You can give them a priority, then it depends of the other items :) Ben On 13 Nov 2013, at 17:31, MartinW <wm(a)fastmail.fm> wrote: > Quite easy indeed. Thank you. > Is there any system behing the ordering of menu entries? > > Martin. > > > Benjamin Van Ryseghem-2 wrote >> It is :) >> And I would even say it is not complicated :P >> >>> So far i added a wizard to the world menu, but i would rather add a menu >>> item to the Nautilus context menu on selected packages - is this >>> possible? > > > > > > -- > View this message in context: http://forum.world.st/Add-menu-item-to-Nautilus-context-menu-on-selected-pa… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Nov. 13, 2013

Re: [Pharo-users] Add menu item to Nautilus context menu on selected packages?

by MartinW

Quite easy indeed. Thank you. Is there any system behing the ordering of menu entries? Martin. Benjamin Van Ryseghem-2 wrote > It is :) > And I would even say it is not complicated :P > >> So far i added a wizard to the world menu, but i would rather add a menu >> item to the Nautilus context menu on selected packages - is this >> possible? -- View this message in context: http://forum.world.st/Add-menu-item-to-Nautilus-context-menu-on-selected-pa… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Ignacio MatÃas Sniechowski

Kilon, great reflection. We should have Pharo display Pharo Zen as exposed in Pharo Vision: Pharo Zen Our values and convictions are condensed in this simple list. Easy to understand, easy to learn from, easy to change. Objects all the way down. Examples to learn from. Fully dynamic and malleable. Beauty in the code, beauty in the comments. Simplicity is the ultimate elegance. Better a set of small polymorphic classes than a large ugly one. Classes structure our vocabulary. Messages are our vocabulary. Polymorphism is our esperanto. Abstraction and composition are our friends. Tests are important but can be changed. Explicit is better than implicit. Magic only at the right place. One step at a time. There is no unimportant fix. Learning from mistakes. Perfection can kill movement. Quality is a emerging property. Simple processes to support progress. Communication is key. A system with robust abstractions that a single person can understand. :D best nacho *Lic. Ignacio Sniechowski, MBA* On Wed, Nov 13, 2013 at 11:57 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > I dont know exactly what you mean by eforced OOP by design. Pharo design > principles are not written in stone, just good habits people picked along > the way and they are to be found in python as well. Python actually takes > OO very deply , sure if , else, while are language constructs but rest > assured that everything else is an object. For example unlike Pharo , > python allows to do procedural programming , but python functions are > objects in disguise . You could say that python functions work similarly > (but not the same , since closures are not supported in python) to Pharo > blocks. > > Ruby is even closer to Pharo, supporting blocks, message passing etc. Also > those kind of languages take clean design in code, very seriously. Just go > to python interpreter console and do "import this" and you will see the zen > of python unfold before your eyes emphasizing the good design principles > you will find many smalltalkers talking about. Another language taking > these principles very seriously is Lisp, actually Smalltalk took a lot from > lisp in terms of overall design and direction. > > Of course clean code in the end is a choice , there is no enforcement, you > will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no > capital punishment for coders that don't follow these principles. Many > coders care only for getting the job done and feel like they dont have time > to worry about how clean their code is. Its a free world, or so we hope. > > On the other hand everything should be put into context and never taken as > the Holy Bible or Holy Grail. > > > On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com>wrote: > >> @Sven >> > There is not necessarily a right and a wrong way. Design is hard to >> > explain, I am not going to try. Sorry ;-) >> >> Of course! I was just trying to find out the design *norm* for a small >> problem; to become familiar with the popular way of thought among >> Smalltalk'ers. >> >> @kilon >> Thanks. I think that may be what I need: real world examples. >> >> As I have already admitted, I am not used to Smalltalk way of thinking. >> This is the first language I know, that enforces OOP by design, none of >> Java, Python, C++ or Scala does. It's ironic; OOP concepts and >> techniques were among the first things I was taught back in University >> but now the more I think about Smalltalk's syntax and design, the more I >> get closer to the conclusion that I didn't use pure OOP many times >> during my career. And, I believe, it was simply because the development >> platforms never enforced it the way Smalltalk does: in a clever and >> camouflaged way. >> >> > But please do have a look at the Chronos library, it even has a >> PersianCalender, among many others. >> >> I knew about Chronos. Someone here, kindly suggested it about 6 months >> ago when I asked about such a thing. I'm not trying to re-write >> something like Chronos rather I'm trying to get my hands dirty with >> Pharo and also re-visit my OOP skills. Thanks. >> >> -- >> Bahman Movaqar (http://BahmanM.com) >> >> ERP Evaluation, Implementation & Deployment Consultant >> PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) >> >> >> >> >> >

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Bahman Movaqar

Kilon, I believe there's a subtle difference between Python, Java, Ruby and Scala on one side and Smalltalk on the other: All those 4 languages are more or less implemented as OO languages with the famous statement "everything is an object". However they are syntactically and semantically designed in a way that they allow a not OO design to be coded. Just imagine the small problem I shared in this thread; in any of those languages I can do it with one class and a couple of static methods and the code will definitely *read and work naturally correct*. On the other hand, consider Smalltalk: "everything is an object", but the syntax and semantics of the language is different. Yes, it allows a not OO design to be coded but there's a difference: think about my small problem again. The moment I thought about coding it the old style (single class with static methods) something started to smell. It smelled so bad that I had to consult you folks. That's what I'm talking about: a tiny but subtle and well thought out difference in the syntax and semantics and it makes a huge difference. Another example: I -like all of you- had studied, heard, read and practiced bottom-to-top design and I thought I knew what it meant. However, the moment I started coding in Lisp I found out I knew little about that paradigm. The natural subtle semantic design of Lisp made it a natural bottom-to-top platform nothing like any other platform I had seen until then. On 11/13/2013 18:27, kilon alios wrote: > I dont know exactly what you mean by eforced OOP by design. Pharo > design principles are not written in stone, just good habits people > picked along the way and they are to be found in python as well. > Python actually takes OO very deply , sure if , else, while are > language constructs but rest assured that everything else is an > object. For example unlike Pharo , python allows to do procedural > programming , but python functions are objects in disguise . You could > say that python functions work similarly (but not the same , since > closures are not supported in python) to Pharo blocks. > > Ruby is even closer to Pharo, supporting blocks, message passing etc. > Also those kind of languages take clean design in code, very > seriously. Just go to python interpreter console and do "import this" > and you will see the zen of python unfold before your eyes emphasizing > the good design principles you will find many smalltalkers talking > about. Another language taking these principles very seriously is > Lisp, actually Smalltalk took a lot from lisp in terms of overall > design and direction. > > Of course clean code in the end is a choice , there is no enforcement, > you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . > There is no capital punishment for coders that don't follow these > principles. Many coders care only for getting the job done and feel > like they dont have time to worry about how clean their code is. Its a > free world, or so we hope. > > On the other hand everything should be put into context and never > taken as the Holy Bible or Holy Grail. > > > On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com > <mailto:Bahman@bahmanm.com>> wrote: > > @Sven > > There is not necessarily a right and a wrong way. Design is hard to > > explain, I am not going to try. Sorry ;-) > > Of course! I was just trying to find out the design *norm* for a > small > problem; to become familiar with the popular way of thought among > Smalltalk'ers. > > @kilon > Thanks. I think that may be what I need: real world examples. > > As I have already admitted, I am not used to Smalltalk way of > thinking. > This is the first language I know, that enforces OOP by design, > none of > Java, Python, C++ or Scala does. It's ironic; OOP concepts and > techniques were among the first things I was taught back in University > but now the more I think about Smalltalk's syntax and design, the > more I > get closer to the conclusion that I didn't use pure OOP many times > during my career. And, I believe, it was simply because the > development > platforms never enforced it the way Smalltalk does: in a clever and > camouflaged way. > > > But please do have a look at the Chronos library, it even has a > PersianCalender, among many others. > > I knew about Chronos. Someone here, kindly suggested it about 6 > months > ago when I asked about such a thing. I'm not trying to re-write > something like Chronos rather I'm trying to get my hands dirty with > Pharo and also re-visit my OOP skills. Thanks. > -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 13, 2013

Re: [Pharo-users] PetitParser and external streams

by Norbert Hartl

Am 13.11.2013 um 13:15 schrieb Federico.Balaguer <federico.balaguer(a)gmail.com>: > Thanks Norbert for your kind reply. > > My only reminding question is about the input. PetitStream are made from the > contents of another stream. So, if I have a readStream on a file and I > convert it to PetitStream, it will end up loading the entire content of the > file on memory. > > Could it be possible to use a "LazyPetitStream" that is getting the content > from the original stream incrementally? > I donât think so. What I said in my last mail is valid for the input stream as well. Parsing is about trying to match some content in multiple ways. This implies that you need to check if something matches and if it fails try matching something else. That also means you need to backtrack or better you need to get back and forth within a stream. This makes streaming less an option because youâll always need to buffer and the buffer is likely to be as big as the whole content. I donât know what you are trying to achieve but probably there is another solution. Your mail sounds as you are concerned about memory consumption. Assuming further it is probably not a single entity you try to parse but a list of the same entity. In the case you could leave out the outermost star or plus parser and use the parser for a single entity until the end of the stream. So you would use the parser multiple times producing smaller chunks in memory. Hope this helps, Norbert

Nov. 13, 2013

Re: [Pharo-users] Message naming

by kilon alios

I dont know exactly what you mean by eforced OOP by design. Pharo design principles are not written in stone, just good habits people picked along the way and they are to be found in python as well. Python actually takes OO very deply , sure if , else, while are language constructs but rest assured that everything else is an object. For example unlike Pharo , python allows to do procedural programming , but python functions are objects in disguise . You could say that python functions work similarly (but not the same , since closures are not supported in python) to Pharo blocks. Ruby is even closer to Pharo, supporting blocks, message passing etc. Also those kind of languages take clean design in code, very seriously. Just go to python interpreter console and do "import this" and you will see the zen of python unfold before your eyes emphasizing the good design principles you will find many smalltalkers talking about. Another language taking these principles very seriously is Lisp, actually Smalltalk took a lot from lisp in terms of overall design and direction. Of course clean code in the end is a choice , there is no enforcement, you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no capital punishment for coders that don't follow these principles. Many coders care only for getting the job done and feel like they dont have time to worry about how clean their code is. Its a free world, or so we hope. On the other hand everything should be put into context and never taken as the Holy Bible or Holy Grail. On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > @Sven > > There is not necessarily a right and a wrong way. Design is hard to > > explain, I am not going to try. Sorry ;-) > > Of course! I was just trying to find out the design *norm* for a small > problem; to become familiar with the popular way of thought among > Smalltalk'ers. > > @kilon > Thanks. I think that may be what I need: real world examples. > > As I have already admitted, I am not used to Smalltalk way of thinking. > This is the first language I know, that enforces OOP by design, none of > Java, Python, C++ or Scala does. It's ironic; OOP concepts and > techniques were among the first things I was taught back in University > but now the more I think about Smalltalk's syntax and design, the more I > get closer to the conclusion that I didn't use pure OOP many times > during my career. And, I believe, it was simply because the development > platforms never enforced it the way Smalltalk does: in a clever and > camouflaged way. > > > But please do have a look at the Chronos library, it even has a > PersianCalender, among many others. > > I knew about Chronos. Someone here, kindly suggested it about 6 months > ago when I asked about such a thing. I'm not trying to re-write > something like Chronos rather I'm trying to get my hands dirty with > Pharo and also re-visit my OOP skills. Thanks. > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > > > > >

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Bahman Movaqar

@Sven > There is not necessarily a right and a wrong way. Design is hard to > explain, I am not going to try. Sorry ;-) Of course! I was just trying to find out the design *norm* for a small problem; to become familiar with the popular way of thought among Smalltalk'ers. @kilon Thanks. I think that may be what I need: real world examples. As I have already admitted, I am not used to Smalltalk way of thinking. This is the first language I know, that enforces OOP by design, none of Java, Python, C++ or Scala does. It's ironic; OOP concepts and techniques were among the first things I was taught back in University but now the more I think about Smalltalk's syntax and design, the more I get closer to the conclusion that I didn't use pure OOP many times during my career. And, I believe, it was simply because the development platforms never enforced it the way Smalltalk does: in a clever and camouflaged way. > But please do have a look at the Chronos library, it even has a PersianCalender, among many others. I knew about Chronos. Someone here, kindly suggested it about 6 months ago when I asked about such a thing. I'm not trying to re-write something like Chronos rather I'm trying to get my hands dirty with Pharo and also re-visit my OOP skills. Thanks. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 13, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Igor Stasenko

On 13 November 2013 12:02, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>wrote: > Thanks a lot Torsten! > > I'll invest the whole morning tomorrow in trying to get a little bit more > of this to work. > > If I don't succeed... there are lots of very good restaurants in > Barcelona, Igor ;) > > i can imagine :) I hope i will be able come there once more one day. Barcelona is very beautiful city. :) > 2013/11/13 Torsten Bergmann <astares(a)gmx.de> > >> Hi Bernat, >> >> >how do I translate this into NB code >> >> Either invite Igor (author of NB) for lunch or try this: >> >> >> Its a C-structure, you convert it by wrapping this in a sublcass >> of "NBExternalStructure". See the examples already in a Pharo 3.0 image. >> >> Basically you need: >> >> - define a subclass NBExternalStructure subclass: #WinNotifyIconData ... >> - define the correct fields in a class side #fieldsDesc method according >> to the native data types used in the structure >> - call "WinNotifyIconData rebuildFieldAccessors" >> - setup the types in a shared pool that you can include later: >> >> - define the pool: SharedPool subclass: #WinTryIconConstants ... >> - in a class initialize method you can setup the type >> >> initialize >> >> NOTIFYICONDATA := #WinNotifyIconData. >> PNOTIFYICONDATA:= 'NOTIFYICONDATA *'. >> >> - by including the pool you can use "NOTIFYICONDATA" or "PNOTIFYICONDATA" >> in any native boost call. >> >> >> If you are in Pharo 3.0 load "OS-Windows" package from the config browser. >> Check the subclasses of NBExternalStructure there. >> >> I wrapped many other windows structures already so you can get an idea >> about >> it. For instance have a look at WinConsoleConstants>>initTypeConstants, >> there you will find >> the CONSOLE_CURSOR_INFO, CONSOLE_SCREEN_BUFFER_INFO structs wrapped in >> WinConsoleCursor, WinConsoleScreenBuffer classes. >> >> Compare them with the MSDN struct description. >> >> >Could the Windows API be any more convoluted and dev-unfriendly in any >> >possible sense? >> >> This question should go to M$ not Pharo-user ;) >> >> Bye >> T. >> >> >> BTW: I'm not sure "PNOTIFYICONDATA" alone will solve your problem if I >> remember correctly >> from my Smalltalk/MT and C/C++ times also playing with tray icons. >> I guess you need a callback that gets called when the icon is >> clicked or the tray icon menu >> is choosen (see uCallbackMessage member in the struct). >> You also need a handle to an icon - either the icon from the EXEs >> resource section or >> by loading one from a bitmap. That means wrapping the icon or bitmap >> apis too... >> >> > > > -- > Bernat Romagosa. > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Igor Stasenko

On 13 November 2013 11:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > JB can you read and reply to this mail? > > Hi > > What Doru wrote pretty much sums it up. > > CodeCity under VW was based on JUN, which provided a programmer-friendly > API built on top of OpenGL. Since there is no such thing under Pharo, when > I later started to work on CodeCity under Pharo, I needed to learn about > how to program directly to OpenGL. And the only example I had for that was > SourceCity. In the meantime I manage to get a grip on my basic needs and > was ready to move forward to implementing CodeCity. Now that does not work > anymore in Pharo 3.0 so I am stuck. I could continue to program under Pharo > 2.0, but what's the point? > > > for now probably, because if you that is the one the most interested guy > in that does not have the time to understand why others that > do not need 3D should do it. NBOpenGL was a side project to give a try of > busy people too. I'm sorry to say that > but we cannot be on all fronts especially when they are changing. > > So can you tell us if you see what changed between 2 and 3. I have no idea. > > NBOpenGL needs to be updated to sync with changes in NB about NBExternalStructure. Right now it cannot even be loaded into 3.0. But update is simple (i think JB did that already, just not published?). > I have already looked at Roassal 3d, but it was not easy to separate the > API from the code. > > > Strange because even me I could see that the shadder code should not be in > Roassal 3D but in NBOpenGL :). > Because Roassal 3d should not be about shadder but about 3D. > > And it is something completely different than what I have been using (and > SourceCity, too), because Roassal 3d is using the modern OpenGL methodology > (with FBOs and stuff). > > > Yes they changed the API and deprecated the old way of doing it. > > So, I would really appreciate if that API would find its way from Roassal > to NBOpenGL and I could use it for CodeCity. > > > See below > > Unfortunately I am able to help a lot with that, because I know very > little about this and I also don't have enough time (I am doing CodeCity in > my spare time). But, if you have concrete things that I can do, I'd be > happy to help. > > > Three remarks: > - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL > - I'm not sure that doing 3d without investing a bit in the underlying > technology is wise. Because you will be always relying > on other people and probably frustrated when things are not working. > - Since JB does not know how to communicate here is what he did for fun > instead of pushing MoosePython :) > a renderer to video to videos stream for openGL -> MKV, mp4 based one > ffmpeg). The code is openGL extra. As an example you > can get > https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk > > Now again if nobody builds a jun like library in Pharo it will not exist. > > Stef > > > > Cheers > Ricky > > > > > On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 >> and 3.0 such that this does not work anymore on Windows. The fact that he >> mentioned 64 bits is not relevant for this discussion :). >> >> I also guess he wants to put some effort into understanding this as well >> but he needs a bit of guidance. Right Ricky? >> >> Cheers, >> Doru >> >> >> >> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Richard >>> >>> you should have a look at ROASSAL 3d because ronie improved the shadder >>> part (no more assembler) >>> and his code should be split in two and one part should go to NBOpenGL. >>> Now he is experiencing some problem with NBOpenGL on windows as you. >>> >>> NativeBoost does not work on 64 bits. Yet but igor is really busy >>> finishing the texteditor (and I can tell you that >>> he does not have fun there). >>> >>> So it is important that you help because we are FULL >>> and sorry about that but really FULL. >>> >>> Ronie will visit us in January and share an office with igor. >>> >>> Stef >>> >>> >>> > Hi >>> > >>> > CodeCity, the project I am working on is based on NBOpenGL. >>> > I'd like to start working on it using Pharo 3, but it seems that >>> NBOpenGL does not work yet with Pharo 3.0. >>> > >>> > I downloaded from jenkins the latest image with Pharo 3 and tried to >>> execute the following code on Windows 7, 64 bits: >>> > >>> > GLTTRenderingDemo new openInWorld. >>> > >>> > but I get a 'No suitable implementation found for initializing OpenGL >>> context for your platform'. >>> > It seems that NBGLContextDriver does not have a subclass for Windows >>> 64bits. Did I omit something? >>> > >>> > Cheers >>> > Ricky >>> > >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Igor Stasenko

On 13 November 2013 10:25, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>wrote: > Hi list, > > I made some progress but I'm still a bit lost here. > > I managed to get Pharo to be headless in Win32, by hiding the window via > NB as Igor suggested, plus suspending the UI process (UIManager default > uiProcess suspend), which was the cause for the window to show up again > after a fraction of a second, because of the refresh interval. > > However, now I can only close Pharo by killing the process manually, which > is not very nice for the end user. So I figured I'd try to add an icon to > the system tray with a single context menu entry for closing Pharo. > > This is what I'm doing, taken from MSDN<http://msdn.microsoft.com/en-us/library/windows/desktop/bb762159(v=vs.85).a…> > : > > NBWin32Shell >> shellNotifyIcon: lpdata dwMessage: dwMessage > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ self nbCall: #(bool Shell_NotifyIcon( > > DWORD dwMessage, > > PNOTIFYICONDATA lpdata > > )) module: #shell32 > > dwMessage is just a 0 (flag to create a tray icon), but lpdata needs to be a > pointer to a struct of this form<http://msdn.microsoft.com/en-us/library/windows/desktop/bb773352(v=vs.85).a…> > : > > typedef struct _NOTIFYICONDATA { > DWORD cbSize; > HWND hWnd; > UINT uID; > UINT uFlags; > UINT uCallbackMessage; > HICON hIcon; > TCHAR szTip[64]; > DWORD dwState; > DWORD dwStateMask; > TCHAR szInfo[256]; > union { > UINT uTimeout; > UINT uVersion; > }; > TCHAR szInfoTitle[64]; > DWORD dwInfoFlags; > GUID guidItem; > HICON hBalloonIcon; > } NOTIFYICONDATA, *PNOTIFYICONDATA; > > > So, my question is: how do I translate this into NB code? How does one > define a struct and then pass its pointer to a function in NativeBoost? > > This is easy. Just make a subclass of NBExternalStructure, define its fields in #fieldsDesc method (see example subclass). Create it using #new, or #externalNew depending if structure should be non-moving in memory for the rest of its life (but i think its needed only at the moment of call, so #new should work), fill it with proper values, and then pass it to that function. Just make sure that argument type PNOTIFYICONDATA changed to class name of your structure in function signature. Also, note that there is two Shell_NotifyIcon functions under the hood: Shell_NotifyIconA Shell_NotifyIconW the 'A' stands for 'ascii', and 'W' stands for 'wide', this is how windows manages strings and characters/unicode. For 'A' functions TCHAR == char (1byte) for 'W' functions TCHAR == unsigned short (2bytes) that means the definition and size of PNOTIFYICONDATA is different depending on what function you going to be using. Thanks a lot for your help, I'm getting closer :) > > Bernat. > > p.s. Could the Windows API be any more convoluted and dev-unfriendly in > any possible sense? > hehe.. this is a typical for everything in windows: many, even basic things require passing and filling various structures with many different fields, and you may find that to initialize fields of one structure, you often need to create another one and initialize it first :) > > > 2013/11/4 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > >> Hi! >> >> Thanks Igor, that kinda worked! Pharo hides, but comes back after half a >> second or so. I'll keep digging, thanks! :) >> >> >> 2013/11/1 phil(a)highoctane.be <phil(a)highoctane.be> >> >> Well, this should rather be: >>> >>> handle :=NativeBoostWin32 squeakWindowHandle. >>> window := NBWin32Window new value: handle; yourself. >>> window hide. >>> >>> or >>> >>> window setWindowText: 'im a main window blablabla'. >>> >>> Phil >>> >>> >>> On Thu, Oct 31, 2013 at 10:03 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> You can try something like this: >>>> >>>> | handle window | >>>> >>>> handle := NativeBoost forCurrentPlatform squeakWindowHandle. >>>> window := NBWin32Window new value: handle; yourself. >>>> window hide. >>>> >>>> or >>>> >>>> window setWindowText: 'im a main window blablabla'. >>>> >>>> :) >>>> >>>> i didn't tested it since its been implemented, but i think it should >>>> work. >>>> >>>> >>>> >>>> On 30 October 2013 11:20, Bernat Romagosa < >>>> tibabenfortlapalanca(a)gmail.com> wrote: >>>> >>>>> In this direction, I'm trying to call a function in the shell32.dll >>>>> lib that apparently should let you minimize an app to the system tray, but >>>>> I'm not having much luck... I guess I don't really understand what am I >>>>> exactly doing. >>>>> >>>>> This is what I found in the MSDN<http://msdn.microsoft.com/en-us/library/bb762159%28VS.85%29.aspx> >>>>> : >>>>> >>>>> BOOL Shell_NotifyIcon( >>>>> _In_ DWORD dwMessage, >>>>> _In_ PNOTIFYICONDATA lpdata >>>>> ); >>>>> >>>>> >>>>> So, I tried to translate this into Pharo as: >>>>> >>>>> MyClass >> minimizeToTray: dwMessage data: lpData >>>>> >>>>> <apicall: bool 'Shell_NotifyIcon' (dword PNOTIFYICONDATA) module: >>>>> 'shell32.dll'> >>>>> >>>>> >>>>> But it won't let me save the method, reporting it's expecting an >>>>> argument before PNOTIFYICONDATA. >>>>> >>>>> I realize PNOTIFYICONDATA is not a primitive type, but I just don't >>>>> know how to handle it... :( >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Bernat Romagosa. >> > > > > -- > Bernat Romagosa. > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] PetitParser and external streams

by Federico.Balaguer

Thanks Norbert for your kind reply. My only reminding question is about the input. PetitStream are made from the contents of another stream. So, if I have a readStream on a file and I convert it to PetitStream, it will end up loading the entire content of the file on memory. Could it be possible to use a "LazyPetitStream" that is getting the content from the original stream incrementally? Thanks! Federico -- View this message in context: http://forum.world.st/PetitParser-and-external-streams-tp4721440p4721691.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Sven Van Caekenberghe

Hi Bahman, On 13 Nov 2013, at 09:19, Bahman Movaqar <Bahman(a)BahmanM.com> wrote: > On 11/13/2013 11:39, Bahman Movaqar wrote: >> On 11/13/2013 11:13, Bahman Movaqar wrote: >>> Let's say I have a method with signature in a language like Java as below: >>> gregorianDayToJulianDay(year, month, day) >>> >>> What could be a proper naming for this method in Smalltalk? I'm a bit >>> confused as I'm so used to the concept of methods being "verbs" which >>> accept some arguments. >>> >>> I'd appreciate any help/idea. > > After reading Sven's reply, I came up with this design. Is it the > idiomatic way to handle this problem in Smalltalk: > > <pseudo-design> > class JulianConverter: > instance variable: 'day' > > #toGregorian > #toIranian > > class GregorianConverter: > instance variable: 'year month day' > > #toJulian > > class IranianConverter: > instance variable: 'year month day' > > #toJulian > > </pseudo-design> There is not necessarily a right and a wrong way. Design is hard to explain, I am not going to try. Sorry ;-) But please do have a look at the Chronos library, it even has a PersianCalender, among many others. This is the class comment: [Chronos] All code (classes and methods, and all associated documentation,) distributed as part of the Chronos Date/Time library are Â¬Â© Copyright 2005-2006 by Alan L. Lovejoy. All Rights Reserved. Usage is controlled by the Chronos License (which is included in the distribution as the contents of the file {chronos-license.txt}, and is also available from the Chronos web site {http://www.chronos-st.org/License.html}) PersianCalendar Concept: PersianCalendar implements the arithmetical version of the Persian Calendar. There is also an astronomical version of the Persian Calendar, which some authorities claim is the one actually used in Iran, although other authorities claim otherwise. Chronos does not currently provide implementations of any astronomical calendars. The astronomical version of the Persian Calendar will (eventually) be implemented by class named AstronomicalPersianCalendar, whose registration key will be #'Persian-Astronomical'. For any and all discussion of what a 'Calendar' is conceptually, how an instance of a Calendar can and/or should be used, the general implementation requirements for subclasses of Calendar, or the architectural requirements and responsibilities of Calendar instances with respect to the rest of the Chronos Date/Time Library, please refer to the documentation of class Calendar. The remainder of this text discusses the specific nature of the Persian Calendar itself (and its implementation by this class,) and assumes that the reader has already become familiar with all the concepts and terminology documented in class Calendar. The Persian Calendar (as implemented here) is an arithmetical, solar calendar. A solar calendar is one that attempts to match the (average) length of its years to that of mean solar years. Epoch Date The epoch date of the Persian Calendar, 0001-01-01 [Persian], corresponds to 0622-03-22 [Gregorian] and to 0622-03-19 [Julian]. The Julian Date of the epoch of the Persian Calendar is 1,948,320.50 (midnight.) The epoch date of the Persian Calendar is the vernal equinox of the year in which the "hijra" of Mohammed to Medina occurred ("hijra" means "flight from danger.") The era of the Persian Calendar is called "Anno Persico" or "Anno Persarum" (AP)--which is Latin for "In the Year of Persia/the Persians." Time-of-Day Clock Modernly, midnight is both the zero-point of the time-of-day clock and also the initial moment of the day. However, such has not always been the case for all users of the Persian Calendar. {PersianCalendar clock today} {PersianCalendar clock now} Year Numbering Policy The Persian Calendar uses "zeroless ordinal" year numbering. This means that the epoch year is an ordinal number whose value is 1, and the year that immediately precedes the year 1 is the year -1. Leap Year Rule According to Birashk [A. Birashk, "A Comparative Calendar of the Iranian, Muslim Lunar, and Christian Eras for Three Thousand Years," Mazda Publishers (in association with Bibliotheca Persica,) Costa Mesa, CA, 1993], the arithmetical form of the Persian Calendar uses the following rather complicated leap year rules: There is a master cycle of 2820 years, during which 683 years are leap years. Each standard year contains 365 days, and each leap year contains 366 days, so the master 2820-year cycle contains 1,029,983 days [(2820 * 365) + 683 = 1,029,983]. Based on the current mean length of the tropical year and solar day, there are 1,029,983.00118 days in 2820 tropical years. So, were it not for the fact that a) the length of the tropical year and the length of a mean solar day is slowly changing, and b) the length of the tropical year (which is defined by the duration between winter solstices) is not the same as the length of the spring equinoctial year (which is defined by the duration between vernal equinoxes,) it would be fair to say that the Persian arithmetical calendar deviates from the length of a year by only 101.952 minutes in 2820 years. But for those (and other) caveats, the Persian arithmetical calendar would slip from perfect alignment with the tropical year by only one day every 39,829.68 years--which is astounding accuracy, in spite of the caveats. Within each 2820-year cycle, there are 22 subcycles--the first 21 each contain 128 years, and the 22nd (final) subcycle contains 132 years [2820 = 21 * 128 + 132]. Each 128-year subcycle contains one 29-year sub-subcycle (the first,) followed by three 33-year sub-subcycles [128 = 29 + (3 * 33)]. Each 132-year subcycle contains one 29-year sub-subcycle (the first,) followed by two 33-year sub-subcycles, followed by one 37-year sub-subcycle [132 = 29 + (2 * 33) + 37]. A year in a sub-subcycle (whether it contains 29, 33 or 37 years) is a leap year if the ordinal index of the year within the cycle satisfies the following two predicate tests: 1) it's greater than 1, and 2) the remainder after dividing it by 4 is 1 (so the first year in sub-subcyle is never a leap year; the first leap year is the fifth year in the sub-subcycle.) Thus, a 29-year sub-subcycle has 7 leap years, a 33-year sub-subcycle has 8 leap years, and a 37-year sub-subcycle has 9 leap years (Note: the last year of a sub-subcycle is always a leap year, since 29, 33 and 37 all result in a remainder of 1 when divided by 4) [21 * (7 + (3 * 8)) + (7 + (2 * 8) + 9) = 683]. The base year of the 2820 cycle of years is NOT the Persian year zero or 1, however. The base year of the 2820-year cycle of years is the Persian year 475 (which starts on 21 March 1096 [Gregorian] or 15 March 1096 [Julian].) However, to facilitate the use of modular arithmetic, the Chronos implementation uses Persian year 474 as the zeroeth year of the 2820-year cycle. Algorithm of Predicate Function that answers true if a <persianYear> is a leap year (input arg=<persianYear>): 1. If <persianYear> >= 1 then set <cardinalYear> to <persianYear> - 1; else set <cardinalYear> to <persianYear>; end 2. Set <dividend> to <cardinalYear> - 473. 3. Set <year> to (dividend mod 2820) + 474. 4. Return (((<year> + 38) * 682) mod 2816) < 682 Month Structure Month Days In Month Standard Year/Leap Year 1: Farvardin 31/31 2: Ordibehesht 31/31 3: Xordad 31/31 4: Tir 31/31 5: Mordad 31/31 6: Shahrivar 31/31 7: Mehr 30/30 8: Aban 30/30 9: Azar 30/30 10: Dey 30/30 11: Bahman 30/30 12: Esfand 29/30 Days In Year 365/366 The semantic month-key of a month is the same as the month's (English) name (as given here.) Pretty deep, right ? HTH, Sven Yes, the main website is down, but you should be able to load the code in Pharo 2.0 using the configuration. > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 13, 2013

Re: [Pharo-users] Message naming

by kilon alios

Thats not only the Pharo, the Squeak, way, the Python way, the Ruby way ..... its the logical way GregorianDate >> toJulian You have a class then you have a method . You want to extend your method ? why increase the size of method ? You just create a new class for it. I have 3 rules when I code 1) Keep it small 2) Keep it simple 3) Keep it obvious Also I cant recommend this book highly enough, its not only the best book I have read, its a goldmine of concentrated wisdom. No vague theories, no assumptions, just a bombarbment of practical examples -> http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X it wont show you just proper naming it will show you everything. Its the kind of book that you will keep coming back to. This something that every coder should have. and yes Java is doing it wrong, its doing it very wrong. On Wed, Nov 13, 2013 at 10:19 AM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > On 11/13/2013 11:39, Bahman Movaqar wrote: > > On 11/13/2013 11:13, Bahman Movaqar wrote: > >> Let's say I have a method with signature in a language like Java as > below: > >> gregorianDayToJulianDay(year, month, day) > >> > >> What could be a proper naming for this method in Smalltalk? I'm a bit > >> confused as I'm so used to the concept of methods being "verbs" which > >> accept some arguments. > >> > >> I'd appreciate any help/idea. > > After reading Sven's reply, I came up with this design. Is it the > idiomatic way to handle this problem in Smalltalk: > > <pseudo-design> > class JulianConverter: > instance variable: 'day' > > #toGregorian > #toIranian > > class GregorianConverter: > instance variable: 'year month day' > > #toJulian > > class IranianConverter: > instance variable: 'year month day' > > #toJulian > > </pseudo-design> > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > > >

Nov. 13, 2013

Re: [Pharo-users] Message naming

by StÃ©phane Ducasse

did you check acancagua (unit and time) or chronos (more complete calendar) package Stef On Nov 13, 2013, at 9:19 AM, Bahman Movaqar <Bahman(a)BahmanM.com> wrote: > On 11/13/2013 11:39, Bahman Movaqar wrote: >> On 11/13/2013 11:13, Bahman Movaqar wrote: >>> Let's say I have a method with signature in a language like Java as below: >>> gregorianDayToJulianDay(year, month, day) >>> >>> What could be a proper naming for this method in Smalltalk? I'm a bit >>> confused as I'm so used to the concept of methods being "verbs" which >>> accept some arguments. >>> >>> I'd appreciate any help/idea. > > After reading Sven's reply, I came up with this design. Is it the > idiomatic way to handle this problem in Smalltalk: > > <pseudo-design> > class JulianConverter: > instance variable: 'day' > > #toGregorian > #toIranian > > class GregorianConverter: > instance variable: 'year month day' > > #toJulian > > class IranianConverter: > instance variable: 'year month day' > > #toJulian > > </pseudo-design> > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 13, 2013

Re: [Pharo-users] How to change background color

by Sergi Reyner

Ben, could you elaborate a bit on: add support for color on AbstractWidget > change a bit the way MorphicAdapters are built to take this color in account > I havenÂ´t quite figured out yet how do all the pieces fit together. It may be due to lack of caffeine though :) I have noticed that color sort of works... for example, you can inspect a SpecWindow, send it (self color: Color red) and the window will indeed change color, but as soon as you click on it it goes back to the default grey. Cheers, Sergi

Nov. 13, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Bernat Romagosa

Thanks a lot Torsten! I'll invest the whole morning tomorrow in trying to get a little bit more of this to work. If I don't succeed... there are lots of very good restaurants in Barcelona, Igor ;) 2013/11/13 Torsten Bergmann <astares(a)gmx.de> > Hi Bernat, > > >how do I translate this into NB code > > Either invite Igor (author of NB) for lunch or try this: > > > Its a C-structure, you convert it by wrapping this in a sublcass > of "NBExternalStructure". See the examples already in a Pharo 3.0 image. > > Basically you need: > > - define a subclass NBExternalStructure subclass: #WinNotifyIconData ... > - define the correct fields in a class side #fieldsDesc method according > to the native data types used in the structure > - call "WinNotifyIconData rebuildFieldAccessors" > - setup the types in a shared pool that you can include later: > > - define the pool: SharedPool subclass: #WinTryIconConstants ... > - in a class initialize method you can setup the type > > initialize > > NOTIFYICONDATA := #WinNotifyIconData. > PNOTIFYICONDATA:= 'NOTIFYICONDATA *'. > > - by including the pool you can use "NOTIFYICONDATA" or "PNOTIFYICONDATA" > in any native boost call. > > > If you are in Pharo 3.0 load "OS-Windows" package from the config browser. > Check the subclasses of NBExternalStructure there. > > I wrapped many other windows structures already so you can get an idea > about > it. For instance have a look at WinConsoleConstants>>initTypeConstants, > there you will find > the CONSOLE_CURSOR_INFO, CONSOLE_SCREEN_BUFFER_INFO structs wrapped in > WinConsoleCursor, WinConsoleScreenBuffer classes. > > Compare them with the MSDN struct description. > > >Could the Windows API be any more convoluted and dev-unfriendly in any > >possible sense? > > This question should go to M$ not Pharo-user ;) > > Bye > T. > > > BTW: I'm not sure "PNOTIFYICONDATA" alone will solve your problem if I > remember correctly > from my Smalltalk/MT and C/C++ times also playing with tray icons. > I guess you need a callback that gets called when the icon is clicked > or the tray icon menu > is choosen (see uCallbackMessage member in the struct). > You also need a handle to an icon - either the icon from the EXEs > resource section or > by loading one from a bitmap. That means wrapping the icon or bitmap > apis too... > > -- Bernat Romagosa.

Nov. 13, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by StÃ©phane Ducasse

JB can you read and reply to this mail? > Hi > > What Doru wrote pretty much sums it up. > > CodeCity under VW was based on JUN, which provided a programmer-friendly API built on top of OpenGL. Since there is no such thing under Pharo, when I later started to work on CodeCity under Pharo, I needed to learn about how to program directly to OpenGL. And the only example I had for that was SourceCity. In the meantime I manage to get a grip on my basic needs and was ready to move forward to implementing CodeCity. Now that does not work anymore in Pharo 3.0 so I am stuck. I could continue to program under Pharo 2.0, but what's the point? for now probably, because if you that is the one the most interested guy in that does not have the time to understand why others that do not need 3D should do it. NBOpenGL was a side project to give a try of busy people too. I'm sorry to say that but we cannot be on all fronts especially when they are changing. So can you tell us if you see what changed between 2 and 3. I have no idea. > I have already looked at Roassal 3d, but it was not easy to separate the API from the code. Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). Because Roassal 3d should not be about shadder but about 3D. > And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). Yes they changed the API and deprecated the old way of doing it. > So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. See below > Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. Three remarks: - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying on other people and probably frustrated when things are not working. - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you can get https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk Now again if nobody builds a jun like library in Pharo it will not exist. Stef > Cheers > Ricky > > > > > On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). > > I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? > > Cheers, > Doru > > > > On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Richard > > you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) > and his code should be split in two and one part should go to NBOpenGL. > Now he is experiencing some problem with NBOpenGL on windows as you. > > NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that > he does not have fun there). > > So it is important that you help because we are FULL > and sorry about that but really FULL. > > Ronie will visit us in January and share an office with igor. > > Stef > > > > Hi > > > > CodeCity, the project I am working on is based on NBOpenGL. > > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. > > > > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: > > > > GLTTRenderingDemo new openInWorld. > > > > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. > > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? > > > > Cheers > > Ricky > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 13, 2013