Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 27 Nov 2010, Ivica Ico Bukvic wrote: This looks like an incompatibility between tagged moving of an object and something in the gridflow. Does this occur with any object or just some specific object(s)? Mathieu, The offending call should be the same like the Regular call except that is this place is using a tag. It can be found in the g_text.c file. Did you say you expanded t_widgetbehavior ? That sounds like that could be the problem. GridFlow compiles with a bundled m_pd.h that does not include extra fields there. Then it hacks the comment-class to add an inlet to it and keep it properly hidden, and this requires copying the t_widgetbehavior struct of the comment-class. Given that I want a single binary for all distributions of Pd, and that I really need the comment-inlets feature, I'll have to add an extra «hack» for that. How do I check for your version of Pd ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Since ctrl r command is something that's going to be used a lot more often (IMHO) then raising the root window (which personally I've not used as much since this last change), I feel like it would be better to have more commonly used keys closer to the center of the keyboard so that one can invoke then with either one hand and thus use the keyboard simultaneously while using mouse. This is why I've moved raise root window to ctrl+; and put cord inspector in its place. Tip-posting courtesy of my android. Hans-Christoph Steiner h...@at.or.at wrote: On Nov 29, 2010, at 2:47 PM, Ivica Ico Bukvic wrote: Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference. Actually, this is an excellent point. Consequently, 3rd release candidate is now up where I've made the following adjustments: *changed paste action so that it pastes where the current mouse position is rather than duplicating original x/y positions. more so, the newly spawned objects are grabbed (as if creating an object from a menu), allowing easy repositioning. This change will greatly help in making sure that objects are not spawned very far from the current canvas location (as per Jonathan's comment/suggestion) due to the new scrolling algorithm. *duplicate now works on other canvases as well (does not require duplicating within the same canvas) thus replacing the functionality of the old paste action which preserves x/y positions. There is no offset if the newly pasted canvas is different than the old one. *fixed bug where scrollbars would not redraw after initial dragging of a newly created object. *enabled autopatch for iemgui objects. *Invoking disabled ctrl+r now enables both the edit mode and the cord inspector (as per Iohannes's suggestion). As usual feedback is most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Ctrl-R raises the Pd window on Pd 0.43 and Pd-extended 0.42. How about making the cord inspector Ctrl-I? .hc [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
That's your choice of course, but its been Ctrl-R in Pd-extended for a while, and now its in Pd-vanilla. .hc On Nov 30, 2010, at 10:20 AM, Ivica Ico Bukvic wrote: Since ctrl r command is something that's going to be used a lot more often (IMHO) then raising the root window (which personally I've not used as much since this last change), I feel like it would be better to have more commonly used keys closer to the center of the keyboard so that one can invoke then with either one hand and thus use the keyboard simultaneously while using mouse. This is why I've moved raise root window to ctrl+; and put cord inspector in its place. Tip-posting courtesy of my android. Hans-Christoph Steiner h...@at.or.at wrote: On Nov 29, 2010, at 2:47 PM, Ivica Ico Bukvic wrote: Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference. Actually, this is an excellent point. Consequently, 3rd release candidate is now up where I've made the following adjustments: *changed paste action so that it pastes where the current mouse position is rather than duplicating original x/y positions. more so, the newly spawned objects are grabbed (as if creating an object from a menu), allowing easy repositioning. This change will greatly help in making sure that objects are not spawned very far from the current canvas location (as per Jonathan's comment/suggestion) due to the new scrolling algorithm. *duplicate now works on other canvases as well (does not require duplicating within the same canvas) thus replacing the functionality of the old paste action which preserves x/y positions. There is no offset if the newly pasted canvas is different than the old one. *fixed bug where scrollbars would not redraw after initial dragging of a newly created object. *enabled autopatch for iemgui objects. *Invoking disabled ctrl+r now enables both the edit mode and the cord inspector (as per Iohannes's suggestion). As usual feedback is most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Ctrl-R raises the Pd window on Pd 0.43 and Pd-extended 0.42. How about making the cord inspector Ctrl-I? .hc [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
--- On Mon, 11/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: Jonathan Wilkes jancs...@yahoo.com Cc: András Murányi muran...@gmail.com, PD List pd-list@iem.at Date: Monday, November 29, 2010, 8:34 AM On Sat, 2010-11-27 at 23:18 -0800, Jonathan Wilkes wrote: Hi, Here are some scrolling observations: In the attached patch, drag the [pd] object far down into the bottom right-hand corner, so that you get some scrollbars to appear. Now, on the current pd-extended, you can scroll down to that object, and when you drag it back to its original location, the scrollbars respond in realtime so that the object swoops back up the patch until, finally, the scrollbars disappear. In your version the scrollbars don't react until you stop dragging and release the mouse button. Just an observation-- I suppose both methods have their strengths and weaknesses. I prefer the current Pd-ext behavior-- for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up. But notice that once you drag the [pd] object back near its original position, the [f] object looks as if it's at (0,0), when it's really at (10,10). However, if you save the patch and reopen it the [f] will appear at its proper, original position-- (10,10). I think this is a bug, because it means any time one adds or takes away the scrollbars the absolute positioning of the objects on the canvas is temporarily lost, forcing the user to close and open to see the real positioning. -Jonathan Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference. The reason canvas is displaced in l2ork version is because our philosophy is if a patch can fit in a window, it should. Granted, it has some shortcomings like patches opening and then having to readjust as well as having them not (0,0)-centric which makes them potentially less compatible with vanilla version. That said, I believe this is a much better way of dealing with patches, and if one really wants to lock-in patch positioning, they should simply use a cnv (canvas) object whose name in many ways suggests exactly that. NB: repositioning of window upon load can be avoided only if the format of saving the patch also includes the top-left corner of the canvas, which current format does not support. Please note that l2ork's scrolling algorithm also accounts for all other operations, such as undo/redo/cut/copy/paste, even key presses that may extend the width of an object. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
--- On Mon, 11/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: Jonathan Wilkes jancs...@yahoo.com Cc: András Murányi muran...@gmail.com, PD List pd-list@iem.at Date: Monday, November 29, 2010, 8:53 AM OK, release candidate 2 is now up with following changes: [...] *cord inspector uses globally defined font size This is turning out to be a wonderful tool: [bang( | [f]x[+ 1] 1) Turn on cord inspector 2) In edit mode, mouse over one of the cords so the inspector appears. 3) Hold down ctrl to go into transient run mode 4) The inspector stays where it is. Awesome! Keep ctrl down and go click the bng and watch your data flow without the need for any number boxes or [print]! -Jonathan *removed xy stretch option from the font menu as it appears to be unstable *corrected text color on pd patcher Latest snapshot is available at: http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference. Actually, this is an excellent point. Consequently, 3rd release candidate is now up where I've made the following adjustments: *changed paste action so that it pastes where the current mouse position is rather than duplicating original x/y positions. more so, the newly spawned objects are grabbed (as if creating an object from a menu), allowing easy repositioning. This change will greatly help in making sure that objects are not spawned very far from the current canvas location (as per Jonathan's comment/suggestion) due to the new scrolling algorithm. *duplicate now works on other canvases as well (does not require duplicating within the same canvas) thus replacing the functionality of the old paste action which preserves x/y positions. There is no offset if the newly pasted canvas is different than the old one. *fixed bug where scrollbars would not redraw after initial dragging of a newly created object. *enabled autopatch for iemgui objects. *Invoking disabled ctrl+r now enables both the edit mode and the cord inspector (as per Iohannes's suggestion). As usual feedback is most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Nov 29, 2010, at 2:47 PM, Ivica Ico Bukvic wrote: Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference. Actually, this is an excellent point. Consequently, 3rd release candidate is now up where I've made the following adjustments: *changed paste action so that it pastes where the current mouse position is rather than duplicating original x/y positions. more so, the newly spawned objects are grabbed (as if creating an object from a menu), allowing easy repositioning. This change will greatly help in making sure that objects are not spawned very far from the current canvas location (as per Jonathan's comment/suggestion) due to the new scrolling algorithm. *duplicate now works on other canvases as well (does not require duplicating within the same canvas) thus replacing the functionality of the old paste action which preserves x/y positions. There is no offset if the newly pasted canvas is different than the old one. *fixed bug where scrollbars would not redraw after initial dragging of a newly created object. *enabled autopatch for iemgui objects. *Invoking disabled ctrl+r now enables both the edit mode and the cord inspector (as per Iohannes's suggestion). As usual feedback is most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Ctrl-R raises the Pd window on Pd 0.43 and Pd-extended 0.42. How about making the cord inspector Ctrl-I? .hc [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sun, Nov 28, 2010 at 7:47 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Small detail-- your 'Put' menu is tearoff-able. ...which is super cool, IMHO Andras ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Nov 28, 2010, at 11:11 AM, András Murányi wrote: On Sun, Nov 28, 2010 at 7:47 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Small detail-- your 'Put' menu is tearoff-able. ...which is super cool, IMHO Andras Its one of those things that people love and hate. That's where GUI plugins come in: people who love them can enable them with a simple GUI plugin. .hc Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 2010-11-27 at 22:47 -0800, Jonathan Wilkes wrote: Small detail-- your 'Put' menu is tearoff-able. This is intentional. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 2010-11-27 at 23:18 -0800, Jonathan Wilkes wrote: Hi, Here are some scrolling observations: In the attached patch, drag the [pd] object far down into the bottom right-hand corner, so that you get some scrollbars to appear. Now, on the current pd-extended, you can scroll down to that object, and when you drag it back to its original location, the scrollbars respond in realtime so that the object swoops back up the patch until, finally, the scrollbars disappear. In your version the scrollbars don't react until you stop dragging and release the mouse button. Just an observation-- I suppose both methods have their strengths and weaknesses. I prefer the current Pd-ext behavior-- for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up. But notice that once you drag the [pd] object back near its original position, the [f] object looks as if it's at (0,0), when it's really at (10,10). However, if you save the patch and reopen it the [f] will appear at its proper, original position-- (10,10). I think this is a bug, because it means any time one adds or takes away the scrollbars the absolute positioning of the objects on the canvas is temporarily lost, forcing the user to close and open to see the real positioning. -Jonathan Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. The reason canvas is displaced in l2ork version is because our philosophy is if a patch can fit in a window, it should. Granted, it has some shortcomings like patches opening and then having to readjust as well as having them not (0,0)-centric which makes them potentially less compatible with vanilla version. That said, I believe this is a much better way of dealing with patches, and if one really wants to lock-in patch positioning, they should simply use a cnv (canvas) object whose name in many ways suggests exactly that. NB: repositioning of window upon load can be avoided only if the format of saving the patch also includes the top-left corner of the canvas, which current format does not support. Please note that l2ork's scrolling algorithm also accounts for all other operations, such as undo/redo/cut/copy/paste, even key presses that may extend the width of an object. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
OK, release candidate 2 is now up with following changes: *This one was *really* bad: Cut/Paste/Undo/Redo creates double entries on gop-in-gop patches. Basically, after literally a day of troubleshooting and posting hooks all over the pd source (heck, I even got to study binbuf stuff :-) it appears in these instances window_name never changes upon restore (in other words tcl/tk canvas's documentation lies about not reusing id with every new object--why am I not surprised?) NB: this finally solves every instance I am familiar with in which pd suddenly starts spewing two or more objects per each key-press/action. Consequently, even though I've said it many times before, I finally believe this solves all of the GOP redraw/bug issues. To best test this problem you can simply create a simple patch using either vanilla pd or pd-extended with a GOP abstraction that has another visible GOP abstraction inside it. Now on the parent window cut and undo (or paste) the GOP-ed abstraction and open it. Try creating a new object inside it and presto, everything is doubled. As you do more cut/undos you can get as many of them per action as you like :-). This can also result in a crash as window close will be also registered multiple times. If you are wondering how the fix works, it's the ugliest hack on the planet made for the comparably attractive toolkit: every time the undo/copy queue is copied I insert a bogus object prior to the selection (in this case a comment with an appropriately redundant name) and offset all connections by one. Once the buffer is restored, the fact it is different from the original scene (seems to me that the tcl/tk might be caching things id-wise without properly disconnecting HID hooks to those widgets, hence multiple entries per action) forces tcl/tk to assign truly unique ids to newly pasted objects. Upon restoring the queue, I erase the bogus object. Now, how ugly is that? So, the next time you have an opportunity to read tcl/tk documentation don't forget to take it with a boulder of salt. Other fixes: *recreation of gop-ed objects when selecting their text (a.k.a. activating them) must not apply to gop-ed pd patchers (when clicked to change their names) *changing name on a gop-ed pd patcher automatically resizes patcher gop window and correctly positions outlets *Added ctrl+enter reselect option *cleaned up stderr errors about canvases/widgets not found *when closing dirty patch and dirty abstraction, prompts are incorrectly focusing on and pointing to wrong windows *cord inspector uses globally defined font size *removed xy stretch option from the font menu as it appears to be unstable *corrected text color on pd patcher Latest snapshot is available at: http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Hi Ico, Regarding libraries/externals: I don't know if anyone else has experience an issue with the py (python) library with L2Ork pd-extended but when the binary is loaded it completely breaks/freezes PD. So much so I have to log out, log back in again and manually delete the py folder to get it to start up again. Also Gridflow as mentioned previously causes crashes but not so hard as py. When I swapped the L2Orkt file to normal extended, I could use Gridflow in the new gui as normal- so perhaps the issue is not in the tk file but else where? Of course the above could be due to my set up (or me just being dumb) so if anyone else has identical problems do me let know? - cheers! On Sat, Nov 27, 2010 at 6:07 AM, Ivica Ico Bukvic i...@vt.edu wrote: On Fri, 2010-11-26 at 21:26 -0500, Ivica Ico Bukvic wrote: Another quick update includes following, mainly cosmetic fixes/improvements: *made iemgui use default $select_color as defined in pd.tk while leaving legacy definition for IEM_GUI_COLOR_SELECTED color (as defined in g_all_guis.h) for other externals that may rely upon it *cleaned up bugs in mycanvas where label did not follow the object *cleaned up segfault on number2 when creating a label *modularized highlight nlet color and width and moved them to pd.tk *changed the way highlight nlet filters different objects and reverts their nlet color properly to original state (e.g. iemgui uses black as default whereas text objects use gray nlets You can grab it from: http://l2ork.music.vt.edu/main/?page_id=56 Ugh, 20101127 is now out fixing two regressions. Namely, 1) segfault due to the way iemgui's implementation of universal color did not allocate proper memory for the char array 2) stale GOP elements due to incorrect check for an open window This latest snapshot should be considered 1st release candidate. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 27 Nov 2010, ALAN BROOKER wrote: Also Gridflow as mentioned previously causes crashes but not so hard as py. When I swapped the L2Orkt file to normal extended, I could use Gridflow in the new gui as normal- so perhaps the issue is not in the tk file but else where? If you (or someone else) can narrow down the l2ork-gridflow problems, I could try to fix them. Is it something happening mostly with the helpfiles, or also with something else ? Is it happening at startup, or later ? What is the L20rkt file ? ___ | Mathieu Bouchard - Aix-en-Provence___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Hi Mathieu, Thanks for this, I have done a trace back with the following output on the terminal : (gdb) run Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] [New Thread 0xb6168b70 (LWP 5214)] init : Avifile RELEASE-0.7.48-100119-21:44-../src/configure init : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_api init : 3200.00 MHz AMD Phenom(tm) II X2 555 Processor detected where Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () (gdb) where #0 0x0011 in ?? () #1 0x080a9665 in gobj_displace_withtag (x=0x8215790, dx=value optimised out, dy=0) at g_editor.c:70 #2 canvas_displaceselection (x=0x8215790, dx=value optimised out, dy=0) at g_editor.c:1913 #3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) at g_editor.c:2102 #4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, argv=0xb08c) at m_class.c:792 #5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, argv=0xb08c) at m_class.c:813 #6 0x080cff0a in binbuf_eval (x=0x814d610, target=value optimised out, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 #8 0x080ddb7a in sys_domicrosleep (microsec=value optimised out, pollem=value optimised out) at s_inter.c:198 #9 0x080de662 in sys_pollgui () at s_inter.c:862 #10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 #13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 (gdb) where #0 0x0011 in ?? () #1 0x080a9665 in gobj_displace_withtag (x=0x8215790, dx=value optimised out, dy=0) at g_editor.c:70 #2 canvas_displaceselection (x=0x8215790, dx=value optimised out, dy=0) at g_editor.c:1913 #3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) at g_editor.c:2102 #4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, argv=0xb08c) at m_class.c:792 #5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, argv=0xb08c) at m_class.c:813 #6 0x080cff0a in binbuf_eval (x=0x814d610, target=value optimised out, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 #8 0x080ddb7a in sys_domicrosleep (microsec=value optimised out, pollem=value optimised out) at s_inter.c:198 #9 0x080de662 in sys_pollgui () at s_inter.c:862 #10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 #13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 Thanks again Al On Sat, Nov 27, 2010 at 11:37 AM, Mathieu Bouchard ma...@artengine.cawrote: On Sat, 27 Nov 2010, ALAN BROOKER wrote: Also Gridflow as mentioned previously causes crashes but not so hard as py. When I swapped the L2Orkt file to normal extended, I could use Gridflow in the new gui as normal- so perhaps the issue is not in the tk file but else where? If you (or someone else) can narrow down the l2ork-gridflow problems, I could try to fix them. Is it something happening mostly with the helpfiles, or also with something else ? Is it happening at startup, or later ? What is the L20rkt file ? ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
This looks like an incompatibility between tagged moving of an object and something in the gridflow. Does this occur with any object or just some specific object(s)? Mathieu, The offending call should be the same like the Regular call except that is this place is using a tag. It can be found in the g_text.c file. Cheers! ALAN BROOKER alan.brooker2...@gmail.com wrote: Hi Mathieu, Thanks for this, I have done a trace back with the following output on the terminal : (gdb) run Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] [New Thread 0xb6168b70 (LWP 5214)] init : Avifile RELEASE-0.7.48-100119-21:44-../src/configure init : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_api init : 3200.00 MHz AMD Phenom(tm) II X2 555 Processor detected where Program received signal SIGSEGV, Segmentation fault. 0x0011 in ?? () (gdb) where #0 0x0011 in ?? () #1 0x080a9665 in gobj_displace_withtag (x=0x8215790, dx=value optimised out, dy=0) at g_editor.c:70 #2 canvas_displaceselection (x=0x8215790, dx=value optimised out, dy=0) at g_editor.c:1913 #3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) at g_editor.c:2102 #4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, argv=0xb08c) at m_class.c:792 #5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, argv=0xb08c) at m_class.c:813 #6 0x080cff0a in binbuf_eval (x=0x814d610, target=value optimised out, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 #8 0x080ddb7a in sys_domicrosleep (microsec=value optimised out, pollem=value optimised out) at s_inter.c:198 #9 0x080de662 in sys_pollgui () at s_inter.c:862 #10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 #13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 (gdb) where #0 0x0011 in ?? () #1 0x080a9665 in gobj_displace_withtag (x=0x8215790, dx=value optimised out, dy=0) at g_editor.c:70 #2 canvas_displaceselection (x=0x8215790, dx=value optimised out, dy=0) at g_editor.c:1913 #3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) at g_editor.c:2102 #4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, argv=0xb08c) at m_class.c:792 #5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, argv=0xb08c) at m_class.c:813 #6 0x080cff0a in binbuf_eval (x=0x814d610, target=value optimised out, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 #8 0x080ddb7a in sys_domicrosleep (microsec=value optimised out, pollem=value optimised out) at s_inter.c:198 #9 0x080de662 in sys_pollgui () at s_inter.c:862 #10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dcc09 in sys_main (argc=5, argv=0xb4e4) at s_main.c:310 #13 0x080e56cb in main (argc=5, argv=0xb4e4) at s_entry.c:32 Thanks again Al On Sat, Nov 27, 2010 at 11:37 AM, Mathieu Bouchard ma...@artengine.cawrote: On Sat, 27 Nov 2010, ALAN BROOKER wrote: Also Gridflow as mentioned previously causes crashes but not so hard as py. When I swapped the L2Orkt file to normal extended, I could use Gridflow in the new gui as normal- so perhaps the issue is not in the tk file but else where? If you (or someone else) can narrow down the l2ork-gridflow problems, I could try to fix them. Is it something happening mostly with the helpfiles, or also with something else ? Is it happening at startup, or later ? What is the L20rkt file ? ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) *** buffer overflow detected ***: ./pd terminated === Backtrace: = /lib/libc.so.6(__fortify_fail+0x37)[0x7f7189d6d217] /lib/libc.so.6(+0xfe0d0)[0x7f7189d6c0d0] /lib/libc.so.6(+0xfd539)[0x7f7189d6b539] /lib/libc.so.6(_IO_default_xsputn+0xcc)[0x7f7189ce3d1c] /lib/libc.so.6(_IO_vfprintf+0x14c)[0x7f7189cb34ec] /lib/libc.so.6(__vsprintf_chk+0x99)[0x7f7189d6b5d9] /lib/libc.so.6(__sprintf_chk+0x7f)[0x7f7189d6b51f] ./pd[0x479cd4] ./pd(sys_pollgui+0xb8)[0x49ed78] ./pd(m_mainloop+0x84b)[0x4984db] ./pd(sys_main+0x225)[0x49d0b5] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f7189c8cc4d] ./pd[0x414159] === Memory map: 0040-0050b000 r-xp 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070a000-0070b000 r--p 0010a000 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070b000-0070d000 rw-p 0010b000 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070d000-00b1d000 rw-p 00:00 0 01694000-0d33e000 rw-p 00:00 0 [heap] 7f71798b6000-7f71798b8000 r-xp 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f71798b8000-7f7179ab7000 ---p 2000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab7000-7f7179ab8000 r--p 1000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab8000-7f7179ab9000 rw-p 2000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab9000-7f7179aba000 r-xp 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179aba000-7f7179cba000 ---p 1000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cba000-7f7179cbb000 r--p 1000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cbb000-7f7179cbc000 rw-p 2000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cbc000-7f7179cbd000 r-xp 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179cbd000-7f7179ebc000 ---p 1000 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebc000-7f7179ebd000 r--p 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebd000-7f7179ebe000 rw-p 1000 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebe000-7f7179ec2000 r-xp 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f7179ec2000-7f717a0c1000 ---p 4000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c1000-7f717a0c2000 r--p 3000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c2000-7f717a0c3000 rw-p 4000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c3000-7f717a0c7000 r-xp 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a0c7000-7f717a2c6000 ---p 4000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c6000-7f717a2c7000 r--p 3000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c7000-7f717a2c8000 rw-p 4000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c8000-7f717a2ce000 r-xp 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a2ce000-7f717a4cd000 ---p 6000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4cd000-7f717a4ce000 r--p 5000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4ce000-7f717a4cf000 rw-p 6000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4cf000-7f717a4d6000 r-xp 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a4d6000-7f717a6d5000 ---p 7000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d5000-7f717a6d6000 r--p 6000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d6000-7f717a6d7000 rw-p 7000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d7000-7f717a6d8000 r-xp 08:12 1630422 /usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux 7f717a6d8000-7f717a8d8000 ---p 1000 08:12 1630422 /usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux 7f717a8d8000-7f717a8d9000 r--p 1000 08:12 1630422 /usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux 7f717a8d9000-7f717a8da000 rw-p 2000 08:12 1630422 /usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux 7f717a8da000-7f717a8dc000 r-xp 08:12 1638450 /home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux 7f717a8dc000-7f717aadb000 ---p 2000 08:12 1638450 /home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux 7f717aadb000-7f717aadc000 r--p 1000 08:12 1638450 /home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux 7f717aadc000-7f717aadd000 rw-p 2000 08:12 1638450 /home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux 7f717aadd000-7f717aaf3000 r-xp 08:12 2236471
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Thx for the report. Let me investigate once I get back home. András Murányi muran...@gmail.com wrote: with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) *** buffer overflow detected ***: ./pd terminated === Backtrace: = /lib/libc.so.6(__fortify_fail+0x37)[0x7f7189d6d217] /lib/libc.so.6(+0xfe0d0)[0x7f7189d6c0d0] /lib/libc.so.6(+0xfd539)[0x7f7189d6b539] /lib/libc.so.6(_IO_default_xsputn+0xcc)[0x7f7189ce3d1c] /lib/libc.so.6(_IO_vfprintf+0x14c)[0x7f7189cb34ec] /lib/libc.so.6(__vsprintf_chk+0x99)[0x7f7189d6b5d9] /lib/libc.so.6(__sprintf_chk+0x7f)[0x7f7189d6b51f] ./pd[0x479cd4] ./pd(sys_pollgui+0xb8)[0x49ed78] ./pd(m_mainloop+0x84b)[0x4984db] ./pd(sys_main+0x225)[0x49d0b5] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f7189c8cc4d] ./pd[0x414159] === Memory map: 0040-0050b000 r-xp 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070a000-0070b000 r--p 0010a000 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070b000-0070d000 rw-p 0010b000 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070d000-00b1d000 rw-p 00:00 0 01694000-0d33e000 rw-p 00:00 0 [heap] 7f71798b6000-7f71798b8000 r-xp 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f71798b8000-7f7179ab7000 ---p 2000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab7000-7f7179ab8000 r--p 1000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab8000-7f7179ab9000 rw-p 2000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab9000-7f7179aba000 r-xp 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179aba000-7f7179cba000 ---p 1000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cba000-7f7179cbb000 r--p 1000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cbb000-7f7179cbc000 rw-p 2000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cbc000-7f7179cbd000 r-xp 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179cbd000-7f7179ebc000 ---p 1000 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebc000-7f7179ebd000 r--p 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebd000-7f7179ebe000 rw-p 1000 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebe000-7f7179ec2000 r-xp 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f7179ec2000-7f717a0c1000 ---p 4000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c1000-7f717a0c2000 r--p 3000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c2000-7f717a0c3000 rw-p 4000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c3000-7f717a0c7000 r-xp 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a0c7000-7f717a2c6000 ---p 4000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c6000-7f717a2c7000 r--p 3000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c7000-7f717a2c8000 rw-p 4000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c8000-7f717a2ce000 r-xp 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a2ce000-7f717a4cd000 ---p 6000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4cd000-7f717a4ce000 r--p 5000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4ce000-7f717a4cf000 rw-p 6000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4cf000-7f717a4d6000 r-xp 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a4d6000-7f717a6d5000 ---p 7000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d5000-7f717a6d6000 r--p 6000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d6000-7f717a6d7000 rw-p 7000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d7000-7f717a6d8000 r-xp 08:12 1630422 /usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux 7f717a6d8000-7f717a8d8000 ---p 1000 08:12 1630422 /usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux 7f717a8d8000-7f717a8d9000 r--p 1000 08:12 1630422 /usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux 7f717a8d9000-7f717a8da000 rw-p 2000 08:12 1630422 /usr/lib/pd-extended/extra/jasch_lib/strcut.pd_linux 7f717a8da000-7f717a8dc000 r-xp 08:12 1638450 /home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux 7f717a8dc000-7f717aadb000 ---p 2000 08:12 1638450 /home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux 7f717aadb000-7f717aadc000 r--p 1000 08:12 1638450 /home/muranyia/Download/pd/extra/moonlib/absolutepath.pd_linux 7f717aadc000-7f717aadd000 rw-p 2000 08:12 1638450
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Sat, 2010-11-27 at 20:44 +0100, András Murányi wrote: with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) Figured this one out--forgot to update one place in the g_numbox.c actually. It should be fine now. That said, there are still a few gop problems when using gop within gop and I've traced these down to the fact that tcl/tk tends to recycle window_names for some reason (not sure if this is a part of the undo/redo/cut/copy/paste system or native tcl/tk). Anyone has any idea? http://l2ork.music.vt.edu/main/?page_id=56 Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
The ctrl-Enter functionality is missing. In normal pd-ext 0.42-5 (on Hardy) I can: 1. Click ctrl-1 and type the name of the object. 2. Click ctrl-Enter to instantiate the object and have it selected. 3. Click ctrl-d and have a new, unconnected object which I can Shift-arrow where I want it, then click ctrl-Enter again to change the object name to something else. -Jonathan --- On Sun, 11/28/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: András Murányi muran...@gmail.com Cc: PD List pd-list@iem.at Date: Sunday, November 28, 2010, 12:18 AM On Sat, 2010-11-27 at 20:44 +0100, András Murányi wrote: with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) Figured this one out--forgot to update one place in the g_numbox.c actually. It should be fine now. That said, there are still a few gop problems when using gop within gop and I've traced these down to the fact that tcl/tk tends to recycle window_names for some reason (not sure if this is a part of the undo/redo/cut/copy/paste system or native tcl/tk). Anyone has any idea? http://l2ork.music.vt.edu/main/?page_id=56 Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Question about the cord inspector: is it feasible to make the font size scale with the 'Edit' menu font bomb dialogue? I know the whole font situation in Pd is problematic, but currently the font bomb dialogue is the only way to make patches readable when projecting them on a large screen. So it would be helpful to have the cord inspector be at the same font size as the rest of the patch. -Jonathan --- On Sat, 11/27/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: András Murányi muran...@gmail.com, PD List pd-list@iem.at Date: Saturday, November 27, 2010, 9:45 PM Thx for the report. Let me investigate once I get back home. András Murányi muran...@gmail.com wrote: with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) *** buffer overflow detected ***: ./pd terminated === Backtrace: = /lib/libc.so.6(__fortify_fail+0x37)[0x7f7189d6d217] /lib/libc.so.6(+0xfe0d0)[0x7f7189d6c0d0] /lib/libc.so.6(+0xfd539)[0x7f7189d6b539] /lib/libc.so.6(_IO_default_xsputn+0xcc)[0x7f7189ce3d1c] /lib/libc.so.6(_IO_vfprintf+0x14c)[0x7f7189cb34ec] /lib/libc.so.6(__vsprintf_chk+0x99)[0x7f7189d6b5d9] /lib/libc.so.6(__sprintf_chk+0x7f)[0x7f7189d6b51f] ./pd[0x479cd4] ./pd(sys_pollgui+0xb8)[0x49ed78] ./pd(m_mainloop+0x84b)[0x4984db] ./pd(sys_main+0x225)[0x49d0b5] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f7189c8cc4d] ./pd[0x414159] === Memory map: 0040-0050b000 r-xp 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070a000-0070b000 r--p 0010a000 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070b000-0070d000 rw-p 0010b000 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070d000-00b1d000 rw-p 00:00 0 01694000-0d33e000 rw-p 00:00 0 [heap] 7f71798b6000-7f71798b8000 r-xp 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f71798b8000-7f7179ab7000 ---p 2000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab7000-7f7179ab8000 r--p 1000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab8000-7f7179ab9000 rw-p 2000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab9000-7f7179aba000 r-xp 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179aba000-7f7179cba000 ---p 1000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cba000-7f7179cbb000 r--p 1000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cbb000-7f7179cbc000 rw-p 2000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cbc000-7f7179cbd000 r-xp 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179cbd000-7f7179ebc000 ---p 1000 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebc000-7f7179ebd000 r--p 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebd000-7f7179ebe000 rw-p 1000 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebe000-7f7179ec2000 r-xp 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f7179ec2000-7f717a0c1000 ---p 4000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c1000-7f717a0c2000 r--p 3000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c2000-7f717a0c3000 rw-p 4000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c3000-7f717a0c7000 r-xp 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a0c7000-7f717a2c6000 ---p 4000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c6000-7f717a2c7000 r--p 3000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c7000-7f717a2c8000 rw-p 4000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c8000-7f717a2ce000 r-xp 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a2ce000-7f717a4cd000 ---p 6000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4cd000-7f717a4ce000 r--p 5000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4ce000-7f717a4cf000 rw-p 6000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4cf000-7f717a4d6000 r-xp 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a4d6000-7f717a6d5000 ---p 7000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d5000-7f717a6d6000 r--p 6000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d6000-7f717a6d7000 rw-p 7000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d7000-7f717a6d8000 r-xp 08:12 1630422
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Small detail-- your 'Put' menu is tearoff-able. -Jonathan --- On Sun, 11/28/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: András Murányi muran...@gmail.com Cc: PD List pd-list@iem.at Date: Sunday, November 28, 2010, 12:18 AM On Sat, 2010-11-27 at 20:44 +0100, András Murányi wrote: with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) Figured this one out--forgot to update one place in the g_numbox.c actually. It should be fine now. That said, there are still a few gop problems when using gop within gop and I've traced these down to the fact that tcl/tk tends to recycle window_names for some reason (not sure if this is a part of the undo/redo/cut/copy/paste system or native tcl/tk). Anyone has any idea? http://l2ork.music.vt.edu/main/?page_id=56 Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Hi, Here are some scrolling observations: In the attached patch, drag the [pd] object far down into the bottom right-hand corner, so that you get some scrollbars to appear. Now, on the current pd-extended, you can scroll down to that object, and when you drag it back to its original location, the scrollbars respond in realtime so that the object swoops back up the patch until, finally, the scrollbars disappear. In your version the scrollbars don't react until you stop dragging and release the mouse button. Just an observation-- I suppose both methods have their strengths and weaknesses. I prefer the current Pd-ext behavior-- for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up. But notice that once you drag the [pd] object back near its original position, the [f] object looks as if it's at (0,0), when it's really at (10,10). However, if you save the patch and reopen it the [f] will appear at its proper, original position-- (10,10). I think this is a bug, because it means any time one adds or takes away the scrollbars the absolute positioning of the objects on the canvas is temporarily lost, forcing the user to close and open to see the real positioning. -Jonathan scrolling.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
On Fri, 2010-11-26 at 21:26 -0500, Ivica Ico Bukvic wrote: Another quick update includes following, mainly cosmetic fixes/improvements: *made iemgui use default $select_color as defined in pd.tk while leaving legacy definition for IEM_GUI_COLOR_SELECTED color (as defined in g_all_guis.h) for other externals that may rely upon it *cleaned up bugs in mycanvas where label did not follow the object *cleaned up segfault on number2 when creating a label *modularized highlight nlet color and width and moved them to pd.tk *changed the way highlight nlet filters different objects and reverts their nlet color properly to original state (e.g. iemgui uses black as default whereas text objects use gray nlets You can grab it from: http://l2ork.music.vt.edu/main/?page_id=56 Ugh, 20101127 is now out fixing two regressions. Namely, 1) segfault due to the way iemgui's implementation of universal color did not allocate proper memory for the char array 2) stale GOP elements due to incorrect check for an open window This latest snapshot should be considered 1st release candidate. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
