On Feb 24, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote:
> when i (last) looked into the libpd API, i noticed that libpd works on
> a global namespace as well...what i mean is, that the API (at least
> the C-API, i haven't checked the others) does not allow to specify an
> "instance" of pd.
That's correct. Because there isn't currently a way to multiple instances beyond previously mentioned hacks to the core or non-portable linker flags, the api isn't in place to support it.
> but i fail to see why libpd doesn't provide the API for this, even if
> the "instance" pointer would not be used (until Pd does support
> multiple instances).
>
> e.g. the application programmer would have to check that libpd_init()
> returns non-NULL anyhow, and in the current implementation it would
> always return NULL but the first time being called.
>
> this would have allowed for a transition to multiple instances without
> having to change the API...
Good point. I wasn't involved when Peter first started the project and I'm sure, back then, multiple PD instances seemed waaay off into the future. I think the best/easiest way to handle this without breaking anyone's current code, would be to shadow all of the functions with functions that take an instance pointer, as you suggest. The default ones would simply handle a single internal pointer to the first opened instance, as it does now. If you use the pointer manually, then it's up to you to keep track of it. I we don't mind breaking compatibility, we can simply add an instance handle to each function we have now. Either way, not that difficult.
The C++ wrapper I wrote has api support for multiple instances (aka you can create multiple PdBase classes). Internally, that is handled by a PdContext static class which would theoretically return new instance pointers but, for now, it simply calls the global libpd functions and there is a big warning in the documentation about only using 1 PdBase instance for now.
Again, wouldn't be too hard to add, just currently waiting whether this could become a reality.
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
---
** [bugs:#1138] [mrpeach/tcpserver] send data to wrong client**
**Status:** open
**Created:** Tue Feb 25, 2014 10:51 AM UTC by Antoine Villeret
**Last Updated:** Tue Feb 25, 2014 10:51 AM UTC
**Owner:** nobody
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Any further updates on this front? If a consensus is made, we could outline a roadmap and move to the task of implementation. At this point, I think breaking externals would be less of an issue if said breakage would be manageable via about find/replace. I'd be willing to handle that, at the least.
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
So would we remove those older implementations or transfer the other OS implementations into newer plugins? Or has that already been done for Linux & Win?
On Feb 23, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote:
> From: IOhannes m zmölnig <zmoelnig(a)iem.at>
> Subject: Re: [PD-dev] Question about multi-arch Mac OS X - is 32-Bit still around?
> Date: February 23, 2014 at 4:09:29 AM EST
> To: Dan Wilcox <danomatika(a)gmail.com>, "me.grimm" <megrimm(a)gmail.com>
> Cc: "pd-dev(a)iem.at" <pd-dev(a)iem.at>
>
>
> On 02/23/2014 01:46 AM, Dan Wilcox wrote:
>> Just to confirm what Iohannes, et al. already know. pix_filmDarwin, pix_movieDarwin, pix_recordQT, & pix_videoDarwin need to be updated to use the newer Apple APIs: QTKit or AVFoundation. I've done an AVFoundation app already and we're using QTkit in the updated OpenFrameworks code, so I can probably reuse bits here and there.
>
> ohoh
> just to make sure: [pix_filmFoo] is long dead. Gem now uses a plugin
> system to access the various platform dependent components.
> so what needs to be done is writing the following plugins:
> - videoQtKit
> - filmQtKil
> - recordQtKit
>
>
> check Gem/plugins/ for examples.
>
> mfdars
> IOhannes
>
> PS: sorry, not much time right now to elaborate
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
Fuck it. I'll do it. It'll be a "reverse kickstarter". I've been thinking about it for a while, but I frankly don't use GEM for much so haven't had to "scratch that itch". I'll pick out the code later today. I too am tired of seeing these requests go unanswered year after year ...
On Feb 17, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote:
> From: Hans-Christoph Steiner <hans(a)at.or.at>
> Subject: Re: [PD-dev] Question about multi-arch Mac OS X - is 32-Bit still around?
> Date: February 16, 2014 at 11:52:37 PM EST
> To: me.grimm <megrimm(a)gmail.com>
> Cc: IOhannes m zmölnig <zmoelnig(a)iem.at>, pd-dev(a)iem.at
>
>
>
> At this point, the thing to do is probably raise money to pay someone to do it.
>
> .hc
>
> On Jan 12, 2014, at 1:42 PM, me.grimm wrote:
>
>> >>admittedly this is an issue of Gem, but little can be done about it.
>>
>> except getting a working 64-bit version of Gem.
>>
>> I have it compiled on 64-bit w/ gmerlin for pix_film but native filmQTKIT would be better. there has been some work done on this for Max and oFX that might be useful code to port to Gem since last time i looked at this a couple years ago:
>>
>> see https://github.com/brianchasalow/jit.BC.QTKit & http://www.openframeworks.cc/documentation/video/ofQTKitPlayer.html
>>
>> unfortunately I am not skilled or organized enough to implement myself but I would be happy to help!!! I would love to get my students using 64-bit pd builds on their macs (all 50 of them this semester have macs)
>>
>> m
>>
>>
>> On Sun, Jan 12, 2014 at 12:33 PM, IOhannes m zmölnig <zmoelnig(a)iem.at> wrote:
>> On 2014-01-11 01:08, Thomas Mayer wrote:
>> > So: Is 32-Bit on Mac OS X still around?
>> >
>>
>> due to QuickTime issues, Gem on OSX is still 32bit only. this means that
>> whoever wants to run Gem on OSX, will need to use a 32bit version of Pd
>> and not being able to run a 64bit-only purest json.
>>
>> admittedly this is an issue of Gem, but little can be done about it.
>>
>> gfmdsar
>> IOhannes
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
Thanks Miller. Is that to the Sourceforge git or some other place? I'll pull it down into libpd and get people to test it.
On Feb 21, 2014, at 6:00 AM, pd-dev-request(a)iem.at wrote:
> It looks like the whole mess1() (etc) macro system is going to fail on
> 64-bit ARM - I can't see how to patch that. I can fix the local problems in
> the Pd vanilla source but I don't know whether it's better to take out the
> "mess()" macros altogether, or to take them out only for ARM64. (The
> former would be source incompatible but object compatible, but I'm thinking
> source compatibilty with a non-working feature is maybe actually worse than
> simply being source incompatible.)
>
> I've gone ahead and git-pushed an attempted fix (changing mess1() etc,
> potentially source-incompatibly) but am open to other ideas how to fix this.
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
Howdy all,
We've found a fun crash on 64 bit iOS related to function pointers with variadic arguments, namely @define mess macro in m_pd.h.
See https://github.com/libpd/libpd/issues/56#issuecomment-33320533
I haven't delved into the pd source yet enough to propose a fix, but a quick hack which calls the function pointers directly without using the mess macro seems to work:
https://github.com/libpd/libpd/issues/49#issuecomment-29535755
This is something that only crashes on the actual hardware and not in the simulator, so I hadn't seen it before since I don't have a fancy new iPhone.
Any PD guru thoughts would be welcome as I (we) would like to find a way to test a change and push a patch upstream.
--------
Dan Wilcox
@danomatika
danomatika.comrobotcowboy.com
Hi,
I am using the library template for PuREST JSON.
This library needs libcurl for compilation, and libcurl throws errors
while cross-compiling for architectures with different word sizes, e.g.
compiling 32-Bit on 64-Bit.
(http://ubuntuforums.org/showthread.php?t=1680426)
To counter this, me.grimm has removed 32-Bit support for Mac OS X, and I
have merged that with my branch.
(https://github.com/megrimm/PuRestJson/commit/c9981507dfc9fb1da763c83d15a86c…)
So: Is 32-Bit on Mac OS X still around?
Also: The version of json-c in fink seems to be 0.10 still, while 0.11
is out for a while. Can someone please update the package?
(https://s3.amazonaws.com/json-c_releases/releases/index.html)
Thanks,
Thomas
--
"When one's home has a really excellent computer capable of reaching
other computers anywhere in the Galaxy, one scarcely needs to budge."
(Janov Pelorat in: Isaac Asimov - Foundation's Edge)
http://www.residuum.org/
---
** [bugs:#1137] [mrpeach/tcpserver] crashes when asking for a client state with a wrong id**
**Status:** open
**Created:** Thu Feb 13, 2014 10:47 AM UTC by Antoine Villeret
**Last Updated:** Thu Feb 13, 2014 10:47 AM UTC
**Owner:** nobody
---
Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.