November 2013 - Pharo-users

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