cocoa devdraw

cocoa devdraw

[Russ Cox]

Thanks to heroic effort by David Jeannot,
there is a new Cocoa-based OS X devdraw that
seems to work well enough that I made it the
default even on Snow Leopard.

If you do the usual hg pull -u; ./INSTALL you'll get it.

I think the only pending Lion issue now is that
people using Xcode 4.1 don't have working threads.
I haven't tracked that down yet.  I suspect the
getcontext/setcontext routines in that Xcode are
just broken.

Russ

Re: [9fans] cocoa devdraw

[Anthony Sorace]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]


On Sep 26, 2011, at 12:34 PM, Russ Cox wrote:

> I think the only pending Lion issue now is that
> people using Xcode 4.1 don't have working threads.
> I haven't tracked that down yet.  I suspect the
> getcontext/setcontext routines in that Xcode are
> just broken.

Do you have reason to believe this is a Lion issue? I'm running
Xcode 4.1 on Snow Leopard and libthread is buggered for me,
as well (I don't currently have a Lion system to confirm it's
buggered in the same way).


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 210 bytes --]

Re: [9fans] cocoa devdraw

[Russ Cox]

On Mon, Sep 26, 2011 at 3:23 PM, Anthony Sorace <a@9srv.net> wrote:
> Do you have reason to believe this is a Lion issue? I'm running
> Xcode 4.1 on Snow Leopard and libthread is buggered for me,
> as well (I don't currently have a Lion system to confirm it's
> buggered in the same way).

No, I believe it is an Xcode 4.1 issue.
However, I don't know how to obtain
Xcode 4.1 for Snow Leopard, only Lion.
How did you get it?

Russ

Re: [9fans] cocoa devdraw

[Jeff Sickel]

On Sep 26, 2011, at 2:47 PM, Russ Cox wrote:

> On Mon, Sep 26, 2011 at 3:23 PM, Anthony Sorace <a@9srv.net> wrote:
>> Do you have reason to believe this is a Lion issue? I'm running
>> Xcode 4.1 on Snow Leopard and libthread is buggered for me,
>> as well (I don't currently have a Lion system to confirm it's
>> buggered in the same way).
> 
> No, I believe it is an Xcode 4.1 issue.
> However, I don't know how to obtain
> Xcode 4.1 for Snow Leopard, only Lion.
> How did you get it?

I believe Xcode 4.1 has been out since an iOS 4.x release.  Xcode
4.2 is still in beta as it is bundled with iOS 5 beta.  There is
a strong chance that the gnu toolchain in that release could our
culprit, akin to Russ' suspect of getcontext/setcontext.  It may
also be that the 4.1 release was the first one where llvm-gcc was
also an option.  My other build issue is in libstdio:

% 9c -v dtoa.c
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
 /usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/cc1 -quiet -v -I/usr/local/plan9/include -imultilib x86_64 -iprefix /usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/ -dD -D__DYNAMIC__ -DPLAN9PORT dtoa.c -fPIC -quiet -dumpbase dtoa.c -mmacosx-version-min=10.7.1 -m64 -mtune=core2 -auxbase dtoa -g3 -O2 -Wall -Wno-parentheses -Wno-missing-braces -Wno-switch -Wno-comment -Wno-sign-compare -Wno-unknown-pragmas -version -fno-omit-frame-pointer -o /var/folders/bl/0lxz1p188xl3x1006s6bjlhh0000gn/T//cc8g6Ba2.s
ignoring nonexistent directory "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
ignoring nonexistent directory "/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/plan9/include
 /usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/include
 /usr/local/include
 /Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) (i686-apple-darwin11)
	compiled by GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=65536
Compiler executable checksum: edef36ecca2ce3f93d0f78610b5af911
dtoa.c:491: error: ‘FPdbleword’ undeclared
dtoa.c:491: error: expected expression before ‘)’ token
dtoa.c:492: error: expected expression before ‘)’ token
dtoa.c:493: error: expected expression before ‘)’ token
...

Re: cocoa devdraw

[David Leimbach]

Ucontext stuff was being deprecated in Leopard was my understanding and that support for it would be shoddy.

Time to roll our own?  Didn't you already do this?

Thanks also to David!

Sent from my iPhone

On Sep 26, 2011, at 9:34 AM, Russ Cox <rsc@swtch.com> wrote:

> Thanks to heroic effort by David Jeannot,
> there is a new Cocoa-based OS X devdraw that
> seems to work well enough that I made it the
> default even on Snow Leopard.
> 
> If you do the usual hg pull -u; ./INSTALL you'll get it.
> 
> I think the only pending Lion issue now is that
> people using Xcode 4.1 don't have working threads.
> I haven't tracked that down yet.  I suspect the
> getcontext/setcontext routines in that Xcode are
> just broken.
> 
> Russ

Re: [9fans] cocoa devdraw

[Anthony Sorace]

> How did you get it?

Yes, as Jeff suggested, I got it through the iOS developer channel.

Re: cocoa devdraw

[Russ Cox]

On Mon, Sep 26, 2011 at 4:10 PM, David Leimbach <leimy2k@gmail.com> wrote:
> Ucontext stuff was being deprecated in Leopard was my understanding and that support for it would be shoddy.
>
> Time to roll our own?  Didn't you already do this?

I did for many systems, and even did for Lion,
but then I tried the system ones and they worked well
(with Xcode 4.2).

Oh well.

Russ

Re: [9fans] cocoa devdraw

[Michaelian Ennis]

I'm seeing missing recipes.  Lion and XCode 4.2

ian

* Resetting /Users/mennis/src/plan9port/config
* Compiler version:
	gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
* Running on Darwin: checking architecture...
	x86-64 found.
* Building mk...
* Building everything (be patient)...
>>> cd /Users/mennis/src/plan9port/src/cmd/fontsrv; mk all
9c  main.c
mk: no recipe to make 'osx-cocoa.o'
>>> cd /Users/mennis/src/plan9port/src/cmd/snarfer; mk all
9l -o o.snarfer osx-cocoa-snarfer.o
ld: warning: directory not found for option '-L/usr/X11R6/lib64'
* Installing everything in /Users/mennis/src/plan9port/bin...
>>> cd /Users/mennis/src/plan9port/src/cmd/devdraw; mk install
9c -DOSX_VERSION=100702 macargv.c
macargv.c:12: warning: passing argument 3 of ‘AEInstallEventHandler’
from incompatible pointer type
macargv.c:13: warning: implicit declaration of function
‘RunApplicationEventLoop’
macargv.c:24: warning: implicit declaration of function ‘FSpMakeFSRef’
macargv.c:30: warning: implicit declaration of function ‘FSMakeFSSpec’
macargv.c:30: error: ‘FSSpec’ has no member named ‘vRefNum’
macargv.c:30: error: ‘FSSpec’ has no member named ‘parID’
macargv.c:45: error: ‘FSSpec’ has no member named ‘name’
macargv.c:49: error: ‘FSSpec’ has no member named ‘name’
macargv.c:83: error: ‘typeFSS’ undeclared
mk: 9c -DOSX_VERSION=100702 macargv.c  : exit status=exit(1)
>>> mk: no recipe to make 'osx-cocoa.o'
>>> cd /Users/mennis/src/plan9port/src/cmd/snarfer; mk install
9l -o o.snarfer osx-cocoa-snarfer.o
ld: warning: directory not found for option '-L/usr/X11R6/lib64'
* Cleaning up...
* Renaming hard-coded /usr/local/plan9 paths...
* Building web manual...
* Done.

Re: [9fans] cocoa devdraw

[Micah Stetson]

> I'm seeing missing recipes.  Lion and XCode 4.2

I get nearly identical output on Snow Leopard with XCode 4.0.2 (see below).

BUT if I manually copy o.devdraw from $PLAN9/src/cmd/devdraw to
$PLAN9/bin/devdraw, nearly everything seems to work. The best part
(for me) is that now my acme and 9term windows work with Divvy!
Huzzah!

One downside: Dragging with the middle button down no longer seems to
work right when I have MagicPrefs enabled. It works fine without
MagicPrefs, but I can't middle drag with my Magic Mouse in Google
SketchUp without MagicPrefs. Oh well, I can turn it on and off as
needed.

Thanks to everybody who's worked on this,

Micah

(./INSTALL output below)

* Resetting /usr/local/plan9/config
* Compiler version:
	gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
* Running on Darwin: checking architecture...
	x86-64 found.
* Building everything (be patient)...
>>> cd /usr/local/plan9/src/cmd/fontsrv; mk all
9c  main.c
mk: no recipe to make 'osx-cocoa.o'
>>> cd /usr/local/plan9/src/cmd/snarfer; mk all
9l -o o.snarfer osx-cocoa-snarfer.o
ld: warning: directory not found for option '-L/usr/X11R6/lib64'
* Installing everything in /usr/local/plan9/bin...
>>> cd /usr/local/plan9/src/cmd/devdraw; mk install
9c -DOSX_VERSION=100608 macargv.c
macargv.c:12: warning: passing argument 3 of 'AEInstallEventHandler'
from incompatible pointer type
macargv.c:13: warning: implicit declaration of function
'RunApplicationEventLoop'
macargv.c:24: warning: implicit declaration of function 'FSpMakeFSRef'
macargv.c:30: warning: implicit declaration of function 'FSMakeFSSpec'
macargv.c:30: error: 'FSSpec' has no member named 'vRefNum'
macargv.c:30: error: 'FSSpec' has no member named 'parID'
macargv.c:45: error: 'FSSpec' has no member named 'name'
macargv.c:49: error: 'FSSpec' has no member named 'name'
macargv.c:83: error: 'typeFSS' undeclared
mk: 9c -DOSX_VERSION=100608 macargv.c  : exit status=exit(1)
>>> mk: no recipe to make 'osx-cocoa.o'
>>> cd /usr/local/plan9/src/cmd/snarfer; mk install
9l -o o.snarfer osx-cocoa-snarfer.o
ld: warning: directory not found for option '-L/usr/X11R6/lib64'
* Cleaning up...
* Renaming hard-coded /usr/local/plan9 paths...
* Building web manual...
* Done.
	
* Add these to your profile environment.
	PLAN9=/usr/local/plan9 export PLAN9
	PATH=$PATH:$PLAN9/bin export PATH

[9fans] cocoa devdraw

[Skip Tavakkolian]

I tried what mauris eriksen suggested (drop -O2 in 9c) and it now
compiles with Xcode 4.1 as well.

A big Thank You to all involved!

-Skip

On Mon, Sep 26, 2011 at 9:34 AM, Russ Cox <rsc at swtch.com> wrote:
> Thanks to heroic effort by David Jeannot,
> there is a new Cocoa-based OS X devdraw that
> seems to work well enough that I made it the
> default even on Snow Leopard.
>
> If you do the usual hg pull -u; ./INSTALL you'll get it.
>
> I think the only pending Lion issue now is that
> people using Xcode 4.1 don't have working threads.
> I haven't tracked that down yet. ?I suspect the
> getcontext/setcontext routines in that Xcode are
> just broken.
>
> Russ
>
>