November 2013 - Pharo-users

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