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

[kilon alios]

Libraries have no job. They have no obligations. No things they should or
must do. They have methods that define what they can do.

So there is nothing stopping Athens from having such a feature. Hence my
question.

But I found the formula for this, looks like i will be learning linear
algebra and geometry.  Good thing I love math :D
Στις 15 Νοε 2013 6:24 π.μ., ο χρήστης "Dennis Schetinin" 
έγραψε:

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

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

[Dennis Schetinin]

Why do you think it's a job for Athens? Shouldn't it be in a geometry lib?


--

Best regards,


Dennis Schetinin


2013/11/15 kilon alios 

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

Re: [Pharo-users] Nautilus + Periscope

[Pavel Krivanek]

Hi Torsten,

thank you very much. Everything is done. Now Periscope can be loaded
using Configuration Browser into Pharo 2.0.

Cheers,
-- Pavel

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

Re: [Pharo-users] Nautilus + Periscope

[Pavel Krivanek]

Yes, it works on the edge of Spec capabilities and it needs to use
some hacks that are not possible in the recent Spec version.

-- Pavel

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

[Pharo-users] Nautilus + Periscope

[Torsten Bergmann]

Pavel wrote:
>I fixed the recent experiments with the new Spec versions so now it
>should work in Pharo 2.0. It really needs a configuration :-)

You mean a configuration like the one I attached  :)

Did you notice the new "Config+" button on the metacello browser - it
helps creating new configs. I also added a postload for plugin registration.

Feel free to use and put into your STHub repo.


I found two bugs in Periscope using Pharo2.0 #20627:

 1. When one enters "Obj" to search for object it crashes in the spotlight
 2. When one opens tools like the Configuration browser they show up inside
of the area of Periscope...

If this gets fixed and config gets usable for Pharo 2.0 then do not forget to 
add the updated config also to "MetaRepoForPharo20" on SS3. This way it will 
show up in the config browser and can easily be loaded.

Thx
T.

ConfigurationOfPeriscope-TorstenBergmann.1.mcz
Description: Binary data

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

[Stéphane Ducasse]

We should change that and use the properties of the node.

Stef

On Nov 14, 2013, at 8:52 PM, Stephan Eggermont  wrote:

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

Re: [Pharo-users] Nautilus + Periscope

[Juraj Kubelka]

Thanks, I will try it. 

Are there some changes in Pharo 3, that does not allow to use it in Pharo 3?

Cheers,
Jura

El 14-11-2013, a las 16:57, Pavel Krivanek  escribió:

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

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

[kilon alios]

So here we are with my first challenge.  I am making Hyperion, a vector
graphics editor using Athens , so far I have a nice line with several
segments, I have added nice handlers to allow me to move the points (start
and end of each segment) of the line around with the mouse, but now I want
each time I click on a segment itself to create a new point.This way I will
create more points with the mouse and bring more detail to the shape of the
line / path.

In order to do that I will have to check that the line passes through a
specific pixel. Or to be more correct that the place that mouse has clicked
is where my path passes through. How I do that ? Can Athens do that ? Can
athens tell me which pixels my path passes through ?

At first I thought to return the Athens surface as a Form but the form will
give me back the colors of each pixel on a specific place, but that does
not guarantee  that my line / path passes through those pixels.

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

[Gisela Decuzzi]

Hi Stephan, thanks for testing it, when I have some time I will work in the
transformation because is a big missing feature.
If you want to contribute with the project tell me your smalltalkhub user
to add you :)

Sorry for the lack of support, as Stef said I'm in the middle of a workshop
planning for this saturday.



2013/11/14 Stephan Eggermont 

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

Re: [Pharo-users] Nautilus + Periscope

[Pavel Krivanek]

I fixed the recent experiments with the new Spec versions so now it
should work in Pharo 2.0. It really needs a configuration :-)

Gofer new
smalltalkhubUser: 'PavelKrivanek' project: 'Periscope';
package: 'Periscope';
load.

Nautilus pluginClasses add: {(Smalltalk at: #NautilusPeriscopePlugin). #none}

-- Pavel

2013/11/14 Juraj Kubelka :
> Hi!
>
> Today Stéphane mentioned project Periscope (Universal Navigation Sidebar for 
> Nautilus).
>
> Does anyone use it or maintain it? It looks like it does not work.
>
> Links:
>  - 
> http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautilus-td4644569.html
>  - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope
>
> Cheers,
> Jura

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

[Stephan Eggermont]

On 14 nov. 2013, at 19:39, Stéphane Ducasse  wrote:

> Gisela is busy preparing a workshop in argentina and working.
> Now did you try to load it?
> I do not know if there is an automated jenkins build.

Gisela contacted me, and I managed to load the newest version. 
AST-Core is changed in Flamel by adding instance variables to RBProgramNode.
That breaks each time AST-Core changes in Pharo.
Still 2 failing tests (already on Trello), and the transformation needs work.

Stephan

[Pharo-users] Nautilus + Periscope

[Juraj Kubelka]

Hi!

Today Stéphane mentioned project Periscope (Universal Navigation Sidebar for 
Nautilus). 

Does anyone use it or maintain it? It looks like it does not work.

Links:
 - 
http://forum.world.st/ANN-Periscope-Universal-Navigation-Sidebar-for-Nautilus-td4644569.html
 - http://smalltalkhub.com/#!/~PavelKrivanek/Periscope

Cheers,
Jura

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[Tudor Girba]

Thanks a lot for looking into this. We will check tomorrow when we are back
in front of a Windows machine, and let you know how it works.

Cheers,
Doru


On Thu, Nov 14, 2013 at 4:57 PM, Jean Baptiste Arnaud <
jbaptiste.arn...@gmail.com> wrote:

> Good news everyone:
> bug fixed and integrated in 3,0 573
> I am open for new feedback.
>
>
> On Nov 14, 2013, at 2:56 PM, Igor Stasenko  wrote:
>
>
>
>
> On 14 November 2013 14:25, Jean Baptiste Arnaud <
> jbaptiste.arn...@gmail.com> wrote:
>
>> Yes the fix is not integrated yet.
>> NBWndClassEx should not be a variable subclass anymore. This part should
>> be checked with Igor.
>>
>> NBWndClassEx>>#initialize
>> self cbSize: (self class instanceSize).
>> and not self basicSize.
>>
>> ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize
> was always == instanceSize, but now it is no longer like that and
> you need to use longer expression e.g. (self class instanceSize)
>
>
>> You can rebuildField accessor too (class side on every
>> NBExternalStructure).
>>
>> Do this change and your image should work. (with the last openGL-Win)
>> I can take you a picture of my computer.
>>
>> For more accurate answer I need the crash.dump
>>
>>
>> On Nov 14, 2013, at 1:47 PM, Tudor Girba  wrote:
>>
>> Hi,
>>
>> As I understand there are still some things to be integrated in
>> NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of
>> NBOpenGL crashes the VM (on Win 7) when doing:
>> GLTTRenderingDemo new openInWorld.
>>
>> Could you point us to the NativeBoost fix to see if it works?
>>
>> Doru
>>
>>
>> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud <
>> jbaptiste.arn...@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.arn...@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.duca...@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  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.duca...@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

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[Jean Baptiste Arnaud]

On Nov 14, 2013, at 5:39 PM, Ronie Salgado  wrote:

> Still having problems with NBOpenGL under Linux.
> 
> First I'm getting a message not understood for NativeBoostConstants 
> mac32PlaformId under NBMacGLContextDriver>>supportsCurrentPlatform. Its fixed 
> by adding the missing 't' to mac32PlaformId, becoming mac32PlatformId.
I think your image is outdated ...

That is a really old bug.

"
Name: NBOpenGL-Mac-IgorStasenko.3
Author: IgorStasenko
Time: 14 March 2013, 4:16:19.35 pm
UUID: d0575b2c-ffc1-4cce-ac2a-3215ae53c599
Ancestors: NBOpenGL-Mac-IgorStasenko.2

- fix typo with mac32PlaformId => mac32PlatformId
"
But check your openGL version maybe not the right one.
How do you load openGL ?
ConfigurationOfOpenGL project load: '3.0' ? ==> you should use this one.

> Then, after changing that I'm receiving a "function unavailable" error. 
> Looking at the code I notice that it looks for libGL.so under 
> /usr/lib/libGL.so. In modern versions of 64 bits Ubuntu, and Linux Mint which 
> is derived from Ubuntu, libGL.so is not placed under /usr/lib, instead is 
> placed in a driver dependent folder, which is referenced by a config file in 
> /etc/ld.so.conf.d/ . With a mesa driver, the OpenGL library is at 
> /usr/lib/i386-linux-gnu/mesa/libGL.so.1 , so the driver shared object path 
> cannot be hardcoded.
The path problem is a know issue, yes. If you have a good solution. But yes 
basically you have to update manually the pass in the moduleName variable.

> Changing the module name for 'libGL.so.1', doesn't work, but changing it for 
> '/usr/lib/i386-linux-gnu/mesa/libGL.so.1' gives me an 'unable to resolve 
> external type: GLXDrawable', adding NBGLXTypes into the pool dictionaries of 
> NBGlxAPI solves it.

I fix that too.

> After changing that, it tries to create a multisampled framebuffer, however 
> it doesn't check the maximum number of samples supported. My machine reports 
> GL_EXT_framebuffer_multisample  as supported, but the FBO created is not 
> complete. I modified the creation code to use only 1 sample for multisampling 
> and its works.
> Using those hacks makes it work under a 64 bits Linux. Still, whenever I run 
> an example, I'm getting a top level window that doesn't does nothing, which 
> is annoying. Closing the windows doesn't break the running OpenGL application.
> 
> Greetings,
> Ronie Salgado
> 
> 
> 2013/11/14 Jean Baptiste Arnaud 
> Good news everyone:
>   bug fixed and integrated in 3,0 573
> I am open for new feedback.
> 
> 
> On Nov 14, 2013, at 2:56 PM, Igor Stasenko  wrote:
> 
>> 
>> 
>> 
>> On 14 November 2013 14:25, Jean Baptiste Arnaud  
>> wrote:
>> Yes the fix is not integrated yet.
>> NBWndClassEx should not be a variable subclass anymore. This part should be 
>> checked with Igor.
>> 
>> NBWndClassEx>>#initialize
>>  self cbSize: (self class instanceSize).
>> and not self basicSize.
>> 
>> ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize
>> was always == instanceSize, but now it is no longer like that and 
>> you need to use longer expression e.g. (self class instanceSize)
>>  
>> You can rebuildField accessor too (class side on every NBExternalStructure).
>> 
>> Do this change and your image should work. (with the last openGL-Win)
>> I can take you a picture of my computer.
>> 
>> For more accurate answer I need the crash.dump
>> 
>> 
>> On Nov 14, 2013, at 1:47 PM, Tudor Girba  wrote:
>> 
>>> Hi,
>>> 
>>> As I understand there are still some things to be integrated in 
>>> NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of 
>>> NBOpenGL crashes the VM (on Win 7) when doing:
>>> GLTTRenderingDemo new openInWorld.
>>> 
>>> Could you point us to the NativeBoost fix to see if it works?
>>> 
>>> Doru
>>> 
>>> 
>>> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud 
>>>  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 
>>>  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  
 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  wrote:
> 
>> Thanks everyone! That would be great. 
>> Looking forward to having NBOpenGL up and running again.
>> 
>> Cheers
>> Ricky
>> 
>> 
>> O

[Pharo-users] NBOpenGL on Pharo 3.0

[Torsten Bergmann]

Jean Baptiste Arnaud wrote
>Good news everyone:
>   bug fixed and integrad

I also merged the #12161 issue that is now also in Pharo 3.0#30573 into 
the official "NativeBoost-Win32" package on STHub so it will not appear 
again when next NB version comes out or is loaded into the image.

Thx
T.

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[Jean Baptiste Arnaud]

Good news everyone:
bug fixed and integrated in 3,0 573
I am open for new feedback.


On Nov 14, 2013, at 2:56 PM, Igor Stasenko  wrote:

> 
> 
> 
> On 14 November 2013 14:25, Jean Baptiste Arnaud  
> wrote:
> Yes the fix is not integrated yet.
> NBWndClassEx should not be a variable subclass anymore. This part should be 
> checked with Igor.
> 
> NBWndClassEx>>#initialize
>   self cbSize: (self class instanceSize).
> and not self basicSize.
> 
> ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize
> was always == instanceSize, but now it is no longer like that and 
> you need to use longer expression e.g. (self class instanceSize)
>  
> You can rebuildField accessor too (class side on every NBExternalStructure).
> 
> Do this change and your image should work. (with the last openGL-Win)
> I can take you a picture of my computer.
> 
> For more accurate answer I need the crash.dump
> 
> 
> On Nov 14, 2013, at 1:47 PM, Tudor Girba  wrote:
> 
>> Hi,
>> 
>> As I understand there are still some things to be integrated in NativeBoost. 
>> Indeed, I just tried now with Ricky, and version 3.0 of NBOpenGL crashes the 
>> VM (on Win 7) when doing:
>> GLTTRenderingDemo new openInWorld.
>> 
>> Could you point us to the NativeBoost fix to see if it works?
>> 
>> Doru
>> 
>> 
>> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud 
>>  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 
>>  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  
>>> 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  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 
>  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
>>> 
 Unfortunate

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

[Stephan Eggermont]

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

Stephan 

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

[Clément Bera]

Hello,

So there is 2 frameworks to do multi language UI in Pharo (but I don't know
if one of them is i18n).

One framework is in the image, does not work very well and no one use it
seemingly. So I don't recommend it.

The other one is the one everyone use, so I recommend it, I'm not sure but
I think it is named getText and you can find here:
http://smalltalkhub.com/#!/~PharoExtras/Gettext
Seemingly it has been ported to Pharo 2.0 recently. Therefore it should
work *nearly* out of the box.

Regards,


2013/11/14 Bahman Movaqar 

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

[Pharo-users] i18n - Where to start?

[Bahman Movaqar]

Hi all,

Would anyone share a pionter to how to do i18n in Pharo for translating
the messages used in a Pharo application (web or desktop)?

TIA,

-- 
Bahman Movaqar  (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)



signature.asc
Description: OpenPGP digital signature

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

[Johan Fabry]

I guess this one fell through the cracks, so 
https://pharo.fogbugz.com/f/cases/12164/One-Click-on-Mac-is-broken-due-to-new-source-file-lookup

On Nov 10, 2013, at 12:48 PM, Johan Fabry  wrote:

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



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

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

[Igor Stasenko]

On 14 November 2013 10:15, Stephan Eggermont  wrote:

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

temp := self.
temp <=> next.
^ temp

here the <=> is a special 'atomic swap' operation which atomically swaps
values
of two variables.
The best way to do that is to introduce a special bytecode in VM,
which either swaps values of two temps or swaps values of temp and instance
variable.
If we could have such bytecode, then we would have a strong guarantee from
VM
about atomicity of certain operations,
but since we don't have it yet, right now it is just (ab)uses the intrinsic
behavior of VM,
knowing that it never interrupts between two simple assignments.

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[Igor Stasenko]

On 14 November 2013 14:25, Jean Baptiste Arnaud
wrote:

> Yes the fix is not integrated yet.
> NBWndClassEx should not be a variable subclass anymore. This part should
> be checked with Igor.
>
> NBWndClassEx>>#initialize
> self cbSize: (self class instanceSize).
> and not self basicSize.
>
> ah, yes, of couse since before NBWndClassEx was var-byte and its basicSize
was always == instanceSize, but now it is no longer like that and
you need to use longer expression e.g. (self class instanceSize)


> You can rebuildField accessor too (class side on every
> NBExternalStructure).
>
> Do this change and your image should work. (with the last openGL-Win)
> I can take you a picture of my computer.
>
> For more accurate answer I need the crash.dump
>
>
> On Nov 14, 2013, at 1:47 PM, Tudor Girba  wrote:
>
> Hi,
>
> As I understand there are still some things to be integrated in
> NativeBoost. Indeed, I just tried now with Ricky, and version 3.0 of
> NBOpenGL crashes the VM (on Win 7) when doing:
> GLTTRenderingDemo new openInWorld.
>
> Could you point us to the NativeBoost fix to see if it works?
>
> Doru
>
>
> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud <
> jbaptiste.arn...@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.arn...@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 
>> 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  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.duca...@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 par

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

[Johan Fabry]

On Nov 14, 2013, at 7:29 AM, jtuc...@objektfabrik.de wrote:

>> Unless my understanding of the proposal is way off, you would just add 
>> "poolDictionaries: 'whatever'" before "category:". No horrible breaking of 
>> anything would happen.
>> 
>> Cheers,
>> Sergi
> I disagree ;-)
> I find it hard to remember the ordering of these parameters. I sometimes have 
> this problem with classInstVars in VAST.
> 
> But you are right in that using a simpler template as the default won't 
> remove the whole feature.

And if you don't remember the ordering, just browse the implementer of the 
message in the template, you will find other variants right next to it :-) 

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[Jean Baptiste Arnaud]

Yes the fix is not integrated yet.
NBWndClassEx should not be a variable subclass anymore. This part should be 
checked with Igor.

NBWndClassEx>>#initialize
self cbSize: (self class instanceSize).
and not self basicSize.

You can rebuildField accessor too (class side on every NBExternalStructure).

Do this change and your image should work. (with the last openGL-Win)
I can take you a picture of my computer.

For more accurate answer I need the crash.dump


On Nov 14, 2013, at 1:47 PM, Tudor Girba  wrote:

> Hi,
> 
> As I understand there are still some things to be integrated in NativeBoost. 
> Indeed, I just tried now with Ricky, and version 3.0 of NBOpenGL crashes the 
> VM (on Win 7) when doing:
> GLTTRenderingDemo new openInWorld.
> 
> Could you point us to the NativeBoost fix to see if it works?
> 
> Doru
> 
> 
> On Thu, Nov 14, 2013 at 1:21 PM, Jean Baptiste Arnaud 
>  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 
>  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  
>> 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  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 
  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 p

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

[Johan Fabry]

Note that I'm not advocating removing PoolDictionaries. Just to have the 
subclassing template not mention them. I would leave the subclassing message 
with the poolDictionaries: argument in the system for people to use it if they 
want to.

On Nov 14, 2013, at 7:02 AM, jtuc...@objektfabrik.de wrote:

> Hi,
> 
> I'd like to draw your attention to something else: consistency.
> 
> I remember the days when Cincom added Namespaces to classes and the class 
> definition template changed drastically. It took me quite a while to get used 
> to that.
> And there is this other aspect in the consistency field: most Smalltalk 
> literature will include and address that line. If you learn Smalltalk, such 
> small differences can cause trouble.
> 
> And what if I need PoolDictionaries? How hard will it be to find the place to 
> add my reference to them?
> A fair amount of Pharo code may not make much use of PoolDictionaries, but 
> other dialects do. I know Pharo has the concept of "never look back" and it 
> is good to be prepared to cut off old strings. But there is a price to it.
> 
> Seaside, apart from being a great web framework, has achieved something that 
> was excellent and helped the whole Smalltalk universe make a leap forward: 
> all Smalltalk dialects moved closer together and honestly worked on being 
> more compatible. Suggestions like this may not break much of this per se, but 
> many such cracks make a wide canyon. I find the argument that a certain line 
> of code may irritate students a bit weak. It may make their life harder once 
> they read code from other dialects. Should we remove class browsers because 
> students are used to use text editors?
> 
> Just my 2 cents
> 
> Joachim



---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry   -   http://pleiad.cl/~jfabry
PLEIAD lab  -  Computer Science Department (DCC)  -  University of Chile

[Pharo-users] Settings > Network > Blab email

[btc]

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

cheers -ben

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[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.arn...@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.arn...@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 
> 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  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.duca...@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 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 

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[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  
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  
> 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  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 
>>>  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  
>> 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

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

[Camille Teruel]

On 14 nov. 2013, at 12:38, Stéphane Ducasse  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 :
>> 
>>> 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  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
 
 
>>> 
>>> 
>> 
>> 
> 
> 

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

[p...@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, jtuc...@objektfabrik.de <
jtuc...@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 :
>>
>>  On 14 Nov 2013, at 10:15, Stephan Eggermont  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:jtuc...@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
>
>
>
>

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[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  
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  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 
>>  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  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 
>  wrote:
> Richard
> 
> you should have a look at ROASSAL 3d because ronie improved the shadder 
> part (no more assembler)
> and his code should be spli

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

[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  wrote:

>
> On Nov 14, 2013, at 11:21 AM, Yuriy Tymchuk  wrote:
>
> >
> > On 14 Nov 2013, at 11:10, jtuc...@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."
> >
> >  
> >  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, jtuc...@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 any

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

[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 :
> 
>> 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  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
>>> 
>>> 
>> 
>> 
> 
> 

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

[Norbert Hartl]

Stef,

Am 14.11.2013 um 12:10 schrieb 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.
> 
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  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
>> 
>> 
> 
> 

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

[Stéphane Ducasse]

On Nov 14, 2013, at 11:21 AM, Yuriy Tymchuk  wrote:

> 
> On 14 Nov 2013, at 11:10, jtuc...@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."
> 
>  
>  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, jtuc...@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
>  wrote:
>> +1
>> 
>> On Nov 12, 2013, at 4:39 PM, Johan Fabry  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  
>>> pool

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

[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  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
> 
> 

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[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  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  
> 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  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 
  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 

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

[Clément Bera]

2013/11/14 jtuc...@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, jtuc...@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
  wrote:

> +1
>
> On Nov 12, 2013, at 4:39 PM, Johan Fabry  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:jtuc...@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
>>>
>>>
>>>
>>
>>
>
> --
> --

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

[jtuc...@objektfabrik.de]

Am 14.11.13 11:23, schrieb Sergi Reyner:
2013/11/14 jtuc...@objektfabrik.de  
mailto:jtuc...@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:jtuc...@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

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

[jtuc...@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, jtuc...@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."

   
   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, jtuc...@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
 wrote:

+1

On Nov 12, 2013, at 4:39 PM, Johan Fabry  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

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

[Sergi Reyner]

2013/11/14 jtuc...@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

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

[jtuc...@objektfabrik.de]

Am 14.11.13 11:19, schrieb Norbert Hartl:

Am 14.11.2013 um 11:16 schrieb jtuc...@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:jtuc...@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

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

[Yuriy Tymchuk]

On 14 Nov 2013, at 11:10, jtuc...@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."

  
  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, jtuc...@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
  wrote:
> +1
> 
> On Nov 12, 2013, at 4:39 PM, Johan Fabry  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:jtuc...@objektfabrik.de
>>> Fliederweg 1 

[Pharo-users] Lock free structures in Pharo

[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

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

[Norbert Hartl]

Am 14.11.2013 um 11:16 schrieb jtuc...@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 :
>> 
>>> On 14 Nov 2013, at 10:15, Stephan Eggermont  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:jtuc...@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
> 
> 

Re: [Pharo-users] State of Flamel?

[Stephan Eggermont]

Anyone?

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

[jtuc...@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 :


On 14 Nov 2013, at 10:15, Stephan Eggermont  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:jtuc...@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

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

[Norbert Hartl]

Am 14.11.2013 um 10:25 schrieb Marcus Denker :

> 
> On 14 Nov 2013, at 10:15, Stephan Eggermont  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

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

[jtuc...@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, jtuc...@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
 wrote:

+1

On Nov 12, 2013, at 4:39 PM, Johan Fabry  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:jtuc...@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:jtuc...@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

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

[Yuriy Tymchuk]

On 14 Nov 2013, at 11:02, jtuc...@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
>>  wrote:
>>> +1
>>> 
>>> On Nov 12, 2013, at 4:39 PM, Johan Fabry  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:jtuc...@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
> 
> 

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

[jtuc...@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
 wrote:

+1

On Nov 12, 2013, at 4:39 PM, Johan Fabry  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:jtuc...@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

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

[Martin Dias]

+10


On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse
 wrote:
> +1
>
> On Nov 12, 2013, at 4:39 PM, Johan Fabry  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
>>
>>
>
>

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

[Marcus Denker]

On 14 Nov 2013, at 10:15, Stephan Eggermont  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

[Pharo-users] Lock free structures in Pharo

[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

Re: [Pharo-users] NBOpenGL on Pharo 3.0

[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  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 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.duca...@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