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

[q-lang-users] Re: Optimizations and tweaks

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

Dr....@t-... (Albert Graef) writes:

[snip]
> I don't consider that cheating, IIRC the Milner Rabin algorithm itself (at
> least the GMP version) also uses a (fairly large) table of known primes.
> I'd even go farther:
>
> primes N	= [2] if N=2;
> 		= [2,3] if N=3;
> 		= [2,3|filter isprime [5,7..N]] otherwise;
>
> Does that speed up your algorithm even further? I haven't tried.

Yes, a little, but not that much, I think.

[snip]
>> Actually, how would I write a memoize function in Q, anyway? I don't see
>> that, or the word `cache', in the docs anywhere :)
>
> At your request :)
>
> http://q-lang.sourceforge.net/qdoc/qdoc_12.html#SEC118

Oh, *excellent* <rubs hands in glee>. Thanks for that. Refs as well? I have
much Q to be learning. :)

I've implemented memoization on `prime' and `isprime' functions - works
first time ;) 
It emphasizes the extreme contrast between composite and prime (or
few-large-factors not-quite-prime) inputs; whereas it was always close (3%
ish) previously, with both algorithms suffering longer computation-times
for larger nearly-prime input N, I'm now seeing improvements of 50% or more
in individual runs - my algorithm is almost constant/linear by comparison.
This one wins :)

Cheers,

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

Re: Optimizations and tweaks (was Re: [q-lang-users] Problem using function "isprime")

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

Tim Haynes wrote:
> Very interesting concerns, but I've just been very rude and benchmarked the
> two... :)
> For smallish N<1E4, it's evenly matched (3% more occasions on which mine is
> faster than yours). 

The trouble with theory is that it's theoretically true but practically 
useless. :) I stand corrected...

> It can of course be considerably quicker: just by amending 
> 
>     primes N = [2] if  N=2;         
>              = [2,3] if N=3;               //cheating!

I don't consider that cheating, IIRC the Milner Rabin algorithm itself 
(at least the GMP version) also uses a (fairly large) table of known 
primes. I'd even go farther:

primes N	= [2] if N=2;
		= [2,3] if N=3;
		= [2,3|filter isprime [5,7..N]] otherwise;

Does that speed up your algorithm even further? I haven't tried.

> it's faster than yours on 10x as many ocassasion than where yours was
> faster than mine, around N<=2E9, so it's hitting the bottom few cases of
> the recursion quite a *lot*.

Ok, ok, I'm convinced. An update of the isprime section is on the TODO 
list. ;-)

> What I'd like to know is whether there's any memoization going on - by the
> time I've evaluated `isprime 13' once for intsqrt(N), I don't need to do it
> all over again for intsqrt(intsqrt(N)), etc.

Maybe the GMP function does some memoization internally? The Q 
interpreter doesn't do it, that I know for sure.

> Actually, how would I write a memoize function in Q, anyway? I don't see
> that, or the word `cache', in the docs anywhere :)

At your request :)

http://q-lang.sourceforge.net/qdoc/qdoc_12.html#SEC118

Albert

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

Optimizations and tweaks (was Re: [q-lang-users] Problem using function "isprime")

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

Dr....@t-... (Albert Graef) writes:

[snip]
>> Not quite as pretty to look at, but I think it may run faster as it only
>> uses the primes between 2..intsqrt N rather than all odds, if I read your
>> algorithm right...
>
> Hi, Tim! From the algorithm I posted:
>
>  >                    =3D try_div 3 (intsqrt N) N otherwise;
>                                    ^^^^^^^
>
> See? :)

Yes... I had that too...

> While your algorithm looks quite neat, I doubt that it will be any
> faster, since it uses a list, while the one from the docs is just plain
> tail-recursive number crunching (which has the added benefit that it only
> needs O(1) space). I'm also a bit worried about the recursive isprime
> call, which might slow down things quite a bit if enough members of the
> [2..N] list fail the Miller-Rabin test.

Very interesting concerns, but I've just been very rude and benchmarked the
two... :)
For smallish N<1E4, it's evenly matched (3% more occasions on which mine is
faster than yours).=20
However, for N approaching 1E9 or so, the number of occasions on which my
algorithm is faster pulls away - around 2.1E9 I've been seeing about 3x as
many occasions on which mine's been faster compared to yours.

It seems to be taking 2-3% less time, when it's better.

The recursive isprime call is actually a win; effectively it's calling
intsqrt(intsqrt(intsqrt(intsqrt.....))) a few times (per prime in range,
not per-odd-number in range) which tends towards 1 quicker than your
concern about implementation slows it down.
Bear in mind that only 1/12 numbers in the range [1..1E6] is a prime, too...

It can of course be considerably quicker: just by amending=20

    primes N =3D [2] if  N=3D2;=20=20=20=20=20=20=20=20=20
             =3D [2,3] if N=3D3;               //cheating!
             =3D filter isprime [2..N] otherwise;

it's faster than yours on 10x as many ocassasion than where yours was
faster than mine, around N<=3D2E9, so it's hitting the bottom few cases of
the recursion quite a *lot*.

                                   ~~~~

What I'd like to know is whether there's any memoization going on - by the
time I've evaluated `isprime 13' once for intsqrt(N), I don't need to do it
all over again for intsqrt(intsqrt(N)), etc.

Actually, how would I write a memoize function in Q, anyway? I don't see
that, or the word `cache', in the docs anywhere :)

~Tim
=2D-=20
<http://spodzone.org.uk/>

Re: [q-lang-users] Problem using function "isprime"

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

Tim Haynes wrote:
> While we're here, consider this pair of mutually-recursive functions for
> the job, as well:
> 
>     isprime N = not (any ((=0).(N mod))) (primes (intsqrt N)) ;
> 
>     primes N = [2] if  N=2;
>              = filter isprime [2..N] otherwise;
> 
> Not quite as pretty to look at, but I think it may run faster as it only
> uses the primes between 2..intsqrt N rather than all odds, if I read your
> algorithm right...

Hi, Tim! From the algorithm I posted:

 >                    = try_div 3 (intsqrt N) N otherwise;
                                   ^^^^^^^

See? :)

While your algorithm looks quite neat, I doubt that it will be any 
faster, since it uses a list, while the one from the docs is just plain 
tail-recursive number crunching (which has the added benefit that it 
only needs O(1) space). I'm also a bit worried about the recursive 
isprime call, which might slow down things quite a bit if enough members 
of the [2..N] list fail the Miller-Rabin test.

Albert

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

Re: [q-lang-users] Problem using function "isprime"

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

Dr....@t-... (Albert Graef) writes:

[snip]
> Here's a suitable definition which you can add to your program, copied
> straight from the docs:
[snip]

While we're here, consider this pair of mutually-recursive functions for
the job, as well:

    isprime N = not (any ((=0).(N mod))) (primes (intsqrt N)) ;

    primes N = [2] if  N=2;
             = filter isprime [2..N] otherwise;

Not quite as pretty to look at, but I think it may run faster as it only
uses the primes between 2..intsqrt N rather than all odds, if I read your
algorithm right...

HTH,

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

Re: [q-lang-users] Problem using function "isprime"

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

we...@gm... wrote:
> ==> isprime 1000003;
> isprime 1000003
> 
> It shouldn't be a problem to determine that 1000003 is a prime?

Well, this uses GMP's probabilistic prime test (Miller-Rabin algorithm), 
which may fail (in which case the Q function also fails). As a remedy, 
you can try to increase the clib::ISPRIME_REP value, or add your own 
test which catches the few cases when the Miller-Rabin test fails. See 
the chapter on "Clib", Section "Additional Integer Functions" in the 
manual for details. Here's a suitable definition which you can add to 
your program, copied straight from the docs:

      isprime N:Int = true if N = 2;
                    = false if N and 1 = 0; // even number
                    = try_div 3 (intsqrt N) N otherwise;

      try_div L M N = true if L > M;
                    = false if N mod L = 0;
                    = try_div (L+2) M N otherwise;

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

[q-lang-users] Problem using function "isprime"

[<we...@gm...>]

Hello,
I got a problem using function "isprime" from GMP:
    :
    :

==> isprime 999907;
true

==> isprime 1000003;
isprime 1000003

==> 

   :
   :

It shouldn't be a problem to determine that 1000003 is a prime?

Best regards,
Willi

Re: [q-lang-users] malloc problems on mac os x

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

Tim Haynes wrote:
> I was doing... got quite adept at retrieving `rm -rf q-5.4' from my shell
> history ;)

Hmm, maybe the -lpthread gets in there because some library needed by 
some module (probably libxml or libxslt) needs it, and Q's configure 
picks up that linker option from pkgconfig?

> Do you have a mac over there to check this on? (Not that I can really
> provide anything other than a config.log etc, to debug it, here.)

Well, I have a G4 at the university, but it still runs 10.2.4. I use 
that to test the latest releases every once in a while, but I didn't 
have the time to check 5.4 yet. Will do that asap.

Albert

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

Re: [q-lang-users] malloc problems on mac os x

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

Dr....@t-... (Albert Graef) writes:

>> and exactly the same error has occurred mid-build... Hmmm. OK,
>> `--without-pthread' is not being respected, as all the **/Makefile files
>> have references to it in.
>
> It should work; it does over here. Maybe start from a clean build tree?

I was doing... got quite adept at retrieving `rm -rf q-5.4' from my shell
history ;)

Do you have a mac over there to check this on? (Not that I can really
provide anything other than a config.log etc, to debug it, here.)

>> However, I've just fixed it. `dlcompat' is a bone of contention in
>> darwinports, but by exporting  | setenv DYLD_LIBRARY_PATH
>> /opt/local/lib/:$DYLD_LIBRARY_PATH
>> it's now picking up another version that doesn't exhibit the problem. So
>> all is back to normal and I can migrate the website to the newer version :)
>
> Ok, fine. Maybe a bug report to the dlcompat maintainers is in order? ;-)

Yeah, if I get a spare moment I'll research that and see what happens.
Meanwhile, at least I have Q 5.4 working :)

Cheers,

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

Re: [q-lang-users] malloc problems on mac os x

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

Tim Haynes wrote:
> Hmmm. Well, q-5.3 still works on here... my inclination is to suggest Q's
> doing something less than compatible in v5.4. :)

I don't think so, because IIRC the thread-related stuff hasn't changed 
for a couple of minor releases.

> and exactly the same error has occurred mid-build... Hmmm. OK,
> `--without-pthread' is not being respected, as all the **/Makefile files
> have references to it in.

It should work; it does over here. Maybe start from a clean build tree?

> However, I've just fixed it. `dlcompat' is a bone of contention in
> darwinports, but by exporting 
> 
>  | setenv DYLD_LIBRARY_PATH /opt/local/lib/:$DYLD_LIBRARY_PATH
> 
> it's now picking up another version that doesn't exhibit the problem. So
> all is back to normal and I can migrate the website to the newer version :)

Ok, fine. Maybe a bug report to the dlcompat maintainers is in order? ;-)

Cheers,
Albert

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

Re: [q-lang-users] malloc problems on mac os x

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

Dr....@t-... (Albert Graef) writes:

> Hi, Tim,
>
>>  | dlcompat: pthread_setspecific failed
>
> That seems to be the real culprit. This should never happen. Looks like
> the pthread implementation in the latest OSX is broken.

Hmmm. Well, q-5.3 still works on here... my inclination is to suggest Q's
doing something less than compatible in v5.4. :)

> To verify this, could you please try building without threads (configure
> --without-pthread)?

OK, I've just done:

(CFLAGS="-I/usr/local/stow/darwinports/include -I/usr/local/iODBC/include
-pipe -g " LDFLAGS="-L/usr/local/stow/darwinports/lib
-L/usr/local/iODBC/lib -liodbc " ./configure --prefix=/usr/local/stow/q
--with-{x,gmp,curl,gdbm,magick,odbc,xml}
--with-rl="-L/usr/local/stow/darwinports/lib -lreadline" --without-pthread
&& nice make )|& tee build-conf.log

and exactly the same error has occurred mid-build... Hmmm. OK,
`--without-pthread' is not being respected, as all the **/Makefile files
have references to it in.

<runs quick perl 1-liner to remove all references to `-lpthread'>

...nope, same thing.

However, I've just fixed it. `dlcompat' is a bone of contention in
darwinports, but by exporting 

 | setenv DYLD_LIBRARY_PATH /opt/local/lib/:$DYLD_LIBRARY_PATH

it's now picking up another version that doesn't exhibit the problem. So
all is back to normal and I can migrate the website to the newer version :)

Cheers

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

Re: [q-lang-users] malloc problems on mac os x

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

Hi, Tim,

>  | dlcompat: pthread_setspecific failed

That seems to be the real culprit. This should never happen. Looks like 
the pthread implementation in the latest OSX is broken.

To verify this, could you please try building without threads (configure 
--without-pthread)?

Albert

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

[q-lang-users] malloc problems on mac os x

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

Hi,

I'm having problems building Q on macos x (Panther, uptodate). My first
build runs 95% the way through, and then complains of a malloc double-free.
A subsequent `make' in the same directory immediately afterwards runs to
completion. However, the resultant binary also displays the malloc errors
when you quit the interpreter or when a script finishes.

Typically it looks like:

 | dlcompat: pthread_setspecific failed
 | *** malloc[23438]: Deallocation of a pointer not malloced: 0x501d90; This
 | could be a double free(), or free() called with the middle of an allocated
 | block; Try setting environment variable MallocHelp to see tools to help
 | debug
 | *** malloc[23438]: error for object 0x501ec0: Double free
 | make[2]: *** [qcwrap.c] Error 1
 | make[1]: *** [all-recursive] Error 1
 | make: *** [all] Error 2

This only appears on my mac box, not any linux machine I've used. I've
played around with a few things - setting the above environment variables
wasn't any use, gdb didn't get me anywhere, playing with various
--disable-pthread options didn't help, neither did switching the underlying
version of libtool (a perennial problem in building things on mac - still
no joy). 

Any blinding flashes of insight would be appreciated. I'm off to *try*
building a debug Q interpreter and maybe trying valgrind or something ...
:/

I'm attaching the full build log here as well. 

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

[q-lang-users] Q-Audio 2.1 released / random musings

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

Hi,

it's that time in the night again. :)

Q-Audio 2.1 has just been released. This is a minor update, I only added 
some sample rate conversion functions which I forgot to include in the 
2.0 version released a few days ago. Version 2.1 is now a fairly 
complete digital audio framework for Q, so if you always wanted to 
program an audio recording and editing tool, you should be able to do 
that now. ;-)

Moreover, the "Dependencies Department" has just released MidiShare RPMs 
for the current (2.6.5) SuSE Linux kernels. As usual these can be found 
in the "deps" section of the download aread. Enjoy!

Some of you may have noticed that anonymous CVS access wasn't working in 
the past few days. That seems to be fixed now.

A call for help: I got faster with making releases, primarily because I 
don't maintain FreeBSD and OSX packages any more. If anyone here can 
provide those, please let me know! I do need help with packaging things 
for systems which I don't use very often, if at all.

Last but not least, you may have noticed that Q (more precisely, the 
previous release of Q-Audio and Q-Synth) has, for the first time, made 
it to the SourceForge frontpage. Quite a feat, considering that sf.net 
hosts 87,860 different projects now. Hopefully this is a good sign of 
things to come. :)

Cheers, and good night,
Albert

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

Re: [q-lang-users] sharing CGI library, potential for inclusion in Q

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

Dr....@t-... (Albert Graef) writes:

> Tim Haynes wrote:
>> // read in all of stdin
>> readIn = "" if eof;
>>        = reads ++ readIn otherwise;
>
> Hmm, I wonder whether that really works. IIRC reads removes the line
> ends. Or is that your intention? Otherwise you could simply do a `fget
> INPUT'.

I'm not sure; however, I have used it to receive multi-line data from a
textarea field through a POST operation, with success.

Actually, that bit took me a while to make work; given that POST is just
GET strings on stdin instead of via QUERY_STRING, I was rather surprised
that my tests worked on command-line but not for real CGIs. Either way, the
script as-presented now works.

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

Re: [q-lang-users] sharing CGI library, potential for inclusion in Q

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

Tim Haynes wrote:
> // read in all of stdin
> readIn = "" if eof;
>        = reads ++ readIn otherwise;

Hmm, I wonder whether that really works. IIRC reads removes the line 
ends. Or is that your intention? Otherwise you could simply do a `fget 
INPUT'.

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

Re: [q-lang-users] sharing CGI library, potential for inclusion in Q

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

Dr....@t-... (Albert Graef) writes:

> Hi, Tim! Thanks for the cgi.q script, I'll add it to cvs asap so that it
> gets into the next release. Maybe I should add your description as a
> comment to the beginning of the script?

Coo. Yes, by all means. And/or anything else you'd find useful to help use
it :8)

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

Re: [q-lang-users] sharing CGI library, potential for inclusion in Q

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

Hi, Tim! Thanks for the cgi.q script, I'll add it to cvs asap so that it 
gets into the next release. Maybe I should add your description as a 
comment to the beginning of the script?

Q web programmers out there: Keep 'em rolling! We really need more cgi 
scripting examples. :)

(For the record: Tim has probably the first (and, right now, AFAIK the 
only) Q-powered WWW page on the Internet.)

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

[q-lang-users] Q-Audio 2.0 and Q-Synth 1.1 released

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

The subject says it all. :) More details on the Q homepage:
http://q-lang.sourceforge.net/

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

[q-lang-users] sharing CGI library, potential for inclusion in Q

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

Hi,

I thought I'd share my Q module for CGI programming. It's probably pretty
crude, but it responds to POST or GET data (fail-over from former to
latter), decodes CGI strings correctly, and allows access to any/all
key/value parameters passed to a script.

Optional things: the sqlXML function requires ODBC. If you don't have it,
remove the module from the import line and don't call sqlXML. Otherwise, it
takes a handle and a query-string (assumes no parameters). 

Function description: 

public 	condstr S,      // conditionally wraps expression with `str'
	starttag T,     // makes a start-tag,  "<T>"
	endtag T,       // makes an end-taag,  "</T>"
	cgipairs,       // hash of all CGI pairs
	tag T C,        // puts content C in start/end tags T
	tagify,         // legacy name for tag
	test,           // use for debugging installation
	xmlify A B,     // builds XML from pair-list B, using A as nodenames
	cgivar S,       // returns value of CGI parameter named S
        sqlXML H Q;     // takes handle, SQL; returns XML for later XSLT


Examples:

a) testing
    #!/usr/bin/env q
    #! -cmain ARGS || quit

    import cgi;

    main = cgi::test;

this dumps a minimal HTML page with title, showing the keys found - so
invoke it as index.q?foo=bar.

b) building XML from a SQL query for later transformation - note this
should be rewritten for Q 5.4 since it has its own XML and XSLT functions
now:

    #!/usr/bin/env q
    #! -cmain ARGS || quit

    import cgi, odbc;

    def H=odbc_connect "DSN=someODBCdsn";

    main = writes (sqlXML H "select * from sometable;");

Please consider it released under the terms of the GPL, for inclusion in
some form in future versions of Q if you wish.

[[c0c2272509f29b1f91e5682c273dd0f0  cgi.q]]

Cheers,

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

Re: [q-lang-users] Q 5.4, new website

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

Tim Haynes wrote:
> Actually, I was beginning to lean toward libx{ml2,slt} myself anyway - as
> long as I can build-up XML fragments using a backend representation such as
> libxml2's, and transform them fairly quickly with some xslt engine (libxslt
> being quite adequate), I'm happy. My little website is still cranking,
> happily "powered by Q" for the most part :)

That should be possible. The entire document tree is available, and can 
be traversed and modified, so it is easy to inspect and change the XML 
in a structured way. Of course you can create new XML trees from 
scratch, too. And you can also access the internal or external DTD, so 
that your program knows the validity constraints which are in effect.

You might wish to take a look at the catalog.q example, it shows how to 
create an XML tree from Q data and then transform it using xslt, I think 
that this is what you need?

Cheers,
Albert

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

Re: [q-lang-users] Q 5.4, new website

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

Dr....@t-... (Albert Graef) writes:

> Q 5.4 was released yesterday. 

Most excellent!

>               a new xml/xslt interface. (Tim: Thanks for pointing me at
> this stuff, playing around with XML has been much fun. I know you
> actually wanted a sablotron interface, but it's just libxml2/libxslt for
> now. ;-)

Actually, I was beginning to lean toward libx{ml2,slt} myself anyway - as
long as I can build-up XML fragments using a backend representation such as
libxml2's, and transform them fairly quickly with some xslt engine (libxslt
being quite adequate), I'm happy. My little website is still cranking,
happily "powered by Q" for the most part :)

I'll have to pencil-in a new download imminently :)

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

[q-lang-users] Q 5.4, new website

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

Hi,

Q 5.4 was released yesterday. It fixes some bugs in the debugger and 
incompatibilities with newer Octave versions, and a new q.xml for Kate 
2.1 is also included. Moreover, the interpreter now has a new profile 
command, and, while I was at it, I also threw in a new xml/xslt 
interface. (Tim: Thanks for pointing me at this stuff, playing around 
with XML has been much fun. I know you actually wanted a sablotron 
interface, but it's just libxml2/libxslt for now. ;-)

I also gave the website http://q-lang.sourceforge.net/ a much needed 
facelift, to make it more accessible and facilitate maintenance. 
Comments are welcome (my webmaster skills are pretty basic, so if you 
have any suggestions for further improvements please let me know!).

Next up on my list is a new Q-Audio version, to add support for 
PortAudio v19 (which adds Alsa and Jack support under Linux). I'm also 
considering SWIG (http://www.swig.org/) to make it easier to construct C 
interfaces for complex libraries. Once that is done, things like a 
KDE/Qt wrapper will hopefully be doable without too much work.

Cheers,
Albert

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

RE: [q-lang-users] QPad "help" & CygWin "info"

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

The html help is fine, it's just that when I get into "keyboard mode" using
emacs and command-line tools, I hate to reach for the mouse :)  It's also
just a matter of 'completeness' and 'coherence'... If something is supposed
to work and doesn't, it bothers me even if I don't absolutely need it. 

-----Original Message-----
From: q-l...@li...
[mailto:q-l...@li...] On Behalf Of Albert Graef
Sent: Monday, August 30, 2004 2:05 PM
To: q-l...@li...
Subject: Re: [q-lang-users] QPad "help" & CygWin "info"

Brian Beckman wrote:
> Hi there -- I was trying to get the "help" command of QPad on windows 
> to work through "info" via CygWin.  The error message I get in QPad is 
> "info -- qdoc not found".  In other words, it looks like info is 
> running but simply can't find the qdocs.  Any clues for me about how 
> to fix this, please & thanks?

You'll need the qdoc.info* files from the source tarball (q-5.3.tar.gz). 
You'll find them in the doc subdirectory. Copy those files to some place
where info finds them.

BTW, what's wrong with the manual included in Qpad's html help? It's exactly
the same material as in the info files.

Albert

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


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
q-lang-users mailing list
q-l...@li...
https://lists.sourceforge.net/lists/listinfo/q-lang-users

Re: [q-lang-users] null problemo

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

Dr....@t-... (Albert Graef) writes:

> Hi, Tim!
>
> Tim Haynes wrote:
>> I'm trying to write a little utility to read & (manipulate &) write PNM
>> bitmap image files.
>
> Have you considered using Q's ImageMagick module for that purpose?

Yes, ish. I just wanted to be perverse and do it myself rather than dig
around to see how imagemagick worked.. :)

>> Reading is OK but I've had to declare that `ord ""=0' around my reader
>> function[1]; I'm having serious problems writing the ascii NUL byte out -
>> have tried declaring that `chr 0="\0"' and other variations on a theme, but
>> every time I try to fwritec the thing, the file truncates prematurely;
>> running hexdump shows that no byte in the output is set to 00.
>
> Yes, Q strings are 0-terminated, as in C, therefore you can't have a \0
> in a string (if you do, the string will be truncated there).
>
> What you probably need are byte strings. These are especially useful for
> encoding arbitrary binary data. See Section 12.3 (Clib -> Byte Strings) of
> the manual. Also see the section on binary files for operations on how to
> read and write such binary data from/to a file.

Right. Thanks a lot. I'll look into those. :)

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