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

[q-lang-users] [OT] Upcoming Book: "Gnuplot in Action"

[Philipp K. J. <ja...@ma...>]

Finally: A book on Gnuplot!

If you are interested in data analysis and visualization, 
you might be interested in the upcoming book:
	"Gnuplot in Action"
(to be published, Fall 2008, Manning Publications).

You can pre-order it directly from the publisher: 
	www.manning.com/janert

Gnuplot is probably the most popular open-source 
program for plotting and visualization. The book 
assumes no previous familiarity with Gnuplot. It 
introduces the most basic concepts rapidly, and 
then moves on to explain Gnuplot's advanced 
concepts and power features in detail.

If you want to learn more about the book and the 
author, check out my book page at 
	wwww.principal-value.com/my-book.php

If you have comments or suggestions for the book,
please let me know!

Feel free to forward this information as appropriate.

Best,

		Ph.

Re: [q-lang-users] Speeding up Q

[Brian B. <bri...@co...>]

Dear Albert : 

Would you be so kind as to give a tiny example of a 'constructor' versus a
'defined function' to clarify how they're different in the lambda calculus
but not so in TR?  My memory of lambda is that it's just the following

T ::= x | \x.T | T T  and a reduction rule (\x.T) y ~~> T[y/x] when y not
free in T

So I'm at a bit of a loss to know what you mean by a constructor here. What
did I miss?

Best,
Brian

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...] On Behalf Of Albert
Graef
Sent: Wednesday, April 02, 2008 5:22 AM
To: Discuss the Q language.
Subject: Re: [q-lang-users] Speeding up Q

Dr Libor Spacek wrote:
> Since Tim Haynes mentioned Clean, I would be interested 
> to know what you see as the main advantages/differences 
> of Pure over Clean?

Well, I probably shouldn't be talking about Pure as if it already
existed (just in case you're wondering if Pure was an April fools joke
after all -- no, it's not!). But my brain is hurting after hours of
coding the LLVM code generator for the pattern-matching automaton, so I
might as well use this as an excuse for a little coffee break. And it
can't hurt to build up some more hype in advance. ;-)

Btw, this might also be a nice read in this context:
http://www.lisperati.com/landoflisp/

Here's a *very* brief rundown of the main features of these languages
(sorry if this comes over as a bit simplistic, but I'm afraid that I
can't go into all the subleties and more esoteric features here):

- Haskell: purely functional (monads for side-effects), lazy
- Clean: dito, but "uniqueness" types for side effects
- ML: impure (allows side-effects), eager (there are lazy versions)

These all belong to the "Hindley-Milner strongly typed" camp, with all
the safety and inconveniences that offers. In addition, with Haskell and
Clean you also have to jump through hoops to get side effects, which is
good for the compiler writer and also greatly facilitates optimization
and auto-parallelization, but is a *big* inconvenience for many
programmers who actually want to *use* those languages for real-world
problems. Moreover, while pervasive laziness seems like a good feature,
it does have its performance penalties and, more importantly, it
sometimes makes it harder to write good programs (space leaks issue).

In contrast, Q and Pure are dynamically typed and allow side-effects
(well, Pure itself is in fact purely functional but it allows "unsafe"
calls into C without any ado), which is more in line with Lisp-like
languages. They also offer Lisp-like reflection capabilities, which is
something where *all* the languages from the strongly typed camp fall
short. In Q, the reflectiveness is limited to expressions, but in Pure
it will be much broader, allowing fully dynamic modifications of the
running program as in Lisp. Q also supports lazy evaluation through its
user-definable special forms (which is kind of like the "futures" in
Alice ML, but the "thunking" is handled automatically). Pure doesn't
have this right now, but it won't be hard to add.

I also think that Pure's syntax is nicer, better than ML's somewhat
complicated definition syntax and Haskell's layout-based block structure
(call me old-fashioned, but free-format languages were invented for good
reasons). But YMMV.

But the biggest difference between all those languages (including Lisp)
and Q/Pure is that the latter are based on general term rewriting rather
than the lambda calculus, which essentially boils down to the simple
feature that there is no distinction between "constructors" and "defined
functions". This might not seem like a big deal, but it makes the
language much more expressive:

1. You can have constructor equations, which is great for expressing
axioms like associativity or idempotence.

2. You can do symbolic calculations involving expressions with free
variables.

3. You can extend the definition of any function or operator to your own
data structures, at any time.

Unless you want to do symbolic algebra, 1 and 2 probably are not much
more than a convenience, but I consider 3 really as a major advantage,
because it gives you much better ad-hoc polymorphism than even Lisp.

Now Haskellers might argue that they have type classes for that, but
you'll have to jump through a lot of hoops to achieve the same kind of
polymorphism, while in Q/Pure it's just there, without even *planning*
for it. To me, that's the most striking advantage of term rewriting as a
programming language. Of course, this comes at a price: In a TR language
the only "argument mismatch" exceptions that you get any more are those
in guards (if the condition doesn't evaluate to a truth value), unless
you explicitly add definitions which throw such exceptions. Whether you
like that pretty much depends on which kind of programmer you are: do
you want a sharp knife, or are you worried about accidentally cutting
your feet off? ;-)

Hope that this clarified the differences a bit.

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

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
q-lang-users mailing list
q-l...@li...
https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] Speeding up Q

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

Dr Libor Spacek wrote:
> Since Tim Haynes mentioned Clean, I would be interested 
> to know what you see as the main advantages/differences 
> of Pure over Clean?

Well, I probably shouldn't be talking about Pure as if it already
existed (just in case you're wondering if Pure was an April fools joke
after all -- no, it's not!). But my brain is hurting after hours of
coding the LLVM code generator for the pattern-matching automaton, so I
might as well use this as an excuse for a little coffee break. And it
can't hurt to build up some more hype in advance. ;-)

Btw, this might also be a nice read in this context:
http://www.lisperati.com/landoflisp/

Here's a *very* brief rundown of the main features of these languages
(sorry if this comes over as a bit simplistic, but I'm afraid that I
can't go into all the subleties and more esoteric features here):

- Haskell: purely functional (monads for side-effects), lazy
- Clean: dito, but "uniqueness" types for side effects
- ML: impure (allows side-effects), eager (there are lazy versions)

These all belong to the "Hindley-Milner strongly typed" camp, with all
the safety and inconveniences that offers. In addition, with Haskell and
Clean you also have to jump through hoops to get side effects, which is
good for the compiler writer and also greatly facilitates optimization
and auto-parallelization, but is a *big* inconvenience for many
programmers who actually want to *use* those languages for real-world
problems. Moreover, while pervasive laziness seems like a good feature,
it does have its performance penalties and, more importantly, it
sometimes makes it harder to write good programs (space leaks issue).

In contrast, Q and Pure are dynamically typed and allow side-effects
(well, Pure itself is in fact purely functional but it allows "unsafe"
calls into C without any ado), which is more in line with Lisp-like
languages. They also offer Lisp-like reflection capabilities, which is
something where *all* the languages from the strongly typed camp fall
short. In Q, the reflectiveness is limited to expressions, but in Pure
it will be much broader, allowing fully dynamic modifications of the
running program as in Lisp. Q also supports lazy evaluation through its
user-definable special forms (which is kind of like the "futures" in
Alice ML, but the "thunking" is handled automatically). Pure doesn't
have this right now, but it won't be hard to add.

I also think that Pure's syntax is nicer, better than ML's somewhat
complicated definition syntax and Haskell's layout-based block structure
(call me old-fashioned, but free-format languages were invented for good
reasons). But YMMV.

But the biggest difference between all those languages (including Lisp)
and Q/Pure is that the latter are based on general term rewriting rather
than the lambda calculus, which essentially boils down to the simple
feature that there is no distinction between "constructors" and "defined
functions". This might not seem like a big deal, but it makes the
language much more expressive:

1. You can have constructor equations, which is great for expressing
axioms like associativity or idempotence.

2. You can do symbolic calculations involving expressions with free
variables.

3. You can extend the definition of any function or operator to your own
data structures, at any time.

Unless you want to do symbolic algebra, 1 and 2 probably are not much
more than a convenience, but I consider 3 really as a major advantage,
because it gives you much better ad-hoc polymorphism than even Lisp.

Now Haskellers might argue that they have type classes for that, but
you'll have to jump through a lot of hoops to achieve the same kind of
polymorphism, while in Q/Pure it's just there, without even *planning*
for it. To me, that's the most striking advantage of term rewriting as a
programming language. Of course, this comes at a price: In a TR language
the only "argument mismatch" exceptions that you get any more are those
in guards (if the condition doesn't evaluate to a truth value), unless
you explicitly add definitions which throw such exceptions. Whether you
like that pretty much depends on which kind of programmer you are: do
you want a sharp knife, or are you worried about accidentally cutting
your feet off? ;-)

Hope that this clarified the differences a bit.

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] Speeding up Q

[Dr L. S. <li...@gm...>]

Since Tim Haynes mentioned Clean, I would be interested 
to know what you see as the main advantages/differences 
of Pure over Clean?

Libor

Re: [q-lang-users] An Etymological Note on Pure

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

Hi Libor,

> Interestingly, "pure" in Italian means much the same as "sure" in "American", which also makes it a positive name for your new languange :)

Pure thing, then. ;-) Well, there's probably another language where it
means something awful... like what "Q" sounds like in French! (Don't ask.)

I did look up the name in the big programming language database which
goes all the way back to the fifties I think, and it seems that "Pure"
isn't taken yet, so I claim it now! (Maybe I should also register the
www.pure-lang.org domain?)

Thanks for being interested in Pure (and Q). Your Geometric Algebra
project sounds very interesting!

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] Speeding up Q

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

Tim Haynes wrote:
> I sense a pun behind that somewhere:
> 
>   haskell -> clean
>   Q       -> pure  ? ;)

So let the rewriting begin (sorry, couldn't resist). But I guess you're
lacking a rewriting rule Clean -> Q somewhere. :)

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] Speeding up Q

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

Eddie Rucker wrote:
> I'm looking forward to Pure. Since I have a new 64bit machine and the
> amount of work (Institutional Research stuff) has picked up, I've
> abandoned Q temporarily. 

Ugh, sorry to hear that. :( The good news is that Pure should be 64
bit-ready right from the start.

> How easy will it be to port the libraries to Pure?

Well, I guess that it shouldn't be too hard to write an implementation
of libq for Pure so that most existing Q modules could be reused right
away, at least if they do all their expression manipulation through the
official libq interface.

In any case, simple modules implemented in C or C plugins talking to Q
should be fairly easy to port, as you will be able to just link/dlopen
Pure and C modules together and do *direct* Pure<->C calls! :)

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] Memory fun

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

> Tim Haynes wrote:
>> Am I right in thinking that the generation of error strings including
>> object-dumps is non-lazy?
>
> Well, if you use a non-lazy data structure (lists rather than streams)
> then that's what you get...

Ah :) Yes, that's something else I've considered, but I'll start with a
smaller script to understand exactly how to convert them all across :)

>> It's a bit of a PITA trying to find the one or two list-elements on
>> which it can't do some function or other in the middle of such a large
>> list.
>
> I guess that you should really take a look at the new bytestring
> operations in clib which allow you to treat a bytestring as a mutable
> integer vector with fast random access. That should probably work much
> better for the application at hand. Or maybe tuples of references would
> be helpful (reftypes.q).

Oh? That's interesting. I discovered uint16_list and relatives the other
day, which has made life an awful lot nicer. Now one of the big slow-downs
is the conversion of the bitmap to triples and back - actually, I could use
a hand improving on this:

  //take flat list, return list of triples
  triplify [] = [];
  triplify Ds = [tuple $ sub Ds 0 2] ++ (triplify (sub Ds 3 ((#Ds)-1)));

  //take list of triples, return flat list
  detriplify = (foldr1 (++)) . (map list) ;

I was wondering if there was something smart I could be doing with zip3,
but memory is a serious concern at this point. 

I don't necessarily need random-access on the thing at the moment - a
simple map across the whole lot will suffice, so this is also a candidate
for streaming to reduce memory footprint later. Any advances welcome :)

> In Pure you'll hopefully be able to do serious number crunching like
> this, although it still won't be quite as fast as Fortran. ;-)

Sounds good to me :)

>> Is there any way to speed the process up a bit? Maybe set a few
>> exceptions or something?
>
> Yup, that's what they're for. Just add a few default rules throwing
> exceptions to the suspicious functions.

Right, I'll see what I can do. It's the occasional simple things like

             ...
             where C=hdict (R ++ [(G,G)])

except I first forgot about the [] there and wound up with a 600M pid for
the interpreter, a list of 64K elements plus a pair on the end in an error
message. Ooops :)

~Tim
-- 
<http://spodzone.org.uk/>

[q-lang-users] An Etymological Note on Pure

[Dr L. S. <li...@gm...>]

Albert,

Interestingly, "pure" in Italian means much the same as "sure" in "American", which also makes it a positive name for your new languange :)

Libor

Re: [q-lang-users] Memory fun (was Re: Speeding up Q)

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

Tim Haynes wrote:
> Am I right in thinking that the generation of error strings including
> object-dumps is non-lazy?

Well, if you use a non-lazy data structure (lists rather than streams)
then that's what you get...

> It's a bit of a PITA trying to find the one or two list-elements on which
> it can't do some function or other in the middle of such a large list.

I guess that you should really take a look at the new bytestring
operations in clib which allow you to treat a bytestring as a mutable
integer vector with fast random access. That should probably work much
better for the application at hand. Or maybe tuples of references would
be helpful (reftypes.q).

In Pure you'll hopefully be able to do serious number crunching like
this, although it still won't be quite as fast as Fortran. ;-)

> Is there any way to speed the process up a bit? Maybe set a few exceptions
> or something?

Yup, that's what they're for. Just add a few default rules throwing
exceptions to the suspicious functions.

HTH,
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] Pure

[Dr L. S. <li...@gm...>]

Albert,

Thanks for telling us about LLVM and Pure. It sounds really interesting! I eagerly await the Pure release. Holidays are a great thing  :) I enjoyed your teaser. It looks much like Q at the moment but I guess the differences will be elucidated in time?
Anyway, even if it was to be the same as Q it would not be a bad thing. Just having the compiler alone would be a major step forward.

As someone who can still remember programming in Lisp and Prolog (and C), I can appreciate the power of the best features of all three combined in one principled package. I was always of the opinion that the matching/unification was the best feature of Prolog and you had been astute to pick this up and run with it.

I am interested in using Pure to implement Geometric Algebra, it sounds like the perfect tool for it! However, it will take me time, 
as I like to think deeply and slowly :) Unless there is someone else who would like to help me with this worthwhile project??

>From the point of view of Q/Pure, it will be an ideal demonstrator for its symbolic manipulation capability.

Regards,
Libor

[q-lang-users] Memory fun (was Re: Speeding up Q)

[Tim H. <q...@st...>]

Just had a thought, since we're talking fairly fundamental bits of Q...

I'm in the middle of hacking up a script to work on potentially large
bitmaps.

In a normal run, my script is well-behaved, albeit slow, using about 23M
RAM for a couple of minutes. That's OK. 

However, during a hacking phase when I'm introducing screwups by the
minute, it feels the urge to spew huge strings as it represents lists of
variously 65536 elements or even that many triples - and most noticeably
hogs up to a gig RAM in the process.

Am I right in thinking that the generation of error strings including
object-dumps is non-lazy?

It's a bit of a PITA trying to find the one or two list-elements on which
it can't do some function or other in the middle of such a large list.

Normal development process here is emacs and a mrxvt session or two in
whcih I either run the script or occasionally q -d theblighter.q or rarely
hack around in the interpreter. 

Is there any way to speed the process up a bit? Maybe set a few exceptions
or something?

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] Speeding up Q

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

[snip]
> The language and interpreter are codenamed "Pure" a.k.a. the "Pure
> Universal Rewriting Engine", and I do have a preliminary manpage for it,
> which I'm attaching as a little teaser. ;-)

I sense a pun behind that somewhere:

  haskell -> clean
  Q       -> pure  ? ;)

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] Speeding up Q

[Eddie R. <er...@bm...>]

I'm looking forward to Pure. Since I have a new 64bit machine and the
amount of work (Institutional Research stuff) has picked up, I've
abandoned Q temporarily. 

One question:
How easy will it be to port the libraries to Pure?

Eddie

On Mon, 2008-03-31 at 13:13 +0200, Albert Graef wrote:
> Dr Libor Spacek wrote:
> > In my view it should be a high priority getting Q to tun faster in order to gain the user base that it deserves.
> 
> Did you read my mind? ;-)
> 
> Actually, being on vacation right now, I started playing around with
> LLVM. In the beginning that was just for fun, but then I began writing a
> "tiny demo interpreter" to see how well it works out. Well, actually
> it's not quite so tiny any more, after hacking away on it for two weeks,
> in some ways it's already much better than Q, with a much cleaner
> syntax, a more minimalistic and dynamic design, real closures (local
> functions, yay!) and a few other goodies.
> 
> The interpreter environment including parser and abstract term rewriting
> code generator is already working and I'm currently doing the final
> touches on the TR -> LLVM JIT code translator. I'm not ready to unveil
> it just yet, but I'll follow up as soon as I have something that can at
> least evaluate 1+1 => 2. :)
> 
> The language and interpreter are codenamed "Pure" a.k.a. the "Pure
> Universal Rewriting Engine", and I do have a preliminary manpage for it,
> which I'm attaching as a little teaser. ;-)
> 
> Cheers,
> Albert
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ q-lang-users mailing list q-l...@li... https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] Speeding up Q

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

Albert Graef wrote:
> Oh, and how about a little example program? ;-)

... and the prelude, as it stands now. This actually illustrates the
language much better than the example. (Sorry for the email bombardment,
I should really think twice before pressing "Send".)

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] Speeding up Q

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

Albert Graef wrote:
> The language and interpreter are codenamed "Pure" a.k.a. the "Pure
> Universal Rewriting Engine", and I do have a preliminary manpage for it,
> which I'm attaching as a little teaser. ;-)

Oh, and how about a little example program? ;-)

-- 
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] Speeding up Q

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

Dr Libor Spacek wrote:
> In my view it should be a high priority getting Q to tun faster in order to gain the user base that it deserves.

Did you read my mind? ;-)

Actually, being on vacation right now, I started playing around with
LLVM. In the beginning that was just for fun, but then I began writing a
"tiny demo interpreter" to see how well it works out. Well, actually
it's not quite so tiny any more, after hacking away on it for two weeks,
in some ways it's already much better than Q, with a much cleaner
syntax, a more minimalistic and dynamic design, real closures (local
functions, yay!) and a few other goodies.

The interpreter environment including parser and abstract term rewriting
code generator is already working and I'm currently doing the final
touches on the TR -> LLVM JIT code translator. I'm not ready to unveil
it just yet, but I'll follow up as soon as I have something that can at
least evaluate 1+1 => 2. :)

The language and interpreter are codenamed "Pure" a.k.a. the "Pure
Universal Rewriting Engine", and I do have a preliminary manpage for it,
which I'm attaching as a little teaser. ;-)

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] GNU Linear Programming Kit with Q

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

Jiri Spitz wrote:
> I have created an interface module to the GNU Linear Programming Kit 
> (GLPK). You can download the source and read something about it on the Q 
> wiki page 
> (http://q-lang.wiki.sourceforge.net/GNU+Linear+Programming+Kit+with+Q).

Great news! :) I haven't had any time to look at it yet, but I put it on
my TODO list to package it for the next Q release.

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] Speeding up Q

[Dr L. S. <li...@gm...>]

In my view it should be a high priority getting Q to tun faster in order to gain the user base that it deserves.

Have any of you considered writing a Q -> C translator, which would then compile to native code using a standard (gnu) C compiler?
It seems to me (perhaps naively) a potentially easier and quicker route to a considerable efficiency gain rather than writing fully blown JIT compiler, plus lots of native compilers?

Furthermore, given the simple re-writing nature of Q, writing a translator may prove to be relatively easy?

Libor

Re: [q-lang-users] GNU Linear Programming Kit with Q

[Jiri S. <jir...@bl...>]

Jiri Spitz napsal(a):
> It is the first full featured release (something between alpha and 
> beta), so expect bugs.

Several bugfixes; precompiled libraries for Linux and Windows now 
available; example file can be downloaded.

Cheers,

Jiri

[q-lang-users] GNU Linear Programming Kit with Q

[Jiri S. <jir...@bl...>]

Hello Q users,

I have created an interface module to the GNU Linear Programming Kit 
(GLPK). You can download the source and read something about it on the Q 
wiki page 
(http://q-lang.wiki.sourceforge.net/GNU+Linear+Programming+Kit+with+Q).

It is the first full featured release (something between alpha and 
beta), so expect bugs. Nontheless, I hope you will find it useful.

Jiri

[q-lang-users] Pd/Q 0.4

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

I've just uploaded a bugfix release of Pd/Q (Q plugin for Miller
Puckette's Pd dataflow programming system), which fixes a deadlock in
the asynchronous messaging code (pd::pd_send). This seems to mainly
manifest itself on multi-cpu systems, but upgrading is recommended anyway.

Enjoy. :)
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] GGI 2.2 issues

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

Hi,

I finally looked into and solved the problems with GGI version 2.2.x and
the '-inwin' option on X11 (this is required to embed GGI graphics
windows into GUI applications, and has been broken ever since GGI 2.2.0
came out). A patch which should work with all GGI 2.2.x versions is
available here: http://q-lang.sourceforge.net/ggi-2.2-inwin.patch

Note that this should be applied to the libggi-2.2.x sources, not the Q
sources. GGI versions <= 2.1.x are ok, they don't need the patch,
neither does the GGI version bundled with the Windows package for Q.

The changes are also in GGI CVS now, so they should eventually trickle
down to systems which currently ship broken GGI packages, such as
Debian. (Once the GGI maintainers decide that it's time for another
bugfix release, that is.)

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 7.11 on Mac OS X

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

Ryan Schmidt wrote:
> Hello. Q 7.10 compiled just fine on Mac OS X 10.4.11 Intel, but 7.11  
> doesn't. Here's what it does:

Hmm, any news on that? Didn't the patch I posted work for you?

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] CSV update

[Eddie R. <er...@bm...>]

Thanks guys! I can move some of my scripts to some of the office machines at work now.

Eddie

On Sat 08/03/08  6:00 AM , Albert Graef Dr....@t-... sent:
> > A new source tarball (q-csv-0.2) is now available from
> the usual> locations and I've updated the Windows MSI as well as
> the Debian eeePC> package. I've also notified Toni Graffy, so a new
> q-addon SUSE rpm will> hopefully be available soon.
> 
> Toni has updated the q-addons package, so the latest Q-CSV should now
> beincluded. Thanks Toni!
> 
> Albert
> 
> -- 
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr.Graef
> @t-online.de, ag...@mu...WWW:    http://www.musikinformatik.uni-mainz.de/ag
> -------------------------------------------------------------------------This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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
> 
>