On Wed, 2 Aug 2006, carmen wrote:

On Tue Aug 01, 2006 at 08:08:33PM -0700, thewade wrote:

...

W00T! Thanks GG!

agreed. definitely one of the cooler patches to show up on the tracker in a long time ;)

are arrays the only thing (including externals) that assume sizeof t_word == t_pointer == long == t_float?

I assume, but I don' t really know. I am not actively using my 64 bit machine anymore, because it is a bit old and slow (533Mhz and terribly small cache).

I assume that externals that deal with arrays have in general the same problem as the pd builtin objects.

altho table is certainly the most obvious thing to notice, pd seemed pretty unstable on 64bit, perhaps stack corruption or something..

mhm, might be that some of the datastructure stuff has problems. If you say unstable you mean crashing right ? Would be interesting if this is a problem of pd itself or some externals. If you are going to do tests, maybe you can start pd inside gdb and do a "bt".

...

Now I just need to find a week so I can reainstall everything again,

this time in 64-bit mode..

Yeah, I recommend to do that on an extra hard drive/partition. There might still be some problems left.

Günter

...

Thanks for the efforts! Much appreciated

ditto!

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Thanks for the report,

have to check, actually the patches weren't against devel_0_39, but against 0.39.2.

On Fri, 11 Aug 2006, carmen wrote:

on the first try, 9 of 11 hunk succeed on devel_0_39. heres a patch which fixes the 2 .rej's.

it is better. [ ; asd 0 1 2 3 4 5 6 7 8( , tabreads back as 1 2 3 4 5 6 7 7, [ ; asd 4 4 4 4 4 4 4 4( reads 1 2 3 4 4 4 4 4.

You know that the first element is the position where to insert ? So 2) looks ok. 1) looks bad, I wonder where the 8 has gone, will check later this day.

then after a bit of fiddling, theres a crash in #0 0x000000000042fe95 in fifo_put ()

There is no fifo_put in standard pd, so this might be due to applying a patch for 0.39.2 to devel_0_39 ? Or devel_0_39 has 64 bit issues in general ?

so theres still one? bug left, at least. well, two, if you count the segfault. i'll try again next year :)

The only proposal I can make is to check the patch against devel_0_39 myself. But if you are not in a hurry, there are other things to do :)

Thanks for trying.

Günter

On Fri, 11 Aug 2006, carmen wrote:

...

...

it is better. [ ; asd 0 1 2 3 4 5 6 7 8( , tabreads back as 1 2 3 4 5 6 7 7, [ ; asd 4 4 4 4 4 4 4 4( reads 1 2 3 4 4 4 4 4.

You know that the first element is the position where to insert ?

thats right then. the 1 2 3 would have been left over from the previous write, and the 4's start at position 4 (does array really start counting from 1 though?!)

No, it starts at 0. The first "4" should be a leftover from the old 1 2 3 4 ..

i'll have to try to get audio working then, it was doing the 'audio stuck' thing with jack..

ah, yeah. In the early days there was an implementation where pd just tried the "logical order" of interfaces by default. So it tried jack, if it didn't succeed alsa, and if that failed too OSS. This covered the different cases without startup options and is a pretty good algorithm to figure out which audio interface the user wants (at least you had sound after startup without fiddling with the configuration).

...

Thanks for trying.

thanks for the patch!..

Youre welcome, one of these days we all end up with a 64 bit processor, so its not completely unselfish ..

Günter