Re: [Swarm-Support] Followup: found work-aroundfor missing~/swarmarchiver.scm too

[Rick Riolo]

paul etal,

as i recall, when swarm first came out,
gcc objc was accepting msgs to nil with no complaint,
as the objC specs said it should.

then in some version of gcc after that, either as the
default or via some gcc switch, it would produce programs
that would crash as paul describes when msgs got sent to nil.
(i recall that was a big help for beginners trying to
locate problems in their programs!)

as hinted at above, what i don't recall was if that
behavior required setting some switch in gcc,
or if it was the default.

in any case, i am confirming that at one time the swarm programs
we ran around did stop on msgs being sent to nil.

- r

Rick Riolo                           address@hidden
Center for the Study of Complex Systems (CSCS)
4477 Randall Lab
University of Michigan         Ann Arbor MI 48109-1120
Phone: 734 763 3323                  Fax: 734 763 9267
http://cscs.umich.edu/~rlr

On Wed, 16 Aug 2006, Paul Johnson wrote:

> Date: Wed, 16 Aug 2006 20:36:54 -0500
> From: Paul Johnson <address@hidden>
> To: Swarm Support <address@hidden>
> Subject: Re: [Swarm-Support] Followup: found work-aroundfor
>     missing~/swarmarchiver.scm too
>
> Marcus G. Daniels wrote:
> > Bill Northcott wrote:
> >
> >> On 16/08/2006, at 4:42 AM, Paul Johnson wrote:
> >>
> >>> Yesterday I was bug shooting a problem in and older FC4 and found
> >>> that gcc treats 50 differently than 50.0 when used as a (double)
> >>> parameter in a draw from a normal distribution, and the value 50 was
> >>> converted to 0.  It does not do that anymore in FC5.
> >>>
> >> C is a strongly typed language.  You can't just feed an integer
> >> constant (50) to a function that expects a double and have any
> >>
> >> ..
> >>
> > guarantee about what will happen.  If you need a floating point Let's 
> > consult ISSO/IEC 9899
> > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
> > --
> >
> >
> I understand Bill's point that objective c is supposed to allow messages
> to nil. All I'm saying, which nobody seems to confirm, is that the Swarm
> runtime used to stop when a message was sent to nil.  I mean, it used to
> segfault and gdb would backtrace to expose the problem.  It may be that
> I had a special set of hacks on my Swarm libraries, I don't know.  But I
> remember distinctly that this happened, because back in 2000, when we
> went to Utah State for an excellent Swarmfest, the ObjC message to nil
> behavior was discussed and debated at some length (with the Next/Apple
> lovers saying "if you don't like it you are dumb" and the Java people
> saying "but it is very prone to error").
>
> But this discussion is distracting me from my major purpose.  Why are
> lispAppArchiver and lispArchiver nil objects after initSwarm() is done,
> and what can I do about it.  Those things are nil, I can tell from
> looking at them inside gdb.  My "feeling" is that, when Swarm used to
> crash on messages to nil, it would have stopped and forced me to fix
> it.  This newer behavior of ignoring messages to nil allows the problem
> to slide by.  And it means there should be more error checking inside
> Swarm library code that creates objects.  Instead of assuming things
> work, we need an if statement of the sort used after malloc commands, to
> make sure the object really gets allocated.  I'm a pretty literal guy,
> and expect I'd start with
>
>    object = [Thing create: self];
>
>    if (object == nil) {raiseEvent(InvalidArgument,"Your object was not
> created");}
>
> Scott's idea of overriding the nil_method is good too and I'll try that,
> but I'm not sure what scope it would have.  Would it catch allocations
> inside Swarm, or just my code?
>
> I'm reading Swarm code and trying to remember how to step through it in
> gdb.  I'm a bit confused about how to set breakpoints on installed
> libraries, as opposed to *m files in the local directory.  I will figure
> that out, or ask again.
>
> I'm in some personal & professional tumult this week, but hopefully next
> week I'll stop writing idiotic emails long enough to think a clear thought.
>
> Sorry for firing off yesterday.
>
>
> --
> Paul E. Johnson                       email: address@hidden
> Professor, Political Science          http://pj.freefaculty.org
> 1541 Lilac Lane, Rm 504
> University of Kansas                  Office: (785) 864-9086
> Lawrence, Kansas 66044-3177           FAX: (785) 864-5700
>
> _______________________________________________
> Support mailing list
> address@hidden
> http://www.swarm.org/mailman/listinfo/support
>