Re: [PD] window close bug

[Lucas Cordiviola]

Just for our records:

Which version of win10 are you running?

32 or 64 bit?

Home? Pro? Etc.



Mensaje telepatico asistido por maquinas.



From: Pd-list  on behalf of Lucas Cordiviola 

Sent: Friday, October 21, 2016 2:55 AM
To: Liam Goodacre; Jonathan Wilkes via Pd-list
Subject: Re: [PD] window close bug


Even stranger!!!


Mensaje telepatico asistido por maquinas.



From: Pd-list  on behalf of Liam Goodacre 

Sent: Friday, October 21, 2016 2:47 AM
To: Jonathan Wilkes via Pd-list
Subject: Re: [PD] window close bug


Just restarting PD.



From: Lucas Cordiviola 
Sent: 21 October 2016 03:13
To: Liam Goodacre; Jonathan Wilkes via Pd-list
Subject: Re: window close bug


> I would expect the whole OS to be running erratically if I had a problem 
> with...

That's correct.


 > A quick restart also solves the issue

Restarting Pd? or the OS?



> Am I the only one who experiences this?

I don't.`



Mensaje telepatico asistido por maquinas.



From: Pd-list  on behalf of Liam Goodacre 

Sent: Friday, October 21, 2016 2:01 AM
To: Jonathan Wilkes via Pd-list
Subject: Re: [PD] window close bug


Thanks Lucas. I would expect the whole OS to be running erratically if I had a 
problem with the keyboard, but as it is I only experience this behaviour in PD. 
A quick restart also solves the issue.



Any other ideas? Am I the only one who experiences this?





From: Lucas Cordiviola
Sent: 18 October 2016 00:15
To: Liam Goodacre;Jonathan Wilkes via Pd-list
Subject: Re: window close bug







Are you sure your keyboard is ok?



Try another keyboard, if you are on a notebook try disabling the one that's 
built-in and connect an usb one.



It could be a faulty key (probably ALT?).



I occasionally use win10 and never experienced this behavior you report, 
normally I'm on win8.1 and also didn`t.





Mensaje telepatico asistido por maquinas.





From: Pd-list  on behalf of Liam Goodacre 

Sent: Monday, October 17, 2016 11:55 AM
To: Jonathan Wilkes via Pd-list
Subject: [PD] window close bug



Here's another curious bug that I've just started experiencing (seems like I'm 
having one of those weeks!) Occasionally, the window cross icon on the top 
right seems to go rogue and start acting out another menu command. So every 
time I press it, it will zoom in on the canvas instead of closing the window, 
or create a comment, or (distressingly) save the file. These are the three that 
I've experienced so far. When  it happens, it's consistent, so that every open 
window has the same problem, and I have to force-quit PD (probably I have to 
force quit because the console cross icon has also been affected). I haven't 
spotted a trigger for this behaviour yet, it seems to be random. Has anyone 
ever experienced this? I'm on 0.47.1, Windows 10.










___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] window close bug

[Lucas Cordiviola]

Even stranger!!!


Mensaje telepatico asistido por maquinas.



From: Pd-list  on behalf of Liam Goodacre 

Sent: Friday, October 21, 2016 2:47 AM
To: Jonathan Wilkes via Pd-list
Subject: Re: [PD] window close bug


Just restarting PD.



From: Lucas Cordiviola 
Sent: 21 October 2016 03:13
To: Liam Goodacre; Jonathan Wilkes via Pd-list
Subject: Re: window close bug


> I would expect the whole OS to be running erratically if I had a problem 
> with...

That's correct.


 > A quick restart also solves the issue

Restarting Pd? or the OS?



> Am I the only one who experiences this?

I don't.`



Mensaje telepatico asistido por maquinas.



From: Pd-list  on behalf of Liam Goodacre 

Sent: Friday, October 21, 2016 2:01 AM
To: Jonathan Wilkes via Pd-list
Subject: Re: [PD] window close bug


Thanks Lucas. I would expect the whole OS to be running erratically if I had a 
problem with the keyboard, but as it is I only experience this behaviour in PD. 
A quick restart also solves the issue.



Any other ideas? Am I the only one who experiences this?





From: Lucas Cordiviola
Sent: 18 October 2016 00:15
To: Liam Goodacre;Jonathan Wilkes via Pd-list
Subject: Re: window close bug







Are you sure your keyboard is ok?



Try another keyboard, if you are on a notebook try disabling the one that's 
built-in and connect an usb one.



It could be a faulty key (probably ALT?).



I occasionally use win10 and never experienced this behavior you report, 
normally I'm on win8.1 and also didn`t.





Mensaje telepatico asistido por maquinas.





From: Pd-list  on behalf of Liam Goodacre 

Sent: Monday, October 17, 2016 11:55 AM
To: Jonathan Wilkes via Pd-list
Subject: [PD] window close bug



Here's another curious bug that I've just started experiencing (seems like I'm 
having one of those weeks!) Occasionally, the window cross icon on the top 
right seems to go rogue and start acting out another menu command. So every 
time I press it, it will zoom in on the canvas instead of closing the window, 
or create a comment, or (distressingly) save the file. These are the three that 
I've experienced so far. When  it happens, it's consistent, so that every open 
window has the same problem, and I have to force-quit PD (probably I have to 
force quit because the console cross icon has also been affected). I haven't 
spotted a trigger for this behaviour yet, it seems to be random. Has anyone 
ever experienced this? I'm on 0.47.1, Windows 10.










___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] window close bug

[Liam Goodacre]

Just restarting PD.



From: Lucas Cordiviola 
Sent: 21 October 2016 03:13
To: Liam Goodacre; Jonathan Wilkes via Pd-list
Subject: Re: window close bug


> I would expect the whole OS to be running erratically if I had a problem 
> with...

That's correct.


 > A quick restart also solves the issue

Restarting Pd? or the OS?



> Am I the only one who experiences this?

I don't.`



Mensaje telepatico asistido por maquinas.



From: Pd-list  on behalf of Liam Goodacre 

Sent: Friday, October 21, 2016 2:01 AM
To: Jonathan Wilkes via Pd-list
Subject: Re: [PD] window close bug


Thanks Lucas. I would expect the whole OS to be running erratically if I had a 
problem with the keyboard, but as it is I only experience this behaviour in PD. 
A quick restart also solves the issue.



Any other ideas? Am I the only one who experiences this?





From: Lucas Cordiviola
Sent: 18 October 2016 00:15
To: Liam Goodacre;Jonathan Wilkes via Pd-list
Subject: Re: window close bug







Are you sure your keyboard is ok?



Try another keyboard, if you are on a notebook try disabling the one that's 
built-in and connect an usb one.



It could be a faulty key (probably ALT?).



I occasionally use win10 and never experienced this behavior you report, 
normally I'm on win8.1 and also didn`t.





Mensaje telepatico asistido por maquinas.





From: Pd-list  on behalf of Liam Goodacre 

Sent: Monday, October 17, 2016 11:55 AM
To: Jonathan Wilkes via Pd-list
Subject: [PD] window close bug



Here's another curious bug that I've just started experiencing (seems like I'm 
having one of those weeks!) Occasionally, the window cross icon on the top 
right seems to go rogue and start acting out another menu command. So every 
time I press it, it will zoom in on the canvas instead of closing the window, 
or create a comment, or (distressingly) save the file. These are the three that 
I've experienced so far. When  it happens, it's consistent, so that every open 
window has the same problem, and I have to force-quit PD (probably I have to 
force quit because the console cross icon has also been affected). I haven't 
spotted a trigger for this behaviour yet, it seems to be random. Has anyone 
ever experienced this? I'm on 0.47.1, Windows 10.










___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [text] object and commas

[Liam Goodacre]

The helpfile for [text] says that it can include commas, but in practice commas 
are interpreted as line separators. This seems to be true even when you use the 
“-c” read flag, which interprets carriage returns as line separators. Is this 
intentional behaviour?



it would be great if there was a startup flag which allows commas to be read 
inline, as with [msgfile]. Or is there some other way of getting around the 
issue?



Liam


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] window close bug

[Lucas Cordiviola]

> I would expect the whole OS to be running erratically if I had a problem 
> with...

That's correct.


 > A quick restart also solves the issue

Restarting Pd? or the OS?



> Am I the only one who experiences this?

I don't.`



Mensaje telepatico asistido por maquinas.



From: Pd-list  on behalf of Liam Goodacre 

Sent: Friday, October 21, 2016 2:01 AM
To: Jonathan Wilkes via Pd-list
Subject: Re: [PD] window close bug


Thanks Lucas. I would expect the whole OS to be running erratically if I had a 
problem with the keyboard, but as it is I only experience this behaviour in PD. 
A quick restart also solves the issue.



Any other ideas? Am I the only one who experiences this?





From: Lucas Cordiviola
Sent: 18 October 2016 00:15
To: Liam Goodacre;Jonathan Wilkes via Pd-list
Subject: Re: window close bug







Are you sure your keyboard is ok?



Try another keyboard, if you are on a notebook try disabling the one that's 
built-in and connect an usb one.



It could be a faulty key (probably ALT?).



I occasionally use win10 and never experienced this behavior you report, 
normally I'm on win8.1 and also didn`t.





Mensaje telepatico asistido por maquinas.





From: Pd-list  on behalf of Liam Goodacre 

Sent: Monday, October 17, 2016 11:55 AM
To: Jonathan Wilkes via Pd-list
Subject: [PD] window close bug



Here's another curious bug that I've just started experiencing (seems like I'm 
having one of those weeks!) Occasionally, the window cross icon on the top 
right seems to go rogue and start acting out another menu command. So every 
time I press it, it will zoom in on the canvas instead of closing the window, 
or create a comment, or (distressingly) save the file. These are the three that 
I've experienced so far. When  it happens, it's consistent, so that every open 
window has the same problem, and I have to force-quit PD (probably I have to 
force quit because the console cross icon has also been affected). I haven't 
spotted a trigger for this behaviour yet, it seems to be random. Has anyone 
ever experienced this? I'm on 0.47.1, Windows 10.










___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] window close bug

[Liam Goodacre]

Thanks Lucas. I would expect the whole OS to be running erratically if I had a 
problem with the keyboard, but as it is I only experience this behaviour in PD. 
A quick restart also solves the issue.



Any other ideas? Am I the only one who experiences this?





From: Lucas Cordiviola
Sent: 18 October 2016 00:15
To: Liam Goodacre;Jonathan Wilkes via Pd-list
Subject: Re: window close bug



Are you sure your keyboard is ok?

Try another keyboard, if you are on a notebook try disabling the one that's 
built-in and connect an usb one.

It could be a faulty key (probably ALT?).

I occasionally use win10 and never experienced this behavior you report, 
normally I'm on win8.1 and also didn`t.



Mensaje telepatico asistido por maquinas.


From: Pd-list  on behalf of Liam Goodacre 

Sent: Monday, October 17, 2016 11:55 AM
To: Jonathan Wilkes via Pd-list
Subject: [PD] window close bug


Here’s another curious bug that I’ve just started experiencing (seems like I’m 
having one of those weeks!) Occasionally, the window cross icon on the top 
right seems to go rogue and start acting out another menu command. So every 
time I press it, it will zoom in on the canvas instead of closing the window, 
or create a comment, or (distressingly) save the file. These are the three that 
I’ve experienced so far. When  it happens, it’s consistent, so that every open 
window has the same problem, and I have to force-quit PD (probably I have to 
force quit because the console cross icon has also been affected). I haven’t 
spotted a trigger for this behaviour yet, it seems to be random. Has anyone 
ever experienced this? I’m on 0.47.1, Windows 10.






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] memory leak problem with small patch

[Jack]

Yep. And I confirm that with Pd-0.47-1, I get no more memory leak.
++

Jack



Le 20/10/2016 à 15:17, Matt Barber a écrit :
> Was probably this:
> 
> https://lists.puredata.info/pipermail/pd-list/2016-03/113725.html
> 
> On Thu, Oct 20, 2016 at 6:29 AM, Jack  > wrote:
> 
> Using sources of Pd-0.47-1 seems to solve this issue.
> ++
> 
> Jack
> 
> 
> 
> Le 20/10/2016 à 11:19, Jack a écrit :
> > Hello,
> >
> > I made a simple patch to control an Enttec DMXUSB Pro, causing memory
> > leak after a few hours (around 4-5 hours) of operation.
> >
> > The patch is attached.
> > Configuration :
> > RaspberryPi 2
> > Raspbian GNU/Linux 7 (wheezy)
> > Pd-0.46.6
> >
> > Someone to help me to solve this issue ?
> > ++
> >
> > Jack
> >
> >
> >
> > Here the log from syslog (I can use gdb if needed ?) :
> >
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496233] pd invoked
> > oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496266] CPU: 2 PID: 2251
> > Comm: pd Not tainted 3.18.11-v7+ #781
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496319] [<800172bc>]
> > (unwind_backtrace) from [<80012f7c>] (show_stack+0x20/0x24)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496348] [<80012f7c>]
> > (show_stack) from [<80520970>] (dump_stack+0x98/0xd8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496445] [<80520970>]
> > (dump_stack) from [<8051e3bc>] (dump_header.isra.12+0x80/0x1a8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496489] [<8051e3bc>]
> > (dump_header.isra.12) from [<800ef2a8>] (oom_kill_process+0x340/0x3b8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496527] [<800ef2a8>]
> > (oom_kill_process) from [<800ef808>] (out_of_memory+0x300/0x34c)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496553] [<800ef808>]
> > (out_of_memory) from [<800f3c64>] (__alloc_pages_nodemask+0x930/0x970)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496578] [<800f3c64>]
> > (__alloc_pages_nodemask) from [<800ede38>] (filemap_fault+0x220/0x4a8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496604] [<800ede38>]
> > (filemap_fault) from [<80113104>] (__do_fault+0x44/0x98)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496628] [<80113104>]
> > (__do_fault) from [<80116068>] (do_read_fault.isra.91+0x1c4/0x274)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496652] [<80116068>]
> > (do_read_fault.isra.91) from [<8011683c>]
> (handle_mm_fault+0x3b8/0xa88)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496679] [<8011683c>]
> > (handle_mm_fault) from [<80528240>] (do_page_fault+0x2e4/0x458)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496706] [<80528240>]
> > (do_page_fault) from [<800084d4>] (do_PrefetchAbort+0x44/0xa8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496731] [<800084d4>]
> > (do_PrefetchAbort) from [<80526864>] (ret_from_exception+0x0/0x1c)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496745] Exception
> > stack(0xb865ffb0 to 0xb865fff8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496763] ffa0:
> > 765c5000 1000 0003 76fe0dc8
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496785] ffc0: 76a00010
> > 0438 76a00040 765c4f78 0088 000c6000 0448 7650
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496804] ffe0: 000c5000
> > 7ea259f0 76d524f4 76daa0c0 2010 
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506406] Mem-info:
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506426] Normal per-cpu:
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506441] CPU0: hi:  186,
> > btch:  31 usd: 160
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506455] CPU1: hi:  186,
> > btch:  31 usd: 166
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506468] CPU2: hi:  186,
> > btch:  31 usd: 168
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506481] CPU3: hi:  186,
> > btch:  31 usd: 153
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510] active_anon:114781
> > inactive_anon:114792 isolated_anon:0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  active_file:15
> > inactive_file:14 isolated_file:0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  unevictable:0
> > dirty:0 writeback:0 unstable:0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  free:2208
> > slab_reclaimable:929 slab_unreclaimable:1352
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  mapped:3 shmem:2
> > pagetables:623 bounce:0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  free_cma:18
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506574] Normal free:8832kB
> > min:8192kB low:10240kB high:12288kB active_anon:459124kB
> > inactive_anon:459168kB active_file:60kB inactiv

Re: [PD] memory leak problem with small patch

[Matt Barber]

Was probably this:

https://lists.puredata.info/pipermail/pd-list/2016-03/113725.html

On Thu, Oct 20, 2016 at 6:29 AM, Jack  wrote:

> Using sources of Pd-0.47-1 seems to solve this issue.
> ++
>
> Jack
>
>
>
> Le 20/10/2016 à 11:19, Jack a écrit :
> > Hello,
> >
> > I made a simple patch to control an Enttec DMXUSB Pro, causing memory
> > leak after a few hours (around 4-5 hours) of operation.
> >
> > The patch is attached.
> > Configuration :
> > RaspberryPi 2
> > Raspbian GNU/Linux 7 (wheezy)
> > Pd-0.46.6
> >
> > Someone to help me to solve this issue ?
> > ++
> >
> > Jack
> >
> >
> >
> > Here the log from syslog (I can use gdb if needed ?) :
> >
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496233] pd invoked
> > oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496266] CPU: 2 PID: 2251
> > Comm: pd Not tainted 3.18.11-v7+ #781
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496319] [<800172bc>]
> > (unwind_backtrace) from [<80012f7c>] (show_stack+0x20/0x24)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496348] [<80012f7c>]
> > (show_stack) from [<80520970>] (dump_stack+0x98/0xd8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496445] [<80520970>]
> > (dump_stack) from [<8051e3bc>] (dump_header.isra.12+0x80/0x1a8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496489] [<8051e3bc>]
> > (dump_header.isra.12) from [<800ef2a8>] (oom_kill_process+0x340/0x3b8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496527] [<800ef2a8>]
> > (oom_kill_process) from [<800ef808>] (out_of_memory+0x300/0x34c)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496553] [<800ef808>]
> > (out_of_memory) from [<800f3c64>] (__alloc_pages_nodemask+0x930/0x970)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496578] [<800f3c64>]
> > (__alloc_pages_nodemask) from [<800ede38>] (filemap_fault+0x220/0x4a8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496604] [<800ede38>]
> > (filemap_fault) from [<80113104>] (__do_fault+0x44/0x98)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496628] [<80113104>]
> > (__do_fault) from [<80116068>] (do_read_fault.isra.91+0x1c4/0x274)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496652] [<80116068>]
> > (do_read_fault.isra.91) from [<8011683c>] (handle_mm_fault+0x3b8/0xa88)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496679] [<8011683c>]
> > (handle_mm_fault) from [<80528240>] (do_page_fault+0x2e4/0x458)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496706] [<80528240>]
> > (do_page_fault) from [<800084d4>] (do_PrefetchAbort+0x44/0xa8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496731] [<800084d4>]
> > (do_PrefetchAbort) from [<80526864>] (ret_from_exception+0x0/0x1c)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496745] Exception
> > stack(0xb865ffb0 to 0xb865fff8)
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496763] ffa0:
> > 765c5000 1000 0003 76fe0dc8
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496785] ffc0: 76a00010
> > 0438 76a00040 765c4f78 0088 000c6000 0448 7650
> > Oct 20 02:28:08 raspberrypi kernel: [20680.496804] ffe0: 000c5000
> > 7ea259f0 76d524f4 76daa0c0 2010 
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506406] Mem-info:
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506426] Normal per-cpu:
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506441] CPU0: hi:  186,
> > btch:  31 usd: 160
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506455] CPU1: hi:  186,
> > btch:  31 usd: 166
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506468] CPU2: hi:  186,
> > btch:  31 usd: 168
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506481] CPU3: hi:  186,
> > btch:  31 usd: 153
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510] active_anon:114781
> > inactive_anon:114792 isolated_anon:0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  active_file:15
> > inactive_file:14 isolated_file:0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  unevictable:0
> > dirty:0 writeback:0 unstable:0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  free:2208
> > slab_reclaimable:929 slab_unreclaimable:1352
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  mapped:3 shmem:2
> > pagetables:623 bounce:0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  free_cma:18
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506574] Normal free:8832kB
> > min:8192kB low:10240kB high:12288kB active_anon:459124kB
> > inactive_anon:459168kB active_file:60kB inactive_file:56kB
> > unevictable:0kB isolated(anon):0kB isolated(file):0kB present:966656kB
> > managed:949408kB mlocked:0kB dirty:0kB writeback:0kB mapped:12kB
> > shmem:8kB slab_reclaimable:3716kB slab_unreclaimable:5408kB
> > kernel_stack:680kB pagetables:2492kB unstable:0kB bounce:0kB
> > free_cma:72kB writeback_tmp:0kB pages_scanned:324 all_unreclaimable? no
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506589] lowmem_reserve[]: 0 0
> > Oct 20 02:28:08 raspberrypi kernel: [20680.506611] Normal: 178*4kB
> > (

Re: [PD] efficient approximation of trig functions for hi pass formula

[Derek Kwan]

> 
> >> Does anyone know a tool that will display the line number of a vim session
> > why not just adding ":set number" into vimrc?
> Because it's tiny.
> 
> 

well, you can make change the color of them with
:highlight LineNr ctermfg=color
if that helps. cterm=bold seems to do the same thing but it might just
be my color scheme... you can make invert the colorsceheme for the line
number column with a cterm=inverse option, hmm, i actually kinda like
that one...

you can also get the line number at the bottom with :set ruler



==
Derek Kwan
www.derekxkwan.com


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] memory leak problem with small patch

[Jack]

Using sources of Pd-0.47-1 seems to solve this issue.
++

Jack



Le 20/10/2016 à 11:19, Jack a écrit :
> Hello,
> 
> I made a simple patch to control an Enttec DMXUSB Pro, causing memory
> leak after a few hours (around 4-5 hours) of operation.
> 
> The patch is attached.
> Configuration :
> RaspberryPi 2
> Raspbian GNU/Linux 7 (wheezy)
> Pd-0.46.6
> 
> Someone to help me to solve this issue ?
> ++
> 
> Jack
> 
> 
> 
> Here the log from syslog (I can use gdb if needed ?) :
> 
> Oct 20 02:28:08 raspberrypi kernel: [20680.496233] pd invoked
> oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
> Oct 20 02:28:08 raspberrypi kernel: [20680.496266] CPU: 2 PID: 2251
> Comm: pd Not tainted 3.18.11-v7+ #781
> Oct 20 02:28:08 raspberrypi kernel: [20680.496319] [<800172bc>]
> (unwind_backtrace) from [<80012f7c>] (show_stack+0x20/0x24)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496348] [<80012f7c>]
> (show_stack) from [<80520970>] (dump_stack+0x98/0xd8)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496445] [<80520970>]
> (dump_stack) from [<8051e3bc>] (dump_header.isra.12+0x80/0x1a8)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496489] [<8051e3bc>]
> (dump_header.isra.12) from [<800ef2a8>] (oom_kill_process+0x340/0x3b8)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496527] [<800ef2a8>]
> (oom_kill_process) from [<800ef808>] (out_of_memory+0x300/0x34c)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496553] [<800ef808>]
> (out_of_memory) from [<800f3c64>] (__alloc_pages_nodemask+0x930/0x970)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496578] [<800f3c64>]
> (__alloc_pages_nodemask) from [<800ede38>] (filemap_fault+0x220/0x4a8)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496604] [<800ede38>]
> (filemap_fault) from [<80113104>] (__do_fault+0x44/0x98)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496628] [<80113104>]
> (__do_fault) from [<80116068>] (do_read_fault.isra.91+0x1c4/0x274)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496652] [<80116068>]
> (do_read_fault.isra.91) from [<8011683c>] (handle_mm_fault+0x3b8/0xa88)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496679] [<8011683c>]
> (handle_mm_fault) from [<80528240>] (do_page_fault+0x2e4/0x458)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496706] [<80528240>]
> (do_page_fault) from [<800084d4>] (do_PrefetchAbort+0x44/0xa8)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496731] [<800084d4>]
> (do_PrefetchAbort) from [<80526864>] (ret_from_exception+0x0/0x1c)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496745] Exception
> stack(0xb865ffb0 to 0xb865fff8)
> Oct 20 02:28:08 raspberrypi kernel: [20680.496763] ffa0:
> 765c5000 1000 0003 76fe0dc8
> Oct 20 02:28:08 raspberrypi kernel: [20680.496785] ffc0: 76a00010
> 0438 76a00040 765c4f78 0088 000c6000 0448 7650
> Oct 20 02:28:08 raspberrypi kernel: [20680.496804] ffe0: 000c5000
> 7ea259f0 76d524f4 76daa0c0 2010 
> Oct 20 02:28:08 raspberrypi kernel: [20680.506406] Mem-info:
> Oct 20 02:28:08 raspberrypi kernel: [20680.506426] Normal per-cpu:
> Oct 20 02:28:08 raspberrypi kernel: [20680.506441] CPU0: hi:  186,
> btch:  31 usd: 160
> Oct 20 02:28:08 raspberrypi kernel: [20680.506455] CPU1: hi:  186,
> btch:  31 usd: 166
> Oct 20 02:28:08 raspberrypi kernel: [20680.506468] CPU2: hi:  186,
> btch:  31 usd: 168
> Oct 20 02:28:08 raspberrypi kernel: [20680.506481] CPU3: hi:  186,
> btch:  31 usd: 153
> Oct 20 02:28:08 raspberrypi kernel: [20680.506510] active_anon:114781
> inactive_anon:114792 isolated_anon:0
> Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  active_file:15
> inactive_file:14 isolated_file:0
> Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  unevictable:0
> dirty:0 writeback:0 unstable:0
> Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  free:2208
> slab_reclaimable:929 slab_unreclaimable:1352
> Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  mapped:3 shmem:2
> pagetables:623 bounce:0
> Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  free_cma:18
> Oct 20 02:28:08 raspberrypi kernel: [20680.506574] Normal free:8832kB
> min:8192kB low:10240kB high:12288kB active_anon:459124kB
> inactive_anon:459168kB active_file:60kB inactive_file:56kB
> unevictable:0kB isolated(anon):0kB isolated(file):0kB present:966656kB
> managed:949408kB mlocked:0kB dirty:0kB writeback:0kB mapped:12kB
> shmem:8kB slab_reclaimable:3716kB slab_unreclaimable:5408kB
> kernel_stack:680kB pagetables:2492kB unstable:0kB bounce:0kB
> free_cma:72kB writeback_tmp:0kB pages_scanned:324 all_unreclaimable? no
> Oct 20 02:28:08 raspberrypi kernel: [20680.506589] lowmem_reserve[]: 0 0
> Oct 20 02:28:08 raspberrypi kernel: [20680.506611] Normal: 178*4kB
> (UEMC) 4*8kB (E) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
> 0*2048kB 2*4096kB (R) = 8936kB
> Oct 20 02:28:08 raspberrypi kernel: [20680.506692] 105 total pagecache pages
> Oct 20 02:28:08 raspberrypi kernel: [20680.506706] 42 pages in swap cache
> Oct 20 02:28:08 raspberrypi kernel: [20680.506719] Swap ca

[PD] memory leak problem with small patch

[Jack]

Hello,

I made a simple patch to control an Enttec DMXUSB Pro, causing memory
leak after a few hours (around 4-5 hours) of operation.

The patch is attached.
Configuration :
RaspberryPi 2
Raspbian GNU/Linux 7 (wheezy)
Pd-0.46.6

Someone to help me to solve this issue ?
++

Jack



Here the log from syslog (I can use gdb if needed ?) :

Oct 20 02:28:08 raspberrypi kernel: [20680.496233] pd invoked
oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Oct 20 02:28:08 raspberrypi kernel: [20680.496266] CPU: 2 PID: 2251
Comm: pd Not tainted 3.18.11-v7+ #781
Oct 20 02:28:08 raspberrypi kernel: [20680.496319] [<800172bc>]
(unwind_backtrace) from [<80012f7c>] (show_stack+0x20/0x24)
Oct 20 02:28:08 raspberrypi kernel: [20680.496348] [<80012f7c>]
(show_stack) from [<80520970>] (dump_stack+0x98/0xd8)
Oct 20 02:28:08 raspberrypi kernel: [20680.496445] [<80520970>]
(dump_stack) from [<8051e3bc>] (dump_header.isra.12+0x80/0x1a8)
Oct 20 02:28:08 raspberrypi kernel: [20680.496489] [<8051e3bc>]
(dump_header.isra.12) from [<800ef2a8>] (oom_kill_process+0x340/0x3b8)
Oct 20 02:28:08 raspberrypi kernel: [20680.496527] [<800ef2a8>]
(oom_kill_process) from [<800ef808>] (out_of_memory+0x300/0x34c)
Oct 20 02:28:08 raspberrypi kernel: [20680.496553] [<800ef808>]
(out_of_memory) from [<800f3c64>] (__alloc_pages_nodemask+0x930/0x970)
Oct 20 02:28:08 raspberrypi kernel: [20680.496578] [<800f3c64>]
(__alloc_pages_nodemask) from [<800ede38>] (filemap_fault+0x220/0x4a8)
Oct 20 02:28:08 raspberrypi kernel: [20680.496604] [<800ede38>]
(filemap_fault) from [<80113104>] (__do_fault+0x44/0x98)
Oct 20 02:28:08 raspberrypi kernel: [20680.496628] [<80113104>]
(__do_fault) from [<80116068>] (do_read_fault.isra.91+0x1c4/0x274)
Oct 20 02:28:08 raspberrypi kernel: [20680.496652] [<80116068>]
(do_read_fault.isra.91) from [<8011683c>] (handle_mm_fault+0x3b8/0xa88)
Oct 20 02:28:08 raspberrypi kernel: [20680.496679] [<8011683c>]
(handle_mm_fault) from [<80528240>] (do_page_fault+0x2e4/0x458)
Oct 20 02:28:08 raspberrypi kernel: [20680.496706] [<80528240>]
(do_page_fault) from [<800084d4>] (do_PrefetchAbort+0x44/0xa8)
Oct 20 02:28:08 raspberrypi kernel: [20680.496731] [<800084d4>]
(do_PrefetchAbort) from [<80526864>] (ret_from_exception+0x0/0x1c)
Oct 20 02:28:08 raspberrypi kernel: [20680.496745] Exception
stack(0xb865ffb0 to 0xb865fff8)
Oct 20 02:28:08 raspberrypi kernel: [20680.496763] ffa0:
765c5000 1000 0003 76fe0dc8
Oct 20 02:28:08 raspberrypi kernel: [20680.496785] ffc0: 76a00010
0438 76a00040 765c4f78 0088 000c6000 0448 7650
Oct 20 02:28:08 raspberrypi kernel: [20680.496804] ffe0: 000c5000
7ea259f0 76d524f4 76daa0c0 2010 
Oct 20 02:28:08 raspberrypi kernel: [20680.506406] Mem-info:
Oct 20 02:28:08 raspberrypi kernel: [20680.506426] Normal per-cpu:
Oct 20 02:28:08 raspberrypi kernel: [20680.506441] CPU0: hi:  186,
btch:  31 usd: 160
Oct 20 02:28:08 raspberrypi kernel: [20680.506455] CPU1: hi:  186,
btch:  31 usd: 166
Oct 20 02:28:08 raspberrypi kernel: [20680.506468] CPU2: hi:  186,
btch:  31 usd: 168
Oct 20 02:28:08 raspberrypi kernel: [20680.506481] CPU3: hi:  186,
btch:  31 usd: 153
Oct 20 02:28:08 raspberrypi kernel: [20680.506510] active_anon:114781
inactive_anon:114792 isolated_anon:0
Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  active_file:15
inactive_file:14 isolated_file:0
Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  unevictable:0
dirty:0 writeback:0 unstable:0
Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  free:2208
slab_reclaimable:929 slab_unreclaimable:1352
Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  mapped:3 shmem:2
pagetables:623 bounce:0
Oct 20 02:28:08 raspberrypi kernel: [20680.506510]  free_cma:18
Oct 20 02:28:08 raspberrypi kernel: [20680.506574] Normal free:8832kB
min:8192kB low:10240kB high:12288kB active_anon:459124kB
inactive_anon:459168kB active_file:60kB inactive_file:56kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:966656kB
managed:949408kB mlocked:0kB dirty:0kB writeback:0kB mapped:12kB
shmem:8kB slab_reclaimable:3716kB slab_unreclaimable:5408kB
kernel_stack:680kB pagetables:2492kB unstable:0kB bounce:0kB
free_cma:72kB writeback_tmp:0kB pages_scanned:324 all_unreclaimable? no
Oct 20 02:28:08 raspberrypi kernel: [20680.506589] lowmem_reserve[]: 0 0
Oct 20 02:28:08 raspberrypi kernel: [20680.506611] Normal: 178*4kB
(UEMC) 4*8kB (E) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 2*4096kB (R) = 8936kB
Oct 20 02:28:08 raspberrypi kernel: [20680.506692] 105 total pagecache pages
Oct 20 02:28:08 raspberrypi kernel: [20680.506706] 42 pages in swap cache
Oct 20 02:28:08 raspberrypi kernel: [20680.506719] Swap cache stats: add
25782, delete 25740, find 90/164
Oct 20 02:28:08 raspberrypi kernel: [20680.506729] Free swap  = 0kB
Oct 20 02:28:08 raspberrypi kernel: [20680.506738] Total swap = 102396kB
Oct 20 02:28:08 raspberrypi kernel: [20680.524406] 241664 pages of RAM
Oct 20 02:28:08 raspberrypi kern

Re: [PD] OT : using libre office for data regression; WAS Re: efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

[cyrille henry]

Le 20/10/2016 à 01:07, katja a écrit :
[...]



For the filter recipe the curve must go through coordinates [0 1] and
[pi -1], to get the expected behavior when cutoff frequency is set to
DC or Nyquist. [hip~ 0] should not block DC, which is only possible
when the coefficient is exactly 1 like you get it with
(1-sin(0))/cos(0). I tuned my factors 'by hand' to do so. That may be
possible with your libre office result as well.


yes, in my example the result is slightly different from 1 / -1.
i tried again, adding about 20 points for X=0 and X=1 to get more weight for
this coordinate.
the coef where better, but not perfect.

still it's a good starting point for manual adjustment.


That's what I thought, avoiding the initial guess iterations saves a
lot of time. Can you post your adjusted parameters? Being an
approximation the function will never be perfect. We can select the
best frequency response compromise.


libre office say :

-1.5743519661 X
-1.1794365231 X^3
-2.0916936873 X^5
(for X between -0.5 / 0.5)



However, when done in


double precision the calculation will give slightly different result.
Above or below 1, I don't know yet. In any case this has to be
considered when writing the C.


shouldn’t it be clipped? (what is a filter with negative frequency, or
frequency above Nyquist?)


Yes coefficients below -1 and above 1 must be clipped. But what if it
doesn't reach 1 at DC or -1 at Nyquist in double precision because of
the rounding difference. The behavior at those extremes would be
incorrect. Not that it matters now, we don't have double precision pd.
But code written today should be double-precision-proof, you never
know what will happen tomorrow.



since we know that aX + bX³ + cX⁵ should be 1 for X = -0.5, we can automatically adjust 
"a" to:
a = 1 - b*0.5³ - c*0.5⁵
using only b and c from the polynomial regression.

(since the function is odd, it will also work for X = 0.5)

I did not try, but apart from rounding error, it should satisfy the extreme condition 
whatever precision is used, as long as "a" is computed in the C code.

(the pi value I used in libreoffice is not double precision accurate anyhow).

cheers
c


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list