Re: Logo

["Ian Bicking" <bickiia@earlham.edu>]

Malonowa <malonowa@wanadoo.fr> wrote:
> > I know things like Gnumeric use it to have an underlying
> > spreadsheet widget upon which you can place annotations -- like
> > making arrows and stuff.  It seems like exactly the sort of
> > functionality that would be nice for Logo, with all the line-drawing,
> > superimposing of pictures, and all that being done for us.  Heck,
> > even printable.  Even if we don't use the power of it for a long time,
> > it seems like the Right Thing as well as the easy thing.
> 
> I think here that I'd personally like a fast, flicker-free raster graphics
> interface it wouldn't be any use to me otherwise.

I don't really know how it works.  For now it probably doesn't matter 
-- whether we use the Canvas or raw Xlib or whatever, it won't effect 
the overall design.

> > Other implementations of multiple turtles that I've seen is a simple
> > step-wise threading.  One primitive for one turtle, one primitive for
> > the next.  Which makes it easier to think about it will work together
> > for the new programmer, but isn't what you want for the threading in
> > an interface.
> >
> > The other way might be to think about turtles in terms of
> > messaging (i.e., callbacks), which would fit nicely with the way
> > widgets work.  For most of the interface you can do things like say
> > "You turtle... do this", but there are the times when you want to
> > say "You turtle... do this while I go and do something else".
> >
> 
> We'd want to make this work for Win3.1 as well as mac for those heterogenous
> environments. Win3.1 doesn't support threading does it? We'd certainly wan't these
> turtles to be event driven and callbacks is a good way of doing this.

For us, callbacks would probably be the easiest way to deal with it. 
But that's not the way children will usually think about multiple 
turtles, particularly the graphical turtles.  These should run in 
parallel.  If things are done by callbacks, you have to make sure 
that none of the callbacks are long-running.  Breaking things up 
into short-running pieces is not easy programming.

This doesn't need OS support.  The CoCo III certainly didn't have 
threading, but it's Logo had multiple turtles.  Just a matter of 
simple, cooperative multitasking.  It can be a fair amount more 
predictable than preemptive multitasking, too.

The problem is, doing this requires a lot of support from the 
interpreter.  UCBLogo is uniturtle, so it could be hard.

> > > The interpreter needs to be extensible in a similar way to Wish from TCL/TK.
> >
> > How do you mean?
> 
> Making it simple to add your own commands to the interpreter to produce your own
> specialised one with fast code in C or indeed any language binding. The
> interpreter supplies functions to call to register commands that become available
> to the language.

I know nothing about shared libraries and that stuff.  With a 
recompile, I think this is already fairly simple from UCBLogo.  
Doing it without a recompile is a bit harder.
 
> > > Back to logo,  can we make some firm decisions now as to how we'd deal with
> > > widgets and windows in logo? Then we could get something going. Personally,
> > > I like the idea of multiple turtles a bit like objects. What do you think of
> > > this.
> >
> > I think we first need to figure out about threading, multiple turtles,
> > and that stuff.
> 
> Multiple turtles definitely. Threading?

Not so much *if* we want them, but how to do it.  I think it's the 
hardest part of what we want to do.

> > We may just want to make the base widgets available, sans-
> > turtles, to the Logo environment.  This is quite neutral to any
> > particular higher-level representation.  I don't think we want to
> > necessarily include every widget, as I've gotten the impression that
> > other language bindings for GTK find it difficult to keep up with the
> > maintenance.  Logo doesn't have to have a complete graphical
> > environment, just a decent one.
> 
> I wouldn't want to write every widget. Just the most needed ones right now. If the
> interpreter is easily extended then users could add their own which could be
> included in the main distro.
> 
> > I don't think we can make the entire environment inside Logo.  In
> > particular, I don't think we'd manage to make a very good editor --
> > though maybe there's a nice text editting widget in GTK now?
> > Probably not good enough for our purposes.  Anyway, pieces like
> > that could quite possibly be controlled from Logo even if they are
> > otherwise black box.
> 
> GTK has a fairly decent text editing widget and there are already examples out
> there of adding colour syntax highlighting. This implementation should be powerful
> enough to write anything and writing it's own environment would be a good test for
> that.

Have we agreed on GTK?  It would be my preference, but we 
haven't really said it for sure.

Writing its own environment sounds good.  I think there's a good 
path from using the console that UCBLogo already has, to having a 
full environment, so we don't need to achieve any huge leaps to 
manage a good environment.
 
> > It's just the threading that worries me.  It's a can of worms, but I
> > think it might be essential...?
> 
> I've never written a program using threading so is it really essential? I've read
> a lot of postings here and there on this subject. It seems to be the "in thing"
> but I don't see many people really coming up with good arguments for it. My
> argument against it is that it could just complicate matters unnecessarily.

Threading under any other name is just as... well, annoying, most 
likely.  Anyway, whether we use OS-level threads or not (I too don't 
relish the idea), I think some sort of mechanism like this is 
necessary if kids are to do simple multiturtle stuff like:

hatch "runner [runawayfrom "chaser]
hatch "chaser [chase "runner]

runawayfrom :turtle
  while "true [
    make "myx xcor
    make "myy ycor
    make "otherx ask :turtle [xcor]
    make "othery ask :turtle [ycor]
    heading atan2 (:myx - :otherx) (:myy - :othery) 
      ;I think Logo has something easier than atan2 for this
    fd 10
  ]
end

to chase :turtle
  while near :turtle > 10 [
    ; all that heading stuff
    fd 15
  ]
  kill :turtle
end

Or something like that -- basically, both turtles are running around 
at the same time.  How do we manage that?


> > > Maybe if the turtles were defined in a similar way to Oberon modules? That
> > > seems fairly easy to understand and implement.
> >
> > How do you mean?
> 
> OK. I say this because UCBLogo can already deal with dynamically loaded external
> modules on disc. In Oberon from what I remember, you can have module files that
> contain code, implementation and interface. A bit like a Pascal Unit not
> surprisingly since it's the same guy.

The dynamic loading is, as I remember, pretty basic in 
functionality.  Basically, if you use an undefined procedure 
UCBLogo looks in a special directory to see if there is a file of the 
same name.  If so, it loads that file and tries to continue.

Basically lazy loading, but not like modules.  There aren't any 
namespaces or anything.
 
> These modules have a name eg.mymodule
> 
> In the interface of mymodule you declare your procedures and variables
> 
> you would call them simply by mymodule.foo or mymodule.var
> 
> The module is then loaded and data accessed or foo executed.
> 
> So we could have external turtles or a library of external turtles could be a
> nest. So a turtle becomes a file on it's own that you would hatch when you wanted
> it or would be hatched automagically if it's not already there.
> 
> So, TELL BILLY [CLOSE] would be like BILLY.CLOSE in oberon.

I was thinking about something like this for defining responses to 
events.  Each turtle could have its own set of procedures.  If you 
want a turtle to respond to a CLICK event, you simply define a 
CLICK procedure for that turtle.  If a procedure wasn't defined for 
that turtle, then it looked at the normal procedures (where CLICK 
might be defined to do nothing -- though for efficiency it would 
probably be better to set the widget not to respond to the event 
unless a turtle-specific procedure had been defined).

There's no reason that any procedure couldn't be redefined for each 
specific turtle.  All this would require is for the interpreter to be 
aware of the current turtle when it looked up functions.

You could define these turtle-specific procedures by, perhaps, 
control-clicking on a turtle (which might be a button, the classi 
turtle, or whatever) which would open up the text editor on its 
personal procedures.  And of course a primitive for turtles which 
aren't visible or for whom control-click has been overridden.
 
> I'm looking at the code for UCBLogo today so I'll get back to you when I'm done.
> Maybe we could involve the original author in these discussions.

I think he'd probably be helpful.  He is fairly active on the Logo-l list 
<logo-l@gsn.org>.  He doesn't seem to be doing any active 
developement on UCBLogo anymore except for the occasional bug 
fix, but he might be able to give us some help as to where we 
should be looking in the code.



--
Ian Bicking <bickiia@earlham.edu>