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

[Rick Riolo]

I now understand what's going on with mousetrap.
I ran it with those switches on, and indeed lots of 
traps were triggered.  What I was seeing in the graphical display was the 
end result when all was done...a pattern of red and black
that wasn't changing, because it was all done.
it all happens so fast I don't see the initial
single dot nor the growing firings.

re market: I will try to arrange for getting a screen
dump to you.  basically I see those graphs as on
the swarm examples page, except when they first come up
the part of the frames with the graph is a very small
part of the frame, and the label parts of the frames
takes up most of the frame.  If I then stretch the
frame (horz) the graph parts then not only grow
but grow relative to the label parts, so that the graph
parts take up more of the frame (and become 
perfectly legible).  the label parts still take up
more of the frame than I see in your examples, but
its not really a problem.

that is, for usage histogram and accuracy frame,
when I first press go, they come up with data part
of frame taking up about 1cm wide in a total frame
width of 10+cm.  the label part (the sunken label region)
takes up about 7cm.

for the price frame, the graph comes up with
the data part using 6cm wide, label part about 
2-3cm...it looks fine.

if I stretch the accuracy or usage frame horiz to total
frame to 20cm wide, the data part (graph or histgram)
occupies 10-11cm, the label part about 7cm.

in short, when I stretch these the data part goes
from taking about 10% of horz width of the frames to
taking over 50%.

They all seem to be displaying the graphs/histogram
bars just fine.

perhaps is something odd in my X or tck/tk setup?
(though as far as I know I have pretty much
out of the box setup of those for hpux 9.05).

Anyway...this is not a serious problem now that I know
i an stretch the graphs and make the data legible;
its more of an oddity (especially that the one graph, price,
starts up just fine while the others don't---maybe
that's because it only has one column of labels,
whereas the others have two columns of labels,
so they are wider).

So...I think everything is working (at least everything
that you expect to be working).

 - r

Rick Riolo                       address@hidden
Program for Study of Complex Systems (PSCS)
1061 Randall Lab     University of Michigan
Ann Arbor MI 48109-1120
http://pscs.physics.lsa.umich.edu/rlr-home.html

On Thu, 26 Oct 1995, Nelson Minar wrote:

> Date: Thu, 26 Oct 95 10:23:15 MDT
> From: Nelson Minar <address@hidden>
> To: address@hidden
> Cc: address@hidden
> Subject: Re: mousetrap; tee; globalTkInterp eval: naive-use 
> 
> 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.
>