Re: [PD] Purr Data beta 2

[Dan Wilcox]

Yeah, I ran that. I was thinking of the following for new users so the install 
itself is not sent and then the setting is permanent:

export HOMEBREW_NO_ANALYTICS=1 && /usr/bin/ruby -e "$(curl -fsSL 
https://raw.githubusercontent.com/Homebrew/install/master/install)” && brew 
analytics off


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 14, 2016, at 8:54 PM, Jonathan Wilkes  wrote:
> 
> According to the doc, "brew analytics off" works, too.  I can certainly 
> suggest 
> that setting in the instructions.
> 
> -Jonathan
> 
> > Also, FYI: just noticed this today: 
> > https://github.com/Homebrew/brew/blob/master/docs/Analytics.md 
> > 
> 
> 
> 
> > I can understand the reasoning but, man, am I tired of everything becoming 
> > opt-in 
> > by default. Looks like you should add the following to your build guide:
> 
> > export HOMEBREW_NO_ANALYTICS=1
> 
> > 
> > Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
>> On Oct 14, 2016, at 11:43 AM, Dan Wilcox > > wrote:
>> 
> 
>> On Oct 14, 2016, at 11:37 AM, Jonathan Wilkes > > wrote:
>> 
>> One snag-- any idea how to get plugin~ building using only Homebrew libs?  I 
>> need 
>> ladspa.h but there's no package for it.  I suppose I can just wget it if 
>> nothing else…
> 
> Should work fine as long as ladspa doesn’t require a ton of dependencies.
> 
> I use curl -LO since wget is not installed on OSX by default.
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

> On Oct 14, 2016, at 11:37 AM, Jonathan Wilkes  wrote:
> 
> One snag-- any idea how to get plugin~ building using only Homebrew libs?  I 
> need 
> ladspa.h but there's no package for it.  I suppose I can just wget it if 
> nothing else…

Should work fine as long as ladspa doesn’t require a ton of dependencies.

I use curl -LO since wget is not installed on OSX by default.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

After a bit of finessing, Homebrew seems to be working just fine.
One snag-- any idea how to get plugin~ building using only Homebrew libs?  I 
need ladspa.h but there's no package for it.  I suppose I can just wget it if 
nothing else...
-Jonathan

  From: Dan Wilcox <danomat...@gmail.com>
 To: Jonathan Wilkes <jancs...@yahoo.com> 
Cc: Matt Barber <brbrof...@gmail.com>; Pd-List <pd-list@lists.iem.at>
 Sent: Wednesday, October 12, 2016 11:53 AM
 Subject: Re: [PD] Purr Data beta 2
   


On Oct 12, 2016, at 9:30 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote:


When building the app bundle, Hans (I think) wrote a script that can grab the 
/opt/local/lib dependencies, copy them to the app bundle, and revise the path 
in the binary using @executable_path to make sure the dependecies in the app 
bundle are correctly found when loading an external.

Yeah, that’s probably using install_name_tool. Here’s an old but relevant 
discussion on this: 
http://forums.macrumors.com/threads/embedding-or-statically-linking-against-a-dylib.176077/

Now, with homebrew:otool -L oggread~.pd_darwin

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1226.10.1)/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
version 915.0.0)
***
There's no path listed at all to the ogg lib dependencies.  When I try to load 
oggread~ with the Purr Data app bundle I just created it doesn't search 
/usr/local/lib and consequently reports missing symbols.

I’m not sure. Maybe, try explicitly adding /usr/local/include to the header 
search path and /usr/local/lib to the linker search path? I’m doing that in the 
autotools_update brach configure.ac: 
https://github.com/pure-data/pure-data/blob/autotools_updates/configure.ac#L62

Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com





   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

> On Oct 12, 2016, at 9:30 AM, Jonathan Wilkes  wrote:
> 
> When building the app bundle, Hans (I think) wrote a script that can grab the 
> /opt/local/lib dependencies, copy them to the app bundle, and revise the path 
> in the binary using @executable_path to make sure the dependecies in the app 
> bundle are correctly found when loading an external.

Yeah, that’s probably using install_name_tool. Here’s an old but relevant 
discussion on this: 
http://forums.macrumors.com/threads/embedding-or-statically-linking-against-a-dylib.176077/
 


> Now, with homebrew:
> otool -L oggread~.pd_darwin
> 
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 1226.10.1)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
> 915.0.0)
> 
> ***
> 
> There's no path listed at all to the ogg lib dependencies.  When I try to 
> load 
> oggread~ with the Purr Data app bundle I just created it doesn't search 
> /usr/local/lib and consequently reports missing symbols.

I’m not sure. Maybe, try explicitly adding /usr/local/include to the header 
search path and /usr/local/lib to the linker search path? I’m doing that in the 
autotools_update brach configure.ac: 
https://github.com/pure-data/pure-data/blob/autotools_updates/configure.ac#L62 



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> You’ll probably need to build form source in either environment if you want 
> to be 
> sure of the deployment target. Both Homebrew and Macports are focused on 
> running OS software for the current system, much less so for building baked 
> libraries to run on other systems.
Ok, so I tried out homebrew on a fresh OSX 10.11 vm.  Great speed of 
installation, 
and flawless downloading of necessary packages.  And it results in completely 
borked external libs-- at least the ones that depend on an external library.
Take oggread~.pd_darwin for example:
With macports:
`otool -L oggread~.pd_darwin`

gives this:

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1226.10.1)/opt/local/lib/libvorbis.0. dylib (compatibility version 5.0.0, 
current version 5.8.0)/opt/local/lib/libvorbisenc.2. dylib (compatibility 
version 3.0.0, current version 3.11.0)/usr/lib/libgcc_s.1.dylib (compatibility 
version 1.0.0, current version 915.0.0)
***
When building the app bundle, Hans (I think) wrote a script that can grab the 
/opt/local/lib dependencies, copy them to the app bundle, and revise the path 
in the binary using @executable_path to make sure the dependecies in the app 
bundle are correctly found when loading an external.

Now, with homebrew:otool -L oggread~.pd_darwin

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1226.10.1)/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
version 915.0.0)
***
There's no path listed at all to the ogg lib dependencies.  When I try to load 
oggread~ with the Purr Data app bundle I just created it doesn't search 
/usr/local/lib and consequently reports missing symbols.
Any clue how to get the compiler to actually link to the necessary libs when 
using homebrew? 
-Jonathan
 



Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

On Oct 10, 2016, at 12:03 PM, Jonathan Wilkes  wrote:
> Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET you 
> should be able to set/override. Simplest way would be when running brew:


>     MACOSX_DEPLOYMENT_TARGET=10.6 brew …
> That, in combination with —build-from-source when installing packages, might 
> give you want you need.

That could work, but then I'm back to building from source.  (macports uses 
binaries for most stuff, btw.)

I'm happy to investigate further _if_ a homebrew dev says that they officially 
support installing this way.  There's a similar way 
to change the deployment target for macports.  But one of the devs told me that 
kind of compatibility isn't a design goal and 
they don't support doing that.
-Jonathan
   



   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

As a blanket answer that may be true as that’s not the goal of the project, but 
technically, it’s totally possible depending on what you’re building. In the 
end, it’s all just C/C++ libraries you *could* download and build yourself.

The same is true for different versions of Linux distros.

Anyway, I’ll stop talking technical then agree that you probably can’t build 
for a 10+ year old OSX version on a contemporary one, at least with the amount 
& type of dependencies you are dealing with. That being said, if it’s easy for 
people to build it themselves, then it’s simpler to focus on putting out a 
binary with more recent compatibility like 10.8+. The vast majority of OSX 
users are using 10.8+.

 My test builds of vanilla for OSX seem to work fine back to 10.8. I need to do 
some more testing to figure out what details I’m missing for it to work on 10.6 
& 10.7, but then I’d need a computer running either of those at hand… maybe not 
worth it since people can much more easily build vanilla for themselves if/when 
they need to.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 2:10 PM, Jonathan Wilkes  wrote:
> 
> > You’ll probably need to build form source in either environment if you want 
> > to be sure of the deployment target. Both Homebrew and Macports are focused 
> > on running OS software for the 
> > current system, much less so for building baked libraries to run on other 
> > systems.
> 
> 
> 
> From #machomebrew on freenode:
> 
> [13:50]  does homebrew support building packages on OSX 
> 10.11 for an earlier version of OSX, like 10.6?
> [13:51]  well, i guess i should say earlier _versions_, like 
> compatible with 10.6 and up...
> [14:36]  doubting_thomas: no
> [15:01]  tdsmith: thanks.
> [15:05]  doubting_thomas: sorry, yw
> 
> -Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> You’ll probably need to build form source in either environment if you want 
> to be sure of the deployment target. Both Homebrew and Macports are focused 
> on running OS software for the 
> current system, much less so for building baked libraries to run on other 
> systems.


>From #machomebrew on freenode:

[13:50]  does homebrew support building packages on OSX 10.11 
for an earlier version of OSX, like 10.6?[13:51]  well, i 
guess i should say earlier _versions_, like compatible with 10.6 and 
up...[14:36]  doubting_thomas: no
[15:01]  tdsmith: thanks.[15:05]  doubting_thomas: 
sorry, yw
-Jonathan   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

I had to push a quick update to fix a freezer bug.

Try:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.1.zip
-Jonathan



  From: Alexandre Torres Porres <por...@gmail.com>
 To: Jonathan Wilkes <jancs...@yahoo.com> 
Cc: Pd-List <pd-list@lists.iem.at>
 Sent: Monday, October 10, 2016 3:18 PM
 Subject: Re: [PD] Purr Data beta 2
   

I get this when trying to download beta 2 for mac
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.zip



404

The page you're looking for could not be found.

2016-10-10 15:26 GMT-03:00 Dan Wilcox <danomat...@gmail.com>:

Well, the deployment target only *indicates* to the OS if the app should be 
runnable. It also helps in defining which APIs are allowed. In either, case 
it’s no guarantee but, if a project is not using anything too new or esoteric, 
it can run fine on a lot of different versions of systems. In Obj-C, it’s 
trivial to check if a method or class definition exists at runtime, so you can 
more easily support a API changes over time without needing to explicitly build 
on an older system. Of course, this approach is less applicable to C/C++, hence 
it becomes more of an indication.
See also http://www.cocoabuilder. com/archive/xcode/287223-mac- 
os-deployment-target.html & ht tp://stackoverflow.com/ 
questions/25352389/difference- between-macosx-deployment- 
target-and-mmacosx-version- min-compiler-op#25362535

Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

On Oct 10, 2016, at 12:14 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
> You’ll probably need to build form source in either environment if you want 
> to be sure of the deployment target. Both Homebrew and Macports are focused 
> on running OS software for the current 
> system, much less so for building baked libraries to run on other systems.


I'm also just assuming that binaries built for the older targets will work on 
all the newer systems.
-Jonathan
   


__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list





   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Alexandre Torres Porres]

I get this when trying to download beta 2 for mac

https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.zip


404
The page you're looking for could not be found.

2016-10-10 15:26 GMT-03:00 Dan Wilcox :

> Well, the deployment target only *indicates* to the OS if the app should
> be runnable. It also helps in defining which APIs are allowed. In either,
> case it’s no guarantee but, if a project is not using anything too new or
> esoteric, it can run fine on a lot of different versions of systems. In
> Obj-C, it’s trivial to check if a method or class definition exists at
> runtime, so you can more easily support a API changes over time without
> needing to explicitly build on an older system. Of course, this approach is
> less applicable to C/C++, hence it becomes more of an indication.
>
> See also http://www.cocoabuilder.com/archive/xcode/287223-mac-
> os-deployment-target.html & http://stackoverflow.com/
> questions/25352389/difference-between-macosx-deployment-
> target-and-mmacosx-version-min-compiler-op#25362535
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
> On Oct 10, 2016, at 12:14 PM, Jonathan Wilkes  wrote:
>
> > You’ll probably need to build form source in either environment if you
> want to be sure of the deployment target. Both Homebrew and Macports are
> focused on running OS software for the current
> > system, much less so for building baked libraries to run on other
> systems.
>
>
>
> I'm also just assuming that binaries built for the older targets will work
> on all the newer systems.
>
> -Jonathan
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

Well, the deployment target only *indicates* to the OS if the app should be 
runnable. It also helps in defining which APIs are allowed. In either, case 
it’s no guarantee but, if a project is not using anything too new or esoteric, 
it can run fine on a lot of different versions of systems. In Obj-C, it’s 
trivial to check if a method or class definition exists at runtime, so you can 
more easily support a API changes over time without needing to explicitly build 
on an older system. Of course, this approach is less applicable to C/C++, hence 
it becomes more of an indication.

See also 
http://www.cocoabuilder.com/archive/xcode/287223-mac-os-deployment-target.html 

 & 
http://stackoverflow.com/questions/25352389/difference-between-macosx-deployment-target-and-mmacosx-version-min-compiler-op#25362535
 



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 12:14 PM, Jonathan Wilkes  wrote:
> 
> > You’ll probably need to build form source in either environment if you want 
> > to be sure of the deployment target. Both Homebrew and Macports are focused 
> > on running OS software for the current 
> > system, much less so for building baked libraries to run on other systems.
> 
> 
> 
> I'm also just assuming that binaries built for the older targets will work on 
> all the newer systems.
> 
> -Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> You’ll probably need to build form source in either environment if you want 
> to be sure of the deployment target. Both Homebrew and Macports are focused 
> on running OS software for the current 
> system, much less so for building baked libraries to run on other systems.


I'm also just assuming that binaries built for the older targets will work on 
all the newer systems.
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

You’ll probably need to build form source in either environment if you want to 
be sure of the deployment target. Both Homebrew and Macports are focused on 
running OS software for the current system, much less so for building baked 
libraries to run on other systems.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 12:03 PM, Jonathan Wilkes  wrote:
> 
> > Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET 
> > you should be able to set/override. Simplest way would be when running brew 
> > :
> 
> 
> 
> > MACOSX_DEPLOYMENT_TARGET=10.6 brew …
> 
> > That, in combination with —build-from-source when installing packages, 
> > might give you want you need.
> 
> That could work, but then I'm back to building from source.  (macports uses 
> binaries for most stuff, btw.)
> 
> I'm happy to investigate further _if_ a homebrew dev says that they 
> officially support installing this way.  There's a similar way 
> to change the deployment target for macports.  But one of the devs told me 
> that kind of compatibility isn't a design goal and 
> they don't support doing that.
> 
> -Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET you 
> should be able to set/override. Simplest way would be when running brew:


>     MACOSX_DEPLOYMENT_TARGET=10.6 brew …
> That, in combination with —build-from-source when installing packages, might 
> give you want you need.

That could work, but then I'm back to building from source.  (macports uses 
binaries for most stuff, btw.)

I'm happy to investigate further _if_ a homebrew dev says that they officially 
support installing this way.  There's a similar way 
to change the deployment target for macports.  But one of the devs told me that 
kind of compatibility isn't a design goal and 
they don't support doing that.
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET you 
should be able to set/override. Simplest way would be when running brew 
:

MACOSX_DEPLOYMENT_TARGET=10.6 brew …

That, in combination with —build-from-source when installing packages, might 
give you want you need.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 9:30 AM, Jonathan Wilkes  wrote:
> 
> > The closest might be -universal which asks to build/install a universal 
> > 32/64 bit package. There might be something else, but you’ll need to check 
> > the docs: http://brew.sh 
> 
> 
> 
> Nothing pops out at me.  It would be an enormous benefit over Macports-- 
> which doesn't officially support targeting versions earlier than the one you 
> happen 
> to be building against.  I assume they'd advertise that front and center.
> 
> -Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> The closest might be -universal which asks to build/install a universal 32/64 
> bit package. There might be something else, but you’ll need to check the 
> docs: http://brew.sh


Nothing pops out at me.  It would be an enormous benefit over Macports-- which 
doesn't officially support targeting versions earlier than the one you happen 
to be building against.  I assume they'd advertise that front and center.

-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

The closest might be -universal which asks to build/install a universal 32/64 
bit package. There might be something else, but you’ll need to check the docs: 
http://brew.sh <http://brew.sh/>

FYI currently the portaudio package cannot build for universal due to a 
configure check.


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Oct 10, 2016, at 8:30 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
> 
> One more Homebrew question:
> Does homebrew let me do the equivalent of -mmacosx-version-min ?  Can I ask 
> it for a libsdl package that 
> runs on 10.4 and greater?
> 
> -Jonathan
> 
> 
> 
> From: Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>
> To: Matt Barber <brbrof...@gmail.com>; Dan Wilcox <danomat...@gmail.com> 
> Cc: Pd-List <pd-list@lists.iem.at>
> Sent: Monday, October 10, 2016 9:31 AM
> Subject: Re: [PD] Purr Data beta 2
> 
> > Thank you. /usr/local always seems iffy to me, but this is after years in 
> > linux 
> > making sure to make packages to install any software via package manager. 
> > The 
> > thing I liked about macport's /opt, which is actually something of a 
> > standard for 
> > non-pacakge-managed software in linux, is that it's relatively encapsulated 
> > away from the rest of the directory structure. But as long as it does a 
> > reasonable 
> > job of uninstalling everything in a package it should be fine.
> 
> 
> 
> Does Homebrew require XCode?  If so then speed of package installs is 
> insignificant by comparison.
> 
> If not then I'll give it a try-- that would reduce the total time to build 
> from 1 day to 
> something less obnoxious.
> 
> -Jonathan
> 
> ___
> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list 
> <https://lists.puredata.info/listinfo/pd-list>
> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

> Does Homebrew require XCode?  If so then speed of package installs is 
> insignificant by comparison.
> 
> If not then I'll give it a try-- that would reduce the total time to build 
> from 1 day to 
> something less obnoxious.

Yes and no. Yes in that you need to install the Xcode Commandline Tools (aka 
gcc/clang, make, git, etc) and No in that you do not need to download and 
install the whole Xcode GUI app & tools if you’re only building things on the 
command line.

As of OSX 10.8 or so, you can run the following to install the commandline 
tools:

xcode-select —install

This will open a dialog box where you can click “Install”. There is no need for 
a login, or App Store, or whatever.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 7:31 AM, Jonathan Wilkes  wrote:
> 
> > Thank you. /usr/local always seems iffy to me, but this is after years in 
> > linux 
> > making sure to make packages to install any software via package manager. 
> > The 
> > thing I liked about macport's /opt, which is actually something of a 
> > standard for 
> > non-pacakge-managed software in linux, is that it's relatively encapsulated 
> > away from the rest of the directory structure. But as long as it does a 
> > reasonable 
> > job of uninstalling everything in a package it should be fine.
> 
> 
> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

One more Homebrew question:Does homebrew let me do the equivalent of 
-mmacosx-version-min ?  Can I ask it for a libsdl package that 
runs on 10.4 and greater?
-Jonathan



  From: Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>
 To: Matt Barber <brbrof...@gmail.com>; Dan Wilcox <danomat...@gmail.com> 
Cc: Pd-List <pd-list@lists.iem.at>
 Sent: Monday, October 10, 2016 9:31 AM
 Subject: Re: [PD] Purr Data beta 2
   
> Thank you. /usr/local always seems iffy to me, but this is after years in 
> linux 
> making sure to make packages to install any software via package manager. The 
> thing I liked about macport's /opt, which is actually something of a standard 
> for 
> non-pacakge-managed software in linux, is that it's relatively encapsulated 
> away from the rest of the directory structure. But as long as it does a 
> reasonable 
> job of uninstalling everything in a package it should be fine.


Does Homebrew require XCode?  If so then speed of package installs is 
insignificant by comparison.
If not then I'll give it a try-- that would reduce the total time to build from 
1 day to 
something less obnoxious.
-Jonathan
   
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Roman Haefeli]

On Mon, 2016-10-10 at 09:13 -0400, Matt Barber wrote:
> Thank you. /usr/local always seems iffy to me, but this is after
> years in linux making sure to make packages to install any software
> via package manager.

/usr/local [1] is exactly meant for _local_ installations that do not
interfere with any package management system and has the advantage that
binaries in /usr/local/bin and /usr/local/sbin usually are
automatically found by shells like bash.

Roman

[1] http://www.pathname.com/fhs/2.2/fhs-4.9.html


> On Mon, Oct 10, 2016 at 1:44 AM, Dan Wilcox <danomat...@gmail.com>
> wrote:
> > I use Homebrew all the time. It’s great. Definitely nicer to use
> > than macports.
> > 
> > I prefer Homebrew as it uses as many of the built in programs and
> > libs already on OSX. That means it’s *much* faster to install/build
> > packages since most things don’t require as many dependencies. You
> > can, of course, also install packages to supersede the often older
> > versions that come with the OS.
> > 
> > Also, it uses the more standard /usr/local as opposed to Macport’s
> > /opt, so most build systems find things automatically.
> > 
> > One more point, Homebrew has prebuilt binaries as well so
> > installing *big things* is relatively quick too.
> > 
> > Actually, when Jonathan sent me the purr data wiki, I did a quick
> > check and pretty much all of the libs y’all install via macports
> > are available in Hombrew.
> > 
> > 
> > Dan Wilcox
> > @danomatika
> > danomatika.com
> > robotcowboy.com
> > 
> > > On Oct 9, 2016, at 11:35 PM, pd-list-requ...@lists.iem.at wrote:
> > > 
> > > From: IOhannes m zmölnig <zmoel...@iem.at>
> > > Subject: Re: [PD] Purr Data beta 2
> > > Date: October 9, 2016 at 3:20:17 PM MDT
> > > To: pd-list@lists.iem.at
> > > 
> > > 
> > > On 10/09/2016 11:09 PM, Matt Barber wrote:
> > > > Thanks for this, IOhannes. We've been using macports for most
> > > > of the
> > > > development of purr-data on OSX (with a couple of fink installs
> > > > for some
> > > > libraries). Do you find brew to be superior, or was this a
> > > > comfortable
> > > > default?
> > > i cannot really remember what led to the actual decision.
> > > maybe brew was just the cool kid when i looked into it...
> > > 
> > > however, i'm under the impression that so far i have had far less
> > > troubles with brew than with fink and or macports.
> > > keep in mind, that i hardly ever use any of these in real live.
> > > (so while i probably find brew to be superior, i have virtually
> > > zero
> > > data points to be able to defend this position).
> > > 
> > > gfmd
> > > IOhannes
> > 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis
> tinfo/pd-list

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> Thank you. /usr/local always seems iffy to me, but this is after years in 
> linux 
> making sure to make packages to install any software via package manager. The 
> thing I liked about macport's /opt, which is actually something of a standard 
> for 
> non-pacakge-managed software in linux, is that it's relatively encapsulated 
> away from the rest of the directory structure. But as long as it does a 
> reasonable 
> job of uninstalling everything in a package it should be fine.


Does Homebrew require XCode?  If so then speed of package installs is 
insignificant by comparison.
If not then I'll give it a try-- that would reduce the total time to build from 
1 day to 
something less obnoxious.
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Matt Barber]

Thank you. /usr/local always seems iffy to me, but this is after years in
linux making sure to make packages to install any software via package
manager. The thing I liked about macport's /opt, which is actually
something of a standard for non-pacakge-managed software in linux, is that
it's relatively encapsulated away from the rest of the directory structure.
But as long as it does a reasonable job of uninstalling everything in a
package it should be fine.

On Mon, Oct 10, 2016 at 1:44 AM, Dan Wilcox <danomat...@gmail.com> wrote:

> I use Homebrew all the time. It’s great. Definitely nicer to use than
> macports.
>
> I prefer Homebrew as it uses as many of the built in programs and libs
> already on OSX. That means it’s *much* faster to install/build packages
> since most things don’t require as many dependencies. You can, of course,
> also install packages to supersede the often older versions that come with
> the OS.
>
> Also, it uses the more standard /usr/local as opposed to Macport’s /opt,
> so most build systems find things automatically.
>
> One more point, Homebrew has prebuilt binaries as well so installing *big
> things* is relatively quick too.
>
> Actually, when Jonathan sent me the purr data wiki, I did a quick check
> and pretty much all of the libs y’all install via macports are available in
> Hombrew.
>
> 
> Dan Wilcox
> @danomatika <https://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
> On Oct 9, 2016, at 11:35 PM, pd-list-requ...@lists.iem.at wrote:
>
> *From: *IOhannes m zmölnig <zmoel...@iem.at>
> *Subject: **Re: [PD] Purr Data beta 2*
> *Date: *October 9, 2016 at 3:20:17 PM MDT
> *To: *pd-list@lists.iem.at
>
>
> On 10/09/2016 11:09 PM, Matt Barber wrote:
>
> Thanks for this, IOhannes. We've been using macports for most of the
> development of purr-data on OSX (with a couple of fink installs for some
> libraries). Do you find brew to be superior, or was this a comfortable
> default?
>
>
> i cannot really remember what led to the actual decision.
> maybe brew was just the cool kid when i looked into it...
>
> however, i'm under the impression that so far i have had far less
> troubles with brew than with fink and or macports.
> keep in mind, that i hardly ever use any of these in real live.
> (so while i probably find brew to be superior, i have virtually zero
> data points to be able to defend this position).
>
> gfmd
> IOhannes
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

I use Homebrew all the time. It’s great. Definitely nicer to use than macports.

I prefer Homebrew as it uses as many of the built in programs and libs already 
on OSX. That means it’s *much* faster to install/build packages since most 
things don’t require as many dependencies. You can, of course, also install 
packages to supersede the often older versions that come with the OS.

Also, it uses the more standard /usr/local as opposed to Macport’s /opt, so 
most build systems find things automatically.

One more point, Homebrew has prebuilt binaries as well so installing *big 
things* is relatively quick too.

Actually, when Jonathan sent me the purr data wiki, I did a quick check and 
pretty much all of the libs y’all install via macports are available in Hombrew.


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Oct 9, 2016, at 11:35 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: IOhannes m zmölnig <zmoel...@iem.at <mailto:zmoel...@iem.at>>
> Subject: Re: [PD] Purr Data beta 2
> Date: October 9, 2016 at 3:20:17 PM MDT
> To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
> 
> 
> On 10/09/2016 11:09 PM, Matt Barber wrote:
>> Thanks for this, IOhannes. We've been using macports for most of the
>> development of purr-data on OSX (with a couple of fink installs for some
>> libraries). Do you find brew to be superior, or was this a comfortable
>> default?
> 
> i cannot really remember what led to the actual decision.
> maybe brew was just the cool kid when i looked into it...
> 
> however, i'm under the impression that so far i have had far less
> troubles with brew than with fink and or macports.
> keep in mind, that i hardly ever use any of these in real live.
> (so while i probably find brew to be superior, i have virtually zero
> data points to be able to defend this position).
> 
> gfmd
> IOhannes

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[IOhannes m zmölnig]

On 10/09/2016 11:09 PM, Matt Barber wrote:
> Thanks for this, IOhannes. We've been using macports for most of the
> development of purr-data on OSX (with a couple of fink installs for some
> libraries). Do you find brew to be superior, or was this a comfortable
> default?

i cannot really remember what led to the actual decision.
maybe brew was just the cool kid when i looked into it...

however, i'm under the impression that so far i have had far less
troubles with brew than with fink and or macports.
keep in mind, that i hardly ever use any of these in real live.
(so while i probably find brew to be superior, i have virtually zero
data points to be able to defend this position).

gfmd
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Matt Barber]

Thanks for this, IOhannes. We've been using macports for most of the
development of purr-data on OSX (with a couple of fink installs for some
libraries). Do you find brew to be superior, or was this a comfortable
default?

Thanks,

Matt

On Sun, Oct 9, 2016 at 5:05 PM, IOhannes m zmölnig  wrote:

> On 10/07/2016 03:35 AM, Jonathan Wilkes via Pd-list wrote:
> > What configure flags do I need to successfully build this?
>
> what errors do you get?
>
> try "--without-QuickTime-framework --without-Carbon-framework" or simile.
>
> or just read the wiki[1]
>
> fgmasrd
> IOhannes
>
> [1]
> https://github.com/umlaeute/Gem/wiki/How-to-build-Gem-on-MacOSX-Mavericks
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[IOhannes m zmölnig]

On 10/07/2016 03:35 AM, Jonathan Wilkes via Pd-list wrote:
> What configure flags do I need to successfully build this?

what errors do you get?

try "--without-QuickTime-framework --without-Carbon-framework" or simile.

or just read the wiki[1]

fgmasrd
IOhannes

[1]
https://github.com/umlaeute/Gem/wiki/How-to-build-Gem-on-MacOSX-Mavericks



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> Sure but it’s often easier to have/start a discussion with a proposed/working 
> solution. Did this involve changes to the pd core or are you wrapping the 
> lower level apis?
Changes to the core.

-Jonathan


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

Sure but it’s often easier to have/start a discussion with a proposed/working 
solution. Did this involve changes to the pd core or are you wrapping the lower 
level apis?


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 7, 2016, at 12:40 PM, Jonathan Wilkes  wrote:
> 
> > Sweet! :) Ok, awesome. You’re ahead on this.
> 
> 
> 
> Just to be clear-- that spec isn't a future proposal.  It's implemented in 
> Purr Data.
> 
> -Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> Sweet! :) Ok, awesome. You’re ahead on this.



Just to be clear-- that spec isn't a future proposal.  It's implemented in Purr 
Data.
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

Sweet! :) Ok, awesome. You’re ahead on this.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 

> On Oct 6, 2016, at 3:49 AM, pd-list-requ...@lists.iem.at 
>  wrote:
>> 
>> 1) External developers who want to support purr-data (pd-l2ork) can #ifdef 
>> their guis.
>> 2) For those who don't want to learn a new toolkit, and for unmaintained 
>> libraries, it'll be up to purr-data developers.
>> 
>> Until we have good documentation for integrating pd+nwjs, the first option 
>> may only work well for people who have a toe in both pools. I think that's 
>> me for cyclone, and I'll be glad to support purr-data directly in the new 
>> cyclone library as soon as I have a good chunk of time to do it, and some 
>> time to work out the kinks with Jonathan.
> 
> > I know I’ve mentioned it before, but I wish there was a middle ground where 
> > the GUI calls were abstracted enough to make these kinds of version/fork 
> > specific approaches unnecessary.
> 
> https://git.purrdata.net/jwilkes/purr-data#gui-messaging-specification 
> 
> 
> -Jonathan


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

On Oct 6, 2016, at 3:49 AM, pd-list-requ...@lists.iem.at wrote:

1) External developers who want to support purr-data (pd-l2ork) can #ifdef 
their guis.2) For those who don't want to learn a new toolkit, and for 
unmaintained libraries, it'll be up to purr-data developers.
Until we have good documentation for integrating pd+nwjs, the first option may 
only work well for people who have a toe in both pools. I think that's me for 
cyclone, and I'll be glad to support purr-data directly in the new cyclone 
library as soon as I have a good chunk of time to do it, and some time to work 
out the kinks with Jonathan.

> I know I’ve mentioned it before, but I wish there was a middle ground where 
> the GUI calls were abstracted enough to make these kinds of version/fork 
> specific approaches unnecessary.
https://git.purrdata.net/jwilkes/purr-data#gui-messaging-specification
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

As a follow up: this approach is what we’ve taken with libpd and it’s worked 
very well so far.

Peter initially discussed with Miller what changes and api access would be 
needed to wrap libpd. Once those were in place, the rest of libpd is 
essentially just wrappers around the vanilla core without touching the core 
directly. All I need to do to update libpd to a newer version of vanilla is to 
update the pure-data submodule to a new commit/tag and update the makefile to 
reflect any source file name additions or changes.

libpd *is* pd vanilla without the GUI or audio backend, not a variant or custom 
version. I’m not sure if that has been fully stated on this list.

Of course, the api & messaging requirements of libpd are small by comparison to 
a full UI implementation but I feel a similar process should be possible.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 7, 2016, at 11:27 AM, Dan Wilcox  wrote:
> 
>> On Oct 6, 2016, at 3:49 AM, pd-list-requ...@lists.iem.at 
>>  wrote:
>> 
>> 1) External developers who want to support purr-data (pd-l2ork) can #ifdef 
>> their guis.
>> 2) For those who don't want to learn a new toolkit, and for unmaintained 
>> libraries, it'll be up to purr-data developers.
>> 
>> Until we have good documentation for integrating pd+nwjs, the first option 
>> may only work well for people who have a toe in both pools. I think that's 
>> me for cyclone, and I'll be glad to support purr-data directly in the new 
>> cyclone library as soon as I have a good chunk of time to do it, and some 
>> time to work out the kinks with Jonathan.
> 
> I know I’ve mentioned it before, but I wish there was a middle ground where 
> the GUI calls were abstracted enough to make these kinds of version/fork 
> specific approaches unnecessary.
> 
> A possibly solution would be to standardize around the tcl messages that 
> vanilla already uses and provide a way to help parse and translate them into 
> whatever is being used by the GUI implementation. “Draw a box here” and “draw 
> some text”, “draw a line from this point to another point”, and “open this 
> window” are all actions possible in tons of languages and environments, just 
> done in a different syntax. Yeah, it’s probably not super efficient but this 
> mechanism seems to have worked pretty well over the years on older, slower 
> hardware to I’m in favor of proposing sticking to what works as a start.
> 
> My thought is if we could standardize some of the api interfaces and allow 
> others to be overridable (say the undo/redo mechanisms in a separate .c file) 
> or via default dummy implementations, vanilla/libpd could be uses as the 
> lingua franca core and each variant of Pd adds on it’s extras without 
> diverging.
> 
> I *really* hope we can talk about this idea in person at the pd con as I 
> still feel that, overall, we should find a way to pool resources more 
> effectively. For instance, Miller keeps the pd core solid & provides a Pd 
> vanilla GUI while pd-l2ork & purr data have their extensions, expanded 
> internals by overriding/extending aspects of the core, and custom GUI 
> implementations. All of this, hopefully, wrapped upon the same core. I think 
> it’s possible, we just have to figure out what kind of architecture would 
> make this possible. Some of this would probably be possible by simply 
> splitting some functions into separate .c files.
> 
> Forgive me if this has already been talked to death, but I have a feeling it 
> hasn’t so far...
> 
> Relatedly, I’d like to be able to add an editing GUI to PdParty and have 
> thoughts on making a console-based ncurses GUI for pd. That would be alot 
> easier with the knowledge and help of those of you to wrap the GUI comm via a 
> libpd api instead of me basically reverse engineering things myself. I’d 
> rather be lazy and use the shared knowledge that is one of the best parts 
> about open source.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

> On Oct 6, 2016, at 3:49 AM, pd-list-requ...@lists.iem.at wrote:
> 
> 1) External developers who want to support purr-data (pd-l2ork) can #ifdef 
> their guis.
> 2) For those who don't want to learn a new toolkit, and for unmaintained 
> libraries, it'll be up to purr-data developers.
> 
> Until we have good documentation for integrating pd+nwjs, the first option 
> may only work well for people who have a toe in both pools. I think that's me 
> for cyclone, and I'll be glad to support purr-data directly in the new 
> cyclone library as soon as I have a good chunk of time to do it, and some 
> time to work out the kinks with Jonathan.

I know I’ve mentioned it before, but I wish there was a middle ground where the 
GUI calls were abstracted enough to make these kinds of version/fork specific 
approaches unnecessary.

A possibly solution would be to standardize around the tcl messages that 
vanilla already uses and provide a way to help parse and translate them into 
whatever is being used by the GUI implementation. “Draw a box here” and “draw 
some text”, “draw a line from this point to another point”, and “open this 
window” are all actions possible in tons of languages and environments, just 
done in a different syntax. Yeah, it’s probably not super efficient but this 
mechanism seems to have worked pretty well over the years on older, slower 
hardware to I’m in favor of proposing sticking to what works as a start.

My thought is if we could standardize some of the api interfaces and allow 
others to be overridable (say the undo/redo mechanisms in a separate .c file) 
or via default dummy implementations, vanilla/libpd could be uses as the lingua 
franca core and each variant of Pd adds on it’s extras without diverging.

I *really* hope we can talk about this idea in person at the pd con as I still 
feel that, overall, we should find a way to pool resources more effectively. 
For instance, Miller keeps the pd core solid & provides a Pd vanilla GUI while 
pd-l2ork & purr data have their extensions, expanded internals by 
overriding/extending aspects of the core, and custom GUI implementations. All 
of this, hopefully, wrapped upon the same core. I think it’s possible, we just 
have to figure out what kind of architecture would make this possible. Some of 
this would probably be possible by simply splitting some functions into 
separate .c files.

Forgive me if this has already been talked to death, but I have a feeling it 
hasn’t so far...

Relatedly, I’d like to be able to add an editing GUI to PdParty and have 
thoughts on making a console-based ncurses GUI for pd. That would be alot 
easier with the knowledge and help of those of you to wrap the GUI comm via a 
libpd api instead of me basically reverse engineering things myself. I’d rather 
be lazy and use the shared knowledge that is one of the best parts about open 
source.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> On 10/06/2016 04:26 PM, Jonathan Wilkes via Pd-list wrote:


>> 
>>> > (Gem: can't load library)
>> Gem currently requires deprecated Apple libs.  Those libs require Gem to 
>> be built for i386 arch.
> not really true.
> Gem can be built fine on OSX/x86_64.
> the only things that cannot be built are the QuickTime based 
> film/image/video backends.> but that only means that the resulting Gem cannot 
> a number of media
> files; Gem can still do a lot of other things.

What configure flags do I need to successfully build this?

> gfmdsar
> IOhannes

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Matt Barber]

​The deprecated library in question is Carbon, which is 32-bit only. I
can't remember whether or not there were plans to update Gem to use Cocoa
instead, but if I remember correctly it was going to require some major
surgery. There are also tons of problems in the Gem code elsewhere that
​clang chokes on (at least on my machine). You'd have to edit some 50 of
Gem's openGL source files because they did constructor declarations wrong
(put default parameters in the definition in the .cpp file rather than in
the declaration in the .h file).

On Thu, Oct 6, 2016 at 10:26 AM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:

> > Is there any chance to get Gem working with Purr Data on OS X?
>
>
> > (Gem: can't load library)
>
> Gem currently requires deprecated Apple libs.  Those libs require Gem to
> be built for i386 arch.  Building Gem that way would require building all
> of Purr
> Data for i386 arch.
>
> When I tried changing the build scripts to do this I got linker errors
> that I didn't
> understand.  Matt also tried and got linker errors.  I tried compiling for
> x86_64
> and everything except Gem seemed to compile ok.  I took this as a sign
> that
> Apple doesn't want me to build i386 binaries.
>
> So there are essentially two options:
> 1. Somebody sends me a patch to flawlessly get all of Purr Data building
> for i386
> arch
> 2. Somebody revises Gem to use updated, non-deprecated API so it can be
> built
> for x86_64.
>
> -Jonathan
>
> > Volker
>
> Am 06.10.16 um 02:53 schrieb Jonathan Wilkes via Pd-list:
> > Here's an update for the OSX binary (Beta 1.2):
> > https://git.purrdata.net/jwilkes/purr-data-binaries/
> raw/master/purr-data-osx64-beta2.1.zip
> >
> > This fixes an error that kept Pd from starting, as well as adding a
> missing
> > dependency to get pdp working.
> >
> > Unfortunately I couldn't get the jack backend support.  I got the
> macports
> > jack library working, but shipping jack with the app is essentially
> useless.
> >
> > -Jonathan
>
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> >
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> Is there any chance to get Gem working with Purr Data on OS X?


> (Gem: can't load library)

Gem currently requires deprecated Apple libs.  Those libs require Gem to 
be built for i386 arch.  Building Gem that way would require building all of 
Purr 
Data for i386 arch.
When I tried changing the build scripts to do this I got linker errors that I 
didn't 
understand.  Matt also tried and got linker errors.  I tried compiling for 
x86_64 
and everything except Gem seemed to compile ok.  I took this as a sign that 
Apple doesn't want me to build i386 binaries.
 
So there are essentially two options:1. Somebody sends me a patch to flawlessly 
get all of Purr Data building for i386 
arch2. Somebody revises Gem to use updated, non-deprecated API so it can be 
built 
for x86_64.
-Jonathan
 
> Volker

Am 06.10.16 um 02:53 schrieb Jonathan Wilkes via Pd-list:
> Here's an update for the OSX binary (Beta 1.2):
> https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.1.zip
>
> This fixes an error that kept Pd from starting, as well as adding a missing
> dependency to get pdp working.
>
> Unfortunately I couldn't get the jack backend support.  I got the macports
> jack library working, but shipping jack with the app is essentially useless.
>
> -Jonathan
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Volker Möllenhoff via Pd-list]

Is there any chance to get Gem working with Purr Data on OS X?
(Gem: can't load library)

Volker

Am 06.10.16 um 02:53 schrieb Jonathan Wilkes via Pd-list:

Here's an update for the OSX binary (Beta 1.2):
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.1.zip

This fixes an error that kept Pd from starting, as well as adding a missing
dependency to get pdp working.

Unfortunately I couldn't get the jack backend support.  I got the macports
jack library working, but shipping jack with the app is essentially useless.

-Jonathan


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

Here's an update for the OSX binary (Beta 
1.2):https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.1.zip
This fixes an error that kept Pd from starting, as well as adding a missing 
dependency to get pdp working.
Unfortunately I couldn't get the jack backend support.  I got the macports 
jack library working, but shipping jack with the app is essentially useless.
-Jonathan
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Matt Barber]

Yep, that's something I'm thinking about carefully and will work with
Jonathan on in the coming days. I made some huge updates to scope~ over the
summer as well which need to be ported, and [comment] needs that also
(although there are some cross-platform font size bugs to take care of on
cyclone end first). I had been meaning to add [coll] to the list. We're
updating [coll] currently, so that may be something we can work in.

Since purr-data uses a toolkit that externals haven't been written for yet,
so far Jonathan has just been porting the GUIs and patching the relevant
code in the purr-data git. We have a couple of options:

1) External developers who want to support purr-data (pd-l2ork) can #ifdef
their guis.
2) For those who don't want to learn a new toolkit, and for unmaintained
libraries, it'll be up to purr-data developers.

Until we have good documentation for integrating pd+nwjs, the first option
may only work well for people who have a toe in both pools. I think that's
me for cyclone, and I'll be glad to support purr-data directly in the new
cyclone library as soon as I have a good chunk of time to do it, and some
time to work out the kinks with Jonathan.

I'd welcome any other thoughts.

Matt

On Wed, Oct 5, 2016 at 7:44 PM, Ivica Ico Bukvic  wrote:

> Jonathan and Alexandre,
>
> coll text editor with all its legacy pdtk calls is inoperable inside
> purr-data. Cyclone and other extern libraries with GUIs may require an
> ifdef for purr-data (or preferably pd-l2ork) and appropriate adaptation.
>
> Best,
>
> Ico
>
> On 10/5/2016 12:56 AM, Jonathan Wilkes via Pd-list wrote:
>
> This is the beta 2 release of Purr Data (the GUI port of Pd-l2ork)
>
> Change log:
> * compatibility with older osx versions
> * fix external library dependencies on OSX
> * first try at jack support for OSX
> * more fixes for out-of-order messages to GUI
> * fix crasher on Windows when opening a help patch
> * fix [draw sprite] index wrapping
> * fix freeze with [struct float foo;]
>
> This is a beta release, so please report lots of bugs to
> https://git.purrdata.net/jwilkes/purr-data/issues
>
> Binaries:
>
> Debian Jessie 32-bit: https://git.purrdata.net/jwilkes/purr-data-binaries/
> raw/master/purr-data-i686-jessie-beta2.deb
>
> Debian Jessie 64-bit: https://git.purrdata.net/jwilkes/purr-data-binaries/
> raw/master/purr-data-x86_64-jessie-beta2.deb
>
> Ubuntu 14.04 32-bit: https://git.purrdata.net/jwilkes/purr-data-binaries/
> raw/master/purr-data-i686-ubuntu-14.04-beta2.deb
>
> Ubuntu 14.04 64-bit: https://git.purrdata.net/jwilkes/purr-data-binaries/
> raw/master/purr-data-x86_64-ubuntu-14.04-beta2.deb
>
> Ubuntu 16.04 64-bit: https://git.purrdata.net/jwilkes/purr-data-binaries/
> raw/master/purr-data-x86_64-ubuntu-16.04-beta2.deb
>
> Windows with 64-bit GUI: https://git.purrdata.net/
> jwilkes/purr-data-binaries/raw/master/purr-data-win32-beta2.zip
>
> Windows with 32-bit GUI: https://git.purrdata.net/
> jwilkes/purr-data-binaries/raw/master/purr-data-win64-beta2.zip
>
> OSX 64-bit: https://git.purrdata.net/jwilkes/purr-data-binaries/
> raw/master/purr-data-osx64-beta2.zip
>
> -Jonathan
>
>
> ___pd-l...@lists.iem.at mailing 
> list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> Jonathan and Alexandre,

 > coll text editor with all its legacy pdtk calls is inoperable inside 
 > purr-data. 
> Cyclone and other extern libraries with GUIs may require an ifdef for 
> purr-data (or 
> preferably pd-l2ork) and appropriate adaptation.
  
Is there a public interface for the editor used by [text define]?

> Best, > Ico
  
 On 10/5/2016 12:56 AM, Jonathan Wilkes via Pd-list wrote:
  
 This is the beta 2 release of Purr Data (the GUI port of Pd-l2ork)
 
 Change log:
 * compatibility with older osx versions
 * fix external library dependencies on OSX
 * first try at jack support for OSX
 * more fixes for out-of-order messages to GUI
 * fix crasher on Windows when opening a help patch
 * fix [draw sprite] index wrapping
 * fix freeze with [struct float foo;]
 
 This is a beta release, so please report lots of bugs to
 https://git.purrdata.net/jwilkes/purr-data/issues
 
 Binaries:
 
 Debian Jessie 
32-bit:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-i686-jessie-beta2.deb
 
 Debian Jessie 
64-bit:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-jessie-beta2.deb
 
 Ubuntu 14.04 
32-bit:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-i686-ubuntu-14.04-beta2.deb
 
 Ubuntu 14.04 
64-bit:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-ubuntu-14.04-beta2.deb
 
 Ubuntu 16.04 
64-bit:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-ubuntu-16.04-beta2.deb
 
 Windows with 64-bit 
GUI:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-win32-beta2.zip
 
 Windows with 32-bit 
GUI:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-win64-beta2.zip
 
 OSX 
64-bit:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.zip
 
  -Jonathan
   
  
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
 
 
 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Ivica Ico Bukvic]

Jonathan and Alexandre,

coll text editor with all its legacy pdtk calls is inoperable inside 
purr-data. Cyclone and other extern libraries with GUIs may require an 
ifdef for purr-data (or preferably pd-l2ork) and appropriate adaptation.


Best,

Ico


On 10/5/2016 12:56 AM, Jonathan Wilkes via Pd-list wrote:

This is the beta 2 release of Purr Data (the GUI port of Pd-l2ork)

Change log:
* compatibility with older osx versions
* fix external library dependencies on OSX
* first try at jack support for OSX
* more fixes for out-of-order messages to GUI
* fix crasher on Windows when opening a help patch
* fix [draw sprite] index wrapping
* fix freeze with [struct float foo;]

This is a beta release, so please report lots of bugs to
https://git.purrdata.net/jwilkes/purr-data/issues

Binaries:

Debian Jessie 32-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-i686-jessie-beta2.deb


Debian Jessie 64-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-jessie-beta2.deb


Ubuntu 14.04 32-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-i686-ubuntu-14.04-beta2.deb


Ubuntu 14.04 64-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-ubuntu-14.04-beta2.deb


Ubuntu 16.04 64-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-ubuntu-16.04-beta2.deb


Windows with 64-bit GUI: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-win32-beta2.zip


Windows with 32-bit GUI: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-win64-beta2.zip


OSX 64-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.zip 



-Jonathan


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

This is the beta 2 release of Purr Data (the GUI port of Pd-l2ork)

Change log:
* compatibility with older osx versions
* fix external library dependencies on OSX
* first try at jack support for OSX
* more fixes for out-of-order messages to GUI
* fix crasher on Windows when opening a help patch
* fix [draw sprite] index wrapping
* fix freeze with [struct float foo;]

This is a beta release, so please report lots of bugs to
https://git.purrdata.net/jwilkes/purr-data/issues

Binaries:

Debian Jessie 32-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-i686-jessie-beta2.deb

Debian Jessie 64-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-jessie-beta2.deb

Ubuntu 14.04 32-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-i686-ubuntu-14.04-beta2.deb

Ubuntu 14.04 64-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-ubuntu-14.04-beta2.deb

Ubuntu 16.04 64-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-x86_64-ubuntu-16.04-beta2.deb

Windows with 64-bit GUI: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-win32-beta2.zip

Windows with 32-bit GUI: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-win64-beta2.zip

OSX 64-bit: 
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.zip
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list