Send Octave-maintainers mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.cae.wisc.edu/listinfo/octave-maintainers
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Octave-maintainers digest..."
Today's Topics:
1. Re: Please build the JIT branch (Michael Goffioul)
2. Re: Compatability and an engineer's perspective (Jonathan Lister)
3. Re: Compatability and an engineer's perspective
(Jordi Guti?rrez Hermoso)
4. Re: Compatability and an engineer's perspective (Michael Goffioul)
---------- Forwarded message ----------
From: Michael Goffioul <address@hidden>
To: Max Brister <address@hidden>
Cc: address@hidden
Date: Sun, 15 Jul 2012 20:48:27 +0100
Subject: Re: Please build the JIT branch
On Sun, Jul 15, 2012 at 8:29 PM, Michael Goffioul <address@hidden> wrote:
On Sat, Jul 14, 2012 at 6:07 PM, Michael Goffioul
<address@hidden> wrote:
> For the record, I finally got it working. I had to hack the calling
> conventions in LLVM to disable the use of ST(0)/ST(1) registers to return
> multiple floating-point values. Then the generated assembly is compatible
> with MSVC ABI. What I don't understand is why that problem does not occur on
> 32-bits Linux. AFAIK the ABI to return aggregates are the same (except for
> who's popping the hidden pointer argument).
Thank you for looking into this. Calling conventions are a real pain.
I'm not sure if disabling ST(0)/ST(1) is a good long term solution as
we might run into issues trying to return some other type. I should
look at clang to see how they handle this issue (this might take some
time though).
I didn't disable ST(0)/ST(1), I just removed ST(1) as a possible return register. So {double,double} are now returned as a hidden pointer (while a single double is returned in ST(0), as it should be). I didn't test, but I'm wondering what LLVM will generate for code returning {float,float}. On x86-32 it should use EAX:EDX.
This problem might also appear on 32bit linux. I have a machine
running 32bit linux and am trying it now.
I wanted to try on my F16 box, but it only has LLVM 2.9. Is LLVM 3.0 absolutely required? The configure script succeeded, but the compilation failed as it couldn't find llvm/Support/TargetSelect.h.
I've upgraded to F17 (which uses llvm-3.0) and bingo! Exactly the same crash. See attachment for the disassembled part of the code calling octave_jig_cast_complex_any. It uses the same ST(0)/ST(1) to return the {double,double} aggregate. I'm wondering whether this can be considered a bug in LLVM, as this is definitely not x86-32 compatible.
After some research, I found out that it looks like the calling convention to return C99 double complex under x86-64. I traced down the change in LLVM to this commit [1], but oddly enough the commit message mentions x86-64, while it actually touches x86-32 conventions.
Max, do you have contacts with LLVM developers? It might be worth reporting/checking the issue. Personally, I don't have much time to follow that further.
Michael.
---------- Forwarded message ----------
From: Jonathan Lister <address@hidden>
To: address@hidden
Cc:
Date: Sun, 15 Jul 2012 18:02:53 -0500
Subject: Re: Compatability and an engineer's perspective
Wow thanks for all the feedback.
First, I don't think that you don't want MATLAB code to run in Octave. But it is now obvious that some of you do not care if Octave code runs in MATLAB.
I personally do not have MATLAB on my own machines. I do have MATLAB at work. The problem is that our organization's IT department is more or less controlled by a branch of the Department of Defense. Octave is currently not approved for use on the network, but I am working on that. Under tight budget constraints we have been forced to have so few licenses that having access to that tool is limited. For ~2000 employees (60% or more engineers) we only have 8 floating license seats. To make matters worse, we only have one seat of the Signal Processing Toolbox! I do signal processing all the time.
I can't do anything about the budget, but I can do my job and advocate for something other than MATLAB.
Most engineers I know have no clue about Octave. (I'm spreading the word!) MATLAB has been taught in our schools, is used by all major suppliers, and is known as the standard (for better or worse). Engineers, especially the babey boomer's generation here in the USA tend to be very conservative and risk adverse. Something different, no matter how good it is, is a risk. I'm fighting this all the time! I tend to embrace FOSS solutions. I've advocated for Linux since I was in high school, worked with Octave at home for about as many years, and use LibreOffice. I believe in what you guys are doing.
So, when I can take the Signal Processing Toolbox from Octave and run it in MATLAB it allows me to prove (in a more credible way) that Octave is a sound alternative. (I've done that, thus eliminating the constraint of only one seat of the Signal Processing Toolbox) If you write any portion of Octave toolboxes such that they will not run on MATLAB it is a risk that some portion of code that we develop will not run on a customer's machine who is running MATLAB. Industry is settled on MATLAB, and not being able to collaborate with customers and industry partners is a huge risk factor.
JAVA. I've developed specialized GUIs using the MATLAB/JAVA interface. Scroll panels, trees, tabs, splitpanes, and much more are not in the default MATLAB handles graphics system.
Jacob, no pressure here ;), but getting the IDE is a key for the engineers I know to be willing to adopt Octave. I've subscribed to your blog as well as most of the other summer of code participants. Keep us informed.
I might be able to help Ben Lewis with the Wavelets. It is an area of interest and I should be picking up an ATI short course at the end of February.
I think I can come up with a good oct2mat solution, but that will have to wait until this winter.
---------- Forwarded message ----------
From: "Jordi Gutiérrez Hermoso" <address@hidden>
To: Jonathan Lister <address@hidden>
Cc: address@hidden
Date: Sun, 15 Jul 2012 22:10:15 -0400
Subject: Re: Compatability and an engineer's perspective
On 15 July 2012 19:02, Jonathan Lister <address@hidden> wrote:
> Jacob, no pressure here ;), but getting the IDE is a key for the engineers I
> know to be willing to adopt Octave. I've subscribed to your blog as well as
> most of the other summer of code participants. Keep us informed.
Btw:
http://planet.octave.org/
- Jordi G. H.
---------- Forwarded message ----------
From: Michael Goffioul <address@hidden>
To: Jonathan Lister <address@hidden>
Cc: address@hidden
Date: Mon, 16 Jul 2012 09:03:20 +0100
Subject: Re: Compatability and an engineer's perspective
On Mon, Jul 16, 2012 at 12:02 AM, Jonathan Lister <address@hidden> wrote:
Wow thanks for all the feedback.
First, I don't think that you don't want MATLAB code to run in Octave. But it is now obvious that some of you do not care if Octave code runs in MATLAB.
I personally do not have MATLAB on my own machines. I do have MATLAB at work. The problem is that our organization's IT department is more or less controlled by a branch of the Department of Defense. Octave is currently not approved for use on the network, but I am working on that. Under tight budget constraints we have been forced to have so few licenses that having access to that tool is limited. For ~2000 employees (60% or more engineers) we only have 8 floating license seats. To make matters worse, we only have one seat of the Signal Processing Toolbox! I do signal processing all the time.
I can't do anything about the budget, but I can do my job and advocate for something other than MATLAB.
Most engineers I know have no clue about Octave. (I'm spreading the word!) MATLAB has been taught in our schools, is used by all major suppliers, and is known as the standard (for better or worse). Engineers, especially the babey boomer's generation here in the USA tend to be very conservative and risk adverse. Something different, no matter how good it is, is a risk. I'm fighting this all the time! I tend to embrace FOSS solutions. I've advocated for Linux since I was in high school, worked with Octave at home for about as many years, and use LibreOffice. I believe in what you guys are doing.
So, when I can take the Signal Processing Toolbox from Octave and run it in MATLAB it allows me to prove (in a more credible way) that Octave is a sound alternative.
You shouldn't have to run Matlab to prove that Octave is a sound alternative. You should run Octave instead.
(I've done that, thus eliminating the constraint of only one seat of the Signal Processing Toolbox) If you write any portion of Octave toolboxes such that they will not run on MATLAB it is a risk that some portion of code that we develop will not run on a customer's machine who is running MATLAB. Industry is settled on MATLAB, and not being able to collaborate with customers and industry partners is a huge risk factor.
Everybody is free to develop toolboxes in Matlab-compatible way or not. But I think the goal of octave-forge packages is to develop toolboxes primarily for Octave. It's not to develop toolboxes that can be used as a drop-in replacement in Matlab, allowing users to work around Mathworks license fees. I even think it's wise to do it that way. As someone mentioned a few months ago, Octave is not a concern for Mathworks. But doing what you suggest has the potential to change that.
JAVA. I've developed specialized GUIs using the MATLAB/JAVA interface. Scroll panels, trees, tabs, splitpanes, and much more are not in the default MATLAB handles graphics system.
Indeed. And you can do (at least partially) the same using the java package from octave-forge (except that java GUI does not work on OS X, because of limitations on that platform). But if you're thinking about mixing regular Matlab handle graphics object and plain Java GUI, then afaik you're using Matlab undocumented/unsupported internals and what you do now can break on the next Matlab release if Mathworks decides so.
Michael.
Jacob, no pressure here ;), but getting the IDE is a key for the engineers I know to be willing to adopt Octave. I've subscribed to your blog as well as most of the other summer of code participants. Keep us informed.
I might be able to help Ben Lewis with the Wavelets. It is an area of interest and I should be picking up an ATI short course at the end of February.
I think I can come up with a good oct2mat solution, but that will have to wait until this winter.
_______________________________________________
Octave-maintainers mailing list
address@hidden
https://mailman.cae.wisc.edu/listinfo/octave-maintainers