iostream et STL

My calculator programs · by **Adriweb** » 30 Mar 2014, 16:47

Nice

→ **MyCalcs** profile · by **Excale** » 30 Mar 2014, 16:54

Il n'a pas l'air d'aimer les puissances par contre.
5^5 fait planter le programme.

Mais sinon, joli travail pour être déjà arrivé jusqu'ici

5^5 crashes the program, though

Nice work anyway

→ **MyCalcs** profile · by **parisse** » 30 Mar 2014, 18:39

Yes, ^ does not work as well as the builtin commandnames from the parser, I believe I have found the reason, I hope I can post a more usable version tomorrow. Once the parser is ok, I hope most things will work (I checked a factorization identificateur x("x"); _factor(pow(x,4)-1,&c),&c); and it worked).

→ **MyCalcs** profile · by **parisse** » 31 Mar 2014, 10:22

I have updated
http://www-fourier.ujf-grenoble.fr/~parisse/calc/giac.tgz
It should work better now.

→ **MyCalcs** profile · by **Excale** » 31 Mar 2014, 14:19

Indeed

.

It still fails with complex numbers though:
1^i

Edit: solve(x^2+x-1=0,x) crashes too
expand(x*y) too
(I have to say I don't know exactly what is supposed to fail since some features may not implemented yet)

→ **MyCalcs** profile · by **parisse** » 31 Mar 2014, 15:24

More probably a problem with ^ than with i, if you enter i*i you get -1.
There are certainly many reboots to expect, I haven't tried many functions and I had to make changes in the source related to the ustl (anything using sort may crash). It's really unfortunate that gdb does not work, any idea why it fails? Debugging by adding console output and keypress is really slow.
Short online help is now available with ?cmdname. readline would be nice!

→ **MyCalcs** profile · by **ExtendeD** » 31 Mar 2014, 19:11

Compiling with -Os may indeed lose GDB with the optimizations. I'll have a closer at why the 7Mb allocation fail and try at least to give you a workaround.

→ **MyCalcs** profile · by **Vogtinator** » 31 Mar 2014, 21:04

Compiling with -Os may indeed lose GDB with the optimizations.

It shouldn't. The only thing that could happen are weird jumps around in the code. But crashes occur to me only if I detach or I attach to a running program. You have to compile first, than launch gdb, connect to nspire_emu, then send the file and start it.

There are certainly many reboots to expect, I haven't tried many functions and I had to make changes in the source related to the ustl (anything using sort may crash).

You could try libstdc++ and use it together with nspireio.

→ **MyCalcs** profile · by **parisse** » 01 Apr 2014, 16:02

Vogtinator wrote:It shouldn't. The only thing that could happen are weird jumps around in the code. But crashes occur to me only if I detach or I attach to a running program. You have to compile first, than launch gdb, connect to nspire_emu, then send the file and start it.

I tried that and it reboots. I got once a debugging session working today but only once.
Anyway, I have modified some calls to sort to be ustl compatible, and giac works now a little better on the TI (archive updated on my site).

→ **MyCalcs** profile · by **ExtendeD** » 02 Apr 2014, 12:34

I tried to build giac with your .ndless, I got a lot of conflicts between standard libraries and os.h/libndls.h, I didn't have the time to look closer at them. Maybe it's because I have recently switched from Windows to Linux and I'm not use to Ndless on Linux, or we broke something with our recent changes to the SDK.
Is there any particular reason for os.h and other Ndless headers being in .ndless/include?
Could you share your .gdb file to let me check what's wrong without having to rebuild?