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

Re: [q-lang-users] Import clauses terminology (Re: Bugfixes in cvs)

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

Albert Graef scripsit:

> John called them "selective" imports in his original proposal, and I'm
> willing to go with that, but that term doesn't seem to be widely used
> (or only informally). Maybe there's a better word?

I came up with "selective" spontaneously, but I can't find any better
alternative:  I looked through Python, Common Lisp, Modula-2, and various
other language specs without finding any such general term.

> I know that the Modula et al community tosses around the terms
> "qualified" and "unqualified" import, so my first reaction was to use
> that as it's kind of "standard", but it doesn't really fit very well
> here, since both forms of import allow both qualified and unqualified
> identifiers in Q. 

Yes, I think qualified or unqualified is orthogonal.

> But I really want a handy term to distinguish the two forms in the
> manual. Any ideas?

I suggest "selective" and "en masse".

-- 
John Cowan   co...@cc...
    "Mr. Lane, if you ever wish anything that I can do, all you will have
        to do will be to send me a telegram asking and it will be done."
    "Mr. Hearst, if you ever get a telegram from me asking you to do
        anything, you can put the telegram down as a forgery."

Re: [q-lang-users] Import clauses terminology (Re: Bugfixes in cvs)

[<ed...@ri...>]

How about "restricted" like "restricted quantifiers" in mathematics. As you=
 =0D
recall "For all, X in A implies P(X)" restricts X to A instead of the unive=
rse. I =0D
know quantifier is not qualifier but it kinda has the same tone.=0D
=0D
Eddie =0D
=0D
=0D

[q-lang-users] Import clauses terminology (Re: Bugfixes in cvs)

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

Albert Graef wrote:
>> - Qualified import clause (as suggested by John Cowan).
> 
> This is in cvs now. Please see the ChangeLog for details:
> http://q-lang.cvs.sourceforge.net/q-lang/q/ChangeLog?view=log

It's maybe silly to discuss this here, but as cvs is down anyway...
While updating the documentation on this stuff, I've run into a
terminological problem: How the heck are these 'from' import clauses
usually called?

John called them "selective" imports in his original proposal, and I'm
willing to go with that, but that term doesn't seem to be widely used
(or only informally). Maybe there's a better word?

I know that the Modula et al community tosses around the terms
"qualified" and "unqualified" import, so my first reaction was to use
that as it's kind of "standard", but it doesn't really fit very well
here, since both forms of import allow both qualified and unqualified
identifiers in Q. Also, it seems that some (including Wirth himself) use
the term "qualified import" for 'from' clauses, whereas others call
these "unqualified". Conversely, Wirth called the 'from'-less imports
"simple", while others would call these "qualified". Go figure.

I also looked at the Python docs, as Python's import statement probably
most closely resembles Q's (or maybe it's the other way round? ;-), but
they don't call them anything at all, they only say that there are these
two different kinds of imports and how they work.

But I really want a handy term to distinguish the two forms in the
manual. Any ideas?

TIA,
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] CVS outage

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

This just in (http://sourceforge.net/docs/A04):

(  2007-09-30 14:42:31 - Project CVS Service )   As of 2007-09-29 at
10:00PM Pacific, we have a CVS outage due to unplanned maintenance. This
affects developer CVS access (including ViewVC) for projects starting
with the letters m, n and q. Site status will be updated when the system
becomes available again.

It's been 16 hours that I couldn't commit anything. Still holding my
breath... x-<

-- 
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] Vector module

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

ed...@ri... wrote:
> Sounds good to me but could we use 'X!I <- A' instead of 'X!I := A'.

That has the same defect as an infix '--' operator: it conflicts with
unary minus. Therefore I would want neither '<-' nor '--' in the
prelude, it's just too error-prone.

> IIRC on lambda-
> the-ultimate, a prof's students called ':=' little penises and that will probably 
> be stuck in my mind forever every time I see that form of assingment (just as the 
> prof stated it stuck in his mind).

LOL. So you can't use Pascal or Modula-2 anymore? Or Algol? What a
shame. ;-) And what about ':-' in Prolog?

> Then again, 'get' and 'put' stand out for mutable operations kind of like function 
> names ending with ! for scheme.

Yes, that was my point exactly.

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] more features in Q

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

Anthony wrote:
> In terms of features for the Q language, what would be
> very good would be "better" documentation.

Hi Anthony, Christophe,

I have to contritely admit that the current documentation certainly
leaves a lot to be desired, especially for beginners. :(

That doesn't mean that the existing documentation is bad (various ppl
have assured me time and again that it is actually quite good), but that
it doesn't specifically target beginners. The "Nutshell" was an effort
to improve this situation, but obviously it didn't go far enough.

However, the truth of the matter is that a (fairly lengthy) book would
be needed to cover all of the language in sufficient detail, provides
the necessary TODOs and real-world examples, and also covers the
important addon modules.

I actually started writing such a thing some 2 or 3 years ago, but then
this mailing list really came to live, and I have been implementing a
lot of essential new language features and library modules (which were
often prompted by discussions here). As a result, we have a fairly nice
language now, with a good library, but it lacks a really good tutorial
for beginners, and my book never went further than the first few
chapters (even these are hopefully outdated now). ;-) While I want to
get back on track with my Q book as soon as the 64 bit port is finished
and I can finally release Q 8.0, I don't have high hopes that it can
fill the gap you rightfully complain about any time soon.

So I certainly welcome your idea of a community effort! In fact, that
was the idea behind the wiki -- start collecting some texts, TODOS,
tutorials about Q. But of course this can only work with enough
contributions by other ppl, and so far (I think) only Eddie Rucker has
picked up the ball yet.

If the wiki is too clumsy, then we can find other ways. I'm open to any
kind of suggestion which can help to make this happen.

> If these are the ramblings of a newbie, please forgive
> me.  It's wonderful to have a freely available
> language that one can use to experiment with and model
> all sorts of stuff with, but I would love to see Q
> reach the level of let's say, a Python.  The more
> users and the more contributors, the more the language
> will grow and prosper.

I'd like to see this, too. :) I'd say that there is a certain chance
right now, since there's still a "market" for a good, modern-style
"functional scripting language" which bridges the gap between Haskell
and Lisp, or even Haskell and Python. But I'll surely need help to make
that happen.

There's just so much that a single person can do, and while I love to
hack on Q, there are some areas which I'm not really good at (PR and web
design comes to my mind, and, as you pointed out, writing beginner
tutorials ;-). I don't think that Guido made it all by himself either.
Thinking about and discussing the language design, hacking on the
interpreter, fixing bugs, implementing interfaces to the great 3rd party
open-source software out there, working on nice examples, doing
releases, updating documentation and the website and doing other things
to promote the use of the language is quite a lot of work.

So I've said it before and I'll say it again: If anyone wants to step in
and help with some or all of these areas, you're most certainly welcome.
If there's anything that can be done to make the project more open to
contributions, let's also discuss this here.

> Have a great October!

You too. :)

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] Vector module

[<ed...@ri...>]

On Sun Sep 30 18:32 , Albert Graef <Dr....@t-...> sent:=0D
=0D
>Of course, if you insist we could still add some syntactic sugar for=0D
>these operations, like, e.g., 'X!!I' for 'get (X!I)' and 'X!I :=3D A' for=
=0D
>'put (X!I) A'. (I can't think of similarly nice sugar for 'get X=3Dget Y'=
=0D
>which would also work with the other comparison operators, but maybe=0D
>someone else has an idea.)=0D
=0D
Sounds good to me but could we use 'X!I <- A' instead of 'X!I :=3D A'. IIRC=
 on lambda-=0D
the-ultimate, a prof's students called ':=3D' little penises and that will =
probably =0D
be stuck in my mind forever every time I see that form of assingment (just =
as the =0D
prof stated it stuck in his mind).=0D
=0D
Then again, 'get' and 'put' stand out for mutable operations kind of like f=
unction =0D
names ending with ! for scheme.=0D
=0D
Eddie=0D

Re: [q-lang-users] Vector module

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

John Cowan wrote:
> Okay, here's my proposal: a vector module with a private vector
> type (basically just a rebranded tuple of references) and the following
> functions and operators:
> [interface ops snipped]

Thanks, John, for the elaborate proposal, I now better understand what
you really want from this. And on second thought I have to agree, it
would indeed be rather useful. :)

In fact I think that the idea applies equally well to all "indexed"
containers: tuples, lists, streams, arrays (i.e., array::Array), and
ordered as well as hashed dictionaries (dict::Dict and hdict::HDict).
I've actually used all of these (except maybe Array, which I don't use a
lot because there's the builtin Tuple type) in combination with
references, so that I can update them destructively, be it for the
purpose of keeping state or simply out of efficiency considerations.

To implement all of these in a clean fashion, of course we'd need to
have separate types like RefTuple, RefList, RefDict, etc. But that would
mean a lot of extra bloat and lifting of existing operations ((!), (#),
(++), sub, (=), etc.) from the base types.

However, I think that we could get most of the same functionality by
just adding the necessary construction and type-checking routines as
convenience functions and providing the additional 'fill' and 'mapinto'
operations. I'd call the latter 'putmap', however, and 'fill' could
instead be an overloaded version of 'put' which takes an entire
container as its first argument. Similarly, we could also overload 'get'
to get the functionality of making a new container from the values in
the given "ref'ed" one.

All the remaining operations would then just be the operations of the
corresponding base types, no lifting necessary.

That means that, in difference to your more elaborate proposal, (!)
would still return the reference rather than the value behind it, and
(=) would compare the references, not the values behind them. But I
think that this functionality would actually be useful, and IMHO it's
easy enough to say 'get (X!I)' if you want the value, 'put (X!I) A' to
change it, or 'get X=get Y' if you want to compare the real contents of
two ref'ed containers. Sure, such constructs stick out like a sore
thumb, but in my book that's actually a Good Thing because it raises the
program reader's awareness that something stateful is going on there.

Of course, if you insist we could still add some syntactic sugar for
these operations, like, e.g., 'X!!I' for 'get (X!I)' and 'X!I := A' for
'put (X!I) A'. (I can't think of similarly nice sugar for 'get X=get Y'
which would also work with the other comparison operators, but maybe
someone else has an idea.)

So then the entire thing would boil down to providing the creation and
type-checking convenience functions, as well as implementing the three
operations 'get', 'put' and 'putmap' (or whatever we call them) on
containers, and add some convenient syntactic sugar, which could easily
be done in an afternoon, I guess.

So, what do you all think, is that an acceptable compromise? Or do we
really have to go for the full version sketched out at the beginning?
Which would take time, and might not materialize as long as I have more
important stuff on my TODO list, like the 64 bit port. ;-) Or are there
any volunteers to implement something along these lines?

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] more features in Q

[christophe m. g. de l. <chr...@gm...>]

hi list,

i'd have to second that opinion. i am most interested in Q, but am now (when
i have the time)
learning erlang and haskell because there is more basic material on those
languages available,
just so that i can eventually come back to Q. (although those languages are
also quite interesting).

i have done some scheme programming which eases the learning curve, but
these languages
are still so different from anything else that i have programmed in that the
Q docs are too dense
for me. i think an important guideline should be, not just saying that you
can do X in Q,
but elaborating as to why and how you would use (and not use!) feature X.

anyway, thanks for the language, and also for the warm welcome i got with my
first post, now
many weeks ago, to which i never responded. hope to come back to Q soon.

best regards,
_c



> In terms of features for the Q language, what would be
> very good would be "better" documentation.
>
>

[q-lang-users] more features in Q

[Anthony <ad...@ke...>]

First of all, Dr. Graef, thank you for making this
tool available to the world and thank you for
continuing to develop it.

In terms of features for the Q language, what would be
very good would be "better" documentation.

When I say "better", of course, that begs the
question, better for who?  Well, I would say the lay
computer user with an interest in computer languages,
computer science, mathematics, or related field would
have a hard time understanding the manual.

>From page 5 of the Q in a Nutshell documentation: The
first paragraph is a simple description of what Q is,
and introduces three italicized terms, only one of
which is defined.  The second and third paragraphs
contain references to other works in the same field
with such jargon-laden gems such as "Like other
modern-style functional languages, Q has curried
function applications, equational function
definitions, algebraic types and a module system.  The
interpreter provides a reasonably efficient
implementation of term rewriting, featuring automatic
memory management, tail call optimization and both
eager and lazy evaluation strategies."

For those of us who follow computer languages, have a
background in computer science or are fans of the Q
language, this page is perhaps easy to understand.

But as a first page in a document ostensibly portrayed
as a tutorial, it seems a bit much.  Granted, on the
previous page is the caveat "Please note that this
document is *not* a general introduction to functional
programming."  

But for the average programming student to leave the
warm, familiar, and safe bosom of java and c++, there
is a need for a "simple" guide to Q.  As an example,
there is the documentation for Mathematica.  If we
look beyond the hyperbole, The Mathematica Book is a
classic text that shows a potential user what can be
done with the language, before explaining the
language's structure in any great detail.     

I'm not advocating a Q for Dummies book (though that
would be, very, very cool), but perhaps we, the users
of Q, can put together alternative documentation that
hides much of the historical and technical detail
while emphasizing what Q is good FOR.  Perhaps a text
in the style of the Thinking in Computer Science that
models important CS concepts in Q would be a welcome
addition to the literature.  Other texts could
include, using Q in mathematics series, each of which
would choose a given topic in math and show how to
create tools in Q to help explain the topic.

If these are the ramblings of a newbie, please forgive
me.  It's wonderful to have a freely available
language that one can use to experiment with and model
all sorts of stuff with, but I would love to see Q
reach the level of let's say, a Python.  The more
users and the more contributors, the more the language
will grow and prosper.

Have a great October!

--Antonio

--- 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. Bugfixes in cvs (Albert Graef)
>    2. Re: Bugfixes in cvs (Albert Graef)
>    3. Re: Bugfixes in cvs (ed...@ri...)
>    4. Re: Bugfixes in cvs (Albert Graef)
>    5. Re: Bugfixes in cvs (Albert Graef)
>    6. Re: Bugfixes in cvs (John Cowan)
>    7. Re: Bugfixes in cvs (Albert Graef)
>    8. Vector module (was: Bugfixes in cvs) (John
> Cowan)
> 
> 
>
----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 25 Sep 2007 11:25:16 +0200
> From: Albert Graef <Dr....@t-...>
> Subject: [q-lang-users] Bugfixes in cvs
> To: q-l...@li...
> Message-ID: <46F...@t-...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi all,
> 
> Here's a brief rundown of the latest in cvs. All
> known bugs in Q 7.7
> have been fixed. If you've found some more, please
> let me know! :)
> 
> Bugfixes:
> 
> - Shared 'where' clauses work without hiccups now.
> In Q 7.7 wrong code
> would sometimes be generated for free variables when
> there was a shared
> 'where' clause in an equation.
> 
> - qc lexer doesn't dump core at end of some source
> files any more. This
> also fixes a long-standing issue which caused the
> parser to "wrap
> around" with an unfinished declaration or definition
> at	the end of an
> imported module; this now properly provokes an error
> message.
> 
> - Shell escapes ('! command') work once again. This
> apparently was
> broken in Q 7.7 due to changes in the command lexer.
> 
> - Path search is now inhibited for filenames
> involving '.' and '..'
> directory prefixes.
> 
> Thanks to Eddie Rucker who reported bugs #1 and #2.
> 
> New stuff:
> 
> - qc bytecode generator: MATCHOPs for irrefutable
> matches (as in 'where
> X = 99') are now optimized away.
> 
> - Added: Eddie Rucker's csv example.
> 
> - Added: Vim syntax file.
> 
> More to come. :) So far, my TODO list for Q 7.8
> still contains the
> following items:
> 
> - Qualified import clause (as suggested by John
> Cowan).
> 
> - Namespace cleanup, unbundling of the POSIX
> interface and stdtypes.q
> from the prelude (as discussed earlier on the list).
> Hmm, I'm still
> thinking about this one... Do we really want this?
> ;-)
> 
> If you have any additional feature requests for Q
> 7.8, now is the time!
> 
> 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: 2
> Date: Thu, 27 Sep 2007 08:50:38 +0200
> From: Albert Graef <Dr....@t-...>
> Subject: Re: [q-lang-users] Bugfixes in cvs
> To: "Discuss the Q language."
> <q-l...@li...>
> Message-ID: <46F...@t-...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Albert Graef wrote:
> > - Qualified import clause (as suggested by John
> Cowan).
> 
> This is in cvs now. Please see the ChangeLog for
> details:
>
http://q-lang.cvs.sourceforge.net/q-lang/q/ChangeLog?view=log
> 
> Note that --pedantic now also warns about
> non-prelude symbols being used
> unqualified without giving a 'from' import clause.
> This encourages the
> use of old-style non-selective import clauses for
> qualified import only
> and is pretty useful to detect errors where an
> imported symbol is
> accidentally "reused" due to a missing local symbol
> declaration.
> 
> Also note that the namespaces of type and
> function/variable symbols
> aren't really disjoint anymore, since both kinds of
> symbols can now
> occur in the same context (namely, in 'from' import
> clauses). Therefore
> I had to revoke the permissive rule that you could
> use identical
> identifiers for both kinds of symbols; the compiler
> now checks that you
> don't redeclare a function or variable symbol as a
> type and vice versa.
> 
> Checking of local function and variable symbols is
> also more strict.
> Specifically, I found that it was possible to
> declare both a local
> symbol and different aliases all with the same print
> name (which, if not
> a bug, certainly was a misfeature). This will now
> correctly produce an
> error message.
> 
> > - Namespace cleanup, unbundling of the POSIX
> interface and stdtypes.q
> > from the prelude (as discussed earlier on the
> list). Hmm, I'm still
> > thinking about this one... Do we really want this?
> ;-)
> 
> Ok, I reviewed the discussion on the mailing list
> about this, and the
> (few) remarks about it have been positive, so I'm
> willing to give it a
> try. Note that this *will* break existing scripts
> which use the system
> interface or the container data structures; you
> *will* have to add an
> explicit import clause to make these work again. (Of
> course you can just
> run the interpreter with -w to be warned if this is
> the case.) Is anyone
> concerned about this?
> 
> 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, 27 Sep 2007 08:33:11 -0400
> From: <ed...@ri...>
> Subject: Re: [q-lang-users] Bugfixes in cvs
> To: q-l...@li...
> Message-ID:
> <D0....@mx...>
> Content-Type: text/plain; charset="utf-8"
> 
> >> - Namespace cleanup, unbundling of the POSIX
> interface and stdtypes.q
> >> from the prelude (as discussed earlier on the
> list). Hmm, I'm still
> >> thinking about this one... Do we really want
> this? ;-)
> 
> > Ok, I reviewed the discussion on the mailing list
> about this, and the
> > (few) remarks about it have been positive, so I'm
> willing to give it a
> > try. Note that this *will* break existing scripts
> which use the system
> > interface or the container data structures; you
> *will* have to add an
> > explicit import clause to make these work again.
> (Of course you can just
> > run the interpreter with -w to be warned if this
> is the case.) Is anyone
> > concerned about this?
> 
> Does this mean I will have to be looking up which
> functions are in what 
> libraries often? If so, I will volunteer to make a
> reference doc containing
> library names (sections) and the functions/types
> included under them.
> 
> On a different note, I cannot get the sources from
> cvs to compile anymore. 
> I installed libcurl3, libcurl3-gnutls, and
> libcurl4-gnutls-dev but no luck.
> 
> Here is the end of the configuration:
> 
> ...
> Q is now configured for i686-pc-linux-gnu.
> 
>   Source directory:     .
>   Installation prefix:  /usr/local
>   C compiler:           gcc -g -O2
> 
>   Shared libraries:     yes
>   Static libraries:     yes
>   Dynamic loader:       use bundled libltdl
> 
>   Unicode support:      yes
>   GMP library:          libraries: -lgmp
>   GNU readline:         libraries: -lreadline
>   POSIX threads:        libraries: -lpthread
>   GNU dbm:              disabled
>   CURL:                 libraries: -lcurl
>   GGI:                  disabled
>   FreeType2:            libraries: -lfreetype -lz
>                         includes :
> -I/usr/include/freetype2
>   ImageMagick:          libraries: -lMagick
>   ODBC:                 disabled
>   Tcl/Tk:               disabled
>   XML/XSLT:             disabled
>   DXLink:               disabled
>   Debug Malloc:         disabled
> 
> Here is what I get in make:
> 
> ...
>  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libq -g -O2
> -MT curl.lo -MD -MP -MF
> .deps/curl.Tpo -c curl.c  -fPIC -DPIC -o
> .libs/curl.o
> curl.c:467: error: 'CURLOPT_PASSWDFUNCTION'
> undeclared here (not in a function)
> curl.c: In function '__F__curl_curl_vars':
> curl.c:666: warning: passing argument 1 of 'mkint'
> makes integer from pointer
> without a cast
> curl.c: In function '__F__curl_curl_setopt':
> curl.c:1011: error: 'CURLOPT_PASSWDDATA' undeclared
> (first use in this function)
> curl.c:1011: error: (Each undeclared identifier is
> reported only once
> curl.c:1011: error: for each function it appears
> in.)
> curl.c:1011: error: incompatible types in assignment
> make[4]: *** [curl.lo] Error 1
> make[4]: Leaving directory
> `/home/eddie/q/modules/curl'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory
> `/home/eddie/q/modules/curl'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/eddie/q/modules'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/eddie/q'
> make: *** [all] Error 2
> 
> Does anyone knows how I should fix this?
> 
> Eddie
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 28 Sep 2007 00:25:14 +0200
> From: Albert Graef <Dr....@t-...>
> Subject: Re: [q-lang-users] Bugfixes in cvs
> To: ed...@ri..., 	"Discuss the Q
> language."
> 	<q-l...@li...>
> Message-ID: <46F...@t-...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> ed...@ri... wrote:
> > Does this mean I will have to be looking up which
> functions are in what 
> > libraries often? If so, I will volunteer to make a
> reference doc containing
> > library names (sections) and the functions/types
> included under them.
> 
> Not really much more than before. You'll have to add
> an 'import getopt'
> to get the getopt function, 'import stdtypes' (or
> 'import array',
> 'import bag', etc.) for the container data types,
> and 'import system'
> for all the POSIX stuff that's not in clib anymore.
> 'q -w' should be
> able to tell you if any of those is needed.
> 
> OTOH, a cross reference for the library would really
> be useful and much
> appreciated! :) This should actually become an
> appendix in the manual.
> (And of course most of the external modules still
> need to be documented
> in the manual...)
> 
> BTW, the following command should help with the xref
> (add other modules
> as needed):
> 
> qc getopt system stdtypes && q q.out -c
> 'completion_matches ""' | grep
> "::" && rm q.out
> 
> It might even possible to automate the entire
> process of building the
> xref, by running the above command to see what's
> there and then looking
> up each item in the qdoc.info file's index to see
> whether there is
> documentation available and which manual section it
> is in. With a bit of
> regex magic you might also be able to extract the
> declaration of each
> item from the corresponding Q source. Sounds like a
> fun little Q
> project. ;-)
> 
> > On a different note, I cannot get the sources from
> cvs to compile anymore. 
> > I installed libcurl3, libcurl3-gnutls, and
> libcurl4-gnutls-dev but no luck.
> > 
> > [snipped]
> > ...
> >  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libq -g
> -O2 -MT curl.lo -MD -MP -MF
> > .deps/curl.Tpo -c curl.c  -fPIC -DPIC -o
> .libs/curl.o
> > curl.c:467: error: 'CURLOPT_PASSWDFUNCTION'
> undeclared here (not in a function)
> > curl.c: In function '__F__curl_curl_vars':
> > curl.c:666: warning: passing argument 1 of 'mkint'
> makes integer from pointer
> > without a cast
> > curl.c: In function '__F__curl_curl_setopt':
> > curl.c:1011: error: 'CURLOPT_PASSWDDATA'
> undeclared (first use in this function)
> > curl.c:1011: error: (Each undeclared identifier is
> reported only once
> > curl.c:1011: error: for each function it appears
> in.)
> > curl.c:1011: error: incompatible types in
> assignment
> 
> Looks like CURLOPT_PASSWDFUNCTION isn't in Curl >=
> 7.16 anymore. I tried
> to fix this in cvs. Could you please get the latest
> curl.c and try again?
> 
> Cheers,
> Albert
> 
> P.S.: Where is everybody else? Will you wake from
> the snooze when I
> publish Q 7.8 RC1? ;-)
> 
> -- 
> 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: 5
> Date: Fri, 28 Sep 2007 00:57:13 +0200
> From: Albert Graef <Dr....@t-...>
> Subject: Re: [q-lang-users] Bugfixes in cvs
> To: "Discuss the Q language."
> <q-l...@li...>
> Message-ID: <46F...@t-...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Albert Graef wrote:
> > - Namespace cleanup, unbundling of the POSIX
> interface and stdtypes.q
> > from the prelude (as discussed earlier on the
> list). Hmm, I'm still
> > thinking about this one... Do we really want this?
> ;-)
> 
> All right, this is in cvs now, too. Startup with the
> standard prelude is
> now more than twice as fast (0.161s versus 0.350s on
> my system). Not
> quite the speedup I was hoping for, but at least the
> global namespace is
> much cleaner now (395 versus 1068 symbols). ;-)
> 
> Note that clib still has all the essential stuff (C
> replacement ops,
> additional string/gmp functions, a few high-level
> file I/O functions
> including printf/scanf and friends, byte strings,
> references and
> multithreading support). I consider these really
> necessary to do any
> serious Q programming, so I retained them in the
> standard prelude.
> 
> BTW, for those of you who are still worried about
> startup times in the
> context of CGI scripting: One useful option is the Q
> Apache module,
> which caches the current script so that you can
> amortize the script load
> time over the number of invocations of the same
> script. This also has
> the nice feature that the state of your script can
> be retained between
> different invocations. If you can put all your
> server-side stuff into a
> single script, then Apache doesn't ever need to
> reload the script at all!
> 
> 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: 6
> Date: Fri, 28 Sep 2007 19:36:03 -0400
> From: John Cowan <co...@cc...>
> Subject: Re: [q-lang-users] Bugfixes in cvs
> To: "Discuss the Q language."
> <q-l...@li...>
> Message-ID:
> <200...@me...>
> Content-Type: text/plain; charset=us-ascii
> 
> Albert Graef scripsit:
> 
> > If you have any additional feature requests for Q
> 7.8, now is the time!
> 
> There is still the remaining stuff at
> http://q-lang.wiki.sourceforge.net/Developers :
> mutable C vectors
> (typeless or typed); spaces around binary operators;
> and one which I
> asked for but isn't there, a few standard rewrite
> rules to make it easy
> to create, view, and change a tuple of references as
> if it were a mutable
> general vector, sheltering application code from the
> implementation
> details.
> 
> -- 
> Ambassador Trentino: I've said enough. I'm a man of
> few words.
> Rufus T. Firefly: I'm a man of one word: scram!
>         --Duck Soup                     John Cowan
> <co...@cc...>
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Sat, 29 Sep 2007 13:12:26 +0200
> From: Albert Graef <Dr....@t-...>
> Subject: Re: [q-lang-users] Bugfixes in cvs
> To: "Discuss the Q language."
> <q-l...@li...>
> Message-ID: <46F...@t-...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> John Cowan wrote:
> > There is still the remaining stuff at
> > http://q-lang.wiki.sourceforge.net/Developers
> 
> Hi John,
> 
> Yes, I haven't forgotten this, but I'm not sure how
> much of that will
> still make it into Q 7.8. It's important for me to
> get Q 7.8 out without
> too much further delay now, since it fixes some
> critical bugs in Q 7.7.
> 
> I've done a lot more bugfixes in this release than I
> anticipated, so I
> didn't quite have as much time as I wanted for new
> features. :(
> Nevertheless, I already implemented the from ...
> import clauses and the
> slim prelude since I consider these really
> essential. Also, one is a
> language change and the other breaks backward
> compatibility, so I wanted
> to have these done asap.
> 
> I'll have a look at the C vector stuff and see what
> I can do. But I'm
> afraid that I will have to postpone this, since
> proper integration of
> these features with the graphics and sound modules
> is quite a lot of
> work to do.
> 
> The sugar operations around reference tuples should
> be easy to do, but
> as the current way of working with get and put works
> just fine for *me*,
> it would help if someone could at least sketch out
> or show me some Q
> code mockups of what else exactly is wanted/needed.
> ;-)
> 
> The spaces around binary operators ... I've put that
> on hold since I
> have some issues with it right now -- see my
> comments at the wiki. It
> would also be a *lot* of work (mostly in the
> documentation, as I'll have
> to walk through each and every example in every
> piece of documentation
> and update them).
> 
> 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: 8
> Date: Sat, 29 Sep 2007 20:39:01 -0400
> From: John Cowan <co...@cc...>
> Subject: [q-lang-users] Vector module (was: Bugfixes
> in cvs)
> To: "Discuss the Q language."
> <q-l...@li...>
> Message-ID: <200...@me...>
> Content-Type: text/plain; charset=us-ascii
> 
> Albert Graef scripsit:
> 
> > The sugar operations around reference tuples
> should be easy to do, but
> > as the current way of working with get and put
> works just fine for *me*,
> > it would help if someone could at least sketch out
> or show me some Q
> > code mockups of what else exactly is
> wanted/needed. ;-)
> 
> Okay, here's my proposal: a vector module with a
> private vector
> type (basically just a rebranded tuple of
> references) and the following
> functions and operators:
> 
> public isvector X;		// return true if X is a vector
> public vector Xs;		// convert list or tuple Xs to a
> vector
> public list V;			// convert vector V to list
> public tuple V;			// convert vector V to list
> public get V I;			// get I'th element of vector V
> public (!) V I;			// same
> public put V I X;		// put X to the I'th element of
> vector V
> public (#) V;			// vector length
> public (++) V1 V2;		// vector concatenate
> public fill V X;		// put X to every element of
> vector V
> public sub V I J;		// extract subvector consisting
> of
> 				//    I'th through J'th member of V
> public (=) V1 V2;		// equality and friends
> public (<>) V1 V2;
> public (<) V1 V2;
> public (<=) V1 V2;
> public (>) V1 V2;
> public (>=) V1 V2;
> public null V;			// return true if vector V is empty
> public mapinto F V;		// destructively map F over
> elements of V
> 
> These are variously from R5RS Scheme, from the
> Scheme SRFI-43 library,
> and from Q itself.
> 
> -- 
> John Cowan        http://ccil.org/~cowan  
> co...@cc...
> Lope de Vega: "It wonders me I can speak at all. 
> Some caitiff rogue did
> rudely yerk me on the knob, wherefrom my wits still
> wander."
> An Englishman: "Ay, a filchman to the nab betimes
> 'll leave a man
> crank for a spell." --Harry Turtledove, Ruled
> Britannia
> 
> 
> 
> ------------------------------
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio
> 2005.
>
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> ------------------------------
> 
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
>
https://lists.sourceforge.net/lists/listinfo/q-lang-users
> 
> 
> End of q-lang-users Digest, Vol 16, Issue 3
> *******************************************
> 

[q-lang-users] Vector module (was: Bugfixes in cvs)

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

Albert Graef scripsit:

> The sugar operations around reference tuples should be easy to do, but
> as the current way of working with get and put works just fine for *me*,
> it would help if someone could at least sketch out or show me some Q
> code mockups of what else exactly is wanted/needed. ;-)

Okay, here's my proposal: a vector module with a private vector
type (basically just a rebranded tuple of references) and the following
functions and operators:

public isvector X;		// return true if X is a vector
public vector Xs;		// convert list or tuple Xs to a vector
public list V;			// convert vector V to list
public tuple V;			// convert vector V to list
public get V I;			// get I'th element of vector V
public (!) V I;			// same
public put V I X;		// put X to the I'th element of vector V
public (#) V;			// vector length
public (++) V1 V2;		// vector concatenate
public fill V X;		// put X to every element of vector V
public sub V I J;		// extract subvector consisting of
				//    I'th through J'th member of V
public (=) V1 V2;		// equality and friends
public (<>) V1 V2;
public (<) V1 V2;
public (<=) V1 V2;
public (>) V1 V2;
public (>=) V1 V2;
public null V;			// return true if vector V is empty
public mapinto F V;		// destructively map F over elements of V

These are variously from R5RS Scheme, from the Scheme SRFI-43 library,
and from Q itself.

-- 
John Cowan        http://ccil.org/~cowan   co...@cc...
Lope de Vega: "It wonders me I can speak at all.  Some caitiff rogue did
rudely yerk me on the knob, wherefrom my wits still wander."
An Englishman: "Ay, a filchman to the nab betimes 'll leave a man
crank for a spell." --Harry Turtledove, Ruled Britannia

Re: [q-lang-users] Bugfixes in cvs

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

John Cowan wrote:
> There is still the remaining stuff at
> http://q-lang.wiki.sourceforge.net/Developers

Hi John,

Yes, I haven't forgotten this, but I'm not sure how much of that will
still make it into Q 7.8. It's important for me to get Q 7.8 out without
too much further delay now, since it fixes some critical bugs in Q 7.7.

I've done a lot more bugfixes in this release than I anticipated, so I
didn't quite have as much time as I wanted for new features. :(
Nevertheless, I already implemented the from ... import clauses and the
slim prelude since I consider these really essential. Also, one is a
language change and the other breaks backward compatibility, so I wanted
to have these done asap.

I'll have a look at the C vector stuff and see what I can do. But I'm
afraid that I will have to postpone this, since proper integration of
these features with the graphics and sound modules is quite a lot of
work to do.

The sugar operations around reference tuples should be easy to do, but
as the current way of working with get and put works just fine for *me*,
it would help if someone could at least sketch out or show me some Q
code mockups of what else exactly is wanted/needed. ;-)

The spaces around binary operators ... I've put that on hold since I
have some issues with it right now -- see my comments at the wiki. It
would also be a *lot* of work (mostly in the documentation, as I'll have
to walk through each and every example in every piece of documentation
and update them).

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] Bugfixes in cvs

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

Albert Graef scripsit:

> If you have any additional feature requests for Q 7.8, now is the time!

There is still the remaining stuff at
http://q-lang.wiki.sourceforge.net/Developers : mutable C vectors
(typeless or typed); spaces around binary operators; and one which I
asked for but isn't there, a few standard rewrite rules to make it easy
to create, view, and change a tuple of references as if it were a mutable
general vector, sheltering application code from the implementation
details.

-- 
Ambassador Trentino: I've said enough. I'm a man of few words.
Rufus T. Firefly: I'm a man of one word: scram!
        --Duck Soup                     John Cowan <co...@cc...>

Re: [q-lang-users] Bugfixes in cvs

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

Albert Graef wrote:
> - Namespace cleanup, unbundling of the POSIX interface and stdtypes.q
> from the prelude (as discussed earlier on the list). Hmm, I'm still
> thinking about this one... Do we really want this? ;-)

All right, this is in cvs now, too. Startup with the standard prelude is
now more than twice as fast (0.161s versus 0.350s on my system). Not
quite the speedup I was hoping for, but at least the global namespace is
much cleaner now (395 versus 1068 symbols). ;-)

Note that clib still has all the essential stuff (C replacement ops,
additional string/gmp functions, a few high-level file I/O functions
including printf/scanf and friends, byte strings, references and
multithreading support). I consider these really necessary to do any
serious Q programming, so I retained them in the standard prelude.

BTW, for those of you who are still worried about startup times in the
context of CGI scripting: One useful option is the Q Apache module,
which caches the current script so that you can amortize the script load
time over the number of invocations of the same script. This also has
the nice feature that the state of your script can be retained between
different invocations. If you can put all your server-side stuff into a
single script, then Apache doesn't ever need to reload the script at all!

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] Bugfixes in cvs

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

ed...@ri... wrote:
> Does this mean I will have to be looking up which functions are in what 
> libraries often? If so, I will volunteer to make a reference doc containing
> library names (sections) and the functions/types included under them.

Not really much more than before. You'll have to add an 'import getopt'
to get the getopt function, 'import stdtypes' (or 'import array',
'import bag', etc.) for the container data types, and 'import system'
for all the POSIX stuff that's not in clib anymore. 'q -w' should be
able to tell you if any of those is needed.

OTOH, a cross reference for the library would really be useful and much
appreciated! :) This should actually become an appendix in the manual.
(And of course most of the external modules still need to be documented
in the manual...)

BTW, the following command should help with the xref (add other modules
as needed):

qc getopt system stdtypes && q q.out -c 'completion_matches ""' | grep
"::" && rm q.out

It might even possible to automate the entire process of building the
xref, by running the above command to see what's there and then looking
up each item in the qdoc.info file's index to see whether there is
documentation available and which manual section it is in. With a bit of
regex magic you might also be able to extract the declaration of each
item from the corresponding Q source. Sounds like a fun little Q
project. ;-)

> On a different note, I cannot get the sources from cvs to compile anymore. 
> I installed libcurl3, libcurl3-gnutls, and libcurl4-gnutls-dev but no luck.
> 
> [snipped]
> ...
>  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libq -g -O2 -MT curl.lo -MD -MP -MF
> .deps/curl.Tpo -c curl.c  -fPIC -DPIC -o .libs/curl.o
> curl.c:467: error: 'CURLOPT_PASSWDFUNCTION' undeclared here (not in a function)
> curl.c: In function '__F__curl_curl_vars':
> curl.c:666: warning: passing argument 1 of 'mkint' makes integer from pointer
> without a cast
> curl.c: In function '__F__curl_curl_setopt':
> curl.c:1011: error: 'CURLOPT_PASSWDDATA' undeclared (first use in this function)
> curl.c:1011: error: (Each undeclared identifier is reported only once
> curl.c:1011: error: for each function it appears in.)
> curl.c:1011: error: incompatible types in assignment

Looks like CURLOPT_PASSWDFUNCTION isn't in Curl >= 7.16 anymore. I tried
to fix this in cvs. Could you please get the latest curl.c and try again?

Cheers,
Albert

P.S.: Where is everybody else? Will you wake from the snooze when I
publish Q 7.8 RC1? ;-)

-- 
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] Bugfixes in cvs

[<ed...@ri...>]

>> - Namespace cleanup, unbundling of the POSIX interface and stdtypes.q=0D
>> from the prelude (as discussed earlier on the list). Hmm, I'm still=0D
>> thinking about this one... Do we really want this? ;-)=0D
=0D
> Ok, I reviewed the discussion on the mailing list about this, and the=0D
> (few) remarks about it have been positive, so I'm willing to give it a=0D
> try. Note that this *will* break existing scripts which use the system=0D
> interface or the container data structures; you *will* have to add an=0D
> explicit import clause to make these work again. (Of course you can just=
=0D
> run the interpreter with -w to be warned if this is the case.) Is anyone=
=0D
> concerned about this?=0D
=0D
Does this mean I will have to be looking up which functions are in what =0D
libraries often? If so, I will volunteer to make a reference doc containing=
=0D
library names (sections) and the functions/types included under them.=0D
=0D
On a different note, I cannot get the sources from cvs to compile anymore. =
=0D
I installed libcurl3, libcurl3-gnutls, and libcurl4-gnutls-dev but no luck.=
=0D
=0D
Here is the end of the configuration:=0D
=0D
...=0D
Q is now configured for i686-pc-linux-gnu.=0D
=0D
  Source directory:     .=0D
  Installation prefix:  /usr/local=0D
  C compiler:           gcc -g -O2=0D
=0D
  Shared libraries:     yes=0D
  Static libraries:     yes=0D
  Dynamic loader:       use bundled libltdl=0D
=0D
  Unicode support:      yes=0D
  GMP library:          libraries: -lgmp=0D
  GNU readline:         libraries: -lreadline=0D
  POSIX threads:        libraries: -lpthread=0D
  GNU dbm:              disabled=0D
  CURL:                 libraries: -lcurl=0D
  GGI:                  disabled=0D
  FreeType2:            libraries: -lfreetype -lz=0D
                        includes : -I/usr/include/freetype2=0D
  ImageMagick:          libraries: -lMagick=0D
  ODBC:                 disabled=0D
  Tcl/Tk:               disabled=0D
  XML/XSLT:             disabled=0D
  DXLink:               disabled=0D
  Debug Malloc:         disabled=0D
=0D
Here is what I get in make:=0D
=0D
...=0D
 gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libq -g -O2 -MT curl.lo -MD -MP -M=
F=0D
.deps/curl.Tpo -c curl.c  -fPIC -DPIC -o .libs/curl.o=0D
curl.c:467: error: 'CURLOPT_PASSWDFUNCTION' undeclared here (not in a funct=
ion)=0D
curl.c: In function '__F__curl_curl_vars':=0D
curl.c:666: warning: passing argument 1 of 'mkint' makes integer from point=
er=0D
without a cast=0D
curl.c: In function '__F__curl_curl_setopt':=0D
curl.c:1011: error: 'CURLOPT_PASSWDDATA' undeclared (first use in this func=
tion)=0D
curl.c:1011: error: (Each undeclared identifier is reported only once=0D
curl.c:1011: error: for each function it appears in.)=0D
curl.c:1011: error: incompatible types in assignment=0D
make[4]: *** [curl.lo] Error 1=0D
make[4]: Leaving directory `/home/eddie/q/modules/curl'=0D
make[3]: *** [all-recursive] Error 1=0D
make[3]: Leaving directory `/home/eddie/q/modules/curl'=0D
make[2]: *** [all-recursive] Error 1=0D
make[2]: Leaving directory `/home/eddie/q/modules'=0D
make[1]: *** [all-recursive] Error 1=0D
make[1]: Leaving directory `/home/eddie/q'=0D
make: *** [all] Error 2=0D
=0D
Does anyone knows how I should fix this?=0D
=0D
Eddie=0D

Re: [q-lang-users] Bugfixes in cvs

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

Albert Graef wrote:
> - Qualified import clause (as suggested by John Cowan).

This is in cvs now. Please see the ChangeLog for details:
http://q-lang.cvs.sourceforge.net/q-lang/q/ChangeLog?view=log

Note that --pedantic now also warns about non-prelude symbols being used
unqualified without giving a 'from' import clause. This encourages the
use of old-style non-selective import clauses for qualified import only
and is pretty useful to detect errors where an imported symbol is
accidentally "reused" due to a missing local symbol declaration.

Also note that the namespaces of type and function/variable symbols
aren't really disjoint anymore, since both kinds of symbols can now
occur in the same context (namely, in 'from' import clauses). Therefore
I had to revoke the permissive rule that you could use identical
identifiers for both kinds of symbols; the compiler now checks that you
don't redeclare a function or variable symbol as a type and vice versa.

Checking of local function and variable symbols is also more strict.
Specifically, I found that it was possible to declare both a local
symbol and different aliases all with the same print name (which, if not
a bug, certainly was a misfeature). This will now correctly produce an
error message.

> - Namespace cleanup, unbundling of the POSIX interface and stdtypes.q
> from the prelude (as discussed earlier on the list). Hmm, I'm still
> thinking about this one... Do we really want this? ;-)

Ok, I reviewed the discussion on the mailing list about this, and the
(few) remarks about it have been positive, so I'm willing to give it a
try. Note that this *will* break existing scripts which use the system
interface or the container data structures; you *will* have to add an
explicit import clause to make these work again. (Of course you can just
run the interpreter with -w to be warned if this is the case.) Is anyone
concerned about this?

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

[q-lang-users] Bugfixes in cvs

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

Hi all,

Here's a brief rundown of the latest in cvs. All known bugs in Q 7.7
have been fixed. If you've found some more, please let me know! :)

Bugfixes:

- Shared 'where' clauses work without hiccups now. In Q 7.7 wrong code
would sometimes be generated for free variables when there was a shared
'where' clause in an equation.

- qc lexer doesn't dump core at end of some source files any more. This
also fixes a long-standing issue which caused the parser to "wrap
around" with an unfinished declaration or definition at	the end of an
imported module; this now properly provokes an error message.

- Shell escapes ('! command') work once again. This apparently was
broken in Q 7.7 due to changes in the command lexer.

- Path search is now inhibited for filenames involving '.' and '..'
directory prefixes.

Thanks to Eddie Rucker who reported bugs #1 and #2.

New stuff:

- qc bytecode generator: MATCHOPs for irrefutable matches (as in 'where
X = 99') are now optimized away.

- Added: Eddie Rucker's csv example.

- Added: Vim syntax file.

More to come. :) So far, my TODO list for Q 7.8 still contains the
following items:

- Qualified import clause (as suggested by John Cowan).

- Namespace cleanup, unbundling of the POSIX interface and stdtypes.q
from the prelude (as discussed earlier on the list). Hmm, I'm still
thinking about this one... Do we really want this? ;-)

If you have any additional feature requests for Q 7.8, now is the time!

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] bug

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

Albert Graef wrote:
> This bug in the qc lexer is now fixed as well. Patch:

2nd attempt:

--- qclex.l	10 Jun 2007 10:37:56 -0000	1.37
+++ qclex.l	23 Sep 2007 19:02:51 -0000
@@ -182,7 +182,7 @@
   }

   *mybuf = 0; t = mybuf;
-  while((r = fgets(t, MAXSTRLEN, fp)) && *t &&
+  while(!feof(fp) && (r = fgets(t, MAXSTRLEN, fp)) && *t &&
 	t[(l = strlen(t))-1] != '\n') {
     /* try to enlarge the buffer: */
     int k = t-mybuf+l;
@@ -1224,12 +1224,14 @@

 yywrap()
 {
+  static int wrapped = 0;
   int have_file = 0;
+  if (wrapped) return 1;
   if (wflag == 1) unresolved_forwards();
   saveimps();
   fclose(yyin);
   if (in_comment)
-    return 1;
+    return (wrapped = 1);
   else if (fsp > fst) {
     int mno = modno;
     fsp--;
@@ -1293,7 +1295,7 @@
       save = 1;
     }
     if (!have_file && save) saveimps();
-    return !have_file;
+    return (wrapped = !have_file);
   }
 }



-- 
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] bug

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

This bug in the qc lexer is now fixed as well. Patch:

--- src/qclex.l	10 Jun 2007 10:37:56 -0000	1.37
+++ src/qclex.l	23 Sep 2007 17:58:55 -0000
@@ -1224,12 +1224,14 @@

 yywrap()
 {
+  static int wrapped = 0;
   int have_file = 0;
+  if (wrapped) return 1;
   if (wflag == 1) unresolved_forwards();
   saveimps();
   fclose(yyin);
   if (in_comment)
-    return 1;
+    return (wrapped = 1);
   else if (fsp > fst) {
     int mno = modno;
     fsp--;
@@ -1293,7 +1295,7 @@
       save = 1;
     }
     if (!have_file && save) saveimps();
-    return !have_file;
+    return (wrapped = !have_file);
   }
 }



ed...@ri... wrote:
> Hello Albert:
> 
> code:
> 
>  #!/usr/local/bin/q -cmain
> 
>  main ARGS = write ARGS
> 
>  
> 
> If you forget to put  a ";" at the end, you get the following error
> 
>  *** glibc detected *** /usr/local/bin/qc: malloc(): memory corruption:
> 0xb7e4cd7
> 5 ***

-- 
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] bug?

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

Ok, I finally fixed this bug (in cvs now). Here's the patch for the
impatient:

--- src/qctables.c	7 Jun 2007 14:46:51 -0000	1.43
+++ src/qctables.c	23 Sep 2007 12:48:04 -0000
@@ -1367,8 +1367,6 @@
     return (NULL);
 }

-extern byte offs;
-
 static int
 vartbadd(s, i)
      char           *s;
@@ -1377,7 +1375,7 @@
   vartb[i].pname = puttmp(s);
   vartb[i].pname_s = -1;
   vartb[i].dflag = 1;
-  vartb[i].offs = offs;
+  vartb[i].offs = 0;
   vartb[i].plen = 0;
   vartb[i].type = NONE;
   return (1);

ed...@ri... wrote:
> Hi Albert!
> 
> code:
> 
> xr L
>   where A = 4, B = 2:
> 	  = \Z . A + B * Z;
> 
> ==> xr [1,2]
> \2 . 4+2*2
> 
> What happended to Z?
> 
> Eddie
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
> 


-- 
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] Qt

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

ed...@ri... wrote:
> Thanks for all you do! Qt will be a good addition to Q.

Yes, I must admit that I'm already having a lot of a fun with it. :) But
the real kudos go to the SmokeQt programmers, they have done a terrific
job to make Qt accessible to scripting languages, and their library
really works very well!

I already ported one of my earlier Qt+Q examples, the MidiShare patchbay
(qmidicc), and the GUI logic was much easier to do in Q than in C++. In
fact, I could just take the existing Q script and QtDesigner file,
replace the whole C++ blurb (which involved some nontrivial list
processing) with a few lines of Q code and the app was up and running
again in just about an hour. I'll commit this to cvs some time this
weekend so that those of you who are eager to try Qt/Q on Linux have a
real application to look at.

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] Qt

[<ed...@ri...>]

Thanks for all you do! Qt will be a good addition to Q.=0D
=0D
Eddie=0D
=0D
On Fri Sep 21 16:32 , Albert Graef <Dr....@t-...> sent:=0D
=0D
>/me wrote:=0D
>> So, while it's not a walk in the park, it's certainly possible. Maybe a=
=0D
>> smokeqt.dll is already out there somewhere (is there a binary=0D
>> distribution of QtRuby for Windows?), then we could just rebuild the=0D
>> import library from that, take smoke.h from the sources, and have a Qt/Q=
=0D
>> version for Qt4 on Windows in no time! Any takers? ;-)=0D
>=0D
>Ok, I just found a Windows binary for QtRuby4 and it includes a=0D
>smokeqt.dll. Not sure which compiler this was built with, but hopefully=0D
>it's mingw. I'll give it a try when porting the next Q version.=0D
>=0D
>Albert=0D
>=0D
>-- =0D
>Dr. Albert Gr"af=0D
>Dept. of Music-Informatics, University of Mainz, Germany=0D
>Email:  Dr....@t-..., ag...@mu...=0D
>WWW:    http://www.musikinformatik.uni-mainz.de/ag=0D
>=0D
>-------------------------------------------------------------------------=
=0D
>This SF.net email is sponsored by: Microsoft=0D
>Defy all challenges. Microsoft(R) Visual Studio 2005.=0D
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/=0D
>_______________________________________________=0D
>q-lang-users mailing list=0D
>q-l...@li...=0D
>https://lists.sourceforge.net/lists/listinfo/q-lang-users=0D
=0D
=0D

Re: [q-lang-users] Qt

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

/me wrote:
> So, while it's not a walk in the park, it's certainly possible. Maybe a
> smokeqt.dll is already out there somewhere (is there a binary
> distribution of QtRuby for Windows?), then we could just rebuild the
> import library from that, take smoke.h from the sources, and have a Qt/Q
> version for Qt4 on Windows in no time! Any takers? ;-)

Ok, I just found a Windows binary for QtRuby4 and it includes a
smokeqt.dll. Not sure which compiler this was built with, but hopefully
it's mingw. I'll give it a try when porting the next Q version.

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] Qt

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

ed...@ri... wrote:
> That makes me wonder about Windows, Mac OSX, Linux without KDE, etc.
> Will Q/Qt run on those without SmokeQt?

Qt/Q is based on SmokeQt, so it won't run without it. But it appears
that SmokeQt in fact already works with Qt4. And SmokeQt doesn't really
need KDE either, it's just that the version which is included with KDE3
has been the most convenient path for me since my Linux system already
has all this stuff on board.

In fact, instructions for building QtRuby (which also comes bundled with
SmokeQt) for Qt 4.2 on Windows using mingw are available here:

http://rubyforge.org/forum/message.php?msg_id=12500

So, while it's not a walk in the park, it's certainly possible. Maybe a
smokeqt.dll is already out there somewhere (is there a binary
distribution of QtRuby for Windows?), then we could just rebuild the
import library from that, take smoke.h from the sources, and have a Qt/Q
version for Qt4 on Windows in no time! Any takers? ;-)

Not sure about OSX, but thanks to Fink most essential Linux software
builds on OSX without much ado these days, so I'm quite confident that
it's possible, too. It's just that someone has to put in a little time
and effort...

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