Been reading up on the new Mac OS X developer IDE, preparatory to a
port of Cello to OS X, hence first a port of Freeglut to OS X.
Turns out they have worked out a way to link C/C++ on the fly, so you
don't have to go thru a whole link every time you recompile one
source.
They point out that this also means you can continue from an error
without quiting the failed run, just edit, recompile, and continue
from the error.
Hmm. I wonder what happens to existing C++ instances. :)
Anyway, this all seems so familiar, just can't figure out why....
:)
kenny
·······@nyc.rr.com (Kenny Tilton) writes:
> Been reading up on the new Mac OS X developer IDE, preparatory to a
> port of Cello to OS X, hence first a port of Freeglut to OS X.
>
> Turns out they have worked out a way to link C/C++ on the fly, so you
> don't have to go thru a whole link every time you recompile one
> source.
>
> They point out that this also means you can continue from an error
> without quiting the failed run, just edit, recompile, and continue
> from the error.
>
> Hmm. I wonder what happens to existing C++ instances. :)
>
> Anyway, this all seems so familiar, just can't figure out why....
Could this mean that correct (albeit incompatible) handling of method
dispatch is far behind?
> Could this mean that correct (albeit incompatible) handling of method
> dispatch is far behind?
What do you mean by this? C++ will never have polymorphic free
functions (it does not fit with the zero-overhead principle), but
there is a proposal to add multimethods to the language.
·······@mindspring.com (Rayiner Hashem) writes:
> > Could this mean that correct (albeit incompatible) handling of method
> > dispatch is far behind?
>
> What do you mean by this? C++ will never have polymorphic free
> functions (it does not fit with the zero-overhead principle), but
> there is a proposal to add multimethods to the language.
I'm talking about the notion that doing the wrong thing with zero
overhead is better than doing the right thing but having a cost.
The same could be asked about the idea in C of having x+1 yield a
value that only "might" be larger than x, because it's both faster
(just one instruction) and more compact (you can guarantee an int
result) to risk it end up being instead smaller than it is to do
the right thing.)
Some of us, at least, think that when correctness is at stake, you
have to accept the choice that has cost, i.e., is correct. You might
or might not be one that is led to that seemingly dictated choice.
One's mileage on such matters of freedom may, I suppose, vary on this
point. Nevertheless, the point of my remark was to highlight the
inane nature of method dispatch whose definition is based on speed
rather than correctness. Can one learn to program around it? I
suppose they must, just as they've learned to program around
unreliable addition operations. Does that make it "better"?
Certainly neither definitively nor canonically so. Hence my comment.
> Turns out they have worked out a way to link C/C++ on the fly, so you
> don't have to go thru a whole link every time you recompile one
> source.
This is nothing new, even for C/C++. MS, IBM, Lucid, and Sun have had
incremental C/C++ compilers for a long time now. I wonder how Apple
did it, though, since GCC is certainly not an incremental compiler.
Maybe they've just got an incremental linker in there...
> Hmm. I wonder what happens to existing C++ instances. :)
If the ABI changes as a result of the recompile, they probably get
trashed. No C++ environment I know of retains enough code information
at runtime to automatically update existing instances.
> Anyway, this all seems so familiar, just can't figure out why....
Maybe you're thinking of the POP-2 language? As far as I can tell, it
was the first one to feature native incremental compilation, sometime
in the early 1970's. Supposedly, MacLisp at MIT was also incrementally
compiled, but just a bit later. There is a nice thread about the
history of incremental compilers here:
http://www.poplog.org/talk/comp.lang.pop/1993/msg00168.html
·······@mindspring.com (Rayiner Hashem) writes:
>> Anyway, this all seems so familiar, just can't figure out why....
> Maybe you're thinking of the POP-2 language? As far as I can tell, it
> was the first one to feature native incremental compilation, sometime
> in the early 1970's. Supposedly, MacLisp at MIT was also incrementally
> compiled, but just a bit later. There is a nice thread about the
> history of incremental compilers here:
> http://www.poplog.org/talk/comp.lang.pop/1993/msg00168.html
Lisp 1.5 had incremental compilation as early as 1962
--
~jrm
> Lisp 1.5 had incremental compilation as early as 1962
Was Lisp 1.5 a native mode compiler? An incremental native compiler is
very different from an incremental interpreter. An interpreter lends
itself naturally to incremental compilation, while native code
doesn't.
Rayiner Hashem writes:
> Was Lisp 1.5 a native mode compiler? An incremental native compiler is
The Lisp 1.5 manual is available online. It looks like it indeed had a
native code compiler.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
·······@mindspring.com (Rayiner Hashem) writes:
> > Turns out they have worked out a way to link C/C++ on the fly, so you
> > don't have to go thru a whole link every time you recompile one
> > source.
> This is nothing new, even for C/C++. MS, IBM, Lucid, and Sun have had
> incremental C/C++ compilers for a long time now. I wonder how Apple
> did it, though, since GCC is certainly not an incremental compiler.
> Maybe they've just got an incremental linker in there...
Yes. I think Xcode compiles stuff in the background, but I've not
used it so I can't say how well it works, and ZeroLink is the buzzword
for some kind of linker technology (I'm not sure "incremental" is
really the right word, though).
It does all seem a fearsomely wrong-headed approach to the problems of
the edit-compile-link cycle time.
Cheers,
mwh
--
Strangely enough I saw just such a beast at the grocery store
last night. Starbucks sells Javachip. (It's ice cream, but that
shouldn't be an obstacle for the Java marketing people.)
-- Jeremy Hylton, 29 Apr 1997
In article <···························@posting.google.com>, Rayiner
Hashem <·······@mindspring.com> wrote:
> > Anyway, this all seems so familiar, just can't figure out why....
> Maybe you're thinking of the POP-2 language? As far as I can tell, it
> was the first one to feature native incremental compilation, sometime
> in the early 1970's. Supposedly, MacLisp at MIT was also incrementally
> compiled, but just a bit later. There is a nice thread about the
> history of incremental compilers here:
> http://www.poplog.org/talk/comp.lang.pop/1993/msg00168.html
What happened to Forth? IIRC Forth supported incremental compilation in
the early '70s.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Kenny Tilton writes:
> Been reading up on the new Mac OS X developer IDE, preparatory to a
> port of Cello to OS X, hence first a port of Freeglut to OS X.
>
> Turns out they have worked out a way to link C/C++ on the fly, so you
CONGRATUL~1.ONS
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <·······@mclink.it> wrote:
> Kenny Tilton writes:
>> Been reading up on the new Mac OS X developer IDE, preparatory to a
>> port of Cello to OS X, hence first a port of Freeglut to OS X.
>>
>> Turns out they have worked out a way to link C/C++ on the fly, so you
>
> CONGRATUL~1.ONS
I think you mean: C:\ONGRAT~1.OSX :)
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews