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

[Paul Johnson]

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