Re: mousetrap; tee; globalTkInterp eval: naive-use

[Nelson Minar]

We're having a general problem here in that it's hard for me to tell
folks what a correct Swarm simulation looks like, and it's hard for
you to tell me what you're seeing. Any ideas how to make this
communication easier? Screen dumps should help, I think.

>markets graphs are ok now, too: they start out a little
>narrow, but if I expand the wframes, the graphs become
>perfectly readable.

I'm suprised at this - the default graph should be readable, and I
can't think offhand what the problem is. The market pictures in
  http://www.santafe.edu/projects/swarm/examples/
are pretty much what they look like on my screen. What's different on
yours?

>mousetrap still doesn't do anything when I hit go

As Roger said, what this should do is draw a red dot in the middle
against a dark grey background, then an expanding cloud of red dots
(mousetraps firing) until the whole screen is consumed. The time
series graphs do not update. Two things could be happening:

something is wrong with the schedule code, so that mousetraps aren't
firing. Mousetraps is currently the most complicated schedule code.

something is wrong with the display code, so you don't see updates.

Try setting the "print trigger events" and "print same tick triggers"
options in the form both to 1.  That should print out textual data
like

mousetrap at x: 20, y: 20 triggered at time: 0
mousetrap at x: 20, y: 19 triggered at time: 5
mousetrap at x: 21, y: 17 triggered at time: 9
triggering mousetrap at same timestep at time: 9
mousetrap at x: 18, y: 16 triggered at time: 9
mousetrap at x: 19, y: 19 triggered at time: 11
triggering mousetrap at same timestep at time: 11
mousetrap at x: 20, y: 18 triggered at time: 11
triggering mousetrap at same timestep at time: 11
mousetrap at x: 22, y: 16 triggered at time: 12
mousetrap at x: 19, y: 16 triggered at time: 12

(Ginger, does yours really show them all at time 0? That's a bug.)

>(except it does become top's top cycle burner, so its
>doing something...)

Hmm, is your X server getting busy, too? On my version, mousetraps
doesn't exit when it's done and so we busy loop redrawing the screen,
which chows a lot of CPU and loads the X server down. That's only
after the simulation has done its thing.

>I tried to tee some output from my model to a file,
>and it didn't work (i'm just printf-ing to stdout).
>the output printf's to screen I start in just fine.

This is really odd - printf is printf, we aren't doing anything
strange. tee works for me under linux. The only thing I can think of
us that somehow tcl or libtclobjc is interfering with your pipes. Does
normal redirection
  axelcult > foo
work? Don't forget that you might have buffered writes, so it won't
write to disk until, say, 8k of data.

>I also wanted to change the background of my Grid2d/ZoomRaster
>display to white (its black by default).

features! :-) I believe the only place where "background" makes sense
to Raster is the erase method, where it's hardwired to use Black.  One
way to change this would be to subclass Raster (or ZoomRaster) to
override the erase method. Another would be to add a "setBackground"
method to Raster for you to use - is this generally useful? I really
should add that as an option to all widgets, come to think of it.

>       [globalTkInterp eval: "%s configure -bg white", zoomRasterWidgetName ];
>        // next two just for fun...
>       [globalTkInterp eval: "button .b -text hi -command exit  -bg green" ];
>       [globalTkInterp eval: "pack .b" ];

That's awfully sporting of you!

In general, I don't expect users to be using globalTkInterp. You're
welcome to, and you'll have to if you write widgets of your own, but
it's the sort of lowlevel stuff I hope most Swarm programmers never use.

The reason the background didn't work is because Raster is just barely
a Tk object at all. All it does is create a frame to scribble in, then
does the rest via Xlib. Similar code would work to set the background
of, say, a button.

The reason your button code didn't work is becasue you packed it into
the frame ., and I supress mapping of frame . (easier to create my own
toplevels so I have handles to them). If you did something like
  toplevel .foo; button .foo.b; pack .foo.b
it will work.