Hi mcclim devels,
Well, I'm finally getting around to learning how to write a mcclim app. For a change, I figured i'd read the documentation first this time.
Granted this is a minor gripe but when I run the presentation example given in the manual, the manual says I should see that output "the 15 or The third month" when I click on the shown objects. In fact I get "the 15 of THE". Is the manual in error or is something wrong here?
Thanks,
Cyrus
Cyrus Harmon ch-mcclim@bobobeach.com writes:
Granted this is a minor gripe but when I run the presentation example given in the manual, the manual says I should see that output "the 15 or The third month" when I click on the shown objects. In fact I get "the 15 of THE". Is the manual in error or is something wrong here?
This is a bug that Goatee is able to handle, but Drei is not. It happens due to the default present/accept methods for presentation types (which is quite a kludge in itself) that just invokes print/read on the objects and try to wing it that way. This works very poorly, since the presentation of a string will then be "string", but that can't be read in by the corresponding default accept method, because it uses `read-token' to get the string, and that removes the quotes (so it'll be interpreted as a symbol by the reader, but that won't work well if the string has whitespace in it, this is why you only see the first word, and in uppercase). Goatee is somehow able to detect that the result of presenting the object to a string is not acceptable back in, and thus puts in an "accept extent" (roughly, a reference to the actual object that is returned instead of attempting to parse the string). I don't quite know why Goatee detects it, it's probably an accident. :-)
In any case, the central problem is accepting textual input of presentation types that do not have accept methods. Bad, bad, bad.
Troels Henriksen athas@sigkill.dk writes:
In any case, the central problem is accepting textual input of presentation types that do not have accept methods. Bad, bad, bad.
This particular issue could fortunately be fixed rather easily by using inheritance and fixing the present method for strings. Should work now in Drei as well as Goatee.
Ok, so while this fixes things, it has the unfortunate effect of putting the text "The third month" in quotes in the prompt box. Not a showstopper, obviously, but not as nice as one would like for a piece of expository code.
Also, the arguments prompting thing in general just feels really hokey. Lots of little bugs. I imagine they could be cleaned up, but this is one of thing that scared me away from mcclim initially and I imagine others might feel similarly. Not to be too negative, but I want to 1) point it out and 2) learn enough so that I might be able to do something about it.
Thanks,
Cyrus
On Feb 10, 2007, at 1:12 PM, Troels Henriksen wrote:
Cyrus Harmon ch-mcclim@bobobeach.com writes:
Granted this is a minor gripe but when I run the presentation example given in the manual, the manual says I should see that output "the 15 or The third month" when I click on the shown objects. In fact I get "the 15 of THE". Is the manual in error or is something wrong here?
This is a bug that Goatee is able to handle, but Drei is not. It happens due to the default present/accept methods for presentation types (which is quite a kludge in itself) that just invokes print/read on the objects and try to wing it that way. This works very poorly, since the presentation of a string will then be "string", but that can't be read in by the corresponding default accept method, because it uses `read-token' to get the string, and that removes the quotes (so it'll be interpreted as a symbol by the reader, but that won't work well if the string has whitespace in it, this is why you only see the first word, and in uppercase). Goatee is somehow able to detect that the result of presenting the object to a string is not acceptable back in, and thus puts in an "accept extent" (roughly, a reference to the actual object that is returned instead of attempting to parse the string). I don't quite know why Goatee detects it, it's probably an accident. :-)
In any case, the central problem is accepting textual input of presentation types that do not have accept methods. Bad, bad, bad.
-- \ Troels /\ Henriksen
Cyrus Harmon ch-mcclim@bobobeach.com writes:
Also, the arguments prompting thing in general just feels really hokey. Lots of little bugs. I imagine they could be cleaned up, but this is one of thing that scared me away from mcclim initially and I imagine others might feel similarly. Not to be too negative, but I want to 1) point it out and 2) learn enough so that I might be able to do something about it.
Indeed, it's all very brittle. Unfortunately, it's hard to write something more robust because you're not (theoretically) allowed to associate any state with the input-editing-stream that cannot be inferred from the buffer contents. I tried to put a limit on the foot-shooter ammunition by preventing the user from editing previous input in Drei, but numerous protests suggest that this might not be a good idea. :-)
I hope someone can figure out how to write something robust on top of the input-editing-stream protocol, because from a programmer perspective, the idea of treating input editing as stream I/O is pretty cool and neat (and makes writing accept methods quite nice).
-
Cyrus Harmon -
Troels Henriksen