1. C_FLOATs and 4.0
Has anyone figured out how to properly pass a floating point value to C
when running 4.0?
2. Re: C_FLOATs and 4.0
irv mullins wrote:
>
>
> Has anyone figured out how to properly pass a floating point value to C
> when running 4.0?
I was not aware the method of passing it in 3.x was wrong? I pass floats and
doubles to a few C libs w/no problem using C_FLOAT. Is there a problem with it?
--
Jeremy Cowgar
http://jeremy.cowgar.com
3. Re: C_FLOATs and 4.0
Jeremy Cowgar wrote:
>
> irv mullins wrote:
> >
> >
> > Has anyone figured out how to properly pass a floating point value to C
> > when running 4.0?
>
> I was not aware the method of passing it in 3.x was wrong? I pass floats and
> doubles to a few C libs w/no problem using C_FLOAT. Is there a problem with
> it?
>
Nothing wrong with 3.1, however, with 4.0 the same code, unchanged, does not
work
properly.
When calling a C function which requires a floating point value, C no longer
sees
the value passed correctly (unless the value is zero)
I'll try to write a small C program to print out what it is getting.
4. Re: C_FLOATs and 4.0
Well, here's what's happening:
Say a C routine requires 2 floating point values: x and y
When we call the routine, passing Eu atoms, the first gets lost,
the second (y) gets used as the first parameter to the C routine,
and is apparently interpreted correctly.
Something to do with C_FLOATS has obviously changed between 3.1 and 4.0,
since none of my code has changed.
5. Re: C_FLOATs and 4.0
irv mullins wrote:
>
>
> Well, here's what's happening:
> Say a C routine requires 2 floating point values: x and y
> When we call the routine, passing Eu atoms, the first gets lost,
> the second (y) gets used as the first parameter to the C routine,
> and is apparently interpreted correctly.
>
> Something to do with C_FLOATS has obviously changed between 3.1 and 4.0,
> since none of my code has changed.
Irv, I'm sorry! I forgot about this, I've had this problem in the past:
http://www.openeuphoria.org/cgi-bin/esearch.exu?thread=1&fromMonth=4&fromYear=D&toMonth=6&toYear=D&keywords=%223.2,+Wrapping+DLLs+and+Float+types%22
I was the only one having it and it was before I started messing with the
Interpreter. The discussion simply died. I do not think it has been resolved.
Thank you for brining it back up! Now that others are also having a problem, and
I know it's not my issue, a bug report should be added to SF.net.
--
Jeremy Cowgar
http://jeremy.cowgar.com
6. Re: C_FLOATs and 4.0
The one thing I can think of that has changed is the compiler.
Using 3.1,which Rob has compiled.
4.0 currently is the one from your website, you compiled.
However, I had the same incorrect results with a version I compiled from the SVN
a few weeks ago.
7. Re: C_FLOATs and 4.0
irv mullins wrote:
>
>
> The one thing I can think of that has changed is the compiler.
> Using 3.1,which Rob has compiled.
> 4.0 currently is the one from your website, you compiled.
> However, I had the same incorrect results with a version I compiled from the
> SVN
> a few weeks ago.
It may very well be the compiler. Are you using Linux or Windows? On Windows my
binaries are compiled with OpenWatcom 1.7a, which is the latest available. Then
on Linux, I am using gcc 4.3.0. Now, in my previous diagnostics I found that if I
compiled Euphoria on Linux with gcc 3.3, then C_FLOAT worked fine. So, it
certainly seems to be a change in the compiler version on Linux.
--
Jeremy Cowgar
http://jeremy.cowgar.com
8. Re: C_FLOATs and 4.0
Jeremy Cowgar wrote:
>
> It may very well be the compiler. Are you using Linux or Windows? On Windows
> my binaries are compiled with OpenWatcom 1.7a, which is the latest available.
> Then on Linux, I am using gcc 4.3.0. Now, in my previous diagnostics I found
> that if I compiled Euphoria on Linux with gcc 3.3, then C_FLOAT worked fine.
> So, it certainly seems to be a change in the compiler version on Linux.
gcc version 4.2.2
By the way, I just checked out ver 605 from SVN, and tried to compile.
I get this far:
make[1]: Entering directory `/root/trunk/source'
echo Translating int.ex to create common.e main.e mode.e pathopen.e error.e
symtab.e scanner.e scientific.e emit.e parser.e opnames.e reswords.e keylist.e
global.e compress.e backend.e c_out.e cominit.e intinit.e int.ex
Translating int.ex to create common.e main.e mode.e pathopen.e error.e symtab.e
scanner.e scientific.e emit.e parser.e opnames.e reswords.e keylist.e global.e
compress.e backend.e c_out.e cominit.e intinit.e int.ex
cd ./intobj && exu -i ../../include ../ec.ex -i ../../include ../int.ex
/root/trunk/source/intobj/../../include/search.e:114
Syntax error - expected to see possibly 'do', not 'entry'
while from > 0 entry do
^
Press Enter
It appears it is trying to use a keyword which doesn't exist until
the new version is compiled, and I can't compile the new version until
the new version is compiled, etc..... this could be a problem.
Here's what is running now:
# exu
Euphoria Interpreter 4.0 (development) for Linux.
Copyright (c) Rapid Deployment Software 2008
See http://www.RapidEuphoria.com/License.txt
9. Re: C_FLOATs and 4.0
irv mullins wrote:
>
> gcc version 4.2.2
>
Yes, it will have the same problem 
Matt, Jim?
> By the way, I just checked out ver 605 from SVN, and tried to compile.
> I get this far:
> Syntax error - expected to see possibly 'do', not 'entry'
> while from > 0 entry do
> ^
> It appears it is trying to use a keyword which doesn't exist until
> the new version is compiled, and I can't compile the new version until
> the new version is compiled, etc..... this could be a problem.
>
Yes. You can download binaries that I have built past that stage:
http://jeremy.cowgar.com/files/eu40-592.tar.gz
or for windows, I have an older build, but still past the "entry" keyword:
http://jeremy.cowgar.com/files/eu40bins-578.zip
We have a solution for the chicken/egg problem that will be in place for the
first alpha, but for now building can be a tad tricky. However, with the above
bin's you should be fine.
--
Jeremy Cowgar
http://jeremy.cowgar.com
10. Re: C_FLOATs and 4.0
I changed the windows binary file for naming consistency:
http://jeremy.cowgar.com/files/eu40-578.zip
--
Jeremy Cowgar
http://jeremy.cowgar.com
11. Re: C_FLOATs and 4.0
Jeremy Cowgar wrote:
> Yes. You can download binaries that I have built past that stage:
>
> <a
> href="http://jeremy.cowgar.com/files/eu40-592.tar.gz">http://jeremy.cowgar.com/files/eu40-592.tar.gz</a>
>
>
OK, did that, recompiled 605, and now floats seem to work!
More testing will tell for sure.
Thanks,
12. Re: C_FLOATs and 4.0
irv mullins wrote:
>
> Jeremy Cowgar wrote:
>
> > Yes. You can download binaries that I have built past that stage:
> >
> > <a
> > href="http://jeremy.cowgar.com/files/eu40-592.tar.gz">http://jeremy.cowgar.com/files/eu40-592.tar.gz</a>
> </font></i>
> >
> OK, did that, recompiled 605, and now floats seem to work!
> More testing will tell for sure.
>
That's good news. I know Jim Brown has done work on making gcc and openwatcom
much less dependent (totaly?) on what version you compile on. I have not checked
any of my C_FLOAT code since that change though. Let us know how it goes.
--
Jeremy Cowgar
http://jeremy.cowgar.com
13. Re: C_FLOATs and 4.0
Jeremy -
Is there a way to determine the build number for a compiled interpreter?
The opening message when executing exu (and presumably the others) shows version
but not build number.
I appreciate your work in posting new binaries, but am afraid I may be losing
track of what build I am using!
Thanks!
George
14. Re: C_FLOATs and 4.0
George Orr wrote:
>
>
> Jeremy -
>
> Is there a way to determine the build number for a compiled interpreter?
> The opening message when executing exu (and presumably the others) shows
> version
> but not build number.
> I appreciate your work in posting new binaries, but am afraid I may be losing
> track of what build I am using!
>
Currently there is not. It's something on the list to do. Sorry.
--
Jeremy Cowgar
http://jeremy.cowgar.com
