1. Langwar crash
Hi
Eu 3.0.1 (and 3.0.0)
SuSE Linux 10.0 64 bit
Langwar is crashing
first part of ex.err
File: ex.err Col 0 16300 bytes 0%
./sched.e:62 in function next_task()
type_check failure, mintime is -11285555.93
mintime = -11285555.93
mintask = 5
i = 5
... called from lw.ex:261 in procedure trek()
nk = <no value>
... called from lw.ex:321
Global & Local Variables
lw.ex:
sum_no = 3
line = -1
/home/crylex/euphoria/include/graphics.e:
BLUE = 4
CYAN = 6
RED = 1
Also, I (still) can't translate programs to c - throws lots of undifined calls
to functions and so on. I suspect this is a feature of 64 bit Linux gcc. Its not
a big problem, as binding works very nicely.
Chris
http://euallegro.wikispaces.com
http://members.aol.com/chriscrylex/euphoria.htm
http://uboard.proboards32.com/
http://members.aol.com/chriscrylex/EUSQLite/eusql.html
2. Re: Langwar crash
Chris Burch wrote:
>
> Hi
>
> Eu 3.0.1 (and 3.0.0)
> SuSE Linux 10.0 64 bit
<snip>
> Also, I (still) can't translate programs to c - throws lots of undifined calls
> to functions and so on. I suspect this is a feature of 64 bit Linux gcc. Its
> not a big problem, as binding works very nicely.
I've had problems on a linux system (fc5, Ubuntu 5.10) using gcc v4. It
seems that CLC_TCKS (or whatever that is--I don't have any eu stuff in
front of me right now). It's supposed to be defined in time.h, but if you
take a look, there are comments stating that it's obsolete. In euphoria.h,
setting a:
#define CLK_TCKS CLOCKS_PER_SEC
(or whatever the other parameter in that function call comes out to be)
seems to make it happy.
Matt Lewis
3. Re: Langwar crash
- Posted by Chris Burch <chriscrylex at aol.com>
Nov 05, 2006
-
Last edited Nov 06, 2006
Matt Lewis wrote:
>
> Chris Burch wrote:
> >
> > Hi
> >
> > Eu 3.0.1 (and 3.0.0)
> > SuSE Linux 10.0 64 bit
>
> <snip>
>
> > Also, I (still) can't translate programs to c - throws lots of undifined
> > calls
> > to functions and so on. I suspect this is a feature of 64 bit Linux gcc. Its
> > not a big problem, as binding works very nicely.
>
> I've had problems on a linux system (fc5, Ubuntu 5.10) using gcc v4. It
> seems that CLC_TCKS (or whatever that is--I don't have any eu stuff in
> front of me right now). It's supposed to be defined in time.h, but if you
> take a look, there are comments stating that it's obsolete. In euphoria.h,
>
> setting a:
>
> #define CLK_TCKS CLOCKS_PER_SEC
>
> (or whatever the other parameter in that function call comes out to be)
> seems to make it happy.
>
> Matt Lewis
Hi
No, seems to be in the linker, here's the relevant output
linking
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
warning: i386 architecture of input file
`/home/cshme/euphoria/bin/ecu.a(be_machine.o)' is incompatible with i386:x86-64
output
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
warning: i386 architecture of input file
`/home/cshme/euphoria/bin/ecu.a(be_inline.o)' is incompatible with i386:x86-64
output
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
warning: i386 architecture of input file `/home/cshme/euphoria/bin/ecu.a(be_w.o)'
is incompatible with i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
warning: i386 architecture of input file
`/home/cshme/euphoria/bin/ecu.a(be_alloc.o)' is incompatible with i386:x86-64
output
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
warning: i386 architecture of input file
`/home/cshme/euphoria/bin/ecu.a(be_runtime.o)' is incompatible with i386:x86-64
output
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
warning: i386 architecture of input file
`/home/cshme/euphoria/bin/ecu.a(be_task.o)' is incompatible with i386:x86-64
output
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld:
warning: i386 architecture of input file
`/home/cshme/euphoria/bin/ecu.a(be_callc.o)' is incompatible with i386:x86-64
output
Fdialogs.o: In function `_10wait_key_nn':
Fdialogs.c:(.text+0x1170): undefined reference to `show_console'
Fdialogs.o: In function `_10get_key_w':
Fdialogs.c:(.text+0x14e3): undefined reference to `show_console'
utilities.o: In function `_17flush_key_buffers':
utilities.c:(.text+0x77): undefined reference to `show_console'
datafuncs.o: In function `_19data_insert_client':
datafuncs.c:(.text+0x2197): undefined reference to `show_console'
datafuncs.o: In function `_19data_insert_note':
datafuncs.c:(.text+0x42d3): undefined reference to `show_console'
invoic_4g_run.o:invoic_4g_run.c:(.text+0x2d05): more undefined references to
`show_console' follow
collect2: ld returned 1 exit status
you can now execute: ./jetvet
Press any key to continue...
It would seem that I need a compatible version of ecu.a. Hmmmm, could I make one
myself?
Chris
http://euallegro.wikispaces.com
http://members.aol.com/chriscrylex/euphoria.htm
http://uboard.proboards32.com/
http://members.aol.com/chriscrylex/EUSQLite/eusql.html
4. Re: Langwar crash
Chris Burch wrote:
> Eu 3.0.1 (and 3.0.0)
> SuSE Linux 10.0 64 bit
>
> Langwar is crashing
>
> first part of ex.err
>
> File: ex.err Col 0 16300 bytes
> 0%
> ./sched.e:62 in function next_task()
> type_check failure, mintime is -11285555.93
> mintime = -11285555.93
> mintask = 5
> i = 5
>
> ... called from lw.ex:261 in procedure trek()
> nk = <no value>
>
> ... called from lw.ex:321
mintime is declared as a positive_atom.
I don't think I ever guarantee in the docs that time()
will return a non-negative number, though it
seems to do that in all cases I've seen. I only
talk about measuring *differences* in time() from one call to
the next. Maybe you can add
without type_check
to the top of lw.exu and see what happens.
You might also try a small test to see if time() advances at the
correct rate.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Langwar crash
Robert Craig wrote:
>
> Chris Burch wrote:
> > Eu 3.0.1 (and 3.0.0)
> > SuSE Linux 10.0 64 bit
> >
> > Langwar is crashing
> >
> > first part of ex.err
> >
> > File: ex.err Col 0 16300 bytes
> > 0%
> > ./sched.e:62 in function next_task()
> > type_check failure, mintime is -11285555.93
> > mintime = -11285555.93
> > mintask = 5
> > i = 5
> >
> > ... called from lw.ex:261 in procedure trek()
> > nk = <no value>
> >
> > ... called from lw.ex:321
>
> mintime is declared as a positive_atom.
> I don't think I ever guarantee in the docs that time()
> will return a non-negative number, though it
> seems to do that in all cases I've seen. I only
> talk about measuring *differences* in time() from one call to
> the next. Maybe you can add
> without type_check
> to the top of lw.exu and see what happens.
> You might also try a small test to see if time() advances at the
> correct rate.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Hi
How curious, my time() returns a -ve integer (and it does advance at the
correct rate)
From the docs
Description: Return the number of seconds since some fixed point in the past.
Does this mean that I am writing this, on this computer, before this fixed
point in the past?
Simply add this above procedure sched() in sched.e
global function my_time()
return time() + 12000000
end function
and replace all instances of time() with my_time throughout the whole of
langwar,
to bring yourself 'up to date', or 'back to the future', or..... etc
Chris
6. Re: Langwar crash
ChrisBurch2 wrote:
>
> Robert Craig wrote:
> >
> > Chris Burch wrote:
> > > Eu 3.0.1 (and 3.0.0)
> > > SuSE Linux 10.0 64 bit
> > >
> > > Langwar is crashing
> > >
> > > first part of ex.err
> > >
> > > File: ex.err Col 0 16300 bytes
> > >
> > > 0%
> > > ./sched.e:62 in function next_task()
> > > type_check failure, mintime is -11285555.93
> > > mintime = -11285555.93
> > > mintask = 5
> > > i = 5
> > >
> > > ... called from lw.ex:261 in procedure trek()
> > > nk = <no value>
> > >
> > > ... called from lw.ex:321
> >
> > mintime is declared as a positive_atom.
> > I don't think I ever guarantee in the docs that time()
> > will return a non-negative number, though it
> > seems to do that in all cases I've seen. I only
> > talk about measuring *differences* in time() from one call to
> > the next. Maybe you can add
> > without type_check
> > to the top of lw.exu and see what happens.
> > You might also try a small test to see if time() advances at the
> > correct rate.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
>
> Hi
>
> How curious, my time() returns a -ve integer (and it does advance at the
> correct rate)
>
> From the docs
>
> Description: Return the number of seconds since some fixed point in the past.
>
> Does this mean that I am writing this, on this computer, before this fixed
> point in the past?
>
> Simply add this above procedure sched() in sched.e
>
> global function my_time()
> return time() + 12000000
> end function
>
> and replace all instances of time() with my_time throughout the whole of
> langwar,
>
> to bring yourself 'up to date', or 'back to the future', or..... etc
>
> Chris
Hi
Is this a feature of time() on 64 bit systems? Is this a dignostic technique for
telling you are running on a 64 bit system? Should it be fixed? Does it matter?
What will happen in 2036?
Chris
7. Re: Langwar crash
- Posted by Robert Craig <rds at RapidEuphoria.com>
Nov 06, 2006
-
Last edited Nov 07, 2006
ChrisBurch2 wrote:
> > How curious, my time() returns a -ve integer (and it does advance at the
> > correct rate)
> >
> > From the docs
> >
> > Description: Return the number of seconds since some fixed point in the
> > past.
> >
> > Does this mean that I am writing this, on this computer, before this fixed
> > point in the past?
> >
> > Simply add this above procedure sched() in sched.e
> >
> > global function my_time()
> > return time() + 12000000
> > end function
> >
> > and replace all instances of time() with my_time throughout the whole of
> > langwar,
> >
> > to bring yourself 'up to date', or 'back to the future', or..... etc
> >
> > Chris
>
> Hi
>
> Is this a feature of time() on 64 bit systems?
Even on 32-bit systems, I always had in the back of my mind
that you shouldn't count on time() starting at zero.
> Is this a dignostic technique
> for telling you are running on a 64 bit system?
I imagine there's a more direct way of telling.
> Should it be fixed? Does it matter?
I could at least emphasize in the docs that time() does not
have to be positive. I should also fix Language War.
> What will happen in 2036?
I think date() might be more affected by that,
not time().
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
