Apologies for cross-posting.
It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release.
20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect "L2Orkified" version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved
As always, comments/feedback are most appreciated.
http://l2ork.music.vt.edu/main/?page_id=56
Best wishes,
Ico
segfault:
- New patch.
- Create [cnv].
- Save as test.pd
- Right-click [cnv] and choose "Properties".
- Click "Ok".
Crash. (Hardy.) -Jonathan
--- On Tue, 12/14/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-dev@disis.music.vt.edu, lau@lists.linuxaudio.org, piksel@piksel.no Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting.
It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release.
20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect "L2Orkified" version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved
As always, comments/feedback are 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
Can't reproduce over here. Are you running different libs and are they precompiled for l2ork?
Also, after you've right-clicked you said cnv is not selected. At what point did you deselect it in the first place?
Ico
On Tue, 2010-12-14 at 19:35 -0800, Jonathan Wilkes wrote:
segfault:
- New patch.
- Create [cnv].
- Save as test.pd
- Right-click [cnv] and choose "Properties".
- Click "Ok".
Crash. (Hardy.) -Jonathan
--- On Tue, 12/14/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-dev@disis.music.vt.edu, lau@lists.linuxaudio.org, piksel@piksel.no Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting.
It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release.
20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect "L2Orkified" version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved
As always, comments/feedback are 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
For example-- right-click on the top left-hand corner of cnv in run mode (since you can't select anything in run mode, this will ensure it's not selected). Then choose "Properties".
Now when I click "Ok" under these circumstances I get the segfault.
-Jonathan
--- On Wed, 12/15/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, l2ork-dev@disis.music.vt.edu, lau@lists.linuxaudio.org, piksel@piksel.no Date: Wednesday, December 15, 2010, 6:33 AM Can't reproduce over here. Are you running different libs and are they precompiled for l2ork?
Also, after you've right-clicked you said cnv is not selected. At what point did you deselect it in the first place?
Ico
On Tue, 2010-12-14 at 19:35 -0800, Jonathan Wilkes wrote:
segfault:
- New patch.
- Create [cnv].
- Save as test.pd
- Right-click [cnv] and choose "Properties".
- Click "Ok".
Crash. (Hardy.) -Jonathan
--- On Tue, 12/14/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-dev@disis.music.vt.edu,
lau@lists.linuxaudio.org, piksel@piksel.no
Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting.
It appears a few more bugs snuck into the stable
release.
At the same time I felt like the rest of the iemgui objects
could
really benefit from the resizing via gui, hence another
release.
20101214 Changelog: *implemented resizable options for all iemgui
objects (some
require different behavior than others (e.g. number2
resizes
horizontally based on the number of characters, while vertical
resize also
adjusts font size as well as gui triangle preceding
characters, thus
resulting in changes in width as well as height--consequently
the target
size tries to be as close to the mouse cursor as possible
while
altering width, height, font size and number of characters
visible)
*changed the whole project naming scheme to
reflect
"L2Orkified" version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects
different
version) *changed appearance and updated content of the
about.pd
patch *fixed regression where help files for core
objects were
erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted
appearance
to match the theme *fixed bug where pddplink failed to open related
files
*fixed resizable canvas so that it updates
scrollbars after
resizing, dirties the canvas, and properly relocates scale
handle
when moved
As always, comments/feedback are 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
On Tue, 2010-12-14 at 21:50 -0800, Jonathan Wilkes wrote:
For example-- right-click on the top left-hand corner of cnv in run mode (since you can't select anything in run mode, this will ensure it's not selected). Then choose "Properties".
Now when I click "Ok" under these circumstances I get the segfault.
-Jonathan
Got it and fixed it. Will be uploading it shortly.
Many thanks for the report!
Best wishes,
Ico
--- On Wed, 12/15/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, l2ork-dev@disis.music.vt.edu, lau@lists.linuxaudio.org, piksel@piksel.no Date: Wednesday, December 15, 2010, 8:24 AM On Tue, 2010-12-14 at 21:50 -0800, Jonathan Wilkes wrote:
For example-- right-click on the top left-hand corner
of cnv in run mode (since you can't select anything in run mode, this will ensure
it's not selected). Then choose "Properties".
Now when I click "Ok" under these circumstances I get
the segfault.
-Jonathan
Got it and fixed it.
You're simply hiding the bug:
- With the Properties dialogue open, go back and click somewhere
on the patch to deselect the iemgui. (Btw-- there are times when this behavior is convienent, so please don't make the Properties dialogue force focus.) 2. Click "Ok". 3. Still crashes.
No crash in Pd-vanilla 0.43.
-Jonathan
Will be uploading it shortly.
Many thanks for the report!
Best wishes,
Ico
You're simply hiding the bug:
- With the Properties dialogue open, go back and click somewhere
on the patch to deselect the iemgui. (Btw-- there are times when this behavior is convienent, so please don't make the Properties dialogue force focus.) 2. Click "Ok". 3. Still crashes.
No crash in Pd-vanilla 0.43.
That is because (afaik) vanilla 0.43 does not have apply undo at all. In other words apply actions that result from properties are simply ignored.
In my case the way I am tracking items in undo is I seek selected items which now I realize is not the most robust way of doing so. That said, I did not make this fix to "hide the bug" but rather for the sake of consistency because I believe one needs to be in edit mode to edit, and getting properties for an object, particularly when there are many crammed near each other I believe one needs to select the item to reflect what they've selected, and then do operations that pertain to editing. I believe that allowing to edit items in this way while not in edit mode is essentially a bug from a usability perspective as it erases differentiation between performance (or whatever you will call it) and editing mode.
All that said, I need to reconsider how to deal with undo and I have a pretty good idea now what needs to be done (e.g. by passing obj pointer to the undo in addition to the canvas pointer)...
--- On Wed, 12/15/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, l2ork-dev@disis.music.vt.edu, lau@lists.linuxaudio.org, piksel@piksel.no Date: Wednesday, December 15, 2010, 6:40 PM
You're simply hiding the bug:
- With the Properties dialogue open, go back and
click somewhere
on the patch to deselect the iemgui. (Btw--
there are times when
this behavior is convienent, so please don't make the
Properties
dialogue force focus.) 2. Click "Ok". 3. Still crashes.
No crash in Pd-vanilla 0.43.
That is because (afaik) vanilla 0.43 does not have apply undo at all. In other words apply actions that result from properties are simply ignored.
In my case the way I am tracking items in undo is I seek selected items which now I realize is not the most robust way of doing so. That said, I did not make this fix to "hide the bug" but rather for the sake of consistency because I believe one needs to be in edit mode to edit, and getting properties for an object, particularly when there are many crammed near each other I believe one needs to select the item to reflect what they've selected, and then do operations that pertain to editing. I believe that allowing to edit items in this way while not in edit mode is essentially a bug from a usability perspective as it erases differentiation between performance (or whatever you will call it) and editing mode.
All that said, I need to reconsider how to deal with undo and I have a pretty good idea now what needs to be done (e.g. by passing obj pointer to the undo in addition to the canvas pointer)...
Actually I just used run mode as an example to ensure your GUI wasn't selected. The problem is that you can also deselect the GUI in edit mode while the "Properties" dialog raised.
-Jonathan
Another crasher:
- Create an array from the "Put" menu.
- Right-click and choose "Open".
- Inside the graph, click <ctrl-1>
- Click to place the object box somewhere.
Crash.
-Jonathan
--- On Wed, 12/15/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, l2ork-dev@disis.music.vt.edu, lau@lists.linuxaudio.org, piksel@piksel.no Date: Wednesday, December 15, 2010, 6:33 AM Can't reproduce over here. Are you running different libs and are they precompiled for l2ork?
Also, after you've right-clicked you said cnv is not selected. At what point did you deselect it in the first place?
Ico
On Tue, 2010-12-14 at 19:35 -0800, Jonathan Wilkes wrote:
segfault:
- New patch.
- Create [cnv].
- Save as test.pd
- Right-click [cnv] and choose "Properties".
- Click "Ok".
Crash. (Hardy.) -Jonathan
--- On Tue, 12/14/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-dev@disis.music.vt.edu,
lau@lists.linuxaudio.org, piksel@piksel.no
Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting.
It appears a few more bugs snuck into the stable
release.
At the same time I felt like the rest of the iemgui objects
could
really benefit from the resizing via gui, hence another
release.
20101214 Changelog: *implemented resizable options for all iemgui
objects (some
require different behavior than others (e.g. number2
resizes
horizontally based on the number of characters, while vertical
resize also
adjusts font size as well as gui triangle preceding
characters, thus
resulting in changes in width as well as height--consequently
the target
size tries to be as close to the mouse cursor as possible
while
altering width, height, font size and number of characters
visible)
*changed the whole project naming scheme to
reflect
"L2Orkified" version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects
different
version) *changed appearance and updated content of the
about.pd
patch *fixed regression where help files for core
objects were
erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted
appearance
to match the theme *fixed bug where pddplink failed to open related
files
*fixed resizable canvas so that it updates
scrollbars after
resizing, dirties the canvas, and properly relocates scale
handle
when moved
As always, comments/feedback are 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
Plus some weirdness: [s2l] doesn't create. [symbol2list] does create, after which: [s2l] creates (?)
-Jonathan
--- On Wed, 12/15/10, Jonathan Wilkes jancsika@yahoo.com wrote:
From: Jonathan Wilkes jancsika@yahoo.com Subject: Re: [PD] L2Ork Pd update now available To: "Ivica Ico Bukvic" ico@vt.edu Cc: pd-list@iem.at Date: Wednesday, December 15, 2010, 8:27 AM Another crasher:
- Create an array from the "Put" menu.
- Right-click and choose "Open".
- Inside the graph, click <ctrl-1>
- Click to place the object box somewhere.
Crash.
-Jonathan
--- On Wed, 12/15/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, l2ork-dev@disis.music.vt.edu,
lau@lists.linuxaudio.org, piksel@piksel.no
Date: Wednesday, December 15, 2010, 6:33 AM Can't reproduce over here. Are you running different libs and are they precompiled for l2ork?
Also, after you've right-clicked you said cnv is not selected. At what point did you deselect it in the first place?
Ico
On Tue, 2010-12-14 at 19:35 -0800, Jonathan Wilkes
wrote:
segfault:
- New patch.
- Create [cnv].
- Save as test.pd
- Right-click [cnv] and choose "Properties".
- Click "Ok".
Crash. (Hardy.) -Jonathan
--- On Tue, 12/14/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-dev@disis.music.vt.edu,
lau@lists.linuxaudio.org, piksel@piksel.no
Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting.
It appears a few more bugs snuck into the
stable
release.
At the same time I felt like the rest of the iemgui
objects
could
really benefit from the resizing via gui, hence another
release.
20101214 Changelog: *implemented resizable options for all
iemgui
objects (some
require different behavior than others (e.g.
number2
resizes
horizontally based on the number of characters, while vertical
resize also
adjusts font size as well as gui triangle preceding
characters, thus
resulting in changes in width as well as
height--consequently
the target
size tries to be as close to the mouse cursor as
possible
while
altering width, height, font size and number of characters
visible)
*changed the whole project naming scheme to
reflect
"L2Orkified" version (pdextended becomes pd-l2ork, install dir
is
/usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects
different
version) *changed appearance and updated content of
the
about.pd
patch *fixed regression where help files for core
objects were
erroneously replaced by incorrect pddp documentation *synced backport of the new browser and
adjusted
appearance
to match the theme *fixed bug where pddplink failed to open
related
files
*fixed resizable canvas so that it updates
scrollbars after
resizing, dirties the canvas, and properly relocates
scale
handle
when moved
As always, comments/feedback are 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2010-12-15 at 04:04 -0500, Ivica Ico Bukvic wrote:
On Tue, 2010-12-14 at 23:47 -0800, Jonathan Wilkes wrote:
Plus some weirdness: [s2l] doesn't create. [symbol2list] does create, after which: [s2l] creates (?)
-Jonathan
Is vanilla pd-extended not exhibiting this particular problem? Just checking before digging into code...
It seems it is not, because it has a copy of 'symbol2list.pd_linux' renamed to 's2l.pd_linux' in extra/flatspace.
Roman
--- On Wed, 12/15/10, Roman Haefeli reduzent@gmail.com wrote:
From: Roman Haefeli reduzent@gmail.com Subject: Re: [PD] L2Ork Pd update now available To: "Ivica Ico Bukvic" ico@vt.edu Cc: "Jonathan Wilkes" jancsika@yahoo.com, pd-list@iem.at Date: Wednesday, December 15, 2010, 10:22 AM On Wed, 2010-12-15 at 04:04 -0500, Ivica Ico Bukvic wrote:
On Tue, 2010-12-14 at 23:47 -0800, Jonathan Wilkes
wrote:
Plus some weirdness: [s2l] doesn't create. [symbol2list] does create, after which: [s2l] creates (?)
-Jonathan
Is vanilla pd-extended not exhibiting this particular
problem? Just
checking before digging into code...
It seems it is not, because it has a copy of 'symbol2list.pd_linux' renamed to 's2l.pd_linux' in extra/flatspace.
Yeah, there's a whole bunch of aliases in externals/build that work the same way.
-Jonathan
Roman
On Wed, 2010-12-15 at 02:16 -0800, Jonathan Wilkes wrote:
--- On Wed, 12/15/10, Roman Haefeli reduzent@gmail.com wrote:
From: Roman Haefeli reduzent@gmail.com Subject: Re: [PD] L2Ork Pd update now available To: "Ivica Ico Bukvic" ico@vt.edu Cc: "Jonathan Wilkes" jancsika@yahoo.com, pd-list@iem.at Date: Wednesday, December 15, 2010, 10:22 AM On Wed, 2010-12-15 at 04:04 -0500, Ivica Ico Bukvic wrote:
On Tue, 2010-12-14 at 23:47 -0800, Jonathan Wilkes
wrote:
Plus some weirdness: [s2l] doesn't create. [symbol2list] does create, after which: [s2l] creates (?)
-Jonathan
Is vanilla pd-extended not exhibiting this particular
problem? Just
checking before digging into code...
It seems it is not, because it has a copy of 'symbol2list.pd_linux' renamed to 's2l.pd_linux' in extra/flatspace.
Yeah, there's a whole bunch of aliases in externals/build that work the same way.
Are there any other that exhibit this issue? s2l is missing because latest svn builds of pd-extended (and consequently pd-l2ork) drop support for flatspace. As you will notice pd-l2ork has no flatspace folder whatsoever. this can be fixed witha symlink addition to the install script but before I do that, can someone please send me a list of any other objects that are currently missing?
Many thanks!
Ico
It seems it is not, because it has a copy of 'symbol2list.pd_linux' renamed to 's2l.pd_linux' in extra/flatspace.
Yeah, there's a whole bunch of aliases in externals/build that work the same way.
Are there any other that exhibit this issue? s2l is missing because latest svn builds of pd-extended (and consequently pd-l2ork) drop support for flatspace. As you will notice pd-l2ork has no flatspace folder whatsoever. this can be fixed witha symlink addition to the install script but before I do that, can someone please send me a list of any other objects that are currently missing?
Many thanks!
Ico
Ok, so I made a list of flatspace objects missing and I keep wondering if it would not be better to simply do away with all these aliases and start anew thus encouraging all potential users of pd-l2ork to shed their redundant aliases in their patches. Sure, it is a few more chars to type but is that really such a big deal? What do others think here, particularly Hans since he made the call to get rid of flatspace in the first place? Hans?
On Wed, 15 Dec 2010, Ivica Ico Bukvic wrote:
Ok, so I made a list of flatspace objects missing and I keep wondering if it would not be better to simply do away with all these aliases and start anew thus encouraging all potential users of pd-l2ork to shed their redundant aliases in their patches. Sure, it is a few more chars to type but is that really such a big deal? What do others think here, particularly Hans since he made the call to get rid of flatspace in the first place? Hans?
That's exactly what hcs wants you to do. The missing aliases are not a simple oversight : you can find plenty of mails by him basically saying that aliases are a bad idea.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Dec 15, 2010, at 2:56 PM, Ivica Ico Bukvic wrote:
It seems it is not, because it has a copy of 'symbol2list.pd_linux' renamed to 's2l.pd_linux' in extra/flatspace.
Yeah, there's a whole bunch of aliases in externals/build that work the same way.
Are there any other that exhibit this issue? s2l is missing because latest svn builds of pd-extended (and consequently pd-l2ork) drop support for flatspace. As you will notice pd-l2ork has no flatspace folder whatsoever. this can be fixed witha symlink addition to the install script but before I do that, can someone please send me a
list of any other objects that are currently missing?Many thanks!
Ico
Ok, so I made a list of flatspace objects missing and I keep wondering if it would not be better to simply do away with all these aliases and start anew thus encouraging all potential users of pd-l2ork to shed their redundant aliases in their patches. Sure, it is a few more chars to type but is that really such a big deal? What do others think here, particularly Hans since he made the call to get rid of flatspace in
the first place? Hans?
Sounds good to me. I've made it a habit years ago to not use aliases.
.hc
kill your television
Sounds good to me. I've made it a habit years ago to not use aliases.
Except it is not consistent that way in respect to zexy lib where a2l is default object for any2list whereas list2symbol is written out in full. It seems to me either one or the other approach should be the right one. The code should be also gutted of redundant setups so that we don't get what Jonathan encountered where s2l creates ok after symbol2list has been. This makes me wonder if those zexy aliases should stay, at least for time being.
kill your television
Wholeheartedly agree :-)
Ico
On Dec 15, 2010, at 10:04 PM, Ivica Ico Bukvic wrote:
Sounds good to me. I've made it a habit years ago to not use aliases.
Except it is not consistent that way in respect to zexy lib where
a2l is default object for any2list whereas list2symbol is written out in
full. It seems to me either one or the other approach should be the right
one. The code should be also gutted of redundant setups so that we don't
get what Jonathan encountered where s2l creates ok after symbol2list has been. This makes me wonder if those zexy aliases should stay, at least for time being.
AFAIK, a2l can be replaced by the vanilla [list].
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
AFAIK, a2l can be replaced by the vanilla [list].
Then I agree with your decision to drop aliases altogether.
Perhaps all libs should be looked over for redundant copies and only the most stable/polished iterations should be left in the final build. Is there a list of such objects and their similarities somewhere to start digging through all this?
Ico
On Wed, 2010-12-15 at 23:41 -0500, Ivica Ico Bukvic wrote:
AFAIK, a2l can be replaced by the vanilla [list].
Then I agree with your decision to drop aliases altogether.
To me this discussion sounds like: "Aliases are hard to implement when using the libdir format (which was not intended by original author anyway), so let's drop them". IMHO, that's a weak base for such a decision.
Perhaps all libs should be looked over for redundant copies and only the most stable/polished iterations should be left in the final build.
I agree, but I guess it's not that simple. How can one decide which classes are 'valuable' enough to keep and which aren't? There's much personal taste involved. Personally, I tend to be as restrictive as possible and I rather use [list prepend bla]-[list trim] instead of [whateverlib/prepend bla], although the vanilla-only approach requires two objects for what could be done with only one object when using an external. And still, if the decision is to include an external, which one of several flavours? It's not only about stability and cleanness, if all flavours are stable, but work slightly different from each other.
Also, it's problematic to include modified libraries while keeping their original name. It would make the portability of patches much more complex, more complex than it is now. A patch using zexy in Pd-extended wouldn't necessarily work in Pd-l2ork. Stating that the patch is dependent on the zexy library would not be sufficient info to ensure that it works where zexy is installed.
I tend to think, that the best option would be a transition to a reorganized library library, which uses names not based on authors but on functionality. New patches could use the new, clean and stable libraries, while old ones would still work with old (current) libraries. Such a transition would allow to drop aliases, to drop superfluous object classes, and to create libraries with meaningful names.
Although I'd be a strong supporter of this idea, I'm probably not the one to start this project. However, I'd happily migrate my patches to the new library library and I'd also participate in discussions.
Is there a list of such objects and their similarities somewhere to start digging through all this.
I don't think think so.
Roman
On Thu, 2010-12-16 at 14:04 +0100, Roman Haefeli wrote:
On Wed, 2010-12-15 at 23:41 -0500, Ivica Ico Bukvic wrote:
AFAIK, a2l can be replaced by the vanilla [list].
Then I agree with your decision to drop aliases altogether.
To me this discussion sounds like: "Aliases are hard to implement when using the libdir format (which was not intended by original author anyway), so let's drop them". IMHO, that's a weak base for such a decision.
Actually, they are not hard at all. I already tried building the whole thing with aliases and it boils down to changing a few lines in the installer. That said, I've reverted it back as I philosophically agree with Hans. There is no reason for those aliases to exist other than backward compatibility. Then again, it is exactly this kind of backward compatibility (imho) that has been keeping Pd from evolving faster. At some point one simply has to leave some things behind to be able to move forward faster. And these aliases are such an easy fix that even in the context of backwards-compatibility it is a matter of a simple script updating your old patches and replacing object aliases with the original ones.
Perhaps all libs should be looked over for redundant copies and only the most stable/polished iterations should be left in the final build.
I agree, but I guess it's not that simple. How can one decide which classes are 'valuable' enough to keep and which aren't? There's much personal taste involved. Personally, I tend to be as restrictive as possible and I rather use [list prepend bla]-[list trim] instead of [whateverlib/prepend bla], although the vanilla-only approach requires two objects for what could be done with only one object when using an external. And still, if the decision is to include an external, which one of several flavours? It's not only about stability and cleanness, if all flavours are stable, but work slightly different from each other.
Also, it's problematic to include modified libraries while keeping their original name. It would make the portability of patches much more complex, more complex than it is now. A patch using zexy in Pd-extended wouldn't necessarily work in Pd-l2ork. Stating that the patch is dependent on the zexy library would not be sufficient info to ensure that it works where zexy is installed.
I tend to think, that the best option would be a transition to a reorganized library library, which uses names not based on authors but on functionality. New patches could use the new, clean and stable libraries, while old ones would still work with old (current) libraries. Such a transition would allow to drop aliases, to drop superfluous object classes, and to create libraries with meaningful names.
Good points. Time permitting, I may put this on my todo list...
--- On Thu, 12/16/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: "Roman Haefeli" reduzent@gmail.com Cc: pd-list@iem.at Date: Thursday, December 16, 2010, 4:00 PM On Thu, 2010-12-16 at 14:04 +0100, Roman Haefeli wrote:
On Wed, 2010-12-15 at 23:41 -0500, Ivica Ico Bukvic
wrote:
AFAIK, a2l can be replaced by the vanilla
[list].
Then I agree with your decision to drop aliases
altogether.
To me this discussion sounds like: "Aliases are hard
to implement when
using the libdir format (which was not intended by
original author
anyway), so let's drop them". IMHO, that's a weak base
for such a
decision.
Actually, they are not hard at all. I already tried building the whole thing with aliases and it boils down to changing a few lines in the installer. That said, I've reverted it back as I philosophically agree with Hans. There is no reason for those aliases to exist other than backward compatibility. Then again, it is exactly this kind of backward compatibility (imho) that has been keeping Pd from evolving faster. At some point one simply has to leave some things behind to be able to move forward faster. And these aliases are such an easy fix that even in the context of backwards-compatibility it is a matter of a simple script updating your old patches and replacing object aliases with the original ones.
It's also a matter of the developer writing a script to find all cases of the aliases in the current documentation and change the ones that have the deprecated name-- and if you're keeping the long name and discarding the short, to actually open each modified patch and make sure the new name doesn't collide with, say, a comment, or another object. But most importantly, making sure any externals that are abstractions have the correct name in their guts (which, if not correct, will adversely affect the mood of a user who just went to the trouble of making/running a script to use this flavor of Pd).
-Jonathan
Perhaps all libs should be looked over for
redundant copies and only the
most stable/polished iterations should be left in
the final build.
I agree, but I guess it's not that simple. How can one
decide which
classes are 'valuable' enough to keep and which
aren't? There's much
personal taste involved. Personally, I tend to be as
restrictive as
possible and I rather use [list prepend bla]-[list
trim] instead of
[whateverlib/prepend bla], although the vanilla-only
approach requires
two objects for what could be done with only one
object when using an
external. And still, if the decision is to include an
external, which
one of several flavours? It's not only about stability
and cleanness, if
all flavours are stable, but work slightly different
from each other.
Also, it's problematic to include modified libraries
while keeping their
original name. It would make the portability of
patches much more
complex, more complex than it is now. A patch using
zexy in Pd-extended
wouldn't necessarily work in Pd-l2ork. Stating that
the patch is
dependent on the zexy library would not be sufficient
info to ensure
that it works where zexy is installed.
I tend to think, that the best option would be a
transition to a
reorganized library library, which uses names not
based on authors but
on functionality. New patches could use the new, clean
and stable
libraries, while old ones would still work with old
(current) libraries.
Such a transition would allow to drop aliases, to drop
superfluous
object classes, and to create libraries with
meaningful names.
Good points. Time permitting, I may put this on my todo list...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 16 Dec 2010, Ivica Ico Bukvic wrote:
Actually, they are not hard at all. I already tried building the whole thing with aliases and it boils down to changing a few lines in the installer. That said, I've reverted it back as I philosophically agree with Hans. There is no reason for those aliases to exist other than backward compatibility. Then again, it is exactly this kind of backward compatibility (imho) that has been keeping Pd from evolving faster.
Evolving from where to where, and why ?
Going from a pd world with aliases, to a pd world without aliases, is only an evolution for people who like to think that it's more evolved to ditch the aliases.
Do you have a philosophy, or just a preference ? Then can you state your logic for getting to that conclusion ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Thu, 12/16/10, Roman Haefeli reduzent@gmail.com wrote:
From: Roman Haefeli reduzent@gmail.com Subject: Re: [PD] L2Ork Pd update now available To: "Ivica Ico Bukvic" ico@vt.edu Cc: pd-list@iem.at Date: Thursday, December 16, 2010, 2:04 PM On Wed, 2010-12-15 at 23:41 -0500, Ivica Ico Bukvic wrote:
AFAIK, a2l can be replaced by the vanilla
[list].
Then I agree with your decision to drop aliases
altogether.
To me this discussion sounds like: "Aliases are hard to implement when using the libdir format (which was not intended by original author anyway), so let's drop them". IMHO, that's a weak base for such a decision.
Perhaps all libs should be looked over for redundant
copies and only the
most stable/polished iterations should be left in the
final build.
I agree, but I guess it's not that simple. How can one decide which classes are 'valuable' enough to keep and which aren't? There's much personal taste involved. Personally, I tend to be as restrictive as possible and I rather use [list prepend bla]-[list trim] instead of [whateverlib/prepend bla], although the vanilla-only approach requires two objects for what could be done with only one object when using an external. And still, if the decision is to include an external, which one of several flavours? It's not only about stability and cleanness, if all flavours are stable, but work slightly different from each other.
Also, it's problematic to include modified libraries while keeping their original name. It would make the portability of patches much more complex, more complex than it is now. A patch using zexy in Pd-extended wouldn't necessarily work in Pd-l2ork. Stating that the patch is dependent on the zexy library would not be sufficient info to ensure that it works where zexy is installed.
I tend to think, that the best option would be a transition to a reorganized library library, which uses names not based on authors but on functionality.
I've tagged many libraries so far with a [pd META] subpatch that has a KEYWORDS tag, and I've got a object-search feature where, for instance, you can search for objects that play a soundfile (keyword "soundfile"), manipulate or store lists ("list_op"), take user input ("user_input"), and so on. You can also search for objects that manipulate lists and take user input, or objects that objects that take a symbol in the left inlet and output a list.
The problem with reorganizing libraries is it's a lot of work for a minor convenience-- the person who is looking for list-manipulating objects is happy if you have libdir "list_op", but then what about the person who wants to find that GUI object within the list_op library? I suppose it's a bit easier to sift through a 100 object library vs. 1500 objects, but it's still a waste of time.
-Jonathan
New patches could use the new, clean and stable libraries, while old ones would still work with old (current) libraries. Such a transition would allow to drop aliases, to drop superfluous object classes, and to create libraries with meaningful names.
Although I'd be a strong supporter of this idea, I'm probably not the one to start this project. However, I'd happily migrate my patches to the new library library and I'd also participate in discussions.
Is there a list of such objects and their similarities
somewhere to start
digging through all this.
I don't think think so.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you look inside the externals/build/src folder you should see them. (I think they are all from zexy but not absolutely sure.)
Isn't class_addcreator supposed to take care of this?
-Jonathan
--- On Wed, 12/15/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Roman Haefeli" reduzent@gmail.com, pd-list@iem.at Date: Wednesday, December 15, 2010, 6:42 PM On Wed, 2010-12-15 at 02:16 -0800, Jonathan Wilkes wrote:
--- On Wed, 12/15/10, Roman Haefeli reduzent@gmail.com
wrote:
From: Roman Haefeli reduzent@gmail.com Subject: Re: [PD] L2Ork Pd update now available To: "Ivica Ico Bukvic" ico@vt.edu Cc: "Jonathan Wilkes" jancsika@yahoo.com,
pd-list@iem.at
Date: Wednesday, December 15, 2010, 10:22 AM On Wed, 2010-12-15 at 04:04 -0500, Ivica Ico Bukvic wrote:
On Tue, 2010-12-14 at 23:47 -0800, Jonathan
Wilkes
wrote:
Plus some weirdness: [s2l] doesn't create. [symbol2list] does create, after
which:
[s2l] creates (?)
-Jonathan
Is vanilla pd-extended not exhibiting this
particular
problem? Just
checking before digging into code...
It seems it is not, because it has a copy of 'symbol2list.pd_linux' renamed to 's2l.pd_linux' in extra/flatspace.
Yeah, there's a whole bunch of aliases in
externals/build that work
the same way.
Are there any other that exhibit this issue? s2l is missing because latest svn builds of pd-extended (and consequently pd-l2ork) drop support for flatspace. As you will notice pd-l2ork has no flatspace folder whatsoever. this can be fixed witha symlink addition to the install script but before I do that, can someone please send me a list of any other objects that are currently missing?
Many thanks!
Ico
On Wed, 15 Dec 2010, Jonathan Wilkes wrote:
If you look inside the externals/build/src folder you should see them. (I think they are all from zexy but not absolutely sure.) Isn't class_addcreator supposed to take care of this?
class_addcreator can only take care of this if it is run. It is normally run by the _setup function of the .pd_linux (or whatever) file. That file was normally loaded by using -lib (the startup list of libraries) but since then, Hans exploded as many libraries as he could manage to, with the firm belief that it made a positive difference. As one of the results, the aliases don't get registered because _setup has to be run first, and the appropriate _setup is found by looking for the .pd_linux file.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
What does "exploded" mean?
-Jonathan
--- On Thu, 12/16/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] L2Ork Pd update now available To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Thursday, December 16, 2010, 2:46 AM On Wed, 15 Dec 2010, Jonathan Wilkes wrote:
If you look inside the externals/build/src folder you
should see
them. (I think they are all from zexy but not
absolutely sure.)
Isn't class_addcreator supposed to take care of this?
class_addcreator can only take care of this if it is run. It is normally run by the _setup function of the .pd_linux (or whatever) file. That file was normally loaded by using -lib (the startup list of libraries) but since then, Hans exploded as many libraries as he could manage to, with the firm belief that it made a positive difference. As one of the results, the aliases don't get registered because _setup has to be run first, and the appropriate _setup is found by looking for the .pd_linux file.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
I believe he means I split out each objectclass into its own file,
like Java does. That allows us to use namespaces prefixes like zexy/
symbol2list.
.hc
On Dec 15, 2010, at 8:56 PM, Jonathan Wilkes wrote:
What does "exploded" mean?
-Jonathan
--- On Thu, 12/16/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] L2Ork Pd update now available To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Thursday, December 16, 2010, 2:46 AM On Wed, 15 Dec 2010, Jonathan Wilkes wrote:
If you look inside the externals/build/src folder you
should see
them. (I think they are all from zexy but not
absolutely sure.)
Isn't class_addcreator supposed to take care of this?
class_addcreator can only take care of this if it is run. It is normally run by the _setup function of the .pd_linux (or whatever) file. That file was normally loaded by using -lib (the startup list of libraries) but since then, Hans exploded as many libraries as he could manage to, with the firm belief that it made a positive difference. As one of the results, the aliases don't get registered because _setup has to be run first, and the appropriate _setup is found by looking for the .pd_linux file.
| 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
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent controls
you." - Richard M. Stallman
On Wed, 15 Dec 2010, Hans-Christoph Steiner wrote:
I believe he means I split out each objectclass into its own file, like Java does. That allows us to use namespaces prefixes like zexy/symbol2list.
There are other ways to introduce namespace prefixes. It can be done rather easily, in much less work than it takes to handle all the explosions of libraries, the hexloader, the symlinks and all the other consequences of dropping the bomb.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Dec 17, 2010, at 9:35 AM, Mathieu Bouchard wrote:
On Wed, 15 Dec 2010, Hans-Christoph Steiner wrote:
I believe he means I split out each objectclass into its own file,
like Java does. That allows us to use namespaces prefixes like
zexy/symbol2list.There are other ways to introduce namespace prefixes. It can be done
rather easily, in much less work than it takes to handle all the
explosions of libraries, the hexloader, the symlinks and all the
other consequences of dropping the bomb.
Patches welcome!
.hc
"We have nothing to fear from love and commitment." - New York Senator
Diane Savino, trying to convince the NY Senate to pass a gay marriage
bill
On Sat, 18 Dec 2010, Hans-Christoph Steiner wrote:
On Dec 17, 2010, at 9:35 AM, Mathieu Bouchard wrote:
There are other ways to introduce namespace prefixes. It can be done rather easily, in much less work than it takes to handle all the explosions of libraries, the hexloader, the symlinks and all the other consequences of dropping the bomb.
Patches welcome!
Specs welcome!!
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2010-12-16 01:20, Jonathan Wilkes wrote:
If you look inside the externals/build/src folder you should see them. (I think they are all from zexy but not absolutely sure.)
Isn't class_addcreator supposed to take care of this?
of what?
of magically making Pd search for all binaries on the filesystem that contain a class_addcreator() call?
class_addcreator() is the reason why you can create [s2l] after you have created (or loaded) [symbol2list].
gfmadf IOhannes
On Wed, 15 Dec 2010, Ivica Ico Bukvic wrote:
Can't reproduce over here. Are you running different libs and are they precompiled for l2ork?
When failing to reproduce a bug that only someone else has, always try Valgrind, in case the bug is invisible. It doesn't work all of the time (there are things Valgrind just can't possibly detect), but it does catch a lot of those bugs anyway.
One man's crash is often another man's Use of Uninitialised Variable warning or buffer overflow error (Invalid Read, Invalid Write). But those warnings and errors are only available in Valgrind.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Narrowing it down: segfault only happens if you right-click and choose "Properties" _without_ having first selected the object.
-Jonathan
--- On Tue, 12/14/10, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-dev@disis.music.vt.edu, lau@lists.linuxaudio.org, piksel@piksel.no Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting.
It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release.
20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect "L2Orkified" version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved
As always, comments/feedback are 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
On Tue, Dec 14, 2010 at 6:28 PM, Ivica Ico Bukvic ico@vt.edu wrote:
Apologies for cross-posting.
It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release.
20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect "L2Orkified" version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved
As always, comments/feedback are most appreciated.
http://l2ork.music.vt.edu/main/?page_id=56
Best wishes,
Ico
Cool! My observations:
- I was trying to package it for debian with dpkg-deb -b (there is no 'make
package' rule...) and appname and provides are both set to "src" and there is no version number - afair with vanilla and extended these things are ok
- It seems 'make install' doesn't set up a shortcut in gnome menu
- I cannot find where the libs that i've compiled with it are set up
- The GUI is so much faster i really hope these fixes will find their way
into mainstream - fingers crossed :)
Andras
-
András Murányi -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Ivica Ico Bukvic -
Jonathan Wilkes -
Mathieu Bouchard -
Roman Haefeli