Hey all,
I'd like to start the release branch for Pd-extended 0.40.3 in two
weeks. Is there any work pending that should get included? If so,
let me know when it'll be done. Otherwise those changes will have
to be merged into the release branch to make it into the release.
Woo hoooo! Let's do the next Pd-extended release sooner than a year
after the last! :D
.hc
------------------------------------------------------------------------
----
http://at.or.at/hans/
Bugs item #1891178, was opened at 2008-02-11 15:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891178&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.40.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: netsend: messages sent just after connect are lost/corrupted
Initial Comment:
If you send a great enough number of messages throught a netsend immediately after the connection is established (for example triggered by the 1 output of netsend), the first messages are lost (and no error message issued). Netreceive receives some corrupted data, and then the last N messages sent.
The attached patch illustrates the problem.
** TEST PROCEDURE:
Click on the [connect ...( message box
** EXPECTED BEHAVIOUR:
On PD output window the following should appear:
CONNECTED: 1
DATA: bla bla 1
DATA: bla bla 2
DATA: bla bla 3
...
DATA: bla bla 1000
** OBSERVED BEHAVIOUR
The following output appears:
CONNECTED: 1
DATA: 53
DATA: bla bla 954
DATA: bla bla 955
...
DATA: bla bla 1000
====
Note that if you later click the [bng], all works as expected, i.e. no message is lost: message loss only seems to happen when too many messages are sent immediately after connection.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1891178&group_…
Bugs item #1890931, was opened at 2008-02-11 07:01
Message generated for change (Comment added) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1890931&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.41.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke Iannini (lukeiannini)
Assigned to: Nobody/Anonymous (nobody)
Summary: [list-split] outputs bad bang type
Initial Comment:
Hi,
Attached it a patch demonstrating the bug. [list-split] outputs a bang on the right outlet when the input is a bang, but it seems to invisibly add the "list" selector so that the bang is unrecognized by, for example, [until] (giving the error: inlet: expected 'bang' but got 'list')
Cheers
Luke
----------------------------------------------------------------------
Comment By: ClaudiusMaximus (claudiusmaximus)
Date: 2008-02-11 08:51
Message:
Logged In: YES
user_id=769033
Originator: NO
I'd say it was a bug in Pd core. Rather than adding special cases to
*all* objects, I think the "distribute lists over inlets if there is no
method for 'list'" code should notice empty lists and call the 'bang'
method, furthermore extra 'list' methods for objects that don't really need
them should be removed. Both these steps are necessary to maintain the
("list",{}) == ("bang",{}) invariant in more places with less code.
Something like this (totally untested, so be warned):
--- m_obj.c.orig 2008-02-11 08:48:44.000000000 +0000
+++ m_obj.c 2007-12-17 20:28:49.000000000 +0000
@@ -224,7 +224,7 @@
t_atom *ap;
int count;
t_inlet *ip = ((t_object *)x)->ob_inlet;
- if (!argc) return;
+ if (!argc) { pd_bang(&x->ob_pd); return; }
for (count = argc-1, ap = argv+1; ip && count--; ap++, ip =
ip->i_next)
{
if (ap->a_type == A_POINTER) pd_pointer(&ip->i_pd,
ap->a_w.w_gpointer);
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2008-02-11 08:24
Message:
Logged In: YES
user_id=569446
Originator: NO
I guess you mean [list split] (without dash). If it's a bug it's one in
[until] I believe. [list split] outputs a zero-element list in your
example, which is what the help-file says it would do. Usually empty lists
get converted to a bang. I suppose this happens at an object's inlet.
However [until] doesn't convert - probably it needs to get a
until_list2(...) method?
(Btw: Better avoid whitespace in the names of example patches uploaded
here. I uploaded a new version and deleted the old.)
File Added: list-split-bug.pd
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1890931&group_…
Bugs item #1890931, was opened at 2008-02-11 08:01
Message generated for change (Comment added) made by fbar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1890931&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.41.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke Iannini (lukeiannini)
Assigned to: Nobody/Anonymous (nobody)
Summary: [list-split] outputs bad bang type
Initial Comment:
Hi,
Attached it a patch demonstrating the bug. [list-split] outputs a bang on the right outlet when the input is a bang, but it seems to invisibly add the "list" selector so that the bang is unrecognized by, for example, [until] (giving the error: inlet: expected 'bang' but got 'list')
Cheers
Luke
----------------------------------------------------------------------
>Comment By: Frank Barknecht (fbar)
Date: 2008-02-11 09:24
Message:
Logged In: YES
user_id=569446
Originator: NO
I guess you mean [list split] (without dash). If it's a bug it's one in
[until] I believe. [list split] outputs a zero-element list in your
example, which is what the help-file says it would do. Usually empty lists
get converted to a bang. I suppose this happens at an object's inlet.
However [until] doesn't convert - probably it needs to get a
until_list2(...) method?
(Btw: Better avoid whitespace in the names of example patches uploaded
here. I uploaded a new version and deleted the old.)
File Added: list-split-bug.pd
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1890931&group_…
Bugs item #1890931, was opened at 2008-02-11 00:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1890931&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.41.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Luke Iannini (lukeiannini)
Assigned to: Nobody/Anonymous (nobody)
Summary: [list-split] outputs bad bang type
Initial Comment:
Hi,
Attached it a patch demonstrating the bug. [list-split] outputs a bang on the right outlet when the input is a bang, but it seems to invisibly add the "list" selector so that the bang is unrecognized by, for example, [until] (giving the error: inlet: expected 'bang' but got 'list')
Cheers
Luke
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1890931&group_…
Bugs item #1856583, was opened at 2007-12-22 13:17
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1856583&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pdpedia
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thumbnail creation is not working
Initial Comment:
...
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-10 13:34
Message:
Logged In: NO
in pdpedia i guess
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-10 13:34
Message:
Logged In: NO
in pdpedia i guess
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1856583&group_…
Bugs item #1856583, was opened at 2007-12-22 13:17
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1856583&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pdpedia
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thumbnail creation is not working
Initial Comment:
...
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-10 13:34
Message:
Logged In: NO
in pdpedia i guess
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1856583&group_…
Patches item #1890705, was opened at 2008-02-10 18:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1890705&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Plans Casal (pland)
Assigned to: Nobody/Anonymous (nobody)
Summary: Repairing s_inter.c so it behaves with OSX 10.5
Initial Comment:
Calls to sys_guicmd between fork() and exec were causing 'you must exec!' errors to do with new Frameworks policy. This patch puts the sys_guicmd before the fork, and was tested on 10.5.1
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1890705&group_…
Subversion is up and running.
check it out at
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/
(beware: if you checkout the entire tree (/svnroot/pure-data), you will
need a lot of space on your harddisk, as you will get multipled copies
of everything)
CVS is now locked for writing (but reading is still possible)
happy hacking!
fmgasd.r
IOhannes
On Feb 7, 2008 1:32 PM, Hans-Christoph Steiner <hans(a)eds.org> wrote:
> This is an example of what I mean, the default browse views for the
> logs show all of the branches. I'll be svn works similarly
>
> http://pure-data.cvs.sourceforge.net/pure-data/pd/src/s_stuff.h
If sourceforge's svn browser works similarly it is being very strange.
No svn tool I've ever used mixes the changes of one branch with the
trunk or any other copy of file(s) (and I've used many!). Trac (one
of the most integrated web interfaces for svn) and "svn log", for
example, both work in the way I describe.
Cheers
Luke