I was able to borrow an iBook to check out Self 4.1.5 yesterday (note - since I don't know how to set up the SELF_WORKING_DIR variable the droplet didn't work) and was interested in seeing how the new "argument count" bytecode was used. I does make an interpreter's life easier, but the code expansion is a bit too much. An interesting alternative would be to define the two remaining opcodes as "send1" and "selfSend1" and only use "argument count" for the rarer cases of two or more arguments.
One thing that seemed surprising to me was the direct evaluation order of the arguments, with the receiver ending up buried in the stack. I thought we used the reverse order with the receiver on top, so I checked in Self 4.0 and saw that it too used the direct order. In fact, my tinySelf 1 does too (as it had to, in order to work with Self 4.0 images) so I obviously knew this a few years back. My tinySelf 0 parser did generate code to evaluate things in the reverse order but since it only read in sources and not snapshot I never noticed this mistake. I checked Craig Chambers' thesis but his single example of bytecodes only has unary messages and could be interpreted either way.
The simple embedded Self hardware I am designing (a 16 bit machine described in http://www.merlintec.com:8080/hardware/oliver) does evaluate arguments in the reverse order, so translating Self bytecodes to its native machine language will be a little more complicated than I had hoped. I have investigated alternative, such as the KMachine (http://fare.tunes.org/tmp/emergent/kmachine.htm) which are a much better fit for the direct order evaluation but that will have to wait for a larger project than this one.
-- Jecel
Hi,
For an application that I'm writing in the moment, I need a morph that has fix position to the current view. For example like the radarView. When I looked at this implementation I found out that it works in different way then I mentioned. The radarView is not fixed, it just ignore the movements that was directed by the radarView itself. For example, if you have 2 radarViews and you use one of them to move to the right, the other is not visible in the current view anymore. What I need is something like the flaps in Squeak, but I found it not very helpful to look at their implementation. For me the differences between the two different implementations looks to great, maybe I'm wrong. Any idea how I can do things like that in self?
Thorsten Dittmar
On Friday 10 May 2002 02:40, Thorsten Dittmar wrote:
For an application that I'm writing in the moment, I need a morph that has fix position to the current view. For example like the radarView. When I looked at this implementation I found out that it works in different way then I mentioned. The radarView is not fixed, it just ignore the movements that was directed by the radarView itself. For example, if you have 2 radarViews and you use one of them to move to the right, the other is not visible in the current view anymore.
I would say that the radarView jumps to a new position in the world and then changes your viewpoint of that world so it ends up in the same place on the screen.
What I need is something like the flaps in Squeak, but I found it not very helpful to look at their implementation. For me the differences between the two different implementations looks to great, maybe I'm wrong. Any idea how I can do things like that in self?
You can't scroll around in Squeak, so flaps are a rather different beast. But you are right - we really do need something like that.
When I was creating a presentation in Self for the 2000 Selfest the awkwardness of moving things around further than a single screen became too much. You have to drag an object from one side to the other, then drop it, then go to the radarView and click once on twice on the arrow buttons, then with the object now near the other side of the screen you repeat the process. So here is what I did - I modified the worldMorph so that typing the arrow keys on the keyboard would have the same effect as using the radarView. Now I could hold the object with the mouse (or objects, when using a carpetMorph) and scroll around with the keyboard to get to where I wanted to drop off the object. This made a *huge* difference in usability and allowed me to quickly do massive rearrangements of morphs spread around the world.
With a little more time I would probably have tried a different approach more like what you want: to allow objects to "hover" above the world so they would stay in the same place as you scrolled in the world. You might find this description of an evolution of this idea interesting: http://www.merlintec.com/pegasus2000/e_gui.html
One feature of flaps, the hability to hide off to one side when not in use, is much more important in Squeak where there is only one screen than in Self where we can have as many windows as we like. See the "open factory window" option in the yellow menu for an example of this flap-like behavior.
A possible implementation for the "hover objects" would be to patch the worldMorph's scrolling code. We could add a slot with a set of such object and the worldMorph would change each of their positions so that they would stay in one place on the screen like the radarView.
-- Jecel
self-interest@lists.selflanguage.org
-
Jecel Assumpcao Jr -
Thorsten Dittmar