octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave Compiler


From: John W. Eaton
Subject: Re: Octave Compiler
Date: Wed, 18 Feb 2004 13:27:45 -0600

On 18-Feb-2004, JD Cole <address@hidden> wrote:

| I agree with you here, and it was definitely one of the reasons  octave 
| -> C++ would be cool. As an intermediate step, it may not be "too" 
| difficult to convert directly to Octave-based stand alone functions, 
| however, since we'd be linking with the Octave libraries, the generated 
| code would still fall under GPL since the whole of Octave source is GPL. 
| (As opposed to LGPL. If you're not clear on this I'd be happy to explain 
| more.) A similar problem would arise when you tried to convert a script 
| file which makes use of other scripts which also fall under 
| GPL...especially so if those were .oct files which could also be 
| converted using the compiler.

Yes, any translated Octave code or any code that depends on the Octave
libraries would be a derivative work, so it would have to be licensed
under terms that are compatible with the GPL.

| NOTE: A couple of caveauts to debugging Octave code. 1) Octave source 
| makes have use  of inlined functions, so often when you arrive at a 
| breakpoints which lies within your code. When stepping through code I 
| have written, it hasn't been uncommon that I see none of my original 
| code. 2) Compiler optimizations will further obfuscate your code. For 
| example using "-g -O2" is sometimes confusing to step through.

I find it nearly impossible to use gdb to debug anything compiled with
g++ -g -O2.  So when I really must use a debugger to check out what is
happening inside Octave, I recompile at least all the parts I want to
debug with only -g.  Otherwise too many local variables are
unavailable and the correspondence between the source code and what
the debugger sees is terrible.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]