Re: [9fans] plan9port: cocoa programmer needed
David, So far my testing on your prior version worked decently on Lion (linked against Snowy built 9libs). Once this new version shows up in the source tree I'll be able to test a little more. One issue I did not w/ acme: screen redraw is significantly slower than the Carbon version. Test by starting win in acme and doing something that creates a long listing (netstat, ps,...). Not a big issue as this can be fixed later. Thanks for the code. -jas
Re: [9fans] plan9port: cocoa programmer needed
One issue I did not w/ acme: screen redraw is significantly slower than the Carbon version. Test by starting win in acme and doing something that creates a long listing (netstat, ps,...). Not a big issue as this can be fixed later. Yes, it was very painful, but the new version is very responsive. (The only way I had found to deal with live resizing compelled Devdraw to swap the back buffer and the front buffer each time plan9 was flushing rectangles to the back buffer, and dreadful was the latency.) Just after my I will be late announcement, Russ advised me to publish all the same what I had, because Carbon's Devdraw apparently also stopped working on Snow Leopard with the latest Xcode. I was in the middle of live resizing madness, and my code was very experimental, but I forgot to mention it on 9fans. Sent from my gesture-enhanced Acme.
Re: [9fans] plan9port: cocoa programmer needed
Can you guys perhaps create a small video about how you use your computers now? It's difficult to understand for someone who doesn't own a mac, but I would still like to see what you're doing there ;) On Wed, Sep 14, 2011 at 18:40, david jeannot djeanno...@gmail.com wrote: One issue I did not w/ acme: screen redraw is significantly slower than the Carbon version. Test by starting win in acme and doing something that creates a long listing (netstat, ps,...). Not a big issue as this can be fixed later. Yes, it was very painful, but the new version is very responsive. (The only way I had found to deal with live resizing compelled Devdraw to swap the back buffer and the front buffer each time plan9 was flushing rectangles to the back buffer, and dreadful was the latency.) Just after my I will be late announcement, Russ advised me to publish all the same what I had, because Carbon's Devdraw apparently also stopped working on Snow Leopard with the latest Xcode. I was in the middle of live resizing madness, and my code was very experimental, but I forgot to mention it on 9fans. Sent from my gesture-enhanced Acme.
Re: [9fans] plan9port: cocoa programmer needed
On Tue, Sep 13, 2011 at 8:59 AM, david jeannot djeanno...@gmail.com wrote: So I will send my code in the next few days, unless there is a need. I'm 9 days late, but here it is: the Cocoa version of Devdraw. I just submitted it to Codereview: http://codereview.appspot.com/5015042 I removed live resizing, because I found no way to make it perfect: the window now becomes gray while resizing. About gestures now. A swipe gesture needs 3 fingers (with trackpads at least). If you want to use them, you must reconfigure OS X Lion to use 4 fingers instead of 3 (to swipe between spaces, or to swipe to Mission Control for example). As previously discussed, OS X Lion doesn't send swipe events anymore for vertical swipes. So I reimplemented swipe gestures with lower-level touch events. All that I can say is that it works well with a late 2010 MacBook Air's trackpad. Unfortunately, it seems only for trackpads: not for Magic Mouse. The higher-level gesture events seem compatible with Magic Mouse (though I don't know to how many fingers a swipe gesture corresponds), but the lower-level touch events seem incompatible (I may be mistaken). If you want to use the reimplemented swipes, you have to set the reimplementswipe variable at the beginning of cocoa-screen.m (the file's name may change soon). One advantage of this reimplementation is that we can now detect 3-finger taps. If you set the usecopygesture variable as well, you have now the following gestures: 3-finger swipe-left to cut (cmd+x), 3-finger swipe-right to paste (cmd+v), 3-finger swipe-up to copy (cmd+c), 3-finger swipe-down to execute with arguments (2-1 chord), 3-finger tap to execute (button 2), pinch to toggle fullscreen. Else you have: swipe-left to cut (cmd+x), swipe-right to paste (cmd+v), swipe-up to execute (button 2), swipe-down to execute with arguments (2-1 chord), pinch to toggle fullscreen. In both cases, horizontal swipes cancel each other if your fingers remain on the device in between. That is to say, the second swipe sends undo (cmd+z): a command only recognized by Acme currently. An annoyance is the behavior of Acme's Undo when we are in the window's tag. Acme only seems to undo filename change, else it undoes the last change in the window's body. For example, if you want to copy from the tag, (unless you use the copy gesture) you will have to lift the fingers between the left and the right swipe, else it will undo the window's body, and you will be completely puzzled. I wish this announcement will not cause too much disappointment among Magic Mouse users. I knew nothing of Mac programming before to begin this project one month ago, and I certainly generalize too much. (I didn't understood what was the mysterious multitouch code in Carbon's Devdraw, until some days ago, where I fell upon a similar code to communicate with the Magic Mouse here: http://www.iphonesmartapps.org/aladino/?a=multitouch) If OS X Lion's users prefer the old fullscreen mode, they can set the useoldfullscreen variable. (Currently, Devdraw can't accept arguments, and as it is so hard to compile anything with current Xcode 4.1, I didn't try to modify Libdraw. This is why you have to set variables instead of using optional arguments.) Be sure to read the description on Codereview for the remaining bugs, to avoid further disappointment. If you need binaries running on Lion (Cocoa's Devdraw, Acme supporting cmd+z, etc.), I will be happy to provide them. I just inherited a Macbook running Lion, so this is suddenly relevant to my interests. I'm very new to the world of OS X; could somebody put together a step-by-step on how to build for Lion? I've downloaded the plan9ports tarball, extracted it to /usr/local/plan9, and done an hg pull -u, but INSTALL dies with complaints from ld about a malformed TOC entry in libbio.a. Also, further up, when it tries to build devdraw I see it failing because it still tries to make the Carbon version. John
Re: [9fans] plan9port: cocoa programmer needed
add: [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar then cd src/cmd/devdraw mk cocoa cp cocoa $PLAN9/bin/devdraw now you're as far as I got :) i'm trying to figure out why 'colors' works, but acme exits with return value of 1.
Re: [9fans] plan9port: cocoa programmer needed
On Wed, Sep 14, 2011 at 10:23 AM, andrey mirtchovski mirtchov...@gmail.comwrote: add: [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar then cd src/cmd/devdraw mk cocoa cp cocoa $PLAN9/bin/devdraw now you're as far as I got :) i'm trying to figure out why 'colors' works, but acme exits with return value of 1. I have the same results.
Re: [9fans] plan9port: cocoa programmer needed
On Wed, Sep 14, 2011 at 10:28 AM, David Leimbach leim...@gmail.com wrote: On Wed, Sep 14, 2011 at 10:23 AM, andrey mirtchovski mirtchov...@gmail.com wrote: add: [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar then cd src/cmd/devdraw mk cocoa cp cocoa $PLAN9/bin/devdraw now you're as far as I got :) i'm trying to figure out why 'colors' works, but acme exits with return value of 1. I have the same results. anything useful from truss? ron
Re: [9fans] plan9port: cocoa programmer needed
On Wed, Sep 14, 2011 at 10:31 AM, ron minnich rminn...@gmail.com wrote: On Wed, Sep 14, 2011 at 10:28 AM, David Leimbach leim...@gmail.com wrote: On Wed, Sep 14, 2011 at 10:23 AM, andrey mirtchovski mirtchov...@gmail.com wrote: add: [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar then cd src/cmd/devdraw mk cocoa cp cocoa $PLAN9/bin/devdraw now you're as far as I got :) i'm trying to figure out why 'colors' works, but acme exits with return value of 1. I have the same results. anything useful from truss? ron I should probably try that... but I've not had time to get back to it yet...
Re: [9fans] plan9port: cocoa programmer needed
anything useful from truss? acid reports 'bad magic: unknown file type'. the app exits before any of the standard osx instruments can record it. here's the change to mkwsysrules.sh to build the cocoa devdraw by default. i'm hoping with this my ./INSTALL will complete or exhibit other errors. - echo 'WSYSOFILES=$WSYSOFILES osx-screen-carbon-objc.o osx-draw.o osx-srv.o' + echo 'WSYSOFILES=$WSYSOFILES cocoa-screen-objc.o osx-draw.o cocoa-srv.o cocoa-thread.o'
Re: [9fans] plan9port: cocoa programmer needed
could somebody put together a step-by-step on how to build for Lion? I've downloaded the plan9ports tarball, extracted it to /usr/local/plan9, and done an hg pull -u, but INSTALL dies with complaints from ld about a malformed TOC entry in libbio.a. John, this problem comes from Xcode 4.1. If the change to 9ar doesn't work for you (it doesn't for me), try this hack: http://9fans.net/archive/2011/09/75 All should compile except Devdraw. There are 3 versions of Devdraw in src/cmd/devdraw(!) The default is the Carbon version: It doesn't work anymore. Then there is devdraw-cocoa: an old attempt. Then there is my version, currently called cocoa, but it is the last week's release, and I don't recommend to use it. I recommend to use the yesterday's release: it is not in the official tree yet, but there is a patch here: http://codereview.appspot.com/5015042 Then you can do: mk cocoa DEVDRAW=cocoa colors But you cannot do: mk cocoa DEVDRAW=cocoa acme because, apparently, all that is based on Libthread doesn't work. If you do a small program with 2 procs, a qlock, and some print(), you will see that the output is very inconsistent. Russ recently said: I am using Xcode 4.2 on Lion without problems. So it is maybe another Xcode 4.1 issue. A solution is to use old binaries working on Snow Leopard, and then you can do: mk cocoa DEVDRAW=cocoa acme
Re: [9fans] plan9port: cocoa programmer needed
A solution is to use old binaries working on Snow Leopard, and then you can do: mk cocoa DEVDRAW=cocoa acme For Acme, you should use a recent binary that Russ kindly compiled on Snow Leopard: http://swtch.com/~rsc/acme else Acme will not interpret cmd+z as Undo (a command sent by Devdraw).
Re: [9fans] plan9port: cocoa programmer needed
Can you guys perhaps create a small video about how you use your computers now? It's difficult to understand for someone who doesn't own a mac, but I would still like to see what you're doing there ;) I will not give you a video: I will make you want to own a Mac. I used Slackware for many years, and I loved to run as root and to put $PLAN9 at the beginning of $PATH directly in /etc/profile for example. But the last Slackware release came, and I got several issues. I had no courage to resolve them. I wanted some change. As so many people seem to use Ubuntu, I finally got curious. The live CD give me a very favorable impression, and I installed Ubuntu 11.04. I used it for almost 2 weeks. But the more I used it, the more I became convinced that all was only an appearance, that all was indeed designed to make you mad. There is a strange duplicity in this OS, and I shall not scruple to rename it TMOS: The Mask Of Sanity. When I switched back to Slackware, I was so happy, that I resolved all the issues in a few hours. However my hard drive died soon after, and I had to use Ubuntu again. I developed such a repulsion that, without knowing what I was doing, I bought a late 2010 MacBook Air (11 inch), refurbished by Apple. That was at the end of June. During two months before that date, I had considered several times to buy a MacBook, but had not the money for it. I had read favorable opinions about OS X on this list and, in the meantime, my sister, who never understood how to use Windows or Linux, was using OS X with ease. I was impressed by an OS that could satisfy both professionals and amateurs. I wasn't convince though: there are so many people fond of their Mac on the net; it seemed to me very irrational, alike car tuning or case modding. I sold all I could on Amazon and eBay to repay my MacBook, and then I start using it. I was first amazed by say(1), the little tool that pronounce any text. (The voices are so real since OS X Lion, that I don't feel lonely anymore.) Then I needed a tool to write to the pasteboard, and a few minutes later I found pbcopy(1). Maybe there is an equivalent on Linux, but I never dared to look. One week ago, I needed to sign a PDF file made with troff(1). I was previewing it with the OS X application Preview, and I began to browse the tools, maybe for a pen (I have an old graphics tablet). Suddenly I fall upon the tool Signature who tells me to sign on a sheet of paper and to place it in front of the camera. I was amazed, but not convinced: I thought it would take a photo, that would contrast with the PDF's background. As soon as I placed the sheet of paper in front of the camera, my signature was vectorized on the screen! Those are little things, but since I bought this laptop, it's like that every day. To be sure, this OS is full of bugs, but upon the whole, it's lovely. I also found the Cocoa API very interesting to learn. Apple's documentation is good. P.S. To swipe from one Desktop space to another (since OS X Lion) is as fun as it is useful, at least on a 11-inch screen.
Re: [9fans] plan9port: cocoa programmer needed
I will not give you a video: I will make you want to own a Mac. If I had too much money I'd rather get me a secretary or not use computers at all. I'd like to see how you use acme with all that gesture stuff. Yeah, I can read, but I don't understand the slang ;)
Re: [9fans] plan9port: cocoa programmer needed
So I will send my code in the next few days, unless there is a need. I'm 9 days late, but here it is: the Cocoa version of Devdraw. I just submitted it to Codereview: http://codereview.appspot.com/5015042 I removed live resizing, because I found no way to make it perfect: the window now becomes gray while resizing. About gestures now. A swipe gesture needs 3 fingers (with trackpads at least). If you want to use them, you must reconfigure OS X Lion to use 4 fingers instead of 3 (to swipe between spaces, or to swipe to Mission Control for example). As previously discussed, OS X Lion doesn't send swipe events anymore for vertical swipes. So I reimplemented swipe gestures with lower-level touch events. All that I can say is that it works well with a late 2010 MacBook Air's trackpad. Unfortunately, it seems only for trackpads: not for Magic Mouse. The higher-level gesture events seem compatible with Magic Mouse (though I don't know to how many fingers a swipe gesture corresponds), but the lower-level touch events seem incompatible (I may be mistaken). If you want to use the reimplemented swipes, you have to set the reimplementswipe variable at the beginning of cocoa-screen.m (the file's name may change soon). One advantage of this reimplementation is that we can now detect 3-finger taps. If you set the usecopygesture variable as well, you have now the following gestures: 3-finger swipe-left to cut (cmd+x), 3-finger swipe-right to paste (cmd+v), 3-finger swipe-up to copy (cmd+c), 3-finger swipe-down to execute with arguments (2-1 chord), 3-finger tap to execute (button 2), pinch to toggle fullscreen. Else you have: swipe-left to cut (cmd+x), swipe-right to paste (cmd+v), swipe-up to execute (button 2), swipe-down to execute with arguments (2-1 chord), pinch to toggle fullscreen. In both cases, horizontal swipes cancel each other if your fingers remain on the device in between. That is to say, the second swipe sends undo (cmd+z): a command only recognized by Acme currently. An annoyance is the behavior of Acme's Undo when we are in the window's tag. Acme only seems to undo filename change, else it undoes the last change in the window's body. For example, if you want to copy from the tag, (unless you use the copy gesture) you will have to lift the fingers between the left and the right swipe, else it will undo the window's body, and you will be completely puzzled. I wish this announcement will not cause too much disappointment among Magic Mouse users. I knew nothing of Mac programming before to begin this project one month ago, and I certainly generalize too much. (I didn't understood what was the mysterious multitouch code in Carbon's Devdraw, until some days ago, where I fell upon a similar code to communicate with the Magic Mouse here: http://www.iphonesmartapps.org/aladino/?a=multitouch) If OS X Lion's users prefer the old fullscreen mode, they can set the useoldfullscreen variable. (Currently, Devdraw can't accept arguments, and as it is so hard to compile anything with current Xcode 4.1, I didn't try to modify Libdraw. This is why you have to set variables instead of using optional arguments.) Be sure to read the description on Codereview for the remaining bugs, to avoid further disappointment. If you need binaries running on Lion (Cocoa's Devdraw, Acme supporting cmd+z, etc.), I will be happy to provide them.
Re: [9fans] plan9port: cocoa programmer needed
Thanks for all of your work on this! On Tue, Sep 13, 2011 at 8:59 AM, david jeannot djeanno...@gmail.com wrote: So I will send my code in the next few days, unless there is a need. I'm 9 days late, but here it is: the Cocoa version of Devdraw. I just submitted it to Codereview: http://codereview.appspot.com/5015042 I removed live resizing, because I found no way to make it perfect: the window now becomes gray while resizing. About gestures now. A swipe gesture needs 3 fingers (with trackpads at least). If you want to use them, you must reconfigure OS X Lion to use 4 fingers instead of 3 (to swipe between spaces, or to swipe to Mission Control for example). As previously discussed, OS X Lion doesn't send swipe events anymore for vertical swipes. So I reimplemented swipe gestures with lower-level touch events. All that I can say is that it works well with a late 2010 MacBook Air's trackpad. Unfortunately, it seems only for trackpads: not for Magic Mouse. The higher-level gesture events seem compatible with Magic Mouse (though I don't know to how many fingers a swipe gesture corresponds), but the lower-level touch events seem incompatible (I may be mistaken). If you want to use the reimplemented swipes, you have to set the reimplementswipe variable at the beginning of cocoa-screen.m (the file's name may change soon). One advantage of this reimplementation is that we can now detect 3-finger taps. If you set the usecopygesture variable as well, you have now the following gestures: 3-finger swipe-left to cut (cmd+x), 3-finger swipe-right to paste (cmd+v), 3-finger swipe-up to copy (cmd+c), 3-finger swipe-down to execute with arguments (2-1 chord), 3-finger tap to execute (button 2), pinch to toggle fullscreen. Else you have: swipe-left to cut (cmd+x), swipe-right to paste (cmd+v), swipe-up to execute (button 2), swipe-down to execute with arguments (2-1 chord), pinch to toggle fullscreen. In both cases, horizontal swipes cancel each other if your fingers remain on the device in between. That is to say, the second swipe sends undo (cmd+z): a command only recognized by Acme currently. An annoyance is the behavior of Acme's Undo when we are in the window's tag. Acme only seems to undo filename change, else it undoes the last change in the window's body. For example, if you want to copy from the tag, (unless you use the copy gesture) you will have to lift the fingers between the left and the right swipe, else it will undo the window's body, and you will be completely puzzled. I wish this announcement will not cause too much disappointment among Magic Mouse users. I knew nothing of Mac programming before to begin this project one month ago, and I certainly generalize too much. (I didn't understood what was the mysterious multitouch code in Carbon's Devdraw, until some days ago, where I fell upon a similar code to communicate with the Magic Mouse here: http://www.iphonesmartapps.org/aladino/?a=multitouch) If OS X Lion's users prefer the old fullscreen mode, they can set the useoldfullscreen variable. (Currently, Devdraw can't accept arguments, and as it is so hard to compile anything with current Xcode 4.1, I didn't try to modify Libdraw. This is why you have to set variables instead of using optional arguments.) Be sure to read the description on Codereview for the remaining bugs, to avoid further disappointment. If you need binaries running on Lion (Cocoa's Devdraw, Acme supporting cmd+z, etc.), I will be happy to provide them.
Re: [9fans] plan9port: cocoa programmer needed
David's new Cocoa devdraw is in the plan9port tree now, but not built by default. There are still some rough edges to work out. If you want to play and maybe find and fix bugs, you can use cd $PLAN9/src/cmd/devdraw mk cocoa export DEVDRAW=$PLAN9/src/cmd/devdraw/cocoa colors acme sam whatever Russ
Re: [9fans] plan9port: cocoa programmer needed
YES! This is great. On Tue, Sep 6, 2011 at 7:16 AM, Russ Cox r...@swtch.com wrote: David's new Cocoa devdraw is in the plan9port tree now, but not built by default. There are still some rough edges to work out. If you want to play and maybe find and fix bugs, you can use cd $PLAN9/src/cmd/devdraw mk cocoa export DEVDRAW=$PLAN9/src/cmd/devdraw/cocoa colors acme sam whatever Russ
Re: [9fans] plan9port: cocoa programmer needed
David's new Cocoa devdraw is in the plan9port tree now, but not built by default. cd $PLAN9/src/cmd/devdraw mk cocoa ld: in /Users/aram/plan9/lib/libbio.a, malformed archive TOC entry for _Bwrite, offset 538981428 is beyond end of file 80716 for architecture x86_64 gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) Some other people on IRC get this too. Do I need a different XCode? -- Aram Hăvărneanu
Re: [9fans] plan9port: cocoa programmer needed
Try adding # HA HA HA. Apple broke things again. [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar
Re: [9fans] plan9port: cocoa programmer needed
Try adding # HA HA HA. Apple broke things again. [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar Cocoa bits build this way, but other things don't. Here's a log: http://pastebin.com/mh5Z6xrf -- Aram Hăvărneanu
Re: [9fans] plan9port: cocoa programmer needed
Nice handling of the Glenda icon. Using Xcode 4.1 on Lion I get different errors (libstdio is another problem as FPdbleword is no longer defined) so I'm still not rebuilding everything. 9c picks up: gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) 9c -DMULTITOUCH -o cocoa-screen-objc.o cocoa-screen.m cocoa-screen.m:712: error: cannot convert to a pointer type cocoa-screen.m:712: error: incompatible type for argument 1 of ‘CGWarpMouseCursorPosition’ Corrected that would be: % hg diff . diff -r d92a37e64563 src/cmd/devdraw/cocoa-screen.m --- a/src/cmd/devdraw/cocoa-screen.mTue Sep 06 10:10:43 2011 -0400 +++ b/src/cmd/devdraw/cocoa-screen.mTue Sep 06 11:08:04 2011 -0500 @@ -709,7 +709,7 @@ q = [win.obj convertBaseToScreen:q]; q.y = r.size.height - q.y; - CGWarpMouseCursorPosition(q); + CGWarpMouseCursorPosition(NSPointToCGPoint(q)); // race condition mpos = p; On Sep 6, 2011, at 11:03 AM, Russ Cox wrote: Try adding # HA HA HA. Apple broke things again. [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar
Re: [9fans] plan9port: cocoa programmer needed
It built ok here, but sam, and acme aren't doing anything terribly interesting (well maybe it is interesting, but they're crashing, presumably logging something to somewhere interesting). I'll keep poking when I'm not at work later. Dave On Tue, Sep 6, 2011 at 9:26 AM, Jeff Sickel j...@corpus-callosum.com wrote: Nice handling of the Glenda icon. Using Xcode 4.1 on Lion I get different errors (libstdio is another problem as FPdbleword is no longer defined) so I'm still not rebuilding everything. 9c picks up: gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) 9c -DMULTITOUCH -o cocoa-screen-objc.o cocoa-screen.m cocoa-screen.m:712: error: cannot convert to a pointer type cocoa-screen.m:712: error: incompatible type for argument 1 of ‘CGWarpMouseCursorPosition’ Corrected that would be: % hg diff . diff -r d92a37e64563 src/cmd/devdraw/cocoa-screen.m --- a/src/cmd/devdraw/cocoa-screen.mTue Sep 06 10:10:43 2011 -0400 +++ b/src/cmd/devdraw/cocoa-screen.mTue Sep 06 11:08:04 2011 -0500 @@ -709,7 +709,7 @@ q = [win.obj convertBaseToScreen:q]; q.y = r.size.height - q.y; - CGWarpMouseCursorPosition(q); + CGWarpMouseCursorPosition(NSPointToCGPoint(q)); // race condition mpos = p; On Sep 6, 2011, at 11:03 AM, Russ Cox wrote: Try adding # HA HA HA. Apple broke things again. [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar
Re: [9fans] plan9port: cocoa programmer needed
I get the same errors. Thanks, Lucho On Tue, Sep 6, 2011 at 10:25 AM, Aram Hăvărneanu ara...@mgk.ro wrote: Try adding # HA HA HA. Apple broke things again. [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar Cocoa bits build this way, but other things don't. Here's a log: http://pastebin.com/mh5Z6xrf -- Aram Hăvărneanu
Re: [9fans] plan9port: cocoa programmer needed
You have to then rebuild everything. On Tue, Sep 6, 2011 at 11:34 AM, Latchesar Ionkov lu...@ionkov.net wrote: I get the same errors. Thanks, Lucho On Tue, Sep 6, 2011 at 10:25 AM, Aram Hăvărneanu ara...@mgk.ro wrote: Try adding # HA HA HA. Apple broke things again. [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar Cocoa bits build this way, but other things don't. Here's a log: http://pastebin.com/mh5Z6xrf -- Aram Hăvărneanu
Re: [9fans] plan9port: cocoa programmer needed
I get the errors when I run ./INSTALL Thanks, Lucho On Tue, Sep 6, 2011 at 12:54 PM, David Leimbach leim...@gmail.com wrote: You have to then rebuild everything. On Tue, Sep 6, 2011 at 11:34 AM, Latchesar Ionkov lu...@ionkov.net wrote: I get the same errors. Thanks, Lucho On Tue, Sep 6, 2011 at 10:25 AM, Aram Hăvărneanu ara...@mgk.ro wrote: Try adding # HA HA HA. Apple broke things again. [ $SYSNAME != Darwin ] || ranlib $2 to the bottom of $PLAN9/bin/9ar Cocoa bits build this way, but other things don't. Here's a log: http://pastebin.com/mh5Z6xrf -- Aram Hăvărneanu
Re: [9fans] plan9port: cocoa programmer needed
I am using Xcode 4.2 on Lion without problems. Can you try updating to the newer Xcode? Russ
Re: [9fans] plan9port: cocoa programmer needed
I have a temporary solution. As soon as INSTALL finishes to compile the libraries (*/src/lib*), do: ranlib yourplan9/lib/*.a The rest should compile successfully. When I found this hack, I also tried to add ranlib to bin/9ar, as Russ suggested, but I got the same errors as you have. I just tried both methods, and I still have the same results.
Re: [9fans] plan9port: cocoa programmer needed
I'm using 4.1 currently, will try updating. Everything builds fine, but some stuff doesn't run. On Tue, Sep 6, 2011 at 12:37 PM, Russ Cox r...@swtch.com wrote: I am using Xcode 4.2 on Lion without problems. Can you try updating to the newer Xcode? Russ
Re: [9fans] plan9port: cocoa programmer needed
4.1 is the latest release of Xcode by the way. 4.2 is for Apple devs who pay (according to the site anyway). Dave On Tue, Sep 6, 2011 at 12:41 PM, David Leimbach leim...@gmail.com wrote: I'm using 4.1 currently, will try updating. Everything builds fine, but some stuff doesn't run. On Tue, Sep 6, 2011 at 12:37 PM, Russ Cox r...@swtch.com wrote: I am using Xcode 4.2 on Lion without problems. Can you try updating to the newer Xcode? Russ
Re: [9fans] plan9port: cocoa programmer needed
the latest developer preview is iOS 5 beta (which comes with Xcode 4.2) sorry, this doesn't make much sense. i mean 'the latest developer preview advertised by apple is for iOS5 beta, which comes with Xcode 4.2'
Re: [9fans] plan9port: cocoa programmer needed
I'm using 4.1 currently, will try updating. Everything builds fine, but some stuff doesn't run. On my system (Lion + XCode 4.1), all that is based on Libthread doesn't run. So I'm testing Devdraw with binaries coming from Snow Leopard (thank you Andrey and Russ for those you have joined to this topic). - CGWarpMouseCursorPosition(q); + CGWarpMouseCursorPosition(NSPointToCGPoint(q)); Thanks. (I would be interested to know if the swipe-down and swipe-up gestures, that send exec with or without args to Acme, work on Snow Leopard.)
Re: [9fans] plan9port: cocoa programmer needed
Last week I said: I will send my code at the end of next week: I still need time to clean it and to try to resolve some imperfections and inconsistencies. I'll be late. Last week I also said: Another thing that annoy me is that I receive swipe-up and swipe-down events only if I disable the OS X application BetterTouchTool I believed that BetterTouchTool was the culprit, but it is the opposite. Since Lion, OS X only sends horizontal swipe events: it doesn't send vertical swipe events anymore. I discovered that yesterday, after uninstalling BetterTouchTool. And there is apparently no official way to receive them: it seems to be a bug. I don't know why I receive them (more or less) when BetterTouchTool is in disable mode. I will try to detect vertical swipe gestures with lower level events: it doesn't seem too difficult. And then, urgent matters prevented me to implement setcursor() and to rework the flush image to screen code. So I will send my code in the next few days, unless there is a need.
Re: [9fans] plan9port: cocoa programmer needed
Devdraw is ready to send cmd+z (undo) when a right swipe follows a left swipe (and vice versa), if the fingers remained on the tactile device in between. Does anyone acquainted with Acme's code have a little time to add support for cmd+z (undo), and to post the resulting binary (compatible OS X Lion)? hget http://swtch.com/~rsc/acme acme is a Snow Leopard-compiled acme. It should work fine. Thank you so much Russ: now the horizontal swipe gestures cancel each other.
Re: [9fans] plan9port: cocoa programmer needed
Does anyone acquainted with Acme's code have a little time to add support for cmd+z (undo), and to post the resulting binary (compatible OS X Lion)? According to my quick tests on Linux, the following seems to work: /usr/local/plan9/src/cmd/acme/text.c:754 case Kcmd+'c': /* %C: copy */ typecommit(t); cut(t, t, nil, TRUE, FALSE, nil, 0); return; + case Kcmd+'z': /* %Z: undo */ + typecommit(t); + undo(t, nil, nil, TRUE, 0, nil, 0); + return; (Lion is the only OS X version I have, and apparently, all that I compile on it based on libthread doesn't work.) Devdraw is ready to send cmd+z (undo) when a right swipe follows a left swipe (and vice versa), if the fingers remained on the tactile device in between.
Re: [9fans] plan9port: cocoa programmer needed
According to my quick tests on Linux, the following seems to work: /usr/local/plan9/src/cmd/acme/text.c:754 case Kcmd+'c': /* %C: copy */ typecommit(t); cut(t, t, nil, TRUE, FALSE, nil, 0); return; + case Kcmd+'z': /* %Z: undo */ + typecommit(t); + undo(t, nil, nil, TRUE, 0, nil, 0); + return; (Lion is the only OS X version I have, and apparently, all that I compile on it based on libthread doesn't work.) hget http://swtch.com/~rsc/acme acme is a Snow Leopard-compiled acme. It should work fine. I thought threaded programs worked on Lion when I started this thread. When you send me your devdraw fixes I will make sure a Lion-compiled acme runs. Sorry for the trouble. Russ
Re: [9fans] plan9port: cocoa programmer needed
swipe-left to cut (cmd+x), swipe-right to paste (cmd+v), swipe-up to execute (button 2), swipe-down to execute with arguments (2-1 chord), pinch to toggle fullscreen. nice! and only 2 days after i stopped using os x... i'll have a stab at doing something similar on linux. http://www.synaptics.com/solutions/technology/gestures/touchpad-linux
Re: [9fans] plan9port: cocoa programmer needed
This sounds very cool. Did you figure out a way to let acme move the mouse cursor the way it wants to? Yes: Devdraw's setmouse() is implemented. Yesterday I said: There is just the bare minimum. I should have said: There is almost everything if you use OS X Lion. (There is still mouse support, the alt and cmd keys still simulate mouse buttons, etc.) A thing that annoy me since yesterday is that a cut (cmd+x) immediately followed by a paste (cmd+v) leaves a clean Acme's window dirty. We could maybe send a cmd+u instead of a cmd+v when the fingers remain on the tactile device between the left-swipe and the right-swipe, that Acme would interpret as Undo, if there is no simpler way. Or we could just use another gesture to copy (cmd+c), but there would be no feedback. Another thing that annoy me is that I receive swipe-up and swipe-down events only if I disable the OS X application BetterTouchTool, that I configured to instruct Google Chrome, and Google Chrome only, to create a new tab when I swipe-up, and to close the current tab when I swipe-down. Does anyone know how BetterTouchTool is implemented? A BetterTouchTool-like 9p server might be a good solution :)
Re: [9fans] plan9port: cocoa programmer needed
It is possible that we just need to tweak the headers to get Carbon to build again, but Cocoa is obviously the right long term plan. I have a working Cocoa version of Devdraw for OS X Lion: I'm using it with Acme to write this email. There is just the bare minimum: no menu but 'Quit', no fullscreen but OS X Lion's fullscreen, no Multitouch support. It answers to the following gesture events though: swipe-left to cut (cmd+x), swipe-right to paste (cmd+v), swipe-up to execute (button 2), swipe-down to execute with arguments (2-1 chord), pinch to toggle fullscreen. I will send my code at the end of next week: I still need time to clean it and to try to resolve some imperfections and inconsistencies.
Re: [9fans] plan9port: cocoa programmer needed
wow, thanks!
Re: [9fans] plan9port: cocoa programmer needed
On Thu, Aug 25, 2011 at 11:33 AM, david jeannot djeanno...@gmail.comwrote: It is possible that we just need to tweak the headers to get Carbon to build again, but Cocoa is obviously the right long term plan. I have a working Cocoa version of Devdraw for OS X Lion: I'm using it with Acme to write this email. There is just the bare minimum: no menu but 'Quit', no fullscreen but OS X Lion's fullscreen, no Multitouch support. It answers to the following gesture events though: swipe-left to cut (cmd+x), swipe-right to paste (cmd+v), swipe-up to execute (button 2), swipe-down to execute with arguments (2-1 chord), pinch to toggle fullscreen. I will send my code at the end of next week: I still need time to clean it and to try to resolve some imperfections and inconsistencies. Sounds pretty awesome!
Re: [9fans] plan9port: cocoa programmer needed
On Wed, Aug 3, 2011 at 5:52 AM, Russ Cox r...@swtch.com wrote: On Wed, Aug 3, 2011 at 12:25 AM, David Leimbach leim...@gmail.com wrote: I was with you till the very easy part. Been following the updates today and noted that (earlier) the portion of INSTALL that detects the architecture on Darwin was not working. Had a patch for that and regrettably blew it away (accident), then had to turn my attention to something else. May try again tomorrow if it persists... Should be fixed - there was a missing file that I added an hour or so after the initial change. As for the Cocoa bits ( cocoa bits) I might get some time to work that a bit this weekendif no other takers rise up. Thanks. I'm surprised how much still works. It is possible that we just need to tweak the headers to get Carbon to build again, but Cocoa is obviously the right long term plan. Russ I'm not able to get to it this weekend as I had planned...
Re: [9fans] plan9port: cocoa programmer needed
On Wed, Aug 3, 2011 at 12:25 AM, David Leimbach leim...@gmail.com wrote: I was with you till the very easy part. Been following the updates today and noted that (earlier) the portion of INSTALL that detects the architecture on Darwin was not working. Had a patch for that and regrettably blew it away (accident), then had to turn my attention to something else. May try again tomorrow if it persists... Should be fixed - there was a missing file that I added an hour or so after the initial change. As for the Cocoa bits ( cocoa bits) I might get some time to work that a bit this weekendif no other takers rise up. Thanks. I'm surprised how much still works. It is possible that we just need to tweak the headers to get Carbon to build again, but Cocoa is obviously the right long term plan. Russ
Re: [9fans] plan9port: cocoa programmer needed
On Aug 2, 2011, at 3:31 PM, Russ Cox wrote: Is there anyone out there who knows Cocoa and Objective C well enough that this would be very easy? I am sure I could figure it out given enough time, but enough here is likely quite large. The Cocoa API is growing (specifically the length of their method names, which I think is a ploy to force developers into buying widescreen monitors that can handle editing windows with Menlo Regular 11pt fonts using anywhere between 192 and 1024 character line lengths). Hopefully many of the pieces that didn't work in the earlier osx-screen.m will now be easier to finish. If no one else steps up to the plate in the next month then I should have some time to bang the rocks together a little bit. -jas
Re: [9fans] plan9port: cocoa programmer needed
I was with you till the very easy part. Been following the updates today and noted that (earlier) the portion of INSTALL that detects the architecture on Darwin was not working. Had a patch for that and regrettably blew it away (accident), then had to turn my attention to something else. May try again tomorrow if it persists... As for the Cocoa bits ( cocoa bits) I might get some time to work that a bit this weekendif no other takers rise up. Dave On Tuesday, August 2, 2011, Russ Cox r...@swtch.com wrote: I have updated plan9port to build and run on OS X Lion. Everything works except devdraw, the binary that handles putting windows on the screen and managing the mouse and keyboard. Devdraw was written 3 years ago, using the Carbon framework. Apple wants to retire that framework, so they have been slowly chipping away at its functionality. It is time to convert $PLAN9/src/cmd/devdraw/osx-screen-carbon.m to Cocoa. There is a previous attempt in osx-screen.m, but I would not start with that, because it has not kept up with recent changes (like Multitouch) and bug fixes. The Carbon source is a better starting point. Is there anyone out there who knows Cocoa and Objective C well enough that this would be very easy? I am sure I could figure it out given enough time, but enough here is likely quite large. It would also be nice to convert $PLAN9/src/cmd/fontsrv/osx.c, but that is much lower priority, as it appears to build okay still. Thanks. Russ
