Hi all
Just a quick couple of questions (nothing serious).
I was going through the SBE and came up on OrderedCollections. I tried the following:
c := OrderedCollection newFrom: { 1. 5. 8. 45. 23. 3. 20 }. String newFrom: c
but I get the following: 'Error: Improper store into indexable object'. What I was expecting was:
1584523320 (because in Ruby world I can do something like this:)
irb(main):001:0> [1,2,3,4,5,6,7,8].to_s => "12345678" irb(main):002:0>
I was at least expecting something weird but not an error.
I eventually figured that it was because I was using Ints instead of Characters because this works fine:
str := OrderedCollection newFrom: { $a. $g. $t. $e }. str as: String
So, the question is why do I get the error? Shouldn't String be able to convert any object into a String representation? In Rubylandwhere that's all fair game but I get the feeling that you can't just do that since it is String doing the conversion by (possibly) sending a message that OrderedCollection does not support. If that's the case, how do you do it?
The second question is kinda stupid. I was playing around with the browser in Squeak (I had just learned how to open Morphs in the World. Yay!) and tried this:
anEllipse := EllipseMorph new. anEllipse defaultColor. anEllipse openInWorld
anEllipse color: Color red anEllipse borderWidth: 10 anEllipse height: 100 100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: randomNo. anEllipse borderWidth: anEllipse borderWidth + 1 ]
It did work but it did the moves all at once. At first I thought that it was just doing it so quick I couldn't see but I increased the number of iterations but all that did was hang the UI for a sec or so and then leave the ellipse at a random location (as expected). I guess I was trying to animate it but the UI doesn't update. Is it a block thing? That is, is it that the block is evaluated and then the UI is updated? Just curious. I'm probably trying to do this in a rather silly way.
Anyhoo, that's it. I'm loving it so far and I've ordered the Seaside book from Lulu. Even if I don't ever get to use this officially in my work, I'm glad I found it because I will now be able to write tools very quickly and easily AND move them between platforms with a quick scp or anything else for that matter..
Sven
Hello Sven,
don't know about your first Question though people now may think it has been replied to.
SS> 100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: SS> randomNo. anEllipse borderWidth: anEllipse borderWidth + 1 ]
SS> SS> It did work but it did the moves all at once. At first I
World doOneCycleNow will update the UI and (Delay forMilliseconds: 20) wait will give you some time to watch every step.
So your loop might look like
100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: randomNo. anEllipse borderWidth: anEllipse borderWidth + 1. World doOneCycleNow. (Delay forMilliseconds: 20) wait]
Cheers,
Herbert
On 20.05.2008, at 07:01, Herbert König wrote:
Hello Sven,
don't know about your first Question though people now may think it has been replied to.
SS> 100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: SS> randomNo. anEllipse borderWidth: anEllipse borderWidth + 1 ]
SS> SS> It did work but it did the moves all at once. At first I
World doOneCycleNow will update the UI and (Delay forMilliseconds: 20) wait will give you some time to watch every step.
So your loop might look like
100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: randomNo. anEllipse borderWidth: anEllipse borderWidth + 1. World doOneCycleNow. (Delay forMilliseconds: 20) wait]
Note that #doOneCycleNow is a Bad Hack, never to be used in real code, being punished by <insert favorite tim quote>.
The Right Way to do this in Morphic is to add a #step method in your own Morph subclass.
- Bert -
Bert Freudenberg wrote:
On 20.05.2008, at 07:01, Herbert König wrote:
Hello Sven,
don't know about your first Question though people now may think it has been replied to.
SS> 100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: SS> randomNo. anEllipse borderWidth: anEllipse borderWidth + 1 ]
SS> SS> It did work but it did the moves all at once. At first I
World doOneCycleNow will update the UI and (Delay forMilliseconds: 20) wait will give you some time to watch every step.
So your loop might look like
100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: randomNo. anEllipse borderWidth: anEllipse borderWidth + 1. World doOneCycleNow. (Delay forMilliseconds: 20) wait]
Note that #doOneCycleNow is a Bad Hack, never to be used in real code, being punished by <insert favorite tim quote>.
The Right Way to do this in Morphic is to add a #step method in your own Morph subclass.
Then you should have a look at ColorPickerMorph :-)
Karl
On 20.05.2008, at 16:46, Karl Ramberg wrote:
Bert Freudenberg wrote:
On 20.05.2008, at 07:01, Herbert König wrote:
Hello Sven,
don't know about your first Question though people now may think it has been replied to.
SS> 100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: SS> randomNo. anEllipse borderWidth: anEllipse borderWidth + 1 ]
SS> SS> It did work but it did the moves all at once. At first I
World doOneCycleNow will update the UI and (Delay forMilliseconds: 20) wait will give you some time to watch every step.
So your loop might look like
100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: randomNo. anEllipse borderWidth: anEllipse borderWidth + 1. World doOneCycleNow. (Delay forMilliseconds: 20) wait]
Note that #doOneCycleNow is a Bad Hack, never to be used in real code, being punished by <insert favorite tim quote>.
The Right Way to do this in Morphic is to add a #step method in your own Morph subclass.
Then you should have a look at ColorPickerMorph :-)
Keep in mind we are on the beginners list. I do know where this is used, and why. But if someone asks this on the beginners list it is bad advice to give.
If you know *exactly* what you are doing, like if you are working on the system-level implementation of a modal color picker, or the internal logic of an MVC-like pop-up menu that actually has to wait until closed before returning a value, then yes, #doOneCycleNow is useful. It still is a dangerous hack, because even though it looks innocuous, it is actually a recursive call on something that's not particularly designed for recursion (in Morphic, you are always in a doOneCycle already).
- Bert -
Bert Freudenberg wrote:
On 20.05.2008, at 16:46, Karl Ramberg wrote:
Bert Freudenberg wrote:
On 20.05.2008, at 07:01, Herbert König wrote:
Hello Sven,
don't know about your first Question though people now may think it has been replied to.
SS> 100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: SS> randomNo. anEllipse borderWidth: anEllipse borderWidth + 1 ]
SS> SS> It did work but it did the moves all at once. At first I
World doOneCycleNow will update the UI and (Delay forMilliseconds: 20) wait will give you some time to watch every step.
So your loop might look like
100 timesRepeat: [randomNo := 100 atRandom. anEllipse height: randomNo. anEllipse borderWidth: anEllipse borderWidth + 1. World doOneCycleNow. (Delay forMilliseconds: 20) wait]
Note that #doOneCycleNow is a Bad Hack, never to be used in real code, being punished by <insert favorite tim quote>.
The Right Way to do this in Morphic is to add a #step method in your own Morph subclass.
Then you should have a look at ColorPickerMorph :-)
Keep in mind we are on the beginners list. I do know where this is used, and why. But if someone asks this on the beginners list it is bad advice to give.
Yes, I know. I browsed the color picker code the other day and I thought it looked kind of unusual.
If you know *exactly* what you are doing, like if you are working on the system-level implementation of a modal color picker, or the internal logic of an MVC-like pop-up menu that actually has to wait until closed before returning a value, then yes, #doOneCycleNow is useful. It still is a dangerous hack, because even though it looks innocuous, it is actually a recursive call on something that's not particularly designed for recursion (in Morphic, you are always in a doOneCycle already).
Some of the code in FileList2 is modal, and recurse when you click the wrong folder :-(
Karl
Then you should have a look at ColorPickerMorph :-)
Keep in mind we are on the beginners list. I do know where this is used, and why. But if someone asks this on the beginners list it is bad advice to give.
If you know *exactly* what you are doing, like if you are working on the system-level implementation of a modal color picker, or the internal logic of an MVC-like pop-up menu that actually has to wait until closed before returning a value, then yes, #doOneCycleNow is useful. It still is a dangerous hack, because even though it looks innocuous, it is actually a recursive call on something that's not particularly designed for recursion (in Morphic, you are always in a doOneCycle already).
- Bert -
sounds like a nice class comment ;)
Cédrick
Hello Bert,
BF> Keep in mind we are on the beginners list. I do know where this is BF> used, and why. But if someone asks this on the beginners list it is BF> bad advice to give.
thanks for your clear words. I'll refrain from further giving that advice here.
I started with every Morph having its own step method for the animation. Then I found I needed exactly controlled synchronisation and ended up with one transparent Morph (subclassed the model from Morph instead of Object) with one central step method to animate everything.
That's how I ended up with doOneCycle.
Other use case: the model is rally busy with a simulation but knows when to draw the animation. And it needs *every* Morph redrawn.
So how to solve this? Send drawOn: in the step method and send step from the model?
In searching I found World>>restoreMorphicDisplay (from the World menu) and WorldState>>displayWorldSavely
Any pointers on how to control morphic display?
Thanks,
Herbert
2008/5/21 Herbert König herbertkoenig@gmx.net:
Hello Bert,
BF> Keep in mind we are on the beginners list. I do know where this is BF> used, and why. But if someone asks this on the beginners list it is BF> bad advice to give.
thanks for your clear words. I'll refrain from further giving that advice here.
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Thanks for both having this discussion.. I learned something again and this is somewhat the aim of the beginner list... Your complementary posts are nice to me.
Cédrick
On 21.05.2008, at 10:33, Herbert König wrote:
Hello Bert,
BF> Keep in mind we are on the beginners list. I do know where this is BF> used, and why. But if someone asks this on the beginners list it is BF> bad advice to give.
thanks for your clear words. I'll refrain from further giving that advice here.
I started with every Morph having its own step method for the animation. Then I found I needed exactly controlled synchronisation and ended up with one transparent Morph (subclassed the model from Morph instead of Object) with one central step method to animate everything.
Sounds great so far ...
That's how I ended up with doOneCycle.
... but I have no idea how this comes into play here.
Other use case: the model is rally busy with a simulation but knows when to draw the animation. And it needs *every* Morph redrawn.
So how to solve this? Send drawOn: in the step method and send step from the model?
No - to mark a Morph for redraw, send #changed to it (or #invalidRect:).
In searching I found World>>restoreMorphicDisplay (from the World menu) and WorldState>>displayWorldSavely
Any pointers on how to control morphic display?
Well, this example does not quite fit into the Morphic logic. Fortunately, Squeak is malleable enough so you can still do what you want, as you found out already :)
Morphic normally forces you to break up the computation into small steps. It has a mainloop that repeatedly evaluates doOneCycle, which dispatches events, calls the step methods, and redraws. What you appear to want to do is run that loop yourself inside your simulation. And indeed repeatedly calling doOneCycle does exactly that. So for that specific use case it might actually be the best way to do it.
It makes sense if your image is customized to run exactly that one application, and you control what is available and what not. But it would interact badly with other Morphs. Imagine you wanted to run two copies of your simulation at the same time. That's a piece of cake with "well-behaved" morphs, you just duplicate it via its green halo handle and it works. But it would break spectacularly if you messed with the main loop.
- Bert -
Hello Bert,
That's how I ended up with doOneCycle.
BF> ... but I have no idea how this comes into play here.
easy question. Not knowing, groping around and taking the first thing that solves (seems to) the problem. :-))
Thanks for the remainder of your reply!
On 20.05.2008, at 05:30, Sven Schott wrote:
c := OrderedCollection newFrom: { 1. 5. 8. 45. 23. 3. 20 }. String newFrom: c
but I get the following: 'Error: Improper store into indexable object'. What I was expecting was:
1584523320
I eventually figured that it was because I was using Ints instead of Characters because this works fine:
str := OrderedCollection newFrom: { $a. $g. $t. $e }. str as: String
So, the question is why do I get the error?
Because generally in Smalltalk we prefer to be explicit about what should happen, and have an error raised when something is unexpected, rather than silently second-guessing the programmer's intention.
For example, I would not have expected '1584523320' as a result but a String made of Characters encoded using the integers given (i.e., 45 would be $- because 45 is the Unicode value for "-").
I'd write your example like this
#(1 5 8 45 23 3 20) inject: '' into: [:string :each | string, each asString]
and to get my behavior:
String withAll: (#(1 5 8 45 23 3 20) collect: [:c | c asCharacter])
The difference is that in the first example, each element is converted to a String (#asString) and then concatenated using the #, method of String, in the second each element is converted to a Character (#asCharacter) and then a new String is formed out of the resulting array of characters.
Note that for literal objects you should use the literal array syntax as I did above. The "brace arrays" are meant for putting expressions between the dots, evaluated each time the code is executed (literal arrays are compiled only once so they are vastly more efficient).
- Bert -
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
cdrick -
Herbert König -
Karl Ramberg -
Sven Schott