Hello, I'm hoping some MacOSX gurus can help me traverse this mine-field.
What I'm trying to do: Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
- Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa. So I
must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be ok because Pd-extended.app is currently set up to use Carbon.
- Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the gui-rewrite
What I've done so far:
- updated the configure file successfully
- made a workaround for statbuf from stat.h not existing on OSX (in s_main.c)
- made a workaround for RTLD not existing after ./configure and trying to make (s_loader.c)
- successfully compiled Pd-l2ork
- checked that tkpath actually works on OSX. It seems to work, using tcl/tk w/Carbon
instead of Cocoa.
- used otool and install_name_tool to change libPdTcl.dylib libraries to point at the
App's Framework directory instead of system directories
- changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does successfully)
What crashes so far:
- inside pd.tk, I'm trying to do this:
load $pd_guidir/bin/libPdTcl.dylib It finds the dylib fine but then it crashes, with the crash report referencing the first line of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp) { const char *argv = Tcl_GetVar(interp, "argv", 0);
Any ideas where to begin to debug this? Is there some code I can add to Pdtcl_Init to print out some info I can use to tell where it's going wrong?
I put the full error log here: http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
- I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that?
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
- I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this?
- key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet.
Best, Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote:
Hello, I'm hoping some MacOSX gurus can help me traverse this mine-field.
What I'm trying to do: Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
- Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa. So I
must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be ok because Pd-extended.app is currently set up to use Carbon.
- Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the gui-rewrite
What I've done so far:
- updated the configure file successfully
- made a workaround for statbuf from stat.h not existing on OSX (in s_main.c)
- made a workaround for RTLD not existing after ./configure and trying to make (s_loader.c)
- successfully compiled Pd-l2ork
- checked that tkpath actually works on OSX. It seems to work, using tcl/tk w/Carbon
instead of Cocoa.
- used otool and install_name_tool to change libPdTcl.dylib libraries to point at the
App's Framework directory instead of system directories
- changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does successfully)
What crashes so far:
- inside pd.tk, I'm trying to do this: load $pd_guidir/bin/libPdTcl.dylib
It finds the dylib fine but then it crashes, with the crash report referencing the first line of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp) { const char *argv = Tcl_GetVar(interp, "argv", 0);
Any ideas where to begin to debug this? Is there some code I can add to Pdtcl_Init to print out some info I can use to tell where it's going wrong?
I put the full error log here: http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2013-10-09 22:45, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
...
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
The linker won't be looking for m_pd.h. It wants the Pd librrary as -lpd
Martin
Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older.
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
- I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that?
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
- I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this?
- key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet.
Best, Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote:
Hello, I'm hoping some MacOSX gurus can help me traverse this mine-field.
What I'm trying to do: Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
- Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa. So I
must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be ok because Pd-extended.app is currently set up to use Carbon.
- Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the
gui-rewrite
What I've done so far:
- updated the configure file successfully
- made a workaround for statbuf from stat.h not existing on OSX (in s_main.c)
- made a workaround for RTLD not existing after ./configure and trying to
make (s_loader.c)
- successfully compiled Pd-l2ork
- checked that tkpath actually works on OSX. It seems to work, using tcl/tk
w/Carbon instead of Cocoa.
- used otool and install_name_tool to change libPdTcl.dylib libraries to
point at the App's Framework directory instead of system directories
- changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does
successfully)
What crashes so far:
- inside pd.tk, I'm trying to do this: load $pd_guidir/bin/libPdTcl.dylib
It finds the dylib fine but then it crashes, with the crash report referencing the first line of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp) { const char *argv = Tcl_GetVar(interp, "argv", 0);
Any ideas where to begin to debug this? Is there some code I can add to Pdtcl_Init to print out some info I can use to tell where it's going wrong?
I put the full error log here: http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
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 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older.
I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link to the Carbon system libraries. Both run.
An update to the Pd-l2ork port:
- figured out how to build tkpath against the Carbon stuff. It runs
fine now.
- got some basic libraries compiled and installed to ship with the app.
(zexy, hcs, cyclone, and a few others).
- currently working on an issue with the Shift key "sticking"-- that is,
if I do <Shift-RightArrow> to move an object by 10 pixels, when I release Shift and then do <RightArrow> it continues moving the object by 10 pixels instead of 1 pixel. Once I fix that it should be usable.
Best, Jonathan
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
- I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that?
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
- I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this?
- key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet.
Best, Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote:
Hello, I'm hoping some MacOSX gurus can help me traverse this mine-field.
What I'm trying to do: Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
- Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa. So I
must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be ok because Pd-extended.app is currently set up to use Carbon.
- Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the
gui-rewrite
What I've done so far:
- updated the configure file successfully
- made a workaround for statbuf from stat.h not existing on OSX (in s_main.c)
- made a workaround for RTLD not existing after ./configure and trying to
make (s_loader.c)
- successfully compiled Pd-l2ork
- checked that tkpath actually works on OSX. It seems to work, using tcl/tk
w/Carbon instead of Cocoa.
- used otool and install_name_tool to change libPdTcl.dylib libraries to
point at the App's Framework directory instead of system directories
- changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does
successfully)
What crashes so far:
- inside pd.tk, I'm trying to do this: load $pd_guidir/bin/libPdTcl.dylib
It finds the dylib fine but then it crashes, with the crash report referencing the first line of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp) { const char *argv = Tcl_GetVar(interp, "argv", 0);
Any ideas where to begin to debug this? Is there some code I can add to Pdtcl_Init to print out some info I can use to tell where it's going wrong?
I put the full error log here: http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 10/21/2013 03:59 PM, Jonathan Wilkes wrote:
On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older.
I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link to the Carbon system libraries. Both run.
Considering that Apple has dropped support even for some older 64-bit Macs, I think using Carbon is surely a dead end.
http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-b...
.hc
An update to the Pd-l2ork port:
- figured out how to build tkpath against the Carbon stuff. It runs fine now.
- got some basic libraries compiled and installed to ship with the app.
(zexy, hcs, cyclone, and a few others).
- currently working on an issue with the Shift key "sticking"-- that is, if I
do <Shift-RightArrow> to move an object by 10 pixels, when I release Shift and then do <RightArrow> it continues moving the object by 10 pixels instead of 1 pixel. Once I fix that it should be usable.
Best, Jonathan
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
- I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that?
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
- I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this?
- key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet.
Best, Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote:
Hello, I'm hoping some MacOSX gurus can help me traverse this mine-field.
What I'm trying to do: Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
- Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa.
So I must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be ok because Pd-extended.app is currently set up to use Carbon.
- Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the
gui-rewrite
What I've done so far:
- updated the configure file successfully
- made a workaround for statbuf from stat.h not existing on OSX (in s_main.c)
- made a workaround for RTLD not existing after ./configure and trying to
make (s_loader.c)
- successfully compiled Pd-l2ork
- checked that tkpath actually works on OSX. It seems to work, using tcl/tk
w/Carbon instead of Cocoa.
- used otool and install_name_tool to change libPdTcl.dylib libraries to
point at the App's Framework directory instead of system directories
- changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does
successfully)
What crashes so far:
- inside pd.tk, I'm trying to do this: load $pd_guidir/bin/libPdTcl.dylib
It finds the dylib fine but then it crashes, with the crash report referencing the first line of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp) { const char *argv = Tcl_GetVar(interp, "argv", 0);
Any ideas where to begin to debug this? Is there some code I can add to Pdtcl_Init to print out some info I can use to tell where it's going wrong?
I put the full error log here: http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
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
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 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote:
On 10/21/2013 03:59 PM, Jonathan Wilkes wrote:
On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older.
I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link to the Carbon system libraries. Both run.
Considering that Apple has dropped support even for some older 64-bit Macs, I think using Carbon is surely a dead end.
http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-b...
What is the relevance of what you've written and linked to?
When I have time to look at what's required to get tkpath to use the updated tkMac headers found in newer versions of tcl/tk, I'll do it. Meanwhile people will have a working version of Pd-l2ork on OSX to play with.
-Jonathan
.hc
An update to the Pd-l2ork port:
- figured out how to build tkpath against the Carbon stuff. It runs fine now.
- got some basic libraries compiled and installed to ship with the app.
(zexy, hcs, cyclone, and a few others).
- currently working on an issue with the Shift key "sticking"-- that is, if I
do <Shift-RightArrow> to move an object by 10 pixels, when I release Shift and then do <RightArrow> it continues moving the object by 10 pixels instead of 1 pixel. Once I fix that it should be usable.
Best, Jonathan
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
- I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that?
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
- I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this?
- key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet.
Best, Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote:
Hello, I'm hoping some MacOSX gurus can help me traverse this mine-field.
What I'm trying to do: Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
- Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa.
So I must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be ok because Pd-extended.app is currently set up to use Carbon.
- Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the
gui-rewrite
What I've done so far:
- updated the configure file successfully
- made a workaround for statbuf from stat.h not existing on OSX (in s_main.c)
- made a workaround for RTLD not existing after ./configure and trying to
make (s_loader.c)
- successfully compiled Pd-l2ork
- checked that tkpath actually works on OSX. It seems to work, using tcl/tk
w/Carbon instead of Cocoa.
- used otool and install_name_tool to change libPdTcl.dylib libraries to
point at the App's Framework directory instead of system directories
- changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does
successfully)
What crashes so far:
- inside pd.tk, I'm trying to do this: load $pd_guidir/bin/libPdTcl.dylib
It finds the dylib fine but then it crashes, with the crash report referencing the first line of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp) { const char *argv = Tcl_GetVar(interp, "argv", 0);
Any ideas where to begin to debug this? Is there some code I can add to Pdtcl_Init to print out some info I can use to tell where it's going wrong?
I put the full error log here: http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
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
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 10/22/2013 12:55 PM, Jonathan Wilkes wrote:
On 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote:
On 10/21/2013 03:59 PM, Jonathan Wilkes wrote:
On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older.
I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link to the Carbon system libraries. Both run.
Considering that Apple has dropped support even for some older 64-bit Macs, I think using Carbon is surely a dead end.
http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-b...
What is the relevance of what you've written and linked to?
When I have time to look at what's required to get tkpath to use the updated tkMac headers found in newer versions of tcl/tk, I'll do it. Meanwhile people will have a working version of Pd-l2ork on OSX to play with.
-Jonathan
I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, which is 64-bit.
Your determination is admirable, I just think there are better areas to focus your efforts. Last I checked, tkpath is not really maintained. We should really be talking about pulling the GUI functions out of the Pd core, then people can do things like write a GUI in C++, which will be dramatically faster than anything written in Tcl/Tk.
.hc
.hc
An update to the Pd-l2ork port:
- figured out how to build tkpath against the Carbon stuff. It runs fine now.
- got some basic libraries compiled and installed to ship with the app.
(zexy, hcs, cyclone, and a few others).
- currently working on an issue with the Shift key "sticking"-- that is, if I
do <Shift-RightArrow> to move an object by 10 pixels, when I release Shift and then do <RightArrow> it continues moving the object by 10 pixels instead of 1 pixel. Once I fix that it should be usable.
Best, Jonathan
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
- I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that?
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
- I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this?
- key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet.
Best, Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote:
Hello, I'm hoping some MacOSX gurus can help me traverse this mine-field.
What I'm trying to do: Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app
Minefields:
- Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa.
So I must use tcl/tk Framework that uses Carbon instead of Cocoa. That should be ok because Pd-extended.app is currently set up to use Carbon.
- Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the
gui-rewrite
What I've done so far:
- updated the configure file successfully
- made a workaround for statbuf from stat.h not existing on OSX (in
s_main.c)
- made a workaround for RTLD not existing after ./configure and trying to
make (s_loader.c)
- successfully compiled Pd-l2ork
- checked that tkpath actually works on OSX. It seems to work, using
tcl/tk w/Carbon instead of Cocoa.
- used otool and install_name_tool to change libPdTcl.dylib libraries to
point at the App's Framework directory instead of system directories
- changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does
successfully)
What crashes so far:
- inside pd.tk, I'm trying to do this: load $pd_guidir/bin/libPdTcl.dylib
It finds the dylib fine but then it crashes, with the crash report referencing the first line of the following function of t_tkcmd.c in the backtrace:
int Pdtcl_Init(Tcl_Interp *interp) { const char *argv = Tcl_GetVar(interp, "argv", 0);
Any ideas where to begin to debug this? Is there some code I can add to Pdtcl_Init to print out some info I can use to tell where it's going wrong?
I put the full error log here: http://pastebin.com/duHdRrsY
Any suggestions appreciated.
-Jonathan
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
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
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 11/04/2013 09:51 AM, Hans-Christoph Steiner wrote:
On 10/22/2013 12:55 PM, Jonathan Wilkes wrote:
On 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote:
On 10/21/2013 03:59 PM, Jonathan Wilkes wrote:
On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older.
I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link to the Carbon system libraries. Both run.
Considering that Apple has dropped support even for some older 64-bit Macs, I think using Carbon is surely a dead end.
http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-b...
What is the relevance of what you've written and linked to?
When I have time to look at what's required to get tkpath to use the updated tkMac headers found in newer versions of tcl/tk, I'll do it. Meanwhile people will have a working version of Pd-l2ork on OSX to play with.
-Jonathan
I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, which is 64-bit.
Yes. AFAICT, getting it to work with Cocoa is a matter of revising tkpath to use the revised TkMacOSXInt.h header functions and structures in the newer versions of tcl/tk instead of the old ones. There are some hints by looking at the rest of tk that uses that header and seeing how they changed their code.
Your determination is admirable, I just think there are better areas to focus your efforts. Last I checked, tkpath is not really maintained. We should really be talking about pulling the GUI functions out of the Pd core, then people can do things like write a GUI in C++, which will be dramatically faster than anything written in Tcl/Tk.
But "people" aren't going to write a gui for Pd. There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that. (Though I'm sure there are a lot of projects that do cool things with it.)
Writing a development environment is a gargantuan task, and testing out tkpath was literally 3 lines of code added to pdtk_canvas.tcl. Ivica said getting it to work fully was more effort than that, but the fact that it supports tk canvas commands allows a lot of improvements to the interface without having to do a complete rewrite of everything g_*.[ch]
And of course removing GUI function from the Pd core can be done in addition to the tkpath improvements. Once you get FUDI messages in both directions, you'll still have a fully-functional gui dev environment in tcl/tk.
I'm not convinced there are the resources in the Pd community to fund doing all the work required to use a different GUI toolkit, plus making all the redesign and testing speed improvements that another toolkit would bring.
-Jonathan
.hc
.hc
An update to the Pd-l2ork port:
- figured out how to build tkpath against the Carbon stuff. It runs fine now.
- got some basic libraries compiled and installed to ship with the app.
(zexy, hcs, cyclone, and a few others).
- currently working on an issue with the Shift key "sticking"-- that is, if I
do <Shift-RightArrow> to move an object by 10 pixels, when I release Shift and then do <RightArrow> it continues moving the object by 10 pixels instead of 1 pixel. Once I fix that it should be usable.
Best, Jonathan
.hc
On 10/09/2013 10:45 PM, Jonathan Wilkes wrote:
Update-- I've got a working Pd-l2ork, tkpath based App running on OSX. (No ppc support, unfortunately.) Audio is running.
Minefields:
- I cannot for the life of me figure out how to build tkpath using the
Tcl/tk Frameworks (Carbon-based) inside Pd-l2ork.app instead of the system ones. (Tried both Xcode and command line tools). Anybody have hints for that?
- I can't figure out how to build the externals in "extra". If I do
"make" the linker doesn't find any of the m_pd.h functions, even if I do the ugly hack of copying m_pd.h to the directory.
- I'm abusing my function for returning the executable path in order
to get Pd to look for doc/ and extra/ inside the App (in addition to the usual places on the system). Is there a trick to this?
- key presses/releases sometimes get stuck in one state or the other.
I think there's some simple tcl/tk hack for ignoring autokeys that may remedy this, but I'm not sure yet.
Best, Jonathan
On 10/07/2013 04:05 PM, Jonathan Wilkes wrote: > Hello, > I'm hoping some MacOSX gurus can help me traverse this mine-field. > > What I'm trying to do: > Port Pd-l2ork (quick-and-dirty) to MacOSX in the form of a Pd-l2ork.app > > Minefields: > * Pd-l2ork uses tkpath, which is built to work with Carbon and not Cocoa. > So I > must use tcl/tk Framework that uses Carbon instead of Cocoa. That > should be > ok because Pd-extended.app is currently set up to use Carbon. > * Pd-l2ork uses the old pd.tk framework instead of the newer stuff from the > gui-rewrite > > What I've done so far: > * updated the configure file successfully > * made a workaround for statbuf from stat.h not existing on OSX (in > s_main.c) > * made a workaround for RTLD not existing after ./configure and trying to > make (s_loader.c) > * successfully compiled Pd-l2ork > * checked that tkpath actually works on OSX. It seems to work, using > tcl/tk > w/Carbon > instead of Cocoa. > * used otool and install_name_tool to change libPdTcl.dylib libraries to > point at the > App's Framework directory instead of system directories > * changed AppMain.tcl to launch pd.tk instead of pd-gui (which it does > successfully) > > What crashes so far: > * inside pd.tk, I'm trying to do this: > load $pd_guidir/bin/libPdTcl.dylib > It finds the dylib fine but then it crashes, with the crash report > referencing the first line > of the following function of t_tkcmd.c in the backtrace: > > int Pdtcl_Init(Tcl_Interp *interp) > { > const char *argv = Tcl_GetVar(interp, "argv", 0); > > *** > > Any ideas where to begin to debug this? Is there some code I can add to > Pdtcl_Init to print out some info I can use to tell where it's going wrong? > > I put the full error log here: > http://pastebin.com/duHdRrsY > > Any suggestions appreciated. > > -Jonathan > > > _______________________________________________ > 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
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
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 4, 2013, at 1:42 PM, Jonathan Wilkes wrote:
On 11/04/2013 09:51 AM, Hans-Christoph Steiner wrote:
On 10/22/2013 12:55 PM, Jonathan Wilkes wrote:
On 10/21/2013 11:18 PM, Hans-Christoph Steiner wrote:
On 10/21/2013 03:59 PM, Jonathan Wilkes wrote:
On 10/21/2013 02:12 PM, Hans-Christoph Steiner wrote:
Carbon has been deprecated by Apple and might have been removed entirely. It will only ever be 32-bit, and starting in 10.7, everything is 64-bit. Anything Carbon is dead, unless you're happy working with 10.6 and older.
I'm running Pd-extended and my Pd-l2ork port on 10.7.5. Both link to the Carbon system libraries. Both run.
Considering that Apple has dropped support even for some older 64-bit Macs, I think using Carbon is surely a dead end.
http://arstechnica.com/apple/2012/07/confirmed-mountain-lion-sends-some-64-b...
What is the relevance of what you've written and linked to?
When I have time to look at what's required to get tkpath to use the updated tkMac headers found in newer versions of tcl/tk, I'll do it. Meanwhile people will have a working version of Pd-l2ork on OSX to play with.
-Jonathan
I think I confused tkZinc and tkpath. tkpath seems to use CoreGraphics, which is 64-bit.
Yes. AFAICT, getting it to work with Cocoa is a matter of revising tkpath to use the revised TkMacOSXInt.h header functions and structures in the newer versions of tcl/tk instead of the old ones. There are some hints by looking at the rest of tk that uses that header and seeing how they changed their code.
Your determination is admirable, I just think there are better areas to focus your efforts. Last I checked, tkpath is not really maintained. We should really be talking about pulling the GUI functions out of the Pd core, then people can do things like write a GUI in C++, which will be dramatically faster than anything written in Tcl/Tk.
But "people" aren't going to write a gui for Pd. There is already libpd and I don't see a bunch of elegant and efficient Pd frontends sprouting up because of that. (Though I'm sure there are a lot of projects that do cool things with it.)
Writing a development environment is a gargantuan task, and testing out tkpath was literally 3 lines of code added to pdtk_canvas.tcl. Ivica said getting it to work fully was more effort than that, but the fact that it supports tk canvas commands allows a lot of improvements to the interface without having to do a complete rewrite of everything g_*.[ch]
And of course removing GUI function from the Pd core can be done in addition to the tkpath improvements. Once you get FUDI messages in both directions, you'll still have a fully-functional gui dev environment in tcl/tk.
I'm not convinced there are the resources in the Pd community to fund doing all the work required to use a different GUI toolkit, plus making all the redesign and testing speed improvements that another toolkit would bring.
-Jonathan
I'm not proposing that we spend more time on this, but rather that we coordinate efforts and work smartly. Sure, we can keep patching up the existing Pd GUI stuff, and hacking in old Tk code, there has been a lot of that over the years. If we instead invest in the up front work of ripping out the GUI code from pd core, then it becomes drastically easier to write a modern, efficient GUI in whatever toolkit. libpd has not addressed this particular issue, but it will become more valuable if the GUI was truly separate from the core.
But the Pd dev community has always been not so good at coordinated efforts. There is a history of lots of effort going into semi-compatible dev forks which mostly die out after a run (pd-devel, desiredata, vibrez, etc. etc.) Perhaps Pd-extended or pd-l2ork will be the next one to die out...
.hc
But the Pd dev community has always been not so good at coordinated
efforts.
There is a history of lots of effort going into semi-compatible dev forks
which
mostly die out after a run (pd-devel, desiredata, vibrez, etc. etc.)
Perhaps Pd-
extended or pd-l2ork will be the next one to die out...
.hc
Hans,
Your heart is in the right place but we also need to practice what we preach. I think the FOSS community's greatest weakness is also its greatest strength--if things die away and even get duplicated, they have done so for a specific reason. I find the existence of pd-l2ork essential in what I do as I am sure you and many others find pd-extended and/or pd-vanilla. Just like Miller, you, I, and many other core contributors to the Pd ecosystem, I am flattered that others may find my flavor useful but I have no intentions of trying to make anyone a convert. In other words, having options is a good thing and we all ultimately choose to use whatever best addresses our needs, even if that means introducing a level of redundancy. Our projects have also inspired each other on various occasions and I see this as a good thing--at the very least I see this as a great source for motivation.
I have no intentions of dropping pd-l2ork anytime soon because it has proven particularly useful in my own work. And even if one day I do stop developing it, I have no expectations about its future. Ideally, someone else will pick up the code and run with it. And if no one does I guess that will be the testament to how bad this branch was and maybe it will be a good thing that it will wither and die away. OTOH, it may persist and transform into something none of us could ever even imagine, and that is fine as well. Ultimately, pd-l2ork serves my purpose (just like I anticipate pd-extended serves yours) and is IMO different enough in its agenda/focus to warrant its existence--and as long as that continues to be the case I am fairly confident that we'll all continue plugging away at that next iteration of our preferred platform.
Best wishes,
Ico
-
Hans-Christoph Steiner -
Ivica Ico Bukvic -
Jonathan Wilkes -
Martin Peach