Rick Taube wrote:
> [Apologies for the multi-list posting; no further announcements will
> be sent]
>
> Thanks to the friendly folks at common-lisp.net, the lambda-gtk code
> now has a home:
>
> http://common-lisp.net/project/lambda-gtk/
Rick,
Nice. Gtk is busting out all over, it seems. :)
fwiw, vasilis margioulas sent me a fairly complete CLisp+Gtk package
which I am converting to use UFFI. This turns out to be a bit of a
comedown for the package, since CLisp handles a few things much more
capably than UFFI (which I realize must restrict itself to the common
denominator of functionality across the supported underlying FFIs).
The examples vasilis did are fairly extensive, but they all use my Cells
package. The FFI work per se of course is independent of Cells.
The original pure-CLisp package is here:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cell-cultures/cells-gtk-root/?cvsroot=cells
I have tested on win xp, and Vasilis tested on one or two *nix.
The UFFI port is running (roughly) on win xp under Allegro.
btw, lambda-gtk is the first look I have had at ffigen. Looks great.
I'll have to give it a try soon.
cheers, kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Hi,
Christophe Rhodes <csr21@...> writes:
> Could you check the value of MAP_ANON in the applicable header file?
> Since Sun is good with binary compatibility, it's likely to be 0x100
> -- but it's not certain.
Yes, it is still 0x100.
> If it is, please try the attached patch.
That fixed the problem. Thanks!
Dan
--
Dan Debertin Unix Systems Admin/Programmer
Diehl Hall #203B University of Minnesota
(612)626-6468 Bio-Medical Library
debertin@...

[Apologies for the multi-list posting; no further announcements will be
sent]
Thanks to the friendly folks at common-lisp.net, the lambda-gtk code
now has a home:
http://common-lisp.net/project/lambda-gtk/
I took the liberty of this initial CVS checkin to add the separate Lisp
symbol packaging that several people commented about (the original
naming method remains an option). Home page had been updated with a bit
more information; if anyone feels a burning desire to help out please
contact me after reading the Lacunae section on the project's home
page.
Rick Taube
Associate Professor, Composition/Theory
School of Music
University of Illinois
Urbana, IL 61821 USA
net: taube@...
fax: 217 244 8319
vox: 217 244 2684

On Tue, Nov 30, 2004 at 02:06:18PM +0000, Christophe Rhodes wrote:
> Brian Mastenbrook <bmastenb@...> writes:
>
> > 1. Don't make any.
> > 2. Make the binaries without sb-unicode.
> > Or, if we make the binaries with unicode, there are two options:
> > 3. Touch test-passed in the sb-md5 directory and ship it, knowing that
> > users who use sb-md5 will see their MD5 computed values change.
> > 4. Don't touch test-passed and distribute without sb-md5.
> > 5. Some combination of #3 or #4 and #2.
> >
> > My personal feeling is that option #3 is the right option: I'd like to
> > ship with unicode to get users testing, and it doesn't make sense to
> > not ship sb-md5 just because the tests haven't been fixed. However, I
> > could see an argument for #2 - waiting until there are encode and
> > decode to string functions before shipping binaries with unicode. #5
> > would be a lot of work.
>
> Again, speaking personally, I'd rather #4; that way, if anyone feels
> that they need sb-md5 in their binaries, they have an incentive to get
> down and make it happen. I see #3 as dishonest -- what is the point
> of having tests for contrib modules which we have always said have a
> slightly less supported status than the main body of code, if at the
> least provocation we circumvent those tests? It's not just a question
> of fixing the tests: the interface itself is broken, and despite two
> calls for contributions remains so.
>
> I believe Kevin has chosen option #2 for his Debian uploads -- in some
> sense, I think that covers that base; it seems to me that #4 is the
> option that best reflects the state of SBCL development at release
> time.
I think I agree with you (CSR) here. Choice #3 seems like promising
what SBCL doesn't (quite) deliver; I would prefer either #2 or #4. By
and large, SBCL tends to err in the direction of not promising what it
doesn't quite deliver. Not only is that direction my personal
preference, but I also have a metapreference: whichever direction we
prefer, we should try to prefer it consistently. Thus, if here we
really wanted to have defaults and summary information which
cheerfully promote things which sort of work, I'd be wondering whether
we should start converting other things to a similar approach.
Between #2 and #4 I don't have as strong a preference, but again I
have a metapreference for having a reasonably consistent policy. #4
looks like an instance of a policy that contrib/ maintainers are
fundamentally the ones responsible for chasing the main code (so when
the main code changes -- Unicode in this case -- and breaks something
in contrib/, the default policy is to release the main code and shut
down sb-md5 until it catches up). #2 looks like an instance of a
policy that the main system shouldn't do things which break the
contribs, starting to promote them to an equal part of the main
system. I think to the extent that we have an explicit policy, it
currently looks like the first, corresponding to #4. And I think if
it's time to make an exception to that policy, then maybe it's time to
think about changing the policy instead.
(I still prefer the #4-style policy, but I can see there are arguments
both ways, and quite some time has passed, and many changes have
occurred, since we argued about it last.)
--
William Harold Newman <william.newman@...>
"But I'll forgive you a good deal for calling it 'Interesting but slightly
mad.'" -- <http://groups.google.com/groups?q=ddfr+Interesting+but+slightly+mad&gt;

Hi,
Something (well, at lot of things) changed between Solaris 9 and 10
that appears to have killed SBCL:
# sbcl
fatal error encountered in SBCL pid 9937:
Unknown mmap() interaction with MAP_ANON
This is with the sparc-sunos binaries on sf.net. Any idea what might
be causing this? I can furnish a login to an S10 system if
necessary...
TIA,
Dan
--
Dan Debertin Unix Systems Admin/Programmer
Diehl Hall #203B University of Minnesota
(612)626-6468 Bio-Medical Library
debertin@...

Brian Mastenbrook <bmastenb@...> writes:
> 1. Don't make any.
> 2. Make the binaries without sb-unicode.
> Or, if we make the binaries with unicode, there are two options:
> 3. Touch test-passed in the sb-md5 directory and ship it, knowing that
> users who use sb-md5 will see their MD5 computed values change.
> 4. Don't touch test-passed and distribute without sb-md5.
> 5. Some combination of #3 or #4 and #2.
>
> My personal feeling is that option #3 is the right option: I'd like to
> ship with unicode to get users testing, and it doesn't make sense to
> not ship sb-md5 just because the tests haven't been fixed. However, I
> could see an argument for #2 - waiting until there are encode and
> decode to string functions before shipping binaries with unicode. #5
> would be a lot of work.
Again, speaking personally, I'd rather #4; that way, if anyone feels
that they need sb-md5 in their binaries, they have an incentive to get
down and make it happen. I see #3 as dishonest -- what is the point
of having tests for contrib modules which we have always said have a
slightly less supported status than the main body of code, if at the
least provocation we circumvent those tests? It's not just a question
of fixing the tests: the interface itself is broken, and despite two
calls for contributions remains so.
I believe Kevin has chosen option #2 for his Debian uploads -- in some
sense, I think that covers that base; it seems to me that #4 is the
option that best reflects the state of SBCL development at release
time.
Cheers,
Christophe

Hello all,
It's time to make the binaries for SBCL 0.8.17, and because of the new
sb-unicode feature, I need to decide how to make the binaries. Right
now, sb-md5 fails its tests on a sb-unicode binary. The way I see it,
there are five options for how to make the binaries:
1. Don't make any.
2. Make the binaries without sb-unicode.
Or, if we make the binaries with unicode, there are two options:
3. Touch test-passed in the sb-md5 directory and ship it, knowing that
users who use sb-md5 will see their MD5 computed values change.
4. Don't touch test-passed and distribute without sb-md5.
5. Some combination of #3 or #4 and #2.
My personal feeling is that option #3 is the right option: I'd like to
ship with unicode to get users testing, and it doesn't make sense to
not ship sb-md5 just because the tests haven't been fixed. However, I
could see an argument for #2 - waiting until there are encode and
decode to string functions before shipping binaries with unicode. #5
would be a lot of work.
Advice?
--
Brian Mastenbrook
http://www.iscblog.info/http://www.cs.indiana.edu/~bmastenb/

Hi,
The MOP says about user-defined defclass options:
"Any other class options become the value of keyword arguments with
the same name. The value of the keyword argument is the tail of the
class option. An ERROR is SIGNALled if any class option appears more
than once in the DEFCLASS form."
But SBCL does not signal an error here. Test case:
(defclass option-class (standard-class)
((option :accessor cl-option :initarg :my-option)))
(defmethod sb-pcl:validate-superclass ((c1 option-class) (c2 standard-class))
t)
(defclass testclass02b ()
()
(:my-option bar)
(:my-option baz)
(:metaclass option-class))
Expected: ERROR
Got: #<OPTION-CLASS TESTCLASS02B>
This works in CLISP CVS and OpenMCL.
Bruno

Kalle Olavi Niemitalo <kon@...> writes:
> I have written an alternative setf expander for THE that seems to
> do the job. It does introduce an unnecessary layer of bindings,
> but the compiler apparently optimizes that out in typical cases.
Thank you. I've merged something similar to your expander in
sbcl-0.8.17.3.
Cheers,
Christophe

>for using closures directly as signal handlers. Hosting the project
>and establishing a mailing-list would be very useful in sync'ing the
>work and getting a common build-procedure e.g for generating new .ffi
>files. The people at common-lisp.net seems to do a very good job at
>hosting. :-)
yes i agree, and in my infinite free time im getting the "project" a bit more
formalized in preparation for hosting. ive read the llgpl and have already
switched the license over to that. the ascii name will 'lambda-gtk' as suggested
by brian mastenbrook and today or tomrrow ill try to add the ability to generate
names without the g-, gtk- ... prefixes. in another fit of optimism i contacted
sourceforge to see i could host the sources there (since that is where my other
project already resides) but of course they rejected me, i think probably my
description was not thourough enough. so i either have to get up the energy to
write more boilerplate english or move on.
>The people at common-lisp.net seems to do a very good job at hosting.
ok sounds good, but when i add a Guile binding will they kick me off? :)
-rick

Quoting taube@... (taube@...):
|
| >G-SIGNAL-CONNECT and so on). One possible alternative to this (which
| >I tend to favour these days) is instead to generate names such as
| >FROB-BAR in the GTK package (and SIGNAL-CONNECT in the G package);
|
| yes, someone else contacted me about this today -- acutally this was my first
| idea but i thought that it would be clearest if i kept a one-to-one naming. but
| since the code is generated i think this would be a very easy task to add this
| feature; maybe keep just a single gtk package but add package nicknames g,
| pango, atk and so on. sigh, maybe i should see about hosting the code somewhere
| as a project.
As can be seen on Planet Lisp ( http://planet.lisp.org/ ), there has
been a flurry of activity adding to lambda-gtk. As it is now it is
useful to me personally but as I need a proper gui-designer to do what
I want, I've started work on getting glade working with lambda-gtk and
so far it works pretty well. Robert J Macomber has written support
for using closures directly as signal handlers. Hosting the project
and establishing a mailing-list would be very useful in sync'ing the
work and getting a common build-procedure e.g for generating new .ffi
files. The people at common-lisp.net seems to do a very good job at
hosting. :-)
As for different CL-packages, I think that's a good idea as there are
many other gtk-based widget-sets that are helpful for CL-programmers,
e.g gnome:, gdk-imlib:, glade:, bonobo:, ... and splitting it up a bit
might help people choose the parts they want. But it works well as it
is now though, great job :-D
Regards,
--
----------------
Stig Erik Sandoe

On Tue, Nov 23, 2004 at 06:45:10PM -0600, taube@... wrote:
[gtk gtk gtk]
> >I share the hope of another poster that the licence of the bindings be
> >made no more restrictive to the licensee than those of the gtk
> >libraries themselves
>
> ok ill switch :)
Cool.
(Coping with per-file credits while brutally slicing and dicing files
into bootstrappable order left a lasting impression on me, so although
I don't understand the issues here at all well, I'm psyched about
anything that makes it sound as though a license is being simplified.)
--
William Harold Newman <william.newman@...>
"This is not the license you are looking for." -- Christophe "Wan" Rhodes

> Well that's a little troubling. I guess it's time for me to bite the
> bullet and build gtk over here -- if you beat me to it, be sure to
> send me the failing cases, so I can add something to the test suite.
If you mean on Darwin you can just download the libs from Fink. Takes
only a minute if you have FinkCommander and Fink installed. I have some
basic instructions for setting up x11/gtk on darwin here:
http://pinhead.music.uiuc.edu/~hkt/cm/doc/install.html#gtk_darwin
the problem could very easily be due to my code and im still looking at
it. things compile fine, gtk seems to load fine, i can pop up an
example window, a button click callback works fine but then a
delete-event callback -- which then triggers a destroy callback and
eventually #'gtk_main_quit -- does not seem to ever actually trigger
the destoy callback. so the window does not and exit and are hung
between the two worlds. same code works fine on x86.
(load (compile-file "lgtk-cmusbcl"))
(in-package gtk)
(load (compile-file "examples"))
(hello-world)
Rick Taube
Associate Professor, Composition/Theory
School of Music
University of Illinois
Urbana, IL 61821 USA
net: taube@...
fax: 217 244 8319
vox: 217 244 2684

taube@... writes:
>
> >a form as possible: most obviously here we have callbacks, I suppose
> >(which I understand Thomas Burdick has working on x86/Linux,
> >ppc/Darwin and sparc/Solaris),
>
> yes Thomas' callbacks, err alien functions are huge, im hoping i can get
> portable real-time midi io going in addition to gtk. In a fit of optimism I
> tried the gtk callbacks on PPC/sbcl today but they didnt work. Im not sure why
> at this point, ill poke around and maybe contact Thomas if I cant figure it out.
> The code seems to work fine on x86. The interface im working on uses all sorts
> of gtk widgets and so far the ffi seems to be holdng up really well.
Well that's a little troubling. I guess it's time for me to bite the
bullet and build gtk over here -- if you beat me to it, be sure to
send me the failing cases, so I can add something to the test suite.

On Nov 23, 2004, at 6:45 PM, <taube@...> wrote:
> yes, someone else contacted me about this today -- acutally this was
> my first
> idea but i thought that it would be clearest if i kept a one-to-one
> naming. but
> since the code is generated i think this would be a very easy task to
> add this
> feature; maybe keep just a single gtk package but add package
> nicknames g,
> pango, atk and so on. sigh, maybe i should see about hosting the code
> somewhere
> as a project.
You will find that common-lisp.net would be able to host your project,
though I would suggest finding a project name that fits within 7-bit
ASCII. lgtk is already taken; maybe lambda-gtk?
--
Brian Mastenbrook
bmastenbrook@...
http://www.cs.indiana.edu/~bmastenb/