From: Kenny Tilton
Subject: UFFI vs. Boolean
Date: 
Message-ID: <H3eod.20787$Vk6.15030@twister.nyc.rr.com>
OK, I have now offically spent more time porting cells-gtk from CLisp 
FFI to UFFI than Vasilis spent /writing cells-gtk/!

<g>

Next question. Asked already on uffi-users but no response.

No boolean type? ie, plz translate between nil/not-nil and 0/not-0 
reasonably. Allegro does it, LW does it, CLisp does it -- who doesn't?

Follow-up Q: WTF?

I see also while working on Vasilis's herculean Gtk bindings that (a) 
Clisp has a killer FFI and (b) UFFI does not support CLisp.

Whassup wid dat?

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

From: Russell McManus
Subject: Re: UFFI vs. Boolean
Date: 
Message-ID: <87oehqf11z.fsf@thelonious.dyndns.org>
Kenny Tilton <·······@nyc.rr.com> writes:

> I see also while working on Vasilis's herculean Gtk bindings that
> (a) Clisp has a killer FFI and (b) UFFI does not support CLisp.
>
> Whassup wid dat?

As you are aware, UFFI is a relatively thin macro layer on top of a
couple of Lisp implementations's FFIs.  So there is an inherent
assumption in the design of UFFI that the underlying FFIs provide
roughly equivalent services, only with different interfaces.

But CLISP's FFI provides higher level constructs and otherwise doesn't
fit in perfectly with the model assumed by UFFI.  This is not to say
that some enterprising hacker couldn't figure out a way to do it.

I agree that CLISP's FFI is very cool.

-russ
From: Kenny Tilton
Subject: Re: UFFI vs. Boolean
Date: 
Message-ID: <VGnod.17987$ld2.4085061@twister.nyc.rr.com>
Russell McManus wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>I see also while working on Vasilis's herculean Gtk bindings that
>>(a) Clisp has a killer FFI and (b) UFFI does not support CLisp.
>>
>>Whassup wid dat?
> 
> 
> As you are aware, UFFI is a relatively thin macro layer on top of a
> couple of Lisp implementations's FFIs.  So there is an inherent
> assumption in the design of UFFI that the underlying FFIs provide
> roughly equivalent services, only with different interfaces.
> 
> But CLISP's FFI provides higher level constructs and otherwise doesn't
> fit in perfectly with the model assumed by UFFI.  This is not to say
> that some enterprising hacker couldn't figure out a way to do it.
> 
> I agree that CLISP's FFI is very cool.

So I was thinking, maybe anything UFFI semantics call for can be 
implemented using the CLisp FFI. I did not exhaustively confirm this, so 
maybe if I tried I would get 80% of the way there and...doh!

I realize this would be a comedown from native CLisp FFI, since we would 
be doing the least common denominator thing, but I think that is 
unavoidable if one wants portable code. And I do not think CLisp would 
be the first Lisp held back by the LCD thing.

Anyway, I am busily hacking a boolean type into UFFI. Partly. :) I just 
want to see cells-gtk run under allegrocl. :)

kt


-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Pascal Bourguignon
Subject: Re: UFFI vs. Boolean
Date: 
Message-ID: <87k6sdpvgy.fsf@thalassa.informatimago.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> Russell McManus wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>I see also while working on Vasilis's herculean Gtk bindings that
> >>(a) Clisp has a killer FFI and (b) UFFI does not support CLisp.
> >>
> >>Whassup wid dat?
> > As you are aware, UFFI is a relatively thin macro layer on top of a
> > couple of Lisp implementations's FFIs.  So there is an inherent
> > assumption in the design of UFFI that the underlying FFIs provide
> > roughly equivalent services, only with different interfaces.
> > But CLISP's FFI provides higher level constructs and otherwise
> > doesn't
> > fit in perfectly with the model assumed by UFFI.  This is not to say
> > that some enterprising hacker couldn't figure out a way to do it.
> > I agree that CLISP's FFI is very cool.
> 
> So I was thinking, maybe anything UFFI semantics call for can be
> implemented using the CLisp FFI. I did not exhaustively confirm this,
> so maybe if I tried I would get 80% of the way there and...doh!
> 
> I realize this would be a comedown from native CLisp FFI, since we
> would be doing the least common denominator thing, but I think that is
> unavoidable if one wants portable code. And I do not think CLisp would
> be the first Lisp held back by the LCD thing.
> 
> Anyway, I am busily hacking a boolean type into UFFI. Partly. :) I
> just want to see cells-gtk run under allegrocl. :)

Already two UFFI for clisp implementations have been started, one by
Joerg-Cyril Hoehle and one by me. 

I've not been able to work on my version for four months, but I'll
resume my work on it as soon as I can.

It seems that Joerg-Cyril's version can be used at least with clsql.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
From: Kenny Tilton
Subject: Re: UFFI vs. Boolean
Date: 
Message-ID: <o1sod.18249$ld2.4151266@twister.nyc.rr.com>
Pascal Bourguignon wrote:

> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>Russell McManus wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>>I see also while working on Vasilis's herculean Gtk bindings that
>>>>(a) Clisp has a killer FFI and (b) UFFI does not support CLisp.
>>>>
>>>>Whassup wid dat?
>>>
>>>As you are aware, UFFI is a relatively thin macro layer on top of a
>>>couple of Lisp implementations's FFIs.  So there is an inherent
>>>assumption in the design of UFFI that the underlying FFIs provide
>>>roughly equivalent services, only with different interfaces.
>>>But CLISP's FFI provides higher level constructs and otherwise
>>>doesn't
>>>fit in perfectly with the model assumed by UFFI.  This is not to say
>>>that some enterprising hacker couldn't figure out a way to do it.
>>>I agree that CLISP's FFI is very cool.
>>
>>So I was thinking, maybe anything UFFI semantics call for can be
>>implemented using the CLisp FFI. I did not exhaustively confirm this,
>>so maybe if I tried I would get 80% of the way there and...doh!
>>
>>I realize this would be a comedown from native CLisp FFI, since we
>>would be doing the least common denominator thing, but I think that is
>>unavoidable if one wants portable code. And I do not think CLisp would
>>be the first Lisp held back by the LCD thing.
>>
>>Anyway, I am busily hacking a boolean type into UFFI. Partly. :) I
>>just want to see cells-gtk run under allegrocl. :)
> 
> 
> Already two UFFI for clisp implementations have been started, one by
> Joerg-Cyril Hoehle and one by me. 

Yes, I googled that up and checked it out. Looks intense.

Right now I am doing something really stupid, trying to get a quick 
(ha!) win by just trying to get the CLisp code to work for AllegroCL, by 
deviously conditionalizing Vasilis's own wrappers for FFI macros. ie, 
trying to make FFI-conscious code work on Allegro.

I should just suck it up and rework all the FFI stuff to use UFFI, and 
then yours or J-C's will let the result get back to CLisp.

kt

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film