I am pleased to announce that Bosco 0.7 is available for download from:
ftp://clozure.com/pub/testing/bosco-0.7.tar.gz
Bosco is a simple framework for construction of Mac OS X applications,
using OpenMCL.
This new version of Bosco adds some significant features and removes a
few. It's designed to make the task of building a fully-functioning
Cocoa application on OpenMCL as easy as possible.
It is now possible to create a running Cocoa application with Bosco in
just two shell commands; for example:
make-new-project -n Foo
sh build-Foo.sh
creates a double-clickable Foo.app, together with the system definition
and Lisp source files needed to build it. For more infomration, see the
README file included with the Bosco distribution.
Carbon support, provided by earlier versions, is removed from Bosco
0.7, at least for now, in order to simplify the implementation and use
of Bosco.
Similarly, SLIME support, built into previous versions of Bosco, is
temporarily removed.
Compatibility
-------------
This release has been tested with the 061110 and 061205 snapshots of
OpenMCL. It should work on later snapshots and releases as well.
Bosco currently works only on Mac OS X PPC. I expect to release a
future version of Bosco that supports the Intel Core 2 Duo.
Sample Code
-----------
Bosco 0.7 includes a sample project called SimpleEdit. SimpleEdit is a
simple, but fully-functioning text editor designed to very closely
resemble the Apple example at
http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/Tasks/TextEditor.html
It is close enough, in fact, that you can read through that Apple
example and the sample code provided in SimpleEdit, and see how the
Lisp code in SimpleEdit corresponds to the Objective-C code in Apple's
example.
Future Bosco releases will include additional example projects.
License
-------
Bosco 0.7 is released under the New BSD license.
Support
-------
If you have questions about Bosco 0.7, or suggestions for future
development, please send them to the OpenMCL-devel mailing list. For
more information about the mailing list, see
http://clozure.com/mailman/listinfo/openmcl-devel
······@evins.net" <·····@evins.net> wrote:
>I am pleased to announce that Bosco 0.7 is available for download from:
>
> ftp://clozure.com/pub/testing/bosco-0.7.tar.gz
>
>Bosco is a simple framework for construction of Mac OS X applications,
>using OpenMCL.
>
Will Bosco and any OpenMCL/Objective C bridges be affected by
Objective C's upcoming garbage collection in Leopard?
On Thu, 21 Dec 2006 04:12:23 +0100, Ralph Richard Cook
<·············@bellsouth.net> wrote:
> ······@evins.net" <·····@evins.net> wrote:
>
>> I am pleased to announce that Bosco 0.7 is available for download from:
>>
>> ftp://clozure.com/pub/testing/bosco-0.7.tar.gz
>>
>> Bosco is a simple framework for construction of Mac OS X applications,
>> using OpenMCL.
>>
>
> Will Bosco and any OpenMCL/Objective C bridges be affected by
> Objective C's upcoming garbage collection in Leopard?
I am totally ignorant of the products in question.
It seems to me the only type of garbage collector that works
seamlessly with C/C++ is a Boyer-More Conservative Garbage collector.
Since it doesn't move allocated memory it is effectively invisible
to the applications that use it and thus to the Lisp Foreign library as
well. IE. it doesn't need to mess with the call/data stack.
To be sure check if it does indeed have this form of garbage collector.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Thu, 21 Dec 2006 04:44:26 +0100, "John Thingstad"
<··············@chello.no> wrote:
>On Thu, 21 Dec 2006 04:12:23 +0100, Ralph Richard Cook
><·············@bellsouth.net> wrote:
>
>> Will Bosco and any OpenMCL/Objective C bridges be affected by
>> Objective C's upcoming garbage collection in Leopard?
>
>I am totally ignorant of the products in question.
>
>It seems to me the only type of garbage collector that works
>seamlessly with C/C++ is a Boyer-More Conservative Garbage collector.
Boyer and Moore never designed a collector ... the only connection I
can see to them is that David Russinoff used their theorem prover to
verify the operation of a Ben-Ari collector.
see http://www.russinoff.com/papers/mp.pdf
I believe you're thinking of Boehm-Demers-Weiser.
>Since it doesn't move allocated memory it is effectively invisible
>to the applications that use it and thus to the Lisp Foreign library as
>well. IE. it doesn't need to mess with the call/data stack.
Completely off topic but ...
C and C++ don't, per se, require conservative collectors ... the most
you can say about them is that all current implementations do.
It has been a while since I've looked at either language spec with an
eye toward putting GC under them (this contentious topic recurs now
and again in c.l.c++) but offhand now I can't think of any particular
misfeatures which would preclude a type-perfect collector - as long as
you are willing to use a FFI for your existing libraries and accept
that they will not be GC'd. C++ already uses a standardized FFI for C
libs (the "C" keyword) and both C and C++ use implementation dependent
FFI for assembler libs so I don't see FFI as a deal breaker for them
any more than it is for Lisp.
You'd need to write the compiler from scratch of course, defining the
safe points where GC can occur. You don't need to tag pointers (or
any other data), but you do need to tag pointer unions and create
pointer maps for data structures, function call frames and for
registers at GC safe points. You also need to guarantee that base
pointers to heap objects are not shrouded at GC safe points and a few
hundred other things in addition to implementing all the rest of the
language. If you are clever, you might still have a spec conforming
compiler when you were finished.
Of course, your better compiler would be as slow as optimized Lisp 8-)
and it wouldn't play nicely with other compilers ... so after all your
work no one would use it.
... we now return you to your regularly scheduled c.l.l
George
--
for email reply remove "/" from address
On Thu, 21 Dec 2006 04:04:37 -0500, George Neuner wrote:
> You'd need to write the compiler from scratch of course, defining the safe
> points where GC can occur. You don't need to tag pointers (or any other
> data), but you do need to tag pointer unions and create pointer maps for
> data structures, function call frames and for registers at GC safe points.
> You also need to guarantee that base pointers to heap objects are not
> shrouded at GC safe points and a few hundred other things in addition to
> implementing all the rest of the language. If you are clever, you might
> still have a spec conforming compiler when you were finished.
I've seen some announcements on (I think) c.o.l.a for the last year or so
from some guys who seem to have done just about exactly that, and targeted
the result at JVM byte-codes. Seems like an interesting exercise, if
largely futile, for all of the reasons that you stated. At least with
their approach you get automatic access to the Java libraries, in exchange
for no or poor access to your old C libraries. Better than nothing,
perhaps.
I note that this has essentially nothing to do with lisp any more, so I'd
better stop here.
Cheers,
--
Andrew
On Thu, 21 Dec 2006 10:04:37 +0100, George Neuner <·········@comcast.net>
wrote:
>
> I believe you're thinking of Boehm-Demers-Weiser.
>
I am Indeed. Just been working/playing with ACL2 and must have mixed up
the two..
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
describes the collector.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> writes:
>> Will Bosco and any OpenMCL/Objective C bridges be affected by
>> Objective C's upcoming garbage collection in Leopard?
>
> I am totally ignorant of the products in question.
>
> It seems to me the only type of garbage collector that works
> seamlessly with C/C++ is a Boyer-More Conservative Garbage collector.
> Since it doesn't move allocated memory it is effectively invisible
> to the applications that use it and thus to the Lisp Foreign library as
> well. IE. it doesn't need to mess with the call/data stack.
>
> To be sure check if it does indeed have this form of garbage collector.
The problem would be if you kept a foreign address in the form of a
lisp bignum (or fixnum) (and it was the only reference): this address
wouldn't be noticed by the the conservative GC, and it would collect
the memory block under the feet of the lisp image.
So the question reduces to: "Does Bosco and any OpenMCL/Objective-C
bridge keep the foreign addresses in the same bit pattern as the C
side?"
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
In article <·······················@79g2000cws.googlegroups.com>,
······@evins.net" <·····@evins.net> wrote:
> I am pleased to announce that Bosco 0.7 is available for download from:
>
> ftp://clozure.com/pub/testing/bosco-0.7.tar.gz
>
> Bosco is a simple framework for construction of Mac OS X applications,
> using OpenMCL.
Good to see you back working on this.
>
> This new version of Bosco adds some significant features and removes a
> few. It's designed to make the task of building a fully-functioning
> Cocoa application on OpenMCL as easy as possible.
>
> It is now possible to create a running Cocoa application with Bosco in
> just two shell commands; for example:
>
> make-new-project -n Foo
>
> sh build-Foo.sh
>
> creates a double-clickable Foo.app, together with the system definition
> and Lisp source files needed to build it. For more infomration, see the
> README file included with the Bosco distribution.
>
> Carbon support, provided by earlier versions, is removed from Bosco
> 0.7, at least for now, in order to simplify the implementation and use
> of Bosco.
>
> Similarly, SLIME support, built into previous versions of Bosco, is
> temporarily removed.
>
> Compatibility
> -------------
>
> This release has been tested with the 061110 and 061205 snapshots of
> OpenMCL. It should work on later snapshots and releases as well.
>
> Bosco currently works only on Mac OS X PPC. I expect to release a
> future version of Bosco that supports the Intel Core 2 Duo.
That would be cool. ;-)
>
> Sample Code
> -----------
>
> Bosco 0.7 includes a sample project called SimpleEdit. SimpleEdit is a
> simple, but fully-functioning text editor designed to very closely
> resemble the Apple example at
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/Tas
> ks/TextEditor.html
>
> It is close enough, in fact, that you can read through that Apple
> example and the sample code provided in SimpleEdit, and see how the
> Lisp code in SimpleEdit corresponds to the Objective-C code in Apple's
> example.
>
> Future Bosco releases will include additional example projects.
>
> License
> -------
>
> Bosco 0.7 is released under the New BSD license.
>
> Support
> -------
>
> If you have questions about Bosco 0.7, or suggestions for future
> development, please send them to the OpenMCL-devel mailing list. For
> more information about the mailing list, see
>
> http://clozure.com/mailman/listinfo/openmcl-devel