taskSwarm - Tasks: task #1132, Resolve issues of runtime...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #1132: Resolve issues of runtime compatability

Submitter:  Bill Northcott <northcob>
Submitted:  -
   
 
Category:  MacOS X port Should Start On:  Mon 08 Jul 2002 02:00:00 PM UTC
Should be Finished on:  Sat 08 Mar 2003 01:00:00 PM UTC Priority:  2
Status:  None Privacy:  Public
Assigned to:  None Percent Complete:  50%
Open/Closed:  Open Effort:  0.00

Tue 21 Jan 2003 12:12:05 AM UTC, comment #3: 

This appears to not be a problem as long as we don't need the Cocoa gui.
Swarm code is running on MacOS X

Bill Northcott <northcob>
Group Member
Thu 03 Oct 2002 02:06:55 AM UTC, comment #2: 

One caveat: before swapping out the local version of "libobjc", we need to test that the ObjC package version they use currently in Cygwin works with Swarm, because as Marcus notes, historically Cygwin didn't include the ObjC compiler or runtime as part of Cygwin,and supporting MacOS X can't be at the expense of support under Windows (since probably half our installation base is probably on Windoze).

Alex Lancaster <alexl>
Group administrator
Thu 03 Oct 2002 01:57:18 AM UTC, comment #1: 

We should merge our local changes to libobjc (where necessary/possible) back into the mainline GNUStep libobjc.  Marcus Daniels in a post to swarm-support on 2002-10-01, identified the following reasons (and solutions) for the historical packaging of libobjc inside Swarm itself.

"libobjc is in Swarm for three reasons.

   1) Historically, Cygwin has not included the Objective C compiler or the runtime.  Because it was necessary to pull the runtime into the Java environment, it was going to be necessary to have it on hand in order to link it into a DLL.  (Unlike the Unix shared library model,Windows DLLs are fully resolved links.)

   2) There have been small but significant fixes for the sake of 64 bit systems like Tru64 in the Swarm copy of the libobjc runtime. Packaging libobjc with Swarm was an easy way to provide control over such things, e.g. when the fix was fragile and potentially bounded to known usages in Swarm.

   3) At the time, Objective C was pretty much dead.  Apple has brought Objective C back to life to some extent, and it would now make sense to identify the fixes and feed them back into the mainline (when there isn't an alternative fix in the modern sources).  Note, the mframe code lives in the Swarm copy of libobjc, and would need to be merged with GNUstep, if it still has that (again, there are a number of Swarm-private changes to that code, which was taken from an old,stale codebase).  mframe is used for taking apart forwarded call frames for resending to Java by FCall.

There should be no problem merging Swarm with GNUstep, since the Objective C data structures are the same.  Note, however, that the phase-oriented programming model is different enough that in practice it would be no more `natural' to use GNUstep Objective C than Java."


Alex Lancaster <alexl>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Digest:
   task dependencies.

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 9 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2003-01-21 northcob Percent Complete10% None
    start_date1026172800
    end_date1047168000
2002-12-29 northcob Percent CompleteNone None
    start_date1026198000
    end_date1039420800
2002-10-03 alexl end_date1039478400
2002-10-03 alexl start_date1026259200
2002-07-10 northcob end_date1026259200

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code