Re: MacOS X first results

[Bill Northcott]

> > with the libtool in Swarm on MacOS X.  When I have rebuilt everything
> > against Apple's X11, I will try updating it to the current 1.4.3
> > verson.

> Well, maybe we should have a look at the fink version of libtool ;-)
> I felt I was too close to a solution, and I wanted to see how close
> exactly. That allowed me to go one step further, and see the next bug.\

GNU libtool is included in the Swarm distribution, but it is version 
1.4.2.  I checked out differences against the current 1.4.3 and amongst 
other things, sed has been made configurable, either this was done for 
MacOS X or some other BSD derivatives have sed problems with libtool.  I 
will see if I can workout how to update the Swarm sources.

> >> methodForSelector:@selector(drop)];
> >>    dropper(self, M(drop));
> >> (But my grasp on ObjC is shaky, correct me if this is a blunder...)

but undoubtedly better than mine

> >
> > Do you use Project Builder?  It really is very helpful.  When you had
> > found _i_Object_s__drop (self, M(drop)) in DefObject.m, all you had to
> > was
> > select the text, go to 'Find>Batch Find Selected Text' in the menu
> > bar. In
> > a few seconds, because all the code is indexed, you would have seen
> > this -
> > macro.h:18
> > #define DROP(obj) _i_Object_s__drop (obj, M(drop)) .
> >
> > This macro is conditional on #ifdef METHOD_FUNCTIONS.  Clearly l:348 
in
> > DefObject.m should be
> > DROP(self);
> > and probably macros.h l:18 should be deleted and l:26 (#define
> > DROP(obj)
> > [obj drop]) should be unconditional.  I will check with the others and
> > fix
> > the cvs.
> >
> > Then the problem is fixed not kluged.
> >
> > If Paul is reading this, do we get the error on x86 builds with
> > METHOD_FUNCTIONS.

> Arhem. Point taken on the search, but it seemed clear to me that the
> intent of the drop as it stands in DefObject.m, line 348 was to bypass
> dispatch (why is obscure to me, however.) There is even a comment to
> that effect. Using DROP(self) as you propose clearly reinstates the
> dispatch, and could lead to new problems, no?

No idea!

> My code was a way to do a dispatchless drop. Maybe we need another
> macro for that call, and certainly I think that the
> void (*dropper)(id, SEL) = (void (*) (id, SEL)) [Object
> methodForSelector:@selector(drop)];
> should be abstracted out in some static startup code for efficiency, so
> my solution was temporary, but please give me some credit for it not
> being totally unthoughtful...

Sorry.

> Trying to configure swarm so -fgnu-runtime is in the CFLAGS breaks
> compilation (in predicates)...
> So maybe I should follow your advice and try with a more recent gcc.
> Will keep you updated.

Thanks
Bill

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.