[gtk-server] Re: string passing/parsing

  • From: Peter van Eerten <administrator@xxxxxxxxxxxxxx>
  • To: gtk-server@xxxxxxxxxxxxx
  • Date: Sat, 4 Dec 2004 00:23:09 +0100

Hi Jim,

Thanks again for your mail!

>if the delimiters arn't embedded in the stream, then
>some form of stream control would be required, like
>prefixing each string with its length, e.g a function
>call could look like:
>
>gtk_show_number_and_name\n
>2\n
>42
>3\n
>bob
>\n
>
>it does avoid having to do any text processing, but
>does require the language to have some form of strlen.

Hmm... I am not sure how well this will work with KSH, BASH and friends. For me,
as I look at it now, the ideal situation would be the proposition of Norman, a
fellow programmer, who contributed to the GTK-server also:

(gtk_func "gtk_text_buffer_insert" buffer iter "Hello world" -1)

As you can see, this code is very clear, no comma's and stuff, and every
interpreted client language can send it without fuzz. (The gtk_func will
actually communicate with the GTK-server.) There are newLisp macro's available
to parse these type of strings; but a real implementation in the GTK-server
itself would be an  improvement.

However, this will shift the old problem to the <space>-character $20, since how
can the GTK-server know if the $20 in the written string "Hello world" is not an
argument separator?

I think that the only way out is some kind of parser, which is able to 'read'
the double-quotes which surround the space. But sometimes a doublequote is part
of the actual string, e.g.:

"This is one: \"1\""

I already use an escape character here, but anyway, the point is that a parser
for this issue seems to be an unpleasant thing to develop. (Maybe it can be done
rather easily using Lex, now I think of it?)

>That sounds like a challenge! After looking at your
>code, I saw that the guts of it came down to loading
>up the right functions from the right librarys, and
>calling them, and CLISP is pretty good at that.
>
>So I gave it a go, and a few macros later I have a
>bunch of function imports, and some code calling it,
>and a GtkWindow on my screen. The signals/events are
>tricky (because of the data variable being last, and
>sometimes the second argument, sometimes the third)
>but I seem to have sorted that out. I also have a
>preliminary glade2 reader (takes in the save file and
>builds up the widgets).
>
>Just like everything else, its all beta, only a few
>days old, I really don't have enough functions defined
>to do anything useful, but the framework is there:
>http://dgym.homeunix.net/clisp-gtk2
>works for me under linux, and under windows too if you
>have all the gtk dll's in the local directory.

That is really cool! Looking into your code it seems you are implementing a kind
of GTK-server directly in CLisp, which is, of course, a better approach with
CLisp. Also your Glade XML reader is a good idea. I am sure the CLisp community
will be very happy seeing this!

>Anyway, back to string passing. It wouldn't be too
>much effort to split the work into three stages:
>the network bit, that reads blocks off the input
>channel.
>the syntax reader - that takes blocks and works out
>the function call/args
>the function call dispatcher - you already have this
>separate
>
>with that in place the syntax reader could be swapped
>out with another one, controlled by command line
>switches/config file. I would certainly be happy to
>write a c style parser capable of accepting:
>function( 42, "some string containing\" and ,\n" )
>
>its just an idea, what do you think?

It seems your idea is intended to send a GTK-string in small pieces, separated
by some delimiter, if I understand it well? Please correct me if I am wrong.
Again, I am not sure if your proposition remains compatible with all the current
shellscript interpreters because of the STRLEN... also, how will the resulting
client script, which sends the GTK functions, look like? Wouldn't the client
code get bigger, more complicated and harder to maintain?

Thanks and greetings from freezing Holland,

Peter

-- 
http://www.gtk-server.org

Other related posts: