OK, I've found the R3StateTracker and am working from that.
--
View this message in context:
http://forum.world.st/3D-with-Pharo-and-OpenGL-tp4760029p4760466.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On May 26, 2014, at 3:08 PM, Esteban A. Maringolo wrote:
> 2014-05-26 15:14 GMT-03:00 Johan Fabry :
>>
>> +1 on the removal of Object>>#name.
>
> Everybody got bitten by the accessor creation of #name: and #name1 :)
Bitten? No. Annoyed? Yes yes yes. :-)
---> Save our in-boxes! http://email
2014-05-26 20:08 GMT+01:00 Esteban A. Maringolo :
> 2014-05-26 15:14 GMT-03:00 Johan Fabry :
> >
> > +1 on the removal of Object>>#name.
>
> Everybody got bitten by the accessor creation of #name: and #name1 :)
>
I hear you!
2014-05-26 15:14 GMT-03:00 Johan Fabry :
>
> +1 on the removal of Object>>#name.
Everybody got bitten by the accessor creation of #name: and #name1 :)
Esteban A. Maringolo
+1 on the removal of Object>>#name.
On May 26, 2014, at 1:19 PM, Sven Van Caekenberghe wrote:
> Object>>#name should be removed, it is possible, I tried it once.
> Most senders of #name are asking for the name of a class.
>
> On 26 May 2014, at 18:15, Stephan Eggermont wrote:
>
>> Do I under
I wouldn't rely on such symmetry.
Given the fact #printOn: is the only printing "instrumentation"
available to show objects in debuggers, inspectors, etc. Most of the
times it just shows a short representation of the object, not very
useful to recreate an instance from such short string.
Regards,
Hello,
Closures were implemented in Squeak/Pharo according to the blue book, so
they were not real closures, up to 2008. Then the VM and the compiler were
changed to support real closures.
The code you showed should work both on latest Squeak and on latest Pharo
fine. Old version of Squeak and/or
Object>>#name should be removed, it is possible, I tried it once.
Most senders of #name are asking for the name of a class.
On 26 May 2014, at 18:15, Stephan Eggermont wrote:
> Do I understand correctly that name is to be understood as inspectorName
> and so should never be implemented as subcla
I wanted to take a second to close the book on this. It turns out that
storeOn:/readFrom: are not supposed to be symmetrical. printOn:/readFrom: are
supposed to be symmetrical.
storeOn: generates a string that can be fed into the interpreter/compiler such
that when it is executed an instance th
I read that Blocks in Squeak and Pharo, since it was derived from Squeak
did not implement true block closures and would not support block
recursion. On one count the statement was correct, but not on the other.
I tried:
| a f |
a := 0.
f := [ Transcript show: a. (a < 5)ifTrue:[a :
Do I understand correctly that name is to be understood as inspectorName
and so should never be implemented as subclass responsibility?
Stephan
Thanks for the help. I'll try to get it working. I haven't found an example
of instantiating a StateTracker or a StateTracker class.
Where is the version of Roassal3D that works with the latest NBOpenGL?
--
View this message in context:
http://forum.world.st/3D-with-Pharo-and-OpenGL-tp4760029p
The main problem with openGL, is two group have been work in parallel.
When we merge the demo work on my version of NBGLProgram.
And we keep the version of Roassal3D, the demo do not work anymore, I expected
as the code has been change, the small demo have been ported too.
It is not working anymo
camille teruel wrote
> "instance perform: filterMethod asSymbol"
"instance perform: filterMessage asSymbol" ;)
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Calling-an-arbitrary-method-tp4760058p4760380.html
Sent from the Pharo Smalltalk Users mailing list archive a
I think the new pharo website could be improved by the addition of two new
pages.
Firstly, the site badly needs a "Success Stories" page. The old web site had
one of these so presumably that can be added easily. You have to show
newcomers that pharo can be used for something real. Look at the/ met
15 matches
Mail list logo
