q-lang-users — general discussion, questions, suggestions, etc.

Re: [q-lang-users] cgi.q

[Albert G. <Dr....@t-...>]

Tim Haynes wrote:
> Eep, well spotted. OK, I'm attaching the latest version I have in use here.

Dear Tim,

thanks a lot indeed. I'm ready to commit the new version to cvs, but 
with Q 7.1 I get: Error cgi.q, line 91: invalid character escape `\?'. 
Here's the corresponding line:

                         (regex "" "^http://[^?]+\?(.*)$" HR (reg 1) )

You probably want a \\? there? (Yes, John, I admit that you were right 
all along: It's hard to spot such bugs without making unrecognized char 
escapes a syntax error. (-:)

>    * A `strictatoi' function (a wrapper around val that only works if the
> string is a number - saves a risk of Q-injection! - also uses `matches')

I don't know whether this is helpful, but you can also use `valq' to do 
a "safe parse" without evaluating anything:

safe_atoi S = I where 'I:Int = valq S;


BTW, do you still have a Q-powered page available anywhere? I remember 
that you once had a part of the interface to your picture collection 
written in Q, is that still the case?

In case someone is interested in this side of Q programming, I also have 
a little Q-powered website. The entry point is here:

http://muwiinfa.geschichte.uni-mainz.de:5050/kirnberger.html

It lets you throw the dice (you must have JavaScript enabled in your 
browser to make that work) and compose your own random "Kirnberger 
polonaise", which is then served as a MIDI file. Instructions and a link 
to the source code of the script are on the page.

Hmm, it just came to me that I should probably put some Q cgi scripting 
examples on q-lang.sf.net...

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

[John C. <co...@cc...>]

Albert Graef scripsit:

> Oops, I goofed. Had to fix a memleak and a missing return value, all in 
> CVS now.
> 
> I also made an attempt to fix the qexecv segfaults that you see on 
> Cygwin. Would be nice if you could check out q.c and try it out again.

Success!

Your defref program does just what it should, and hello and pmq now also
work right with any number of arguments.  I also reran all the standard tests
with "make test", and they are all fine.

I think you should add the "-lqint -liconv -lgmp -lq" incantation to
Appendix C for Cygwin users.

Thanks for everything!

-- 
It was impossible to inveigle           John Cowan <co...@cc...>
Georg Wilhelm Friedrich Hegel           http://www.ccil.org/~cowan
Into offering the slightest apology
For his Phenomenology.                      --W. H. Auden, from "People" (1953)

[q-lang-users] cgi.q (was: Q 6.2 is out)

[Albert G. <Dr....@t-...>]

BTW, Tim, what became of the improved cgi.q version you promised a while 
ago? ;-) CGI programming is an area where Q is still a bit weak when 
compared to the likes of PHP and Python. So I'm _very_ interested in 
your work on this. I think that most of the basic stuff is already there 
(Apache module, XML support etc.), so it's more a matter of wrapping 
this up in a nice high-level API. If I can be of any help to get the new 
cgi.q out of the door then please let me know.

Tim Haynes wrote:
>>cgi.q should be ok (at least the version included with the Q core package
>>is), I checked that.
> 
> There'll be a better version - it's evolved POST and PATH_INFO handling in
> the meantime :)

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] CVS issues/Q 7.1

[Albert G. <Dr....@t-...>]

Ok, it looks like the ML archives are in sync again. Thanks to the 
sf.net staff. :)

BTW, does anyone here know how to remove spam from a sf.net mailing list 
archive? Is there a direct way to do this in the admin interface? I 
couldn't find any... And all the sf.net site docs say about this is that 
sf.net doesn't send out spam by policy. ;-)

Albert Graef wrote:
> Hmm, I don't what the heck is wrong with sf's mailing lists again. I 
> keep getting posts from myself which are delivered several days late. 
> Does anyone else experience this? And the ML archive still hasn't been 
> updated...

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Q as a 2Lisp

[Albert G. <Dr....@t-...>]

Keith Trenton wrote:
> 
>>Never mind, I just found the PhD thesis on library.readscheme.org. 
>  
> Hah! 761 pages! But yes, I will read it (with coffee and anime breaks :) from beginning to end.

More the size of a habilitation thesis in the humanities. :) Well, my 
download died halfway through, will have to try again when I'm back at 
the office.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Q as a 2Lisp

[Keith T. <kaz...@ea...>]

John Cowan wrote:
>I don't know.  Most of the book is in fact about 2Lisp; only the last chapter or so covers 3Lisp, and it was less interesting to me. 

Fair enough. If 3Lisp was more of a 2Lisp++, then "Q as a 2Lisp" makes more sense to me, too. Thank you for starting this thread; I enjoy tangential (oblique?) learning opportunities!

Cheers,
Keith 
 

Re: [q-lang-users] Q as a 2Lisp

[John C. <co...@cc...>]

Keith Trenton scripsit:

> Hah! 761 pages! But yes, I will read it (with coffee and anime breaks
> :) from beginning to end. Would it be more correct to say that Q has
> a 3-Lisp core, as opposed to a 2-Lisp core (given that the 3-Lisp
> extesions added in the ability for reflection)?

I don't know.  Most of the book is in fact about 2Lisp; only the last
chapter or so covers 3Lisp, and it was less interesting to me.

-- 
Income tax, if I may be pardoned for saying so,         John Cowan
is a tax on income.  --Lord Macnaghten (1901)           co...@cc...

Re: [q-lang-users] Compilation time

[Albert G. <Dr....@t-...>]

Hi Arnoldo,

Arnoldo Muller wrote:
> Well, yeah the rules are generated and they are actually term rewriting 
> rules.
> checkAvailability (X,Y) could be written in q as X = Y.
> However I don't really want to transform expressions, I want to find 
> patterns between pairs of expressions and make sure that the pattern I 
> find is in a database. The file I sent you is the database of "learned" 
> patterns

Ok, I see. So what you actually need is a data structure to represent 
relations on arbitrary expressions. The easiest way to do this would be 
to store the pairs as keys in a hashed dictionary. Something like:

learn T R = update T R true;
available T R = member T R;

Here, T is the table of learned rules (emptyhdict initially) and R the 
rule to be learned or checked. The associated value "true" could 
actually be anything, so you could also use it to store some more info 
with each learned rule.

If you only need a simple global instance of the table, and you don't 
mind a little imperativeness, you can also do this with a global 
reference, as follows:

def T = ref emptyhdict;

learn R = put T (update (get T) R true);
available R = member (get T) R;

Then you could just do, e.g.:

==> learn (farrayRef (V0,fphi (fintConstant 1,V1)),farrayRef (V0,fphi 
(flocalRef BC0,V1)))

==> learn (fstaticInvoque (fmethodRef (AC0,AC1),V0),fphi (flocalRef BC0,V0))

...

That way, you don't have to keep track of the T parameter all the time.

Of course, there are other ways to store such relations efficiently, but 
hdicts are probably the easiest way to go to solve your problem. If the 
rules don't get arbitrarily large then this implementation should 
certainly be fast enough.

> What I've been doing 
> is to put all these learned patterns in a database as strings (in a hash 
> table), and learn a new pattern every time I want to match  expressions 
> and search the hash table.

No need to resort to strings there, with hdicts the keys can actually be 
arbitrary values. See http://q-lang.sf.net/qdoc/qdoc_11.html#SEC67.

> Sorry for the huge delay, but japanese works like a charm in 7.0 
> : )

Very good news, thanks for the report! And thanks for the nice 
real-world example of a pattern set which makes deterministic 
left-to-right matching explode. ;-)

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Q as a 2Lisp

[Keith T. <kaz...@ea...>]

 
Albert Graef wrote: 
>Never mind, I just found the PhD thesis on library.readscheme.org. 
 
Hah! 761 pages! But yes, I will read it (with coffee and anime breaks :) from beginning to end. Would it be more correct to say that Q has a 3-Lisp core, as opposed to a 2-Lisp core (given that the 3-Lisp extesions added in the ability for reflection)? 
 
Cheers,
Keith 
 

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

[Albert G. <Dr....@t-...>]

John Cowan wrote:
>>That's in CVS now. A simple example is attached below.
> 
> Thanks.

Oops, I goofed. Had to fix a memleak and a missing return value, all in 
CVS now.

I also made an attempt to fix the qexecv segfaults that you see on 
Cygwin. Would be nice if you could check out q.c and try it out again.

>>Then you'll have to use libtool to compile your sources, too. If you 
>>want to do this, the easiest way to go is to autotoolize your program 
>>and use an automake Makefile. Automake makes handling libtool libraries 
>>much easier.
> 
> I don't think I want to go there, at least not yet.

Already thought so. :) Autotools is quite a time investment, but it pays 
off eventually. Scons appears to be simpler but it still has to prove 
itself.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Compilation time

[Arnoldo M. <arn...@gm...>]

Dear Dr Albert:

Thank you for your prompt reply.

Well, yeah the rules are generated and they are actually term rewriting
rules.
checkAvailability (X,Y) could be written in q as X =3D Y.
However I don't really want to transform expressions, I want to find
patterns between pairs of expressions and make sure that the pattern I find
is in a database. The file I sent you is the database of "learned" patterns
I will try the suggestion you gave me. Thank you. What I've been doing is t=
o
put all these learned patterns in a database as strings (in a hash table),
and learn a new pattern every time I want to match  expressions and search
the hash table. Maybe your suggestion is faster than learning the pattern
each time.

Sorry for the huge delay, but japanese works like a charm in 7.0
: )

regards,

Arnoldo


On 5/19/06, q-l...@li... <
q-l...@li...> wrote:
>
> Send q-lang-users mailing list submissions to
>         q-l...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/q-lang-users
> or, via email, send a message with subject or body 'help' to
>         q-l...@li...
>
> You can reach the person managing the list at
>         q-l...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of q-lang-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Compilation time (Albert Graef)
>    2. Re: Compilation time (Albert Graef)
>    3. Re: CVS head failed to build, flex yytext_ptr problems (Peter
> Minten)
>    4. Love is a canvas furnished by Nature and embroidered by imagination
> (caleb nikolaus)
>    5. Re: Request to add new reserved words "quote" and
>        "QUOTE" to Q (Albert Graef)
>    6. Re: Q as a 2Lisp (Albert Graef)
>    7. Re: Q as a 2Lisp (Albert Graef)
>    8. Re: Request to add new reserved words "quote" and "QUOTE" to Q (Joh=
n
> Cowan)
>
> --__--__--
>
> Message: 1
> Date: Thu, 18 May 2006 07:05:36 +0200
> From: Albert Graef <Dr....@t-...>
> To:  q-l...@li...
> Subject: Re: [q-lang-users] Compilation time
> Reply-To: q-l...@li...
>
> Arnoldo Muller wrote:
> > I am trying to compile a 106 rule script (attached in this e-mail). I
> > started it an hour ago and hasn't finished yet.
>
> Nice one. ;-) Could be one of the rare cases where the deterministic
> matching automaton has an exponential size. But more likely it's just a
> bug. I'll have to look into it.
>
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr....@t-..., ag...@mu...
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
>
>
> --__--__--
>
> Message: 2
> Date: Thu, 18 May 2006 09:02:51 +0200
> From: Albert Graef <Dr....@t-...>
> To:  q-l...@li...
> Subject: Re: [q-lang-users] Compilation time
> Reply-To: q-l...@li...
>
> Dear Arnoldo,
>
> Arnoldo Muller wrote:
> > I am trying to compile a 106 rule script (attached in this e-mail). I
> > started it an hour ago and hasn't finished yet.
>
> Sorry for the bad news, but it looks like you really hit one of the
> (few?) cases where the deterministic left-to-right tree matching
> automaton is exponentially larger than the nondeterministic one.
> Specifically, it seems that the number of states triples with each rule
> (at least some of them), and you can imagine where that leads... In
> fact, I isolated three of the rules near the beginning of your script
> which already produce an automaton with more than 4500 states. And the
> effect even gets worse with a bugfix I recently did to resolve an
> obscure bug in the pattern matching code. :(
>
> Well, it's the first real-world example that I see which exhibits the
> behaviour. I suppose that your ruleset is generated in some way?
>
> There's still the faint possibility that there might be a bug in my
> implementation of the pattern matching algorithm, I'll have to take
> another look at the generated automata to figure this out. Even if it
> doesn't turn out to be a bug, there might be ways to cope with the
> situation, but not with deterministic left-to-right matching, and in any
> case that surely needs a complete overhaul of the pattern matching
> algorithm. (AFAICS, using backtracking matching is not an option in
> general, since that would make the pattern matching much too slow.)
>
> To work around this problem, the only thing I can suggest right now is
> to rewrite the overlapping rules in order to reduce the complexity. E.g.:
>
> checkAvailability (X,Y) =3D true where X =3D farrayRef (V0,fphi
> (fintConstant 1,V1)), Y =3D farrayRef (V0,fphi (flocalRef BC0,V1));
>
> I know that this is not very convenient (kind of defeats the purpose of
> using term rewriting), and it will also be slow since this effectively
> makes the pattern matching work in a backtracking way. But I hope it's
> still a workable solution until I find something better.
>
> Cheers,
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr....@t-..., ag...@mu...
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
>
>
> --__--__--
>
> Message: 3
> Date: Thu, 18 May 2006 10:28:41 +0200
> From: Peter Minten <pet...@wa...>
> To: q-l...@li...
> Subject: Re: [q-lang-users] CVS head failed to build, flex yytext_ptr
> problems
> Reply-To: q-l...@li...
>
> Albert Graef wrote:
> > Peter Minten wrote:
> >> This works. However when I removed the qclex.c file (which was in the
> >> archive) and ran make again to recreate the file it fails in exactly
> >> the same way as before (not suprisingly as there is no difference
> >> between the 7.1rc2 qclex.l file and the one in CVS HEAD).
> >
> > Ok, so we know for sure now that it's a flex compatibility issue.
> >
> > The necessary change apparently is to move all the routines which use
> > unput to the first %{ %} code section of the Lex source. Unfortunately,
> > that doesn't work with older Flex versions. Stupid. :(
> >
> > I've attached a patch which I *think* should make qmlex.l compile,
> > according to the little documentation that I have about this "feature"
> > of the new flex version. Could you please try whether that works for
> you?
>
> ~/Desktop/q-7.1/src$ make
> /bin/sh ../ylwrap qmlex.l lex.yy.c qmlex.c -- flex -I
> if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libltdl       -DYEAR=3D'"2006"'
> -DSYSINFO=3D'"i686-pc-linux"'
> -DQPATH=3D'".:/usr/local/share/q/lib:/usr/local/lib/q"'
> -DQEXEC=3D'"/usr/local/bin/q"' -DLIBTOOL=3D'"/usr/local/lib/q/libtool"'
> -DCC=3D'"gcc"'  -g -O2 -MT libglobs_a-qmlex.o -MD -MP -MF
> ".deps/libglobs_a-qmlex.Tpo" -c -o libglobs_a-qmlex.o `test -f 'qmlex.c'
> || echo './'`qmlex.c; \
> then mv -f ".deps/libglobs_a-qmlex.Tpo" ".deps/libglobs_a-qmlex.Po";
> else rm -f ".deps/libglobs_a-qmlex.Tpo"; exit 1; fi
> qmlex.c:1396: warning: conflicting types for 'yyunput'
> qmlex.c:1396: error: static declaration of 'yyunput' follows non-static
> declaration
> qmlex.l:287: error: previous implicit declaration of 'yyunput' was here
> qmlex.c:1411: error: static declaration of 'input' follows non-static
> declaration
> qmlex.l:202: error: previous implicit declaration of 'input' was here
> qmlex.l:669: error: static declaration of 'initbuf' follows non-static
> declaration
> qmlex.l:343: error: previous implicit declaration of 'initbuf' was here
> qmlex.l:674: error: conflicting types for 'addbuf'
> qmlex.l:674: note: an argument type that has a default promotion can't
> match an empty parameter name list declaration
> qmlex.l:298: error: previous implicit declaration of 'addbuf' was here
> make: *** [libglobs_a-qmlex.o] Error 1
>
> Greetings,
>
> Peter
>
>
> --__--__--
>
> Message: 4
> From: "caleb nikolaus" <eye...@co...>
> To: "gene jakeb" <q-l...@li...>
> Date: Thu, 18 May 2006 10:10:54 +0000
> Subject: [q-lang-users] Love is a canvas furnished by Nature and
> embroidered by imagination
> Reply-To: q-l...@li...
>
> ------=3D_NextPart_000_A89B_53D40CE1.F627A89B
> Content-Type: text/html; charset=3Dus-ascii
> Content-Transfer-Encoding: 7bit
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <title>defense laboredly</title>
> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-asci=
i">
> </head>
>
> <body>
> <b>Hail!</b><br>
> <div align=3D"center">
> <IMG src=3D"cid:0ce1f627a89b$53d40ce1$f627a89b@makenzie" border=3D"0"><br=
>
> <strong><font size=3D"5" face=3D"Verdana, Arial, Helvetica, sans-serif">
> comisarovnety<font color=3D"#CC0000">[dot]</font>com</font></strong><br>
> <br><br>----
> <p>He had only five birds in his game-bag when he walked out of the
> marsh towards the alders where he was to rejoin Stepan
> Arkadyevitch.
> Before he caught sight of Stepan Arkadyevitch he saw his dog.
> Krak darted out from behind the twisted root of an alder, black
> all over with the stinking mire of the marsh, and with the air of
> a conqueror sniffed at Laska.  Behind Krak there came into view
> in the shade of the alder tree the shapely figure of Stepan
> Arkadyevitch.  He came to meet him, red and perspiring, with
> unbuttoned neckband, still limping in the same way.
> "Well?  You have been popping away!" he said, smiling
> good-humoredly.
> "How have you got on?" queried Levin.  But there was no need to
> ask, for he had already seen the full game bag.
> "Oh, pretty fair."
> He had fourteen birds.
> "A splendid marsh!  I've no doubt Veslovsky got in your way.
> It's awkward too, shooting with one dog," said Stepan
> Arkadyevitch, to soften his triumph.
> Chapter 11
> When Levin and Stepan Arkadyevitch reached the peasant's hut
> where Levin always used to stay, Veslovsky was already there.  He</p>
> <br>
> </div>
> </body>
> </html>
> ------=3D_NextPart_000_A89B_53D40CE1.F627A89B
> Content-Type: image/gif; name=3D"nylcfpr.gif"
> Content-Transfer-Encoding: base64
> Content-ID: <0ce1f627a89b$53d40ce1$f627a89b@makenzie>
>
>
> R0lGODdhugH8AMIAAP///8UNBO3t7QAAAACW/+EJCQAAAAAAACwAAAAAugH8AAAD/gi63P4wy=
kmrvTjrzbv/YCiOZGmeaKqubOu+cIwOs0Obd17LHFH5AGBHuCC2bhQkSBdRcpwMKK9EMEqR2AtU=
umxwm5bvVGKElHuOs0q82y7YH7diQB9vqtZHdq61nZxwXmF2GWoNhoVpMYElTFFva36ChBhVkoI=
0mW91fJ1YdHIAn3uiko6jNqBznF6qm6SoeqygUkJAeLZ4DLoKt0WWvUW/ucBBwxCuorOQqZx7mZ=
rKrNJXy6VRqrTY1dbUq87J15QWxcyYpaed1+l+sOpyTO6T4qHwzKR674rBxvy2/P189Qso7BBAg=
f/m6eNz5d69Zw7V5Vt3CaLEhewsmhv3/qNMQ00ZI+KDJG8kRXTbpi0UZ25UFpfc2O0qmLAmLn+9=
bgYjorNmTl7YUirhotHRyaMxPVV8GA6jU6UbOVIod5EhSnpPTV7FyvXRumli5HlFSjLqPJkFCeJ=
cO1OtwYRuESYxOvbsU6hk7R5tGRGZyL5GGUkN4tHvypBdFRY1hdekWL6Jh5pdbJCtwLhr4Q4ceF=
kuQMb6GjaWiJhl1qWj9ZamO7hjuS/4wmmj1zSq7NrxWqrc9G0ibbCtiLrS2pMmUMI+f1YedgsoM=
VlDuyX9FvhwbW97ecPazdWl9aqtB9kRHL68+fO+zZNHX2E9Dvbw48u/zpG+/Pv48+vfz7+//v//=
AAYo4IAKjdeBe5YgMkEg7nnVIIEQRjiCTuA91kgGWpGRyBMesBGLhCCGeEdzZnX1YHsYlqhhJQd=
2uOAlIsYo41REfLRVMrNh11sz0W2RzW1Q3OQLMLpQ6Ml1OUpDEiDv1JHkiTNG+R9VNkbjIGAw3l=
UPlsuR+NlmXI6VkWh0MSnlmVJSZZpVVs5GmY6Q0bLlkbUll1NbkzjGlDOG5SCZimgGSqCaa6IUD=
WVvxilBSSu69cuXqY
>
> lZFVGkVSfopRESWqiJXCaqJWp54XlZW2eg9emmZYKH6aoB4lIMbBu5GWaS1G2DTJuvPGAncrv=
kkZh1GcYDFmusFisglMYm/qvssl0w6+yz0EYr7bTUVmvttdgaCB+yYIjAbV0b7PYgHAr+EN631x=
oJG7pxbMthlimSQC4arXFr37NECrHuOOymMG56GvS7KZ4bDsauwFG+NtFLfor2G2TB6QBOj69A8=
wyQ3FRsa2hNPbnMsE4q83CtGu/YaznH8SLkTzwdB6yiIB/6I8UFUusymbyt9Aijkz4E8aypZRh0=
p76NWTSiRJtBU1pLW3ZQPjx/VfRhOiOccI0Lx0qrVadKypKcJfPsKclI4+U12KjGSt1qqyjtD4X=
FOc0Z1IqafXacOVp9NbjU8Ako191N1teab+YWad15aXR3zVX3fPhuuz499+Sa/pV1KqWREqt3iP=
ny/eefaSM+J+hsQzV22YlPHbjqQx++pp2dSQ67YZfTLpOp2aqbXpncXYQxdLz3eHvmSA4HZEo5Q=
4yj7WJKFzZ3RqbsnA+xs0y7ydjtOzz2m6O5efcvgI+tGuJn662//91r/hCalr/++/DHL//89Ndv=
//345x9ufTCE0qz7qirWegYYr2hhDVTf618kBvYHCJVLXn8DWBKwZyyFIRB94VsgABm4nweOQGj=
XQxHfMHUzurVpFjg6Ho82hg5AzIyFFvEYd5ZHON0wSlzDEZmSclUrFQaHh97wIXOMkaC0uIxOPn=
KSEEvGvY4li3q+OoeVklZD1fjs/oJ5ql0AT2KjyznMTz/LXABfArRfcQYu1buS41ZXxdSR5ol3G=
iFIflM6OGFEVqzzzlbcWCg8dpGNxGJj38KGtxAWbm372IxNjoi7kmztYjnUGatcdUAp8rGOiFNR=
1BqmxlDV7Y+os6LgxJg825RRDJqJXBbXqDjUzImDgqIS87ToSVrqxY2oG52qSHcXUdJyJFs6pBl=
T2TQw1ZJTZsyltCz
>
> IuuzNCjc21KTyIslFG04nkC4U3hip2US/dad3KRTLhw5BPXIW44jHFNl2ptNNECZrg+kLATz1=
R094PUt94qmnPvfJz376858AxZ/e/PdBuxW0EQMt4KLaBcsVrMeD/jIA3ykwxz6gfDGCnmvgCBc=
qwoNCcIsSDCkGAulQjC6HRfHcKJ00oKaLgjSj71FpCLvlUY8ScIIuamhMdcq0C0D0PGYyZCFKZc=
KRARKaTbJQNZO6wh1GjIVOhQbypBrVFz5VhsCDoRDtg1XQjLNjM6OZOVtGVuRYwaom29pXZohWP=
bVwYjQlRwnbcZWyaQVXrluqUvcapiueZZOjBCSoqEhS0XkVNHmUJOWKCSlkdtIerOQLzhwr0wkw=
c2d1TdpdkelWiQkFi2fLGze91rVXNkxc1ryj8V6ERDfMkWwUhSTkjKMyniSWbKN0K6cmCxN7+rS=
SmD2UZkuE12MKC3S3/l2ccm8p2MgaVLmlaQVNCztHtKC2l4kcVa8aC9hkKlacfcxrZXXlpV0q7z=
TmNewqt0daXbZusMJs73cJK0lYiRe8MG2uqCTH2PPqt69Uk2ao0KW7WbYzqRQ98HqjKQsKvoyQz=
YxqGNu2zqw+D2RAzCM4tQbXBlc4DdJ7zqPki1vH6TY2faqUw5o1hnkG9MUBUw8hXAzjGnfUxjjO=
sY53zOMe+/jHQA6ykIdM5CIb+chITrKSl8zkJjv5yVCOspSnTOUqW/nKWM6ylrfM5S57+cvUste=
NF5GfwrK2phzdwf5yKk8a4zTGJq1Xi8vMuDOfj4PduylPSxohd8p4Cm5+/lecxxsvDy2wDy91Qa=
AxmE2tzpBkV7WGDAXz4cCpBI9rFStVw6leCb+1uMjr5sZo9UhOQ7qqMWvqVJfIw9NmeNROZKpTL=
u3DvL0aDEHFZF7FBuAXdffRSvk1MCU7YcNJxqWh/BWy6fvf+XbNlI91pV+ErTq7YojWxqMmZNsY=
w14jibODu5sjuRkz
>
> 5K7T2JiVdmvbFkZkY/q0uvauanFYl9768hy2DK22jzTSN9ass4Httnhxrd7YAq6VhMMmdE2Xb=
l9i01TLvveznS3IWzVuuub99Szdy+43a9zEAf/LwOOabP/mW4wfT1W1AQzxlb833ifutciLHe56=
U9Hh2AUh/ukwfGpvfzK1/YYqpm+pTSCK1dN0hPAnACVaTTtPuk9Na62BTtqgVBqGkKYPDQH2O1R=
N3XTA0SidD71nSixa0NA62E4vNHYMDtrs/Dk7evolMLmD+e54zzu2GJHnIxxW7B/N55pZRVA5x3=
XMCkwz4N2eJb4Lfu2HV2gGDeZbFkMd8X424+QjH3iyF8jxiO885xFNZsrX2fJBebzmB6toO+oon=
E5PtYNRLRw9VlMbwMy2hmP/Ed1HPa06VCvtq40b3zfD6AxuIfB/j3SJcbJCCA61xrpK6t59NOKX=
PHmns8bwvUzR5Kf0+erl/XScm5/E4FKmDle58G8GNtq7pnkb/lmguT2Nad/ud3kf8Y9uyxGdrhU=
Db862dLtnKWs1cc1GWR03SAc3dM5kfopzadyXgOI0WuvHZ9iXSc92XcY1XN4XXt8Vdvm1bQtoS5=
sVfyi4et7UcP6DcOrnI5OBNqdTcBaHgfpXOp7CcTrYfUH1f+ynfp0UcoJ0gh2YgkJjXcvlgsy2Y=
jACczQ4UzuFQyhke813YbeiVNlDQxPFdM9HdDznerThVO01WsK3ddekdV0odBKIdaFmWrJ3dC0I=
LNVgIikEVXMnIzRmd4ynd34nIm6mh2rGh4I4iIRYiIZ4iIh4eufSLXVXMFECiFSWeYsXeolGeg9=
1B4tIiXaWiBPW/nqSR2iW6Ig+lYlvFnScOH2stlRV2IbgZGqq+CFU1UOpGD0okyCM9DGuJmpBJI=
VpyEQStoKnCG4gx20gKG+45EW3ZRKzAyZExW8D6IPoV3DIFYzjhlqv9XrFGHMMmA72ZnDr1iUsU=
17GNIRAJ4LaSIzbq
>
> IiGGDVFNTwuhY7bBmrpVXHgOI6EwV2DkyjedI4cB23BGGBE+BjeCI8z9zU1B5BmsYz91Us5GG=
DRqH3/qB3Jx1xP0gS9yERamH7dkAp0WAshdgwjxoYYaXxY2GFeOGwRWXr6BIkpaXj0hE8tGZMyO=
ZM0WZM2eZM4mZM6uZM82ZM++ZNAGZRCOZREWZRG/nmUSJmUSrmUTNmUTpmI/wJoZ6J22bGTwkd2=
efh2cadBo/eP00h/oBiFeMiVUOiVFkmFyxMyDvY5GSYrJjkXSvSF0udpmuOKXaV8O4R7Rlc8kiZ=
rZTeI3ogoM0h+fhWW3dV+hoOYnTJZ2SdKiamVgNlq74ZIBslAt8N/zLeWeINUmeZZ3/dN/OeAk0=
mBIgdGYVmIZtKP/hYWv+RvPMWO6hZcBClxldmY2viYGxmTbPlyq0lcu8lH44dFtwl+TwicLyiEj=
/mXiHiXlbZzwtE8Uxg85KGWRjWGvGRhq4h0WXdCe5WRBwiZTylPIMKSlRee9WJ9/QGTcGee7Nme=
7oll/mbWfeWRC/boAT9VlhJyIuSZP2E3nZX4AmVwn42lK6iXUvhpYFzWn0EHiQGKiebCUMeieB2=
1n/cTXVnXGGzFMLPHK8qxE65CREUCkhzaE7VIKLA3lyIKN0Z0Th8JHXvJi8tXnbL4hbiHnj9moa=
uTnH2iVP9gE0YkOz2VRmk0gbhDKj+KRkAKKSipW2rEV635nzmGowJnmhYmPEEyVqOyjAGqMswxp=
BCWTnEzN0hKOUYyKfhXbzlkpcI5msr5YnKio1OaeknYKJBiW3JjBAr5oxCYkMXUo3qqSuknfqAp=
U7CpgEK2m+6lcnNaFX7KFovlNArppc2ljH1KMFraU1gx/pg5Kn+TSpw+hqiqZmytCIz0MT2VU0S=
Tw6FmNWIhVipnqlZhaqcpuqLkE52KFXyv2oodaXIUaj69CkfX8qt7V2QCuirC+p7ImqzK6pISin=
YH6iyFt6yhWIqe93
>
> jquShyqS1VJ60ep4lspwXmyGZFGlGsR5TMmXwWE1YiWWscWHzZanMVgovnN02ahqsZE31QmpP=
H6YzC+Iq+w4gYp4I/5Eq114nFBQ9HOHOSaJX2538ySGIPu43RsaMbV4bbSo8IeCNNFxiB6ZBGiX=
A30oQaWJULyIEXiF27g5wbR1zGyBrtSkpHqY+L2qnK9m82O3DXuVztJ7LvNYIjZ64TaRpb/kdh6=
Pqit/adJwk84ySSx3e0vvOGdoh8F8qtUUq1y2m1WJu1Wru1XNu1Xvu1YBu2Yju2ZFu2Znu2aJu2=
aru2bNu2bvu2cBu3chsj8UmtLTIwchetIlWtYBmZt9qV+YQuJPUtgvs3C4tmfSiIWAi4E3pn9gW=
hEMqa+SqeKqm4huK0fmSvtqKXmmeXfnmuHeYmwJYbNQqjd2mdvth0SzJ7J+qLfFhdFCcshuUOFy=
Vw8HcxRJpb8smPsfukuJto8ZZ3sMuAi6OmQktsjaewmGk37/ZIlztga/pt3biEctpUYyO8zyu5q=
jh/u8V1pUm920dXwmWohYpvswmcJUizbWpl/vhVvAuHYlMTp7xZm+wFsZx6vfTruxIEhH77NaOa=
nOxam01LlxdWr9L3luhHnXN4dZ9XfqqrYld4mTbansc6t2lnwRicwRrMZHr7rKRHCMW6iQXKtoe=
7t58InkNwZ+urrZYFN7WIqRXMTyVcnqZIw1SgwjF8mnfqqJObZaXLwNsJh+06Mbl2a1DUodaTqq=
a6QqeLkepktAQLo2KYXU1TTjYMZry2sj37g9D3XHH0qJghpjAcvvlHFsPpXAMzpvc4jjm8kp/Us=
d+4YelIsG4TjknqKGZVGPPWj9K5g9B4UpUTEMBFiOz4shh7slX5jogsq3/aX4hQvpmkqDcIWoCM=
/qlWrC9Xm3Ox2XJcnI01I6vVMzuBfJiRHBoqi8a1UI9V7JV4dZFB7GhHM7FRdx14WqLEIGKqKl1=
AjI3o+r89lzOlCmI
>
> N+sUrvMEz5onGLD/u08bJ3MzOvLUFMA7RDAHTPM0jYM12gM0KoM0OwM3cvGNSUADifALfvM3m=
jALjvADWXM4RwM52u87qjAHs7M4aAM+U4M31vAHaLM7YzM8MkM4AQM+E180C3QHzrGYAHdDxLM9=
3+88LrdAXcNDX/NDZ3M35LM8Jbc8afc4FjSlQkNAlINExVc3bzM8mXdLr7M8B7c8p3dLYHM4KHc=
0tTc0qvdIbDdE4XdMy3c8sXdM2/q3OPf3NJJ3TAL3TRJ3OQz3UNj3TFNDPC33TMj0BJ43SGa3TU=
73SJU3VO83TRV3NLu2ip0YrJm3USO3TV90AV63THP3Qaj3O9nwNSv3WNw3Rcx3XJRLVUZ3TFr3W=
fG3Xeo3Ve/3XdU3RfX3OdD3YdF3YfI3T7ezQi53Shi3VXp3VgF3WlG3ZlT3ZmX3Zms1aY9PVPc3=
ZlO3Yia3YiJ3RjH0Dfn3USP3Urv3Ydx3Th+3Thu3VKm3XLq3UaM3WWl3bhC3beT3XpZ3YeA3bSy=
3QTm3cjg3SQH3bmo3ZmL3UQC3am13dZ92GvdbV/zzWWo3PHD3VuN3cre3QL33cq+3d/sPt128N0=
8XN2IGt27D91r/t24vN25Ftzu0t3OoN3Mbd0ZGN2OR939b93AQ+2mld4ANu4LStvh8N2dON1u4s=
3PH92/uc2ox93q+d3vQt39Rs3+4t2K+d3Bve4SOu3ELt4bqN4SWu4aoi4qut2NtN3dCN4KOd4DY=
O0szNvwoe499N4Rme1KQN4rsd2ETN2XI93Uz915si3wtO1c2d4e6t1jSt5FKu5KTN1RT91fTN2k=
9uFtyN0tuN3szd29Ut3dRd4zMu3mFe1mP+gEkH4Q+u5nJO0KAN5ftc1ERezOtIIG3eT/49k8ws2=
TX2589c6IZ+6Iie6Iq+6Ize6I7+6JAe/umSPumUXumWfumYnumavsEJNmcivHngmmInXKDlo5/i=
iQQLXtA1/ZkoUiVS
>
> 8aYIE2iUhsx6NoHHrI6U66wcguok/gAVDjjAG151m3iTSOx2q2a1jli3rsOD1+wuotq9nufT/=
JmOxyQzzGesCxh8Umo3lJqfq0Lpmu3fnkThfmuiWxR9yUVdN7BB7Hy6qJ1qY5K29u74dOd1buYf=
zopQAohOur0kK5jch4OdfL69a4Tfy4PzK+qJA5vRKsvqiyXu5OIrLuB/POpSeaut/JuK2Y6U+bs=
YyplUSrz+hTb2mzqvFbyjGYGiW70k91lHRapX+d8/ft/0vLjeSq4YHxk6ofrwsumyWvOzsUFdI1=
vyIXHyCLivu+Tw1/OVtivJUn3lE5/vD1nD6ymw0FZ/W5zA9QWz7VbwRbipjqXjDO6aPdi58HqMo=
xHxUC/k8z31eY7CgchVDiIdSYTdCNq6zefKWXh0Vhe0EPzxJf/mv7exTwuLIshcw4evqNbUEH7v=
Bj4XGzrkuE61xzrrLUDovm7sW3utVf/p5Nznko35Db3pYJYAADs=3D
> ----=3D_NextPart_000_A89B_53D40CE1.F627A89B--
>
>
>
> --__--__--
>
> Message: 5
> Date: Fri, 19 May 2006 02:42:10 +0200
> From: Albert Graef <Dr....@t-...>
> To:  q-l...@li...
> Subject: Re: [q-lang-users] Request to add new reserved words "quote" and
> "QUOTE" to Q
> Reply-To: q-l...@li...
>
> This is a multi-part message in MIME format.
> --------------070802080107040407060600
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
> Content-Transfer-Encoding: 7bit
>
> John Cowan wrote:
> > Good point, and I think "def" will suffice for now.  That allows one to
> pass
> > a value in to be evaluated by an already-existing expression without
> > having to cons up a new expression.
>
> That's in CVS now. A simple example is attached below.
>
> > There's a couple of problems with libqint on Cygwin:
> >
> > 1) You have to link with -lqint -lgmp -liconv -lq explicitly in order t=
o
> > satisfy the linker.  The -liconv was expected, as Cygwin doesn't have
> > iconv in its default library.  Without -lq, it reports:
>
> Looks like Cygwin gcc is not very clever in resolving dependencies in
> linked shared libs. With both Linux gcc and mingw I only have to specify
> -lqint.
>
> > Should I be using libtool, and if so, how?
>
> Then you'll have to use libtool to compile your sources, too. If you
> want to do this, the easiest way to go is to autotoolize your program
> and use an automake Makefile. Automake makes handling libtool libraries
> much easier.
>
> > 2) More seriously, the sample programs in Appendix C crash when trying
> > to pass additional arguments to qexecl and qexeclx, either with a SIGHU=
P
> > or with a SIGABRT.  The poor man's Q interpreter will crash if you give
> > it command-line arguments other than the script, and the hello-world
> > program crashes when it tries to load the internal script.
>
> Strange. Both programs work just fine over here, both on Linux and
> Windows/mingw. Do you have a gdb backtrace?
>
> > Changing hello.c to use qexeclx(script, strlen(script), 1,
> strdup("Hello!"));
> > works fine, and changing it to use qexeclx(script, strlen(script), 0)
> > sort of works, except that the value of ARGS is ["/tmp/tc40.2"], Ghu
> > only knows why -- there is no such file.
>
> Everything o.k. with that. qexeclx() creates a temporary script file
> which is removed again as soon as the interpreter has loaded the script.
>
> > I realize you probably can't do much about this, but I'm passing it
> along
> > in hopes that you can think of something.
>
> Could be a bug in the interpreter's main (although I doubt this since it
> doesn't show with mingw). Anyway, a backtrace would be helpful since I
> cannot reproduce the error. ;-)
>
> Albert
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr....@t-..., ag...@mu...
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
>
> --------------070802080107040407060600
> Content-Type: text/x-csrc;
> name=3D"vardef.c"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename=3D"vardef.c"
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> #include <qint.h>
>
> int main(int argc, char **argv)
> {
>   int status;
>
>   char *script =3D "def TEST =3D 99;";
>
>   qexeclx(script, strlen(script), 0);
>
>   /* change the value of an existing variable */
>   printf("TEST =3D=3D> %s\n", qeval("TEST", &status));
>   status =3D qdef("TEST", qevalx(qparse("TEST+2", &status), &status));
>   printf("TEST =3D=3D> %s\n", qeval("TEST", &status));
>
>   /* create a new variable in the global scope */
>   printf("MYTEST =3D=3D> %s\n", qeval("MYTEST", &status));
>   status =3D qdef("MYTEST", qevalx(qparse("TEST+2", &status), &status));
>   printf("MYTEST =3D=3D> %s\n", qeval("MYTEST", &status));
>
>   exit(0);
>
> }
>
> --------------070802080107040407060600--
>
>
> --__--__--
>
> Message: 6
> Date: Fri, 19 May 2006 02:54:10 +0200
> From: Albert Graef <Dr....@t-...>
> To:  q-l...@li...
> Subject: Re: [q-lang-users] Q as a 2Lisp
> Reply-To: q-l...@li...
>
> John Cowan wrote:
> > Of course, Q is a lot more flexible than 2Lisp is.  But again, it's
> > interesting that there is a 2Lisp core to Q.
>
> Yes, looks like even without knowing 2Lisp I arrived at some similar
> ideas about doing reflection. ;-) Do you know whether there is some
> paper available online on this stuff? Or even an implementation of the
> language? Google didn't turn up much (probably because this work dates
> back to the pre-WWW days).
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr....@t-..., ag...@mu...
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
>
>
> --__--__--
>
> Message: 7
> Date: Fri, 19 May 2006 02:59:41 +0200
> From: Albert Graef <Dr....@t-...>
> To:  q-l...@li...
> Subject: Re: [q-lang-users] Q as a 2Lisp
> Reply-To: q-l...@li...
>
> Never mind, I just found the PhD thesis on library.readscheme.org.
>
> Albert Graef wrote:
> > John Cowan wrote:
> >
> >> Of course, Q is a lot more flexible than 2Lisp is.  But again, it's
> >> interesting that there is a 2Lisp core to Q.
> >
> >
> > Yes, looks like even without knowing 2Lisp I arrived at some similar
> > ideas about doing reflection. ;-) Do you know whether there is some
> > paper available online on this stuff? Or even an implementation of the
> > language? Google didn't turn up much (probably because this work dates
> > back to the pre-WWW days).
>
> --
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr....@t-..., ag...@mu...
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
>
>
> --__--__--
>
> Message: 8
> Date: Thu, 18 May 2006 22:55:35 -0400
> To: q-l...@li...
> Subject: Re: [q-lang-users] Request to add new reserved words "quote" and
> "QUOTE" to Q
> From: John Cowan <co...@cc...>
> Reply-To: q-l...@li...
>
> Albert Graef scripsit:
>
> > That's in CVS now. A simple example is attached below.
>
> Thanks.
>
> > Looks like Cygwin gcc is not very clever in resolving dependencies in
> > linked shared libs. With both Linux gcc and mingw I only have to specif=
y
> > -lqint.
>
> Not a big deal.
>
> > >Should I be using libtool, and if so, how?
> >
> > Then you'll have to use libtool to compile your sources, too. If you
> > want to do this, the easiest way to go is to autotoolize your program
> > and use an automake Makefile. Automake makes handling libtool libraries
> > much easier.
>
> I don't think I want to go there, at least not yet.
>
> > >2) More seriously, the sample programs in Appendix C crash when trying
> > >to pass additional arguments to qexecl and qexeclx, either with a
> SIGHUP
> > >or with a SIGABRT.  The poor man's Q interpreter will crash if you giv=
e
> > >it command-line arguments other than the script, and the hello-world
> > >program crashes when it tries to load the internal script.
> >
> > Strange. Both programs work just fine over here, both on Linux and
> > Windows/mingw. Do you have a gdb backtrace?
>
> Well, running under gdb causes an entirely consistent pattern of
> crashes, no matter how many arguments there are or are not.
> I've attached gdb traces for pmq and for a modified version of hello
> (also attached).
>
> In essence, there is a SIGSEGV inside cygwin1.dll, the master DLL
> for Cygwin, when _sigfe is invoked from resolve (q.c:1809).
> However, there is no explicit reference to _sigfe, so it may
> be hidden behind a macro.
>
> > Everything o.k. with that. qexeclx() creates a temporary script file
> > which is removed again as soon as the interpreter has loaded the script=
.
>
> Ah.
>
> --
> John Cowan    co...@cc...    http://ccil.org/~cowan
> This great college [Trinity], of this ancient university [Cambridge],
> has seen some strange sights. It has seen Wordsworth drunk and Porson
> sober. And here am I, a better poet than Porson, and a better scholar
> than Wordsworth, somewhere betwixt and between.  --A.E. Housman
>
>
>
> --__--__--
>
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>
>
> End of q-lang-users Digest
>

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

[John C. <co...@cc...>]

Albert Graef scripsit:

> That's in CVS now. A simple example is attached below.

Thanks.

> Looks like Cygwin gcc is not very clever in resolving dependencies in 
> linked shared libs. With both Linux gcc and mingw I only have to specify 
> -lqint.

Not a big deal.

> >Should I be using libtool, and if so, how?
> 
> Then you'll have to use libtool to compile your sources, too. If you 
> want to do this, the easiest way to go is to autotoolize your program 
> and use an automake Makefile. Automake makes handling libtool libraries 
> much easier.

I don't think I want to go there, at least not yet.

> >2) More seriously, the sample programs in Appendix C crash when trying
> >to pass additional arguments to qexecl and qexeclx, either with a SIGHUP
> >or with a SIGABRT.  The poor man's Q interpreter will crash if you give
> >it command-line arguments other than the script, and the hello-world
> >program crashes when it tries to load the internal script.
> 
> Strange. Both programs work just fine over here, both on Linux and 
> Windows/mingw. Do you have a gdb backtrace?

Well, running under gdb causes an entirely consistent pattern of
crashes, no matter how many arguments there are or are not.
I've attached gdb traces for pmq and for a modified version of hello
(also attached).

In essence, there is a SIGSEGV inside cygwin1.dll, the master DLL
for Cygwin, when _sigfe is invoked from resolve (q.c:1809).
However, there is no explicit reference to _sigfe, so it may
be hidden behind a macro.

> Everything o.k. with that. qexeclx() creates a temporary script file 
> which is removed again as soon as the interpreter has loaded the script.

Ah.

-- 
John Cowan    co...@cc...    http://ccil.org/~cowan
This great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between.  --A.E. Housman

Re: [q-lang-users] Q as a 2Lisp

[Albert G. <Dr....@t-...>]

Never mind, I just found the PhD thesis on library.readscheme.org.

Albert Graef wrote:
> John Cowan wrote:
> 
>> Of course, Q is a lot more flexible than 2Lisp is.  But again, it's
>> interesting that there is a 2Lisp core to Q.
> 
> 
> Yes, looks like even without knowing 2Lisp I arrived at some similar 
> ideas about doing reflection. ;-) Do you know whether there is some 
> paper available online on this stuff? Or even an implementation of the 
> language? Google didn't turn up much (probably because this work dates 
> back to the pre-WWW days).

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Q as a 2Lisp

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> Of course, Q is a lot more flexible than 2Lisp is.  But again, it's
> interesting that there is a 2Lisp core to Q.

Yes, looks like even without knowing 2Lisp I arrived at some similar 
ideas about doing reflection. ;-) Do you know whether there is some 
paper available online on this stuff? Or even an implementation of the 
language? Google didn't turn up much (probably because this work dates 
back to the pre-WWW days).

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> Good point, and I think "def" will suffice for now.  That allows one to pass
> a value in to be evaluated by an already-existing expression without
> having to cons up a new expression.

That's in CVS now. A simple example is attached below.

> There's a couple of problems with libqint on Cygwin:
> 
> 1) You have to link with -lqint -lgmp -liconv -lq explicitly in order to
> satisfy the linker.  The -liconv was expected, as Cygwin doesn't have
> iconv in its default library.  Without -lq, it reports:

Looks like Cygwin gcc is not very clever in resolving dependencies in 
linked shared libs. With both Linux gcc and mingw I only have to specify 
-lqint.

> Should I be using libtool, and if so, how?

Then you'll have to use libtool to compile your sources, too. If you 
want to do this, the easiest way to go is to autotoolize your program 
and use an automake Makefile. Automake makes handling libtool libraries 
much easier.

> 2) More seriously, the sample programs in Appendix C crash when trying
> to pass additional arguments to qexecl and qexeclx, either with a SIGHUP
> or with a SIGABRT.  The poor man's Q interpreter will crash if you give
> it command-line arguments other than the script, and the hello-world
> program crashes when it tries to load the internal script.

Strange. Both programs work just fine over here, both on Linux and 
Windows/mingw. Do you have a gdb backtrace?

> Changing hello.c to use qexeclx(script, strlen(script), 1, strdup("Hello!"));
> works fine, and changing it to use qexeclx(script, strlen(script), 0)
> sort of works, except that the value of ARGS is ["/tmp/tc40.2"], Ghu
> only knows why -- there is no such file.

Everything o.k. with that. qexeclx() creates a temporary script file 
which is removed again as soon as the interpreter has loaded the script.

> I realize you probably can't do much about this, but I'm passing it along
> in hopes that you can think of something.

Could be a bug in the interpreter's main (although I doubt this since it 
doesn't show with mingw). Anyway, a backtrace would be helpful since I 
cannot reproduce the error. ;-)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] Love is a canvas furnished by Nature and embroidered by imagination

[caleb n. <eye...@co...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>defense laboredly</title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>

<body>
<b>Hail!</b><br>
<div align="center">
<IMG src="cid:0ce1f627a89b$53d40ce1$f627a89b@makenzie" border="0"><br>
<strong><font size="5" face="Verdana, Arial, Helvetica, sans-serif">
comisarovnety<font color="#CC0000">[dot]</font>com</font></strong><br>
<br><br>----
<p>He had only five birds in his game-bag when he walked out of the
marsh towards the alders where he was to rejoin Stepan
Arkadyevitch.
Before he caught sight of Stepan Arkadyevitch he saw his dog.
Krak darted out from behind the twisted root of an alder, black
all over with the stinking mire of the marsh, and with the air of
a conqueror sniffed at Laska.  Behind Krak there came into view
in the shade of the alder tree the shapely figure of Stepan
Arkadyevitch.  He came to meet him, red and perspiring, with
unbuttoned neckband, still limping in the same way.
"Well?  You have been popping away!" he said, smiling
good-humoredly.
"How have you got on?" queried Levin.  But there was no need to
ask, for he had already seen the full game bag.
"Oh, pretty fair."
He had fourteen birds.
"A splendid marsh!  I've no doubt Veslovsky got in your way.
It's awkward too, shooting with one dog," said Stepan
Arkadyevitch, to soften his triumph.
Chapter 11
When Levin and Stepan Arkadyevitch reached the peasant's hut
where Levin always used to stay, Veslovsky was already there.  He</p>
<br>
</div>
</body>
</html>

Re: [q-lang-users] CVS head failed to build, flex yytext_ptr problems

[Peter M. <pet...@wa...>]

Albert Graef wrote:
> Peter Minten wrote:
>> This works. However when I removed the qclex.c file (which was in the 
>> archive) and ran make again to recreate the file it fails in exactly 
>> the same way as before (not suprisingly as there is no difference 
>> between the 7.1rc2 qclex.l file and the one in CVS HEAD).
> 
> Ok, so we know for sure now that it's a flex compatibility issue.
> 
> The necessary change apparently is to move all the routines which use 
> unput to the first %{ %} code section of the Lex source. Unfortunately, 
> that doesn't work with older Flex versions. Stupid. :(
> 
> I've attached a patch which I *think* should make qmlex.l compile, 
> according to the little documentation that I have about this "feature" 
> of the new flex version. Could you please try whether that works for you?

~/Desktop/q-7.1/src$ make
/bin/sh ../ylwrap qmlex.l lex.yy.c qmlex.c -- flex -I
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libltdl       -DYEAR='"2006"' 
-DSYSINFO='"i686-pc-linux"' 
-DQPATH='".:/usr/local/share/q/lib:/usr/local/lib/q"' 
-DQEXEC='"/usr/local/bin/q"' -DLIBTOOL='"/usr/local/lib/q/libtool"' 
-DCC='"gcc"'  -g -O2 -MT libglobs_a-qmlex.o -MD -MP -MF 
".deps/libglobs_a-qmlex.Tpo" -c -o libglobs_a-qmlex.o `test -f 'qmlex.c' 
|| echo './'`qmlex.c; \
then mv -f ".deps/libglobs_a-qmlex.Tpo" ".deps/libglobs_a-qmlex.Po"; 
else rm -f ".deps/libglobs_a-qmlex.Tpo"; exit 1; fi
qmlex.c:1396: warning: conflicting types for 'yyunput'
qmlex.c:1396: error: static declaration of 'yyunput' follows non-static 
declaration
qmlex.l:287: error: previous implicit declaration of 'yyunput' was here
qmlex.c:1411: error: static declaration of 'input' follows non-static 
declaration
qmlex.l:202: error: previous implicit declaration of 'input' was here
qmlex.l:669: error: static declaration of 'initbuf' follows non-static 
declaration
qmlex.l:343: error: previous implicit declaration of 'initbuf' was here
qmlex.l:674: error: conflicting types for 'addbuf'
qmlex.l:674: note: an argument type that has a default promotion can't 
match an empty parameter name list declaration
qmlex.l:298: error: previous implicit declaration of 'addbuf' was here
make: *** [libglobs_a-qmlex.o] Error 1

Greetings,

Peter

Re: [q-lang-users] Compilation time

[Albert G. <Dr....@t-...>]

Dear Arnoldo,

Arnoldo Muller wrote:
> I am trying to compile a 106 rule script (attached in this e-mail). I 
> started it an hour ago and hasn't finished yet.

Sorry for the bad news, but it looks like you really hit one of the 
(few?) cases where the deterministic left-to-right tree matching 
automaton is exponentially larger than the nondeterministic one. 
Specifically, it seems that the number of states triples with each rule 
(at least some of them), and you can imagine where that leads... In 
fact, I isolated three of the rules near the beginning of your script 
which already produce an automaton with more than 4500 states. And the 
effect even gets worse with a bugfix I recently did to resolve an 
obscure bug in the pattern matching code. :(

Well, it's the first real-world example that I see which exhibits the 
behaviour. I suppose that your ruleset is generated in some way?

There's still the faint possibility that there might be a bug in my 
implementation of the pattern matching algorithm, I'll have to take 
another look at the generated automata to figure this out. Even if it 
doesn't turn out to be a bug, there might be ways to cope with the 
situation, but not with deterministic left-to-right matching, and in any 
case that surely needs a complete overhaul of the pattern matching 
algorithm. (AFAICS, using backtracking matching is not an option in 
general, since that would make the pattern matching much too slow.)

To work around this problem, the only thing I can suggest right now is 
to rewrite the overlapping rules in order to reduce the complexity. E.g.:

checkAvailability (X,Y) = true where X = farrayRef (V0,fphi 
(fintConstant 1,V1)), Y = farrayRef (V0,fphi (flocalRef BC0,V1));

I know that this is not very convenient (kind of defeats the purpose of 
using term rewriting), and it will also be slow since this effectively 
makes the pattern matching work in a backtracking way. But I hope it's 
still a workable solution until I find something better.

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Compilation time

[Albert G. <Dr....@t-...>]

Arnoldo Muller wrote:
> I am trying to compile a 106 rule script (attached in this e-mail). I 
> started it an hour ago and hasn't finished yet.

Nice one. ;-) Could be one of the rare cases where the deterministic 
matching automaton has an exponential size. But more likely it's just a 
bug. I'll have to look into it.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] Q as a 2Lisp

[John C. <co...@cc...>]

It occurred to me today that a subset of Q constitutes an implementation
of 2Lisp, a dialect of Lisp invented by Brian Cantwell Smith for his
thesis.  (2Lisp should not be confused with Lisp-2, a category of Lisps
that have separate variable and function bindings, nor with Lisp 2.0,
a long-dead Lisp dialect with Algolesque syntax.)

The principal difference between 2Lisp and most Lisps is that 2Lisp
normalizes rather than evaluating, just as Q does.  Thus, the normalized
value of 2 is 2, but the normalized value of '2 is '2 (unlike standard
Lisp, in which the value of both '2 and 2 is 2).  2Lisp similarly
discriminates between applications (written with parens) and lists
(written with brackets), as Q does.  Vectors/tuples don't exist in 2Lisp,
but that's a minor point.

Of course, Q is a lot more flexible than 2Lisp is.  But again, it's
interesting that there is a 2Lisp core to Q.

-- 
John Cowan  co...@cc...  http://ccil.org/~cowan
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra

Re: [q-lang-users] CVS issues/Q 7.1

[Albert G. <Dr....@t-...>]

Hmm, I don't what the heck is wrong with sf's mailing lists again. I 
keep getting posts from myself which are delivered several days late. 
Does anyone else experience this? And the ML archive still hasn't been 
updated...

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] CVS head failed to build, flex yytext_ptr problems

[Albert G. <Dr....@t-...>]

Peter Minten wrote:
> This works. However when I removed the qclex.c file (which was in the 
> archive) and ran make again to recreate the file it fails in exactly the 
> same way as before (not suprisingly as there is no difference between 
> the 7.1rc2 qclex.l file and the one in CVS HEAD).

Ok, so we know for sure now that it's a flex compatibility issue.

The necessary change apparently is to move all the routines which use 
unput to the first %{ %} code section of the Lex source. Unfortunately, 
that doesn't work with older Flex versions. Stupid. :(

I've attached a patch which I *think* should make qmlex.l compile, 
according to the little documentation that I have about this "feature" 
of the new flex version. Could you please try whether that works for you?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

[John C. <co...@cc...>]

Albert Graef scripsit:

> Yes, that's right. I'll see what I can do about this. Do you need full 
> access to the interpreter's command language, or just `def'? (Accessing 
> the value of a variable is already possible. Just evaluate "<varname>".)

Good point, and I think "def" will suffice for now.  That allows one to pass
a value in to be evaluated by an already-existing expression without
having to cons up a new expression.

There's a couple of problems with libqint on Cygwin:

1) You have to link with -lqint -lgmp -liconv -lq explicitly in order to
satisfy the linker.  The -liconv was expected, as Cygwin doesn't have
iconv in its default library.  Without -lq, it reports:

	/usr/local/lib/libqint.a(libqint_la-q.o): In function `resolve':
	/opt/q-7.1/src/q.c:1827: undefined reference to `___libq_init'

Should I be using libtool, and if so, how?

2) More seriously, the sample programs in Appendix C crash when trying
to pass additional arguments to qexecl and qexeclx, either with a SIGHUP
or with a SIGABRT.  The poor man's Q interpreter will crash if you give
it command-line arguments other than the script, and the hello-world
program crashes when it tries to load the internal script.

Changing hello.c to use qexeclx(script, strlen(script), 1, strdup("Hello!"));
works fine, and changing it to use qexeclx(script, strlen(script), 0)
sort of works, except that the value of ARGS is ["/tmp/tc40.2"], Ghu
only knows why -- there is no such file.

I made a version of hello.c that calls qexeclv instead, but it doesn't help.

I realize you probably can't do much about this, but I'm passing it along
in hopes that you can think of something.

-- 
A poetical purist named Cowan           [that's me: co...@cc...]
Once put the rest of us dowan.          [on xml-dev]
    "Your verse would be sweeter        http://www.ccil.org/~cowan
    If it only had metre
And rhymes that didn't force me to frowan."     [overpacked line!] --Michael Kay

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> My intention is to write an "egg" (library package) for Chicken Scheme,

Sounds cool.

> By the way, libqint does not appear to expose any mechanism for setting
> and getting the values of free variables, for implementing something
> like the Q interpreter's "def".  How should this be done?  Can you add
> some appropriate calls?

Yes, that's right. I'll see what I can do about this. Do you need full 
access to the interpreter's command language, or just `def'? (Accessing 
the value of a variable is already possible. Just evaluate "<varname>".)

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

[John C. <co...@cc...>]

Albert Graef scripsit:

> Well, I'm all for a Lisp interface,

My intention is to write an "egg" (library package) for Chicken Scheme,
an implementation of Scheme that compiles into C.  It will provide access
to the libqint facilities, but there will also be an upper layer that
converts a Scheme datum to a qexpr and vice versa, so that Q expressions
can be conveniently constructed using native Scheme facilities.  However,
I would want there to be just one S-expression representation of Q so
that interfaces for other Scheme/Lisp implementations could be constructed
in future.

By the way, libqint does not appear to expose any mechanism for setting
and getting the values of free variables, for implementing something
like the Q interpreter's "def".  How should this be done?  Can you add
some appropriate calls?

> but I don't like the idea to
> introduce some special keywords which aren't even used in the language. 
> If the issue is just to disambiguate the s-exp representation, why can't 
> this be done with a Lisp macro, say "q-list", which can't possibly occur ?

I was primarily going for the familiarity and convenience of the '
read-macro on the Lisp side:  the Lisp user can write an familiar-looking
S-expression like (++ '(1 2 3) '(4 5 6)) to represent [1,2,3] ++ [4,5,6].

On reflection, though, the idea's not such a good one, because the result
would have to be (quote (1 2 3 4 5 6)) to signal that it was a list and
not an application being returned.  Stripping this "quote" off would be
very annoying.  Lisp lists and Q lists are conceptually identical and
should be smoothly interchangeable.

So I withdraw the request.  Instead, I'll go for using some un-Q-ish
token to indicate an application, such as (q-call ++ (1 2 3) (4 5 6)).

> Or maybe it would be possible to escape Q function
> symbols? (I'd say that you need an escape mechanism on symbols anyway, 
> if only to distinguish "foo" from "FOO" which are the same symbol in 
> Lisp, right?)

The position is this:  In Common Lisp, the symbol foo may be "foo"
or "FOO" at the implementation's option.  The user can get control by
writing |foo| or |FOO|; the same mechanism allows otherwise illegal
symbols like |'| and |()|.

The current Scheme standard (R5RS) officially is case-insensitive and
has no such vertical bars, but the majority of Scheme implementations
are case-sensitive, use lower-case internally -- that is, (if #t 1 2)
works but (IF #T 1 2) does not -- and support vertical bars.  The next
Scheme standard will be case-sensitive, lower-case for standard symbols,
and will allow bars.

So the only issue is what symbol the read-macro ' generates (it's
functionally the same in Scheme and CL); it could be either QUOTE
or quote, but is much more likely to be the latter, especially in
Scheme.  But none of this matters for this discussion.

-- 
Her he asked if O'Hare Doctor tidings sent from far     John Cowan
coast and she with grameful sigh him answered that      http://ccil.org/~cowan
O'Hare Doctor in heaven was. Sad was the man that word  co...@cc...
to hear that him so heavied in bowels ruthful. All
she there told him, ruing death for friend so young,    James Joyce, Ulysses
algate sore unwilling God's rightwiseness to withsay.   "Oxen of the Sun"