Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
And as an experiment, I made a new autobuild called pd-main+libs,
which is Pd straight from the HEAD of MAIN and the rest of Pd-
extended. None of the patches are included tho, so it shouldn't be
considered
Frank Barknecht wrote:
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
And as an experiment, I made a new autobuild called pd-main+libs,
which is Pd straight from the HEAD of MAIN and the rest of Pd-
extended. None of the patches are included tho, so it
On 26/10/2007, at 19.43, Hans-Christoph Steiner wrote:
On Oct 24, 2007, at 6:02 AM, Steffen Juul wrote:
On 23/10/2007, at 22.55, Hans-Christoph Steiner wrote:
Anyone know anything about Mac OS X Universal builds? The Pd-
extended and Pd build systems need to be updated to a sane, Mac
On Oct 28, 2007, at 4:53 AM, Frank Barknecht wrote:
Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
And as an experiment, I made a new autobuild called pd-main+libs,
which is Pd straight from the HEAD of MAIN and the rest of Pd-
extended. None of the patches are
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
the only reasoning behind the .deb is to get the dependencies right.
apart from that, i agree to frank.
one hack to solve this would be to distribute pd-extended as .tgz and
additionally provide a pd-extended-deps package
Hey all,
The tclpd API/loader has gotten me thinking about making a pure Tcl
API for writing GUIs. I was thinking a bit about how to handle the
Tcl code for the separate pd and pd-gui processes. Is there a way in
Tcl to get the contents of a procedure and stick it into a variable?
I was
On Oct 26, 2007, at 3:38 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Oct 26, 2007, at 2:13 PM, Martin Peach wrote:
Any specific suggestions? You mean casting as (entry_class) or
something like that?
you have to copy the struct definitions from whereever to your
On Oct 27, 2007, at 2:25 AM, Mathieu Bouchard wrote:
On Sat, 27 Oct 2007, Hans-Christoph Steiner wrote:
Duh... thanks. It now compiles and runs, but sadly, this doesn't
work:
Both of them returned entry as the class, even when I loaded
with a namespace prefix.
I don't really know
Bugs item #1821847, was opened at 2007-10-28 19:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=478070aid=1821847group_id=55736
Please note that this message will contain a full copy of
Bugs item #1821847, was opened at 2007-10-28 19:12
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=478070aid=1821847group_id=55736
Please note that this message will contain a full copy of the comment
Hans-Christoph Steiner wrote:
I tried this in entry_new() and entry_save(), and in both, binbuf
ends being nothing useful (i.e. segfault):
t_glist *glist = (t_glist *) canvas_getcurrent();
t_canvas *canvas = (t_canvas*) glist_getcanvas(glist);
t_binbuf *binbuf =
On Oct 28, 2007, at 8:47 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
I tried this in entry_new() and entry_save(), and in both,
binbuf ends being nothing useful (i.e. segfault):
t_glist *glist = (t_glist *) canvas_getcurrent();
t_canvas *canvas = (t_canvas*)
I think the binbuf is always present, but in the case of a top-level
canvas, it might be empty; binbuf_getnatom() tells you how many atoms
there are.
cheers
Miller
On Sun, Oct 28, 2007 at 10:14:48PM -0400, Hans-Christoph Steiner wrote:
On Oct 28, 2007, at 8:47 PM, Martin Peach wrote:
It sounds like this isn't the way to do it then. But somewhere the
whole classname with the namespace prefix must be stored for every
single object instantiated, since it will get written out to the
file. How do I access that?
.hc
On Oct 28, 2007, at 10:50 PM, Miller Puckette wrote:
I
14 matches
Mail list logo
