Four questions 
Author Message
 Four questions

AS EVERYBODY KNOWS THE TRIVIUM IS FOLLOWED BY THE QUADRIVIUM.

(1)
This is maybe a stupid question: Has GTK anything to do with Tk? Is it a Tk
idiom?

(2)
And why are you using the word "binding"? Has this word some special
meaning? I saw that the HASKELL people also talk about a "GTK binding".

(3)
Several LISP implementations like CLISP or Coman Lisp have a foreign
function call interface and offer call-back support (actually I do not know
if CLISP does). So if you want to create a "GTK" binding or the possibility
to use Tk (which may be completely different things): What has to be done?
Is it easy to implement or is it a lot of work?

(4)
Let us suppose in LISP the variable x contains a string. I would like to
split the string into different parts like with STRTOK in C or SPLIT in
Python. Then I would like to return the substrings in a list. Is there a
function in LISP to do that? (Clearly I could easily write such a funktion.)

Janos Blazi



Thu, 18 Apr 2002 02:00:00 GMT  
 Four questions

Quote:

> (2) And why are you using the word "binding"? Has this word some
> special meaning? I saw that the HASKELL people also talk about a
> "GTK binding".

see Q3

Quote:
> (3) Several LISP implementations like CLISP or Coman Lisp have a
> foreign function call interface and offer call-back support
> (actually I do not know if CLISP does). So if you want to create a
> "GTK" binding or the possibility to use Tk (which may be completely
> different things): What has to be done?  Is it easy to implement or
> is it a lot of work?

(someone please correct me if i am wrong)

binding is attaching a function (your call-back) to an event.  for
example, in emacs, i can bind a function to a key.  when i press that
key, the aforementioned function is called (with some arguement(s)
telling me what key was pressed and in what circumstances).  lisp
nomenclature calls it a binding rather that a call-back.

lisp is especially good at this since functions are first class
objects.  in emacs, i have a few keys bound to anonymous lambda
functions.  i also use advise to modify existing functions.  this can
be very useful and powerful.

--
J o h a n  K u l l s t a m

Don't Fear the Penguin!



Thu, 18 Apr 2002 02:00:00 GMT  
 Four questions

Quote:


> > (2) And why are you using the word "binding"? Has this word some
> > special meaning? I saw that the HASKELL people also talk about a
> > "GTK binding".

> see Q3

Look further down.

Quote:

> > (3) Several LISP implementations like CLISP or Coman Lisp have a
> > foreign function call interface and offer call-back support
> > (actually I do not know if CLISP does). So if you want to create a
> > "GTK" binding or the possibility to use Tk (which may be completely
> > different things): What has to be done?  Is it easy to implement or
> > is it a lot of work?

> (someone please correct me if i am wrong)
O.K. ;-)

> binding is attaching a function (your call-back) to an event.  for
> example, in emacs, i can bind a function to a key.  when i press that
> key, the aforementioned function is called (with some arguement(s)
> telling me what key was pressed and in what circumstances).  lisp
> nomenclature calls it a binding rather that a call-back.

> lisp is especially good at this since functions are first class
> objects.  in emacs, i have a few keys bound to anonymous lambda
> functions.  i also use advise to modify existing functions.  this can
> be very useful and powerful.

That is a binding but not what people are talking about when that say
a binding to GTK or some such thing.  A binding is an interface from
some library or body of code in a different language presented in an
esthetically pleasing manner.  It is more than just ffi.  For
instance a binding for GTK in lisp would not only map the raw
functions of the GTK library to lisp functions it would also present
thin in a Lispy way, for instance GTK objects could be mapped to CLOS
objects.   People also talk about thick and thin bindings where a
thin binding is little more than a set of ffi calls which leave the
original C:ness or whatever of the original library untouched.  While
a thick binding attempts to wrap up the system in code to present
things in the wrapping languages native way.

-Eric



Thu, 18 Apr 2002 02:00:00 GMT  
 Four questions

Quote:

> AS EVERYBODY KNOWS THE TRIVIUM IS FOLLOWED BY THE QUADRIVIUM.

> (1)
> This is maybe a stupid question: Has GTK anything to do with Tk? Is it a Tk
> idiom?

GTK: Gnome ToolKit, which is a GUI toolkit on Linux.  Its primary
purpose is to implement a graphical window manager called Gnome.  Go to
http:/www.gnome.org .

Quote:
> (2)
> And why are you using the word "binding"? Has this word some special
> meaning? I saw that the HASKELL people also talk about a "GTK binding".

In this context it simply means the language has been equipped with
facilities (functions, data structures etc.) that allow using GTK -
i.e., foreign function calls and some wrappers packaged in the form of a
library.

Quote:
> (3)
> Several LISP implementations like CLISP or Coman Lisp have a foreign
> function call interface and offer call-back support (actually I do not know
> if CLISP does). So if you want to create a "GTK" binding or the possibility
> to use Tk (which may be completely different things): What has to be done?
> Is it easy to implement or is it a lot of work?

It requires familiarity with both GTK and the ffi (foreign function
interface).  Typical problems include data conversions and callbacks.
Maybe you could look at some existing implementation (e.g., the one
Duane Rettig referred to a few days ago), and try to understand it.

Quote:
> (4)
> Let us suppose in LISP the variable x contains a string. I would like to
> split the string into different parts like with STRTOK in C or SPLIT in
> Python. Then I would like to return the substrings in a list. Is there a
> function in LISP to do that? (Clearly I could easily write such a funktion.)

As far as I remember, C and Lisp store strings in a very different way -
browse amongst former c.l.l. postings, I think it was discussed once.

Regards
Robert



Thu, 18 Apr 2002 02:00:00 GMT  
 Four questions

Quote:
> (4)
> Let us suppose in LISP the variable x contains a string. I would like to
> split the string into different parts like with STRTOK in C or SPLIT in
> Python. Then I would like to return the substrings in a list. Is there a
> function in LISP to do that? (Clearly I could easily write such a funktion.)

Browse the Dejanews archives. Several versions of such a function
have been posted.


Fri, 19 Apr 2002 03:00:00 GMT  
 Four questions

Quote:

> (1)
> This is maybe a stupid question: Has GTK anything to do with Tk? Is it a Tk
> idiom?

No. "tk" in each name stands for "toolkit". They're both toolkits;
that is, things for making window-based applications with a consistent
look and feel.

Quote:
> (2)
> And why are you using the word "binding"? Has this word some special
> meaning? I saw that the HASKELL people also talk about a "GTK binding".

A binding is anything that associates things with other things.
So, a variable binding associates the name of the variable with
its value (or, the symbol used to refer to the variable with
a memory location containing the value; or, some other variant
on the same theme). And a "GTk binding" for a programming
language is a bunch of functions/procedures/objects/whatever
in that language that provide the features of GTk. It associates
functions/[etc] with GTk facilities.

--

sig under construction



Fri, 19 Apr 2002 03:00:00 GMT  
 Four questions

Quote:

> GTK: Gnome ToolKit, which is a GUI toolkit on Linux.  Its primary
> purpose is to implement a graphical window manager called Gnome.  Go to
> http:/www.gnome.org .

Nitpicking....

GTK == Gimp ToolKit. Gnome is not a window manager, nor does it even
have its own window manager, unlike KDE. (Actually, WindowMaker may be
the standard Gnome window manager, not that I know for sure or really
care; Gnome so far hasn't impressed me much....)

Christopher



Fri, 19 Apr 2002 03:00:00 GMT  
 Four questions

Quote:

> Let us suppose in LISP the variable x contains a string. I would like to
> split the string into different parts like with STRTOK in C or SPLIT in
> Python. Then I would like to return the substrings in a list. Is there a
> function in LISP to do that? (Clearly I could easily write such a funktion.)

No ready-made function similar to either strtok or split is contained
in the ANSI Common Lisp standard.  Writing such a function is indeed
quite easy, _after_ you've had a hard time deciding on the semantics
and pragmatics of such a function (for example C's strtok and Perl's
split have quite different semantics and pragmatics, and there are
pros and cons with both approaches, even if you ignore the inherent
flaw that strtok is not safe to reenter).

Fire up dejanews on comp.lang.lisp to find a huge collection of
solutions for problems in this domain...

Regs, Pierre.

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]



Fri, 19 Apr 2002 03:00:00 GMT  
 Four questions

Quote:

> No. "tk" in each name stands for "toolkit". They're both toolkits;
> that is, things for making window-based applications with a consistent
> look and feel.

It's interesting that the use of the word has changed  in the last few
years as well.  X used to have Xt -- the `X toolkit', which was
specifically *not* about look and feel, but about mechanism.  On top
of this there are widget sets -- the athena widgets, the motif
widgets, which do the look & feel stuff.

I get the impression that most of the newer toolkits (new sense) don't
actually use Xt but live on top of raw xlib or something.

--tim



Fri, 19 Apr 2002 03:00:00 GMT  
 Four questions

Quote:

> (4)
> Let us suppose in LISP the variable x contains a string. I would like to
> split the string into different parts like with STRTOK in C or SPLIT in
> Python. Then I would like to return the substrings in a list. Is there a
> function in LISP to do that? (Clearly I could easily write such a funktion.)

There is no built-in.  Tokenizing is something that's harder than you
think to do in a general way -- the C strtok basically doesn't work
(not reentrant), and there are a whole load of ways of deciding what a
token is &c, which people usually never think about.  The SCSH manual has
some stuff on this.

That being said, there have been a number of tokenizers posted here,
and here is my one.  This uses what the DP people would call an
`iterator' or a `cursor', although in Lisp you hardly need a design
pattern for that.  It's emphatically not suitable for the standard
`read every line and split it' type job as it conses a closure for
each string it tokenizes, which is often much bigger than the string.
However it's useful if you have some string that you may want to get
some more tokens from later: you just make a tokenizer for it and then
ask it for more tokens when you need them.

It may have bugs -- I've used it but my data was rather regular.

--tim

(defun make-tokenizer (string &key (bag '(#\Space #\Tab #\Newline))
                                   (separator-function
                                    #'(lambda (c)
                                        (member c bag)))
                                   (start 0))
  ;; Make a tokenizer for STRING.  SEPARATOR-FUNCTION, if given,
  ;; should take one argument, a character, and return true if this
  ;; character is a token separator.  If it is not given, it defaults
  ;; to a function which returns true if the character is in BAG.
  ;; START says where to start.
  (let ((len (length string))
        (curpos start))
    #'(lambda ()
        (if curpos
            (let* ((up (loop for j upfrom curpos
                           while (and (< j len)
                                      (funcall separator-function
                                               (aref string j)))
                           finally (return j)))
                   (down (loop for j upfrom up
                             while (and (< j len)
                                        (not (funcall separator-function
                                                      (aref string j))))
                             finally (return j))))
              (setf curpos down)
              (if (= up down)
                  ;; found nothing, which ought to mean end of string
                  ;; (should check this)
                  nil
                  (subseq string up down)))))))

(declaim (inline next-token))

(defun next-token (tokenizer)
  (funcall tokenizer))

#||
(defun collect-tokens (s)
  ;; bad use of it but good test
  (loop with tokenizer = (make-tokenizer s)
      for tok = (next-token tokenizer)
      while tok
      collect tok))
||#



Fri, 19 Apr 2002 03:00:00 GMT  
 Four questions

Quote:


> > No. "tk" in each name stands for "toolkit". They're both toolkits;
> > that is, things for making window-based applications with a consistent
> > look and feel.

> It's interesting that the use of the word has changed  in the last few
> years as well.  X used to have Xt -- the `X toolkit', which was
> specifically *not* about look and feel, but about mechanism.  On top
> of this there are widget sets -- the athena widgets, the motif
> widgets, which do the look & feel stuff.

> I get the impression that most of the newer toolkits (new sense) don't
> actually use Xt but live on top of raw xlib or something.

GTK doesn't use Xt because the guy that wrote the first version of GTK
in cooperation with the guy writing the Gimp wanted the added
challenge of reinventing the wheel and not using Xt (which makes a lot
of things a lot easier). QT doesn't use Xt because it is a true
cross-platform thing.

Christopher



Fri, 19 Apr 2002 03:00:00 GMT  
 Four questions
Janos:

Quote:
>> (3)
>> Several LISP implementations like CLISP or Coman Lisp have a foreign
>> function call interface and offer call-back support (actually I do not know
>> if CLISP does). So if you want to create a "GTK" binding or the possibility
>> to use Tk (which may be completely different things): What has to be done?
>> Is it easy to implement or is it a lot of work?

>It requires familiarity with both GTK and the ffi (foreign function
>interface).  Typical problems include data conversions and callbacks.
>Maybe you could look at some existing implementation (e.g., the one
>Duane Rettig referred to a few days ago), and try to understand it.

just to answer janos' last sentence on (3):
it is harder to implement for lisp than for other languages, esp. for
callbacks. calling c funcs just involves data conversion, stack handling
and alignment issues. (this is common for all inter-language bindings)
callbacks also must have GC support. (current reference counted
languages such as perl or python can support callbacks much easier)

first, the GC has to be aware of such external objects, either to be
able to re-adjust pointers (not really possible on callbacks) or keep it
in a fixed position and do memory management differently for the ffi
heap.

second, lisp types are generally not c compatible. either tags are used
to indicate lisp types (those bits have to be filtered out on
conversion), or nodes consisting of structs or combinations thereof.
so ffi data needs a c-compatible external area for the lisp-side.

functional style vs side-effects:
lisp functions are normally used functionally, just passing args and
returning values without side-effects.
externally bound languages (C/C++) are typically not that side-effect
free, either immediate globals are used for communication or mostly
pointers to arrays or structures. this is faster than copying them, but
not that safe. most c funcs just return a success/error word whilst lisp
functions pass the whole structure (or better pointers to it)

a typical lisp ffi can now work in lisp style (functional): return
copies or nil on errors or c style (side-effects): using the pointer to
the malloced ffi data. also every better ffi has some convenience macros
(or even CLOS objects) to deal with c structures.

imho fine lisp ffi's come with ACL and corman lisp, the clisp and
lispworks ffi is also very okay (don't know cmucl's "alien" enough nor
the mcl ffi).
on the other hand most scheme ffi's such as with guile, gambit et al.
work very low-level, more on the c side.

--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html



Sat, 20 Apr 2002 03:00:00 GMT  
 Four questions
I agree with what you say. I just wanted to make a small point:

Quote:

> current reference counted languages such as perl or python can support callbacks
> much easier

It is a shame that this does not always work in perl. I have got perl to core dump
on a number of ocassions when a callback had been gc'd.

Best Regards,

:) will



Sun, 21 Apr 2002 03:00:00 GMT  
 Four questions

Quote:

> a typical lisp ffi can now work in lisp style (functional): return
> copies or nil on errors or c style (side-effects): using the pointer to
> the malloced ffi data. also every better ffi has some convenience macros
> (or even CLOS objects) to deal with c structures.

> imho fine lisp ffi's come with ACL and corman lisp, the clisp and
> lispworks ffi is also very okay (don't know cmucl's "alien" enough nor
> the mcl ffi).

Just another data-point:
CMUCL's alien ffi is also very nice, high-level and easy to use, IMHO,
at least for the direction Lisp -> C (callbacks into Lisp seem to be a
bit of a problem, at least as far as ILU is concerned.  You'd have to
ask Joachim Achtzehnter about this, he seems to have studied the
situation in some detail;  see his posting in comp.lang.lisp a while
back).

I've been able to use it with no problems and very little doc reading
to generate some mappings to C code (see the mappings in MaiSQL for
examples).

From the postings of MCL users on c.l.l it seems that MCL's ffi is
also quite nice...

Regs, Pierre.

--

  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]



Sun, 21 Apr 2002 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Four questions...

2. four questions

3. Four more basic questions about Eiffel

4. Camp Smalltalk Four

5. The four byte bug lives

6. "Smalltalk-Architect-Contract(four positions)-KS"

7. "Smalltalk-Contracts (four positions)-KS"

8. "Smalltalk-Contracts (four positions)-KS"

9. "Smalltalk-Contracts (four positions)-KS"

10. "Smalltalk-Contracts (four positions)-KS"

11. "Smalltalk-Contracts (four positions)-KS"

12. Four related files in report

 

 
Powered by phpBB® Forum Software