[Pharo-users] Unintuitive behavior of class-side initialize

As class is just an object in Smalltalk, it would be reasonable to believe that #initialize message is always sent to class on creation. However, that's not true. It is only sent to classes that redefine #initialize. Also sending super initialize may lead to problems. None of these is mentioned

Re: [Pharo-users] Unintuitive behavior of class-side initialize

On Wed, Aug 27, 2014 at 8:22 AM, webwarrior r...@webwarrior.ws wrote: As class is just an object in Smalltalk, it would be reasonable to believe that #initialize message is always sent to class on creation. However, that's not true. It is only sent to classes that redefine #initialize. Also

Re: [Pharo-users] Unintuitive behavior of class-side initialize

I will be adding an Introduction to Object Orientation chapter to the new updated Pharo By Example online book, so I will add this to the chapter. The chapter will target people not familiar with Object Orientation and people new to coding. Its not an immediate target but it will happen till the

Re: [Pharo-users] Unintuitive behavior of class-side initialize

This is not something fundamental to OOP, just specific to Pharo or Smalltalk. Take for example Python. It has similar object model (objects, classes, metaclasses). Every time class is defined (either by class keyword, or by type() function, or by calling a metaclass), its metaclass' __init__

Re: [Pharo-users] Unintuitive behavior of class-side initialize

ok officially I am confused are we talking about initialise at the instance side or class side (metaclass) side ? I am a python coder myself but I have not done any metaprogramming . If it is a metaprogramming thing then yes it wont go inside my intro chapter since this is advanced topic and

Re: [Pharo-users] Unintuitive behavior of class-side initialize

class-side initialize. I don't think it can be considered a metaprogramming in Smalltalk. In Python, yes, messing with metaclass is metaprogramming. But things are a bit different there and metaclasses are very rarely used [explicitly]. 27.08.2014 19:05, kilon.alios [via Smalltalk]

Re: [Pharo-users] Unintuitive behavior of class-side initialize

Yeah don't do super initialize unless you know why on the class side. That being said class side initialize is pretty cool when loading new packages and setting everything up automagically. Phil Le 27 août 2014 18:33, webwarrior r...@webwarrior.ws a écrit : class-side initialize. I don't

Re: [Pharo-users] Problems Pharo 3.0 Windows 8.1 (64 Bit)

Le 27/08/2014 03:36, Ben Coman a écrit : Hi Volkert, I don't have Win 8.1 64-bit to test on, but to help reproducibility for others, could you provide the exact downloads you are using for VM and Image. Do you end up with a PharoDebug.log or crash.dmp file in any Pharo folder? cheers -ben

Re: [Pharo-users] Unintuitive behavior of class-side initialize

yeah python does not need initialisation for class variables like it does for instance variables, but then same applies for instance variables, for example you can add instance variables and even instance method after the instance is created , pharo does something similar too. Well OOP is a deep

Re: [Pharo-users] Unintuitive behavior of class-side initialize

I've also chosen ifNil route. However, in that case you either: - break encapsulation by providing accessors - have to invoke initializing method in every method that uses class instance variables or class variables 27.08.2014 20:31, kilon.alios [via Smalltalk] написав(ла): yeah python does not

Re: [Pharo-users] Unintuitive behavior of class-side initialize

I assume you mean there will be an inheritance issue if I want the variables to be inherited with a default value by the subclasses, which is a valid concern. Other than that you can have accessors for it as far I know . But yeah in that case of inheritance you need some kind of initialise method.

Re: [Pharo-users] Problems Pharo 3.0 Windows 8.1 (64 Bit)

Thanks for all the feedback. Hope to find some time tomorrow ... BW, Volkert Am 27.08.2014 um 07:54 schrieb Göran Krampe: Hi! On 08/25/2014 05:34 PM, volk...@nivoba.de wrote: Dear all, i have problems with Pharo 3.0 under Win 8.1 (64 Bit). When i quit Pharo and then restarting the it,

[Pharo-users] Pharo on Nvidia Jetson TK1?

Wouldn't this a nice platform for Pharo? I mean a Pharo with full CUDA and OpenGL Support ... i would like it. :-) https://developer.nvidia.com/jetson-tk1 http://devblogs.nvidia.com/parallelforall/jetson-tk1-mobile-embedded-supercomputer-cuda-everywhere/ http://elinux.org/Jetson_TK1

Re: [Pharo-users] Pharo on Nvidia Jetson TK1?

On 27/8/14 22:29, volk...@nivoba.de wrote: Wouldn't this a nice platform for Pharo? I mean a Pharo with full CUDA and OpenGL Support ... i would like it. :-) me too but time/money... for the OpenGL support there is already a part. https://developer.nvidia.com/jetson-tk1

Re: [Pharo-users] Pharo on Nvidia Jetson TK1?

There is a chance if you are able to run Pharo on that platform and support python wrappers for CUDA (python is already support for CUDA for regular nvidia GPUs but I dont know about this platform ) you could use my Atlas lib to access Cuda from Pharo. Atlas is a library I am making that allows

Re: [Pharo-users] Persistence on Moose browsers, showing always a selection in trees and making tree labels editable.

Hi Doru, Sven and community, I have made a small experiment to get persistence on browsers by using STON. I really like the readability of STON. At [1] you can see a screen shoot of a moose browser tree and attached to this mail is equivalent STON file. [1]