Re: [Chicken-users] Cocoa Bridge and Chicken gui repl
On Dec 3, 2007, at 9:37 AM, Thomas Christian Chust wrote: I would deem it highly unlikely that the Carbon API will be deprecated any time soon: Fundamentally, Apple engineering is focused on Cocoa much more than Carbon, and Apple's engineering management made the decision to un- support 64-bit Carbon to emphasize that fact. - Eric Schlegel, Apple from: http://www.carbondev.com/site/?page=64-bit+Carbon IOW, Apple has already deprecated Carbon on 64-bit platforms. The Carbon GUI libs are not present in 64-bit Leopard. Apple will certainly keep large portions of what were formerly known as Carbon (i.e., the non-GUI parts) because even parts of Cocoa rely on these as well. But going forward (i.e., when everything is 64-bit), you simply won't be able to do GUIs using Carbon - Apple isn't porting the Carbon GUI libs to 64-bit. regards, Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: MacOS X is its' own beast
On May 16, 2007, at 3:55 AM, Thomas Christian Chust wrote: But I would consider the Mach interfaces internal API and only the BSD, Carbon and Cocoa interfaces public API, because it would be pretty tedious to write anything useful using only the Mach interfaces and because otherwise I also would have to claim that Carbon and Cocoa are not native APIs on MacOS X but rather compatibility layers for MacOS =9 and OpenStep just like the BSD subsystem is a compatibility layer for other UNIX flavors. This is really just a matter of marketing. Apple now considers Mac OS X Unix and considers BSD and X11 core OS components: http://developer.apple.com/documentation/MacOSX/Conceptual/ OSX_Technology_Overview/SystemTechnology/chapter_4_section_2.html#// apple_ref/doc/uid/TP40001067-CH207-TPXREF101 but those who have been using Mac OS X since the first releases remember that the BSD subsystem used to be an *optional* install in early versions of Mac OS X. There were many early Mac OS X machines which had no BSD subsystem on them at all. Similarly, Apple lists Java support in the Core OS section, presumably because that document: http://developer.apple.com/documentation/MacOSX/Conceptual/ OSX_Technology_Overview/SystemTechnology/chapter_4_section_2.html#// apple_ref/doc/uid/TP40001067-CH207-BCIEHIBD was first written when Apple was at pains to give the appearance that Mac OS X was a great platform for doing Java development. But this more recent diagram shows Java (probably more properly) as a much higher level Application Framework on their System Architecture page, no doubt because Apple no longer cares nearly as much about marketing Mac OS as a Java platform: http://developer.apple.com/macosx/architecture/index.html The reality (as seen in chapter 2 of Amit Singh's Mac OS X Internals) is that everything is built more or less in layers: Hardware Firmware Kernel Mach BSD Core Services and JVM Graphics/Multimedia (OpenGL, Quartz, Core Audio, Core MIDI, QuickTime) Application Environments (Classic, X11, Carbon, Cocoa, WebObject, Quicktime, Java AWT, Swing) GUI (Aqua) Apple considers all of Core Services/Carbon, Cocoa, and Quicktime (but not Java) to be native APIs. Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On May 15, 2007, at 3:06 AM, Peter Keller wrote: Unfortunately, the real world for UNIX basically works on linux and solaris. Solaris gets this right far more than you could imagine, linux couldn't care less if they got it right. Since the title of this thread is Mac OS X static library names it's worth noting that Mac OS X is UNIX, and Mac OS X really does care about getting this right, and, in my experience, does. This is one of the reasons that static linking is deprecated on Mac OS X- the OS vendor goes to great lengths to assure that dynamic library upgrades are backwards compatible for that OS version. regards, Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Mac OS X static library names
On May 12, 2007, at 11:36 PM, Brandon Van Every wrote: Do Mac OS X users think this is worth doing? I personally do not think it worth doing. Ideally any application that used chicken would distribute the necessary .dylib files with the app, either as a framework for user level or system wide installation, or as part of the application bundle itself. In either case, having this component be a pluggable dynamic library would allow kinds of of application updates - those where chicken itself or some egg the app used was updated - by simply replacing this framework or library rather than replacing the whole application. This of course becomes even more convenient if there are several applications that use the chicken framework or library. Basically it comes down to the fact that modern Mac OS X applications are really directories with lots of components in them, not monolithic files. This being the case it makes more sense to use dynamic linking. At a higher level (politically speaking) I've found over the years that doing things that are deprecated by Apple is a good way to get burned down the road. regards, Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] syntax-case macros as extensions?
On Mar 8, 2007, at 5:28 AM, felix winkelmann wrote: Then you have to make those macros available at _compile-time_, or the compiler will not see them. (require ...) loads code at run-time, not at compile-time. Try require-for-syntax. A somewhat related question: I have some macros that are defined with define-syntax using the syntax-case extension. I can't seem to make these macros into an extension that is usable at runtime in csi. I can load the .scm file just fine, and then the macros work in csi, but If I try to compile these into an extension, when I load it I get unbound variable errors. Here's a simple example: --- dotimes.scm - (require-for-syntax 'syntax-case) (define-syntax dotimes (syntax-rules () ((dotimes (var limit) e ...) (let loop ((var 0)) (if ( var limit) (begin e ... (loop (+ 1 var -- end dotimes.scm ;;; I suspect that I'm not quite doing the right thing in this setup file -- dotimes.setup --- (compile -s dotimes.scm) (install-extension 'dotimes dotimes.so '((syntax) (require-at-runtime syntax-case))) - end dotimes.setup --- ;; when simply loaded, dotimes.scm works as expected: // / ___ (______ ( ___ ___ || )| ||___)|___)| ) |__ | / | |__ | \ |__ | / Version 2.6 - macosx-unix-gnu-x86 - [ libffi dload ptables applyhook ] (c)2000-2007 Felix L. Winkelmann #;1 (load /scheme/dotimes.scm) ; loading /scheme/dotimes.scm ... ; loading /usr/local/lib/chicken/1/syntax-case.so ... ; loading /usr/local/lib/chicken/1/syntax-case-chicken-macros.scm ... #;2 (dotimes (n 10) (display n)) 0123456789 ;; when required-for-syntax or used as an extension, it throws an unbound variable error: // / ___ (______ ( ___ ___ || )| ||___)|___)| ) |__ | / | |__ | \ |__ | / Version 2.6 - macosx-unix-gnu-x86 - [ libffi dload ptables applyhook ] (c)2000-2007 Felix L. Winkelmann #;1 (require-for-syntax 'dotimes) ; loading /usr/local/lib/chicken/1/dotimes.so ... ; loading /usr/local/lib/chicken/1/syntax-case.so ... ; loading /usr/local/lib/chicken/1/syntax-case-chicken-macros.scm ... #;2 (dotimes (n 10) (display n)) Error: unbound variable: n Call history: syntax (dotimes (n (quote 10)) (display n)) syntax (n (quote 10)) syntax (quote 10) syntax (display n) eval(dotimes (n (quote 10)) (display n)) eval(n (quote 10)) -- ;; same with require-extension instead of require-for-syntax: // / ___ (______ ( ___ ___ || )| ||___)|___)| ) |__ | / | |__ | \ |__ | / Version 2.6 - macosx-unix-gnu-x86 - [ libffi dload ptables applyhook ] (c)2000-2007 Felix L. Winkelmann #;1 (require-extension dotimes) ; loading /usr/local/lib/chicken/1/dotimes.so ... ; loading /usr/local/lib/chicken/1/syntax-case.so ... ; loading /usr/local/lib/chicken/1/syntax-case-chicken-macros.scm ... #;2 (dotimes (n 10) (display n)) Error: unbound variable: n Call history: syntax (dotimes (n (quote 10)) (display n)) syntax (n (quote 10)) syntax (quote 10) syntax (display n) eval(dotimes (n (quote 10)) (display n)) eval(n (quote 10)) -- Any idea what I'm doing wrong in the setup? regards, Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OS X binary
On May 15, 2006, at 2:53 AM, felix winkelmann wrote: I've put together a binary of chicken 2.311. ppc? intel? universal? TIA Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken on OS X
On May 2, 2006, at 2:07 AM, felix winkelmann wrote: You don't really need libffi to run the basic chicken (and if you install it from sources), but you will need it for developing cocoa-apps with the objc bridge. Does anybody know of a version of libffi that will compile on intel Macs? configure spits this out with the version I have: configure: error: libffi has not been ported to i686-apple- darwin8.6.1. TIA Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Question
On Dec 29, 2005, at 8:41 AM, felix winkelmann wrote:Real OS-level multithreading is currently not posssible for Scheme code,Right, I got this from your reply a few months ago when I asked whether this would wreak havoc with the stack and gc. but separate processes might actually be a working alternative.Gauche (gosh) does threads this way, as separate unix processes, which is why I suggested it. What we need is some efficient method of exchanging data between processes. Perhaps serialization over shared memory? I was thinking shared memory too (but only because I imagine this would be the fastest kind of IPC). Of course actual benchmarking as you suggested is the right way to do it.This is what I love about Chicken - I say "wouldn't it be nice if..." a few days after xmas, and Felix is talking about benchmarking different implementation strategies before new years! Raffael Cavallaro, Ph.D. [EMAIL PROTECTED]P.S. rereading my recent mail to the list, I realize that due to my poor choice of phrasing, some readers might get the impression that I was writing that the objc egg was the work of Andre van Tonder. The objc egg is of course the work of Zbigniew Szadkowski based on Felix's earlier version. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] objc egg
On Dec 12, 2005, at 8:45 PM, Zbigniew wrote:I renamed zobjc to objc, and added an eggdoc. http://jiyu.gnook.org/~zbigniew/eggs/objc.egg http://jiyu.gnook.org/~zbigniew/eggs/objc.html Zbiggy and Felix,Thanks for this, both of you - I'm really looking forward to using Chicken with Cocoa.regards,Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken mode for Emacs?
On Dec 5, 2005, at 4:35 AM, Ralph Moritz wrote:is there an Emacs mode available that will run csi as an inferior Emacs process (preferably with syntax highlighting)? I use Quack which is at http://www.neilvandyke.org/quack/regards,Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: libffi
On Nov 26, 2005, at 8:27 PM, Thomas Chust wrote:Hello,this library will finally drive me crazy %-] I gave the version you providedhere a try and it compiled -- but CHICKEN failed to link against it, becausethe resulting library did not contain some of the essential functions likeffi_call!Before someone asks: I'm running MacOS X 10.4.3, XCode 2.2, gcc 4.0.1 FWIW I had to do:rafg5:~ raffaelc$ sudo ln -s /usr/lib/include/ffi.h /usr/include/ffi.hrafg5:~ raffaelc$ sudo ln -s /usr/lib/include/ffitarget.h /usr/include/ffitarget.hbefore chicken would link against it, but with these symlinks everything was fine. Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Objective-C interface (sort of...)
On Nov 25, 2005, at 1:41 AM, felix winkelmann wrote: Attached is a version of my code that is slightly less broken. cheers, felix objc.egg I got the simple example in the docs to work by downloading a pre- built binary of libffi at: ftp://ftp.swarm.org/pub/swarm/binaries/macosx/2005-07-05/gcc-4- swarm.dmg To install it you will need a package viewer application such as Pacifist since I assume you won't want to overwrite the version of gcc that ships with the Apple Developer Tools but just want to add libffi. more detailed instructions: 1. Download the prebuilt gcc at the above link. 2. Download and install Pacifist from http://www.charlessoft.com/ 3. extract only those portions of the dmg that compose libffi and copy them to the appropriate directories within your existing gcc installation. 4. create the necessary symlinks as well. 5. When you run chicken-setup for lazy-ffi.egg it may complain about ffi.h etc. not existing. You'll need to create a symlink from these headers to /usr/include. Repeat for any other failures to find the necessary headers. Alternatively you could pass the correct include flags to csc but I prefer symlinks cause these will work for anything else that's looking for the libffi headers. 6. (sudo) chicken-setup -keep objc.egg 7. read the docs and run the test examples. Thanks for this Felix. I only hope that libffi can be made to work with each OS upgrade. regards, Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Objective-C interface (sort of...)
On Nov 24, 2005, at 12:08 PM, Thomas Chust wrote:It should, but it never did for me... After all the failed attempts, I have developed a certain dislike for the libffi library ;) I can second this negative view of libffi. I have never gotten it to work on Mac OS X despite several attempts over the years. This is one of those areas where things taken for granted in the unix/linux world simply don't hold true on Mac OS X. Apple doesn't provide libffi with their Mac OS X Developer Tools even though it is distributed with gcc now and Apple's whole tool chain is based on gcc. I think it would be best to base any Objective-C interface on tools and libraries that ship Apple's Developer Tools installation. That way it would be more likely to work without issue and to not break the next time Apple upgraded their OS.regards,Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Dynamic loading foreign C library problem
On Nov 22, 2005, at 12:04 PM, Matthew David Parker wrote:PS. On a side question, is there some thing you can do in the csi chicken interpreter to make it so you can press the "up" arrow and cycle through the history of your commands, like in a bash shell? If you use emacs with one of the scheme packages such as quack (built on cmuscheme.el and scheme.el) you get command history in csi with meta-p and meta-n.Quack is at http://www.neilvandyke.org/quack/You can do your shell stuff (such as chicken setup) from eshell and never leave emacs.regards Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Significant overhead to simple-macros?
On Oct 10, 2005, at 1:52 AM, felix winkelmann wrote:Simple macros is pretty big and the numbers code is quite memory intensive/allocation happy, so we have more data in the heap (simple macros) and loads of GC's (numbers). Thanks for tracking this down. It's not a big issue for me - I only stumbled across it accidentally - I was just testing to make sure that I understood how to use simple-macros with other libraries when I noticed that certain things seems to take longer when simple-macros was loaded. I was only concerned that there might be a bug in simple-macros that might need to be fixed. Glad to hear that there is not and that this is only a matter of taxing resources excessively.BTW, your responsiveness on this list is nothing short of amazing, and Chicken grows more and more impressive with each release.warmest regards,Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Conflict between simple-macros and other extensions?
Using the latest 2.2 release, with (or without) the hash patch, if I compile the simple-macros egg and try to use it and, for example the posix extension, I get odd errors: rafg5:/scheme raffaelc$ csi ___ _ __ / ___/ / (_)___/ /_ ___ / /__/ _ \/ / __/ '_/ -_) _ \ \___/_//_/_/\__/_/\_\\__/_//_/ Version 2, Build 2 - macosx-unix-gnu-ppc - [ dload ] (c)2000-2005 Felix L. Winkelmann #;1 (require-extension simple-macros) ; loading /usr/local/lib/chicken/simple-macros.so ... #;2 (use posix) ; loading library posix ... #;3 (current-directory) Error: unbound variable: current-directory#top #;3 This all works fine if I don't load simple-macros: rafg5:/scheme raffaelc$ csi ___ _ __ / ___/ / (_)___/ /_ ___ / /__/ _ \/ / __/ '_/ -_) _ \ \___/_//_/_/\__/_/\_\\__/_//_/ Version 2, Build 2 - macosx-unix-gnu-ppc - [ dload ] (c)2000-2005 Felix L. Winkelmann #;1 (use posix) ; loading library posix ... #;2 (current-directory) /Users/raffaelc/Developer/scheme #;3 or even if I load simple-macros.scm but not the compiled extension: rafg5:~/Developer/scheme/tonder/www.het.brown.edu/people/andre/macros/ implementation/version 2.1 raffaelc$ csi ___ _ __ / ___/ / (_)___/ /_ ___ / /__/ _ \/ / __/ '_/ -_) _ \ \___/_//_/_/\__/_/\_\\__/_//_/ Version 2, Build 2 - macosx-unix-gnu-ppc - [ dload ] (c)2000-2005 Felix L. Winkelmann #;1 (load simple-macros.scm) ; loading simple-macros.scm ... #;2 (use posix) ; loading library posix ... #;3 (current-directory) /Users/raffaelc/Developer/scheme/tonder/www.het.brown.edu/people/ andre/macros/implementation/version 2.1 #;4 BTW, it doesn't matter what order I load posix and the simple-macros extension - it's broken both ways. Additionally, even with just the simple-macros extension loaded, the tests in simple-macros-tests.scm now fail, while they pass if I just load simple-macros.scm in the interpreter instead of using the compiled extension generated by the simple-macros egg. Any thoughts? Or am I missing something I should have seen in the docs for simple-macros? regards, Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Strange hash-table behavior in compiled code
On Sep 26, 2005, at 1:51 AM, felix winkelmann wrote:Here a patch for extras.scm: 1493d1492 ((##sys#permanent? x) (##core#inline "C_hashptr" x))Not to pick nits, but Felix's patch seems to differ somewhat from Alex's (Felix's is shorter). Alex, what else does your patch do that Felix's doesn't. Does it matter which I apply?While I'm on the subject, If I apply the patch and then run make it fails because the makefile assumes that there's a chicken executable in the distribution directory (there isn't). Putting a symlink from my previous installation of chicken to ./chicken fixes this.regards Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken-setup failure with gmp
When I try to use chicken-setup to install the gmp egg, I get the error: csc: invalid option `-H' which I believe comes from this form in gmp.setup: (make/proc (map (lambda (s o) (list o (list s) (lambda () (run (csc -sH -O2 - d0 ,s -L -lgmp) sfiles ofiles) (list-vector ofiles) ) Is there any way to correct this? FWIW, I built and installed the gmp library from sources prior to trying to setup the gmp egg if that makes any difference. Here is the full terminal transcript: raffaelc$ sudo chicken-setup -keep gmp The extension gmp does not exist. Do you want to download it ? (yes/no/abort) [yes] yes downloading catalog ... downloading catalog from www.call-with-current-continuation.org ... downloading gmp.egg from (www.call-with-current-continuation.org eggs 80) ... mkdir -p gmp.egg.dir gunzip -c ../gmp.egg | tar xvf - gmp.setup gmp_types.scm gmp_test.scm gmp_integer.scm gmp_test_rational.scm gmp_rational.scm gmp_test_utils.scm gmp_test_integer.scm gmp.scm gmp_test_float.scm gmp_utils.scm gmp_float.scm gmp_random.scm /usr/local/bin/csc -feature compiling-extension -sH -O2 -d0 gmp_float.scm -L -lgmp csc: invalid option `-H' make: Failed to make gmp_float.so: shell invocation failed with non- zero return status Error: shell invocation failed with non-zero return status /usr/local/bin/csc -feature compiling-extension -sH -O2 -d0 gmp_float.scm -L -... 64 Error: shell invocation failed with non-zero return status /usr/local/bin/csc -feature compiling-extension -sH -O2 -d0 gmp_float.scm -L -... 64 Thanks in advance, Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] foreign-lambda* problems on Mac OS X
Can someone provide me with a minimal example scheme file that shows proper use of foreign-lambda* or foreign-callback-lambda* or foreign- safe-lambda* - in other words, a scheme file that embeds c code in the scheme file. Whenever I try to do this I get a linker error stating that the symbol in question - the name of the foreign-lambda* - prepended by an underscore, e.g., _foo is undefined: /usr/bin/ld: Undefined symbols: _tak BTW, I'm on Mac OS X 10.4.1 and I compiled Chicken from source: Version 1, Build 941 - macosx-unix-gnu-ppc On this version of Mac OS X the default c compiler is gcc 4.0, so Chicken is using gcc 4.0. Thanks in advance, Ralph Raffael Cavallaro, Ph.D. [EMAIL PROTECTED] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
