q-lang-users

[q-lang-users] Just starting with Q

[Burton S. <kr...@gm...>]

Hi Everyone,

I just started working with Q and I seem to be running in a newbie
problem that I can't seem to get around.  My first little function I
am trying to write would be a copy of the Unix 'cat' utility, which I
thought would be rather simple.  I found the example for 'fcopy' in
the manual and made a file 'cat' (the Q source file) containing the
following code:

public cat F;

cat F = () if feof F;
      = writes (freads F) || cat F otherwise;

And then in the interpreter i do the following:

[.q/] run cat
[.q/cat] def F = fopen "cat" "r"
[.q/cat] cat F
cat <<File>>
[.q/cat] cat::cat F
cat <<File>>
[.q/cat] whos cat

cat             function symbol defined in /home/kruhft/.q/cat
                cat X1

As you can see, there seems to be some sort of problem but I can't
seem to figure it out (hence my asking here ;-).  I tried playing
around with the interpreter and file handles and noticed that <<File>>
seems to be returned on errors during file operations, but I don't
understand how that's happening on a freshly opened file.

Any help or suggestions for this newbie problem? TIA

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

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

Burton Samograd wrote:
> public cat F;
> 
> cat F = () if feof F;
>       = writes (freads F) || cat F otherwise;

That script works fine over here. I'd suggest replacing freads with 
fgets from clib, though, because freads chops off the newline at the end 
of a line, whereas fgets keeps it.

> [.q/cat] def F = fopen "cat" "r"
> [.q/cat] cat F
> cat <<File>>

There's definitely something strange going on there. Are you running Q 
7.2? Unfortunately, there's a bug in that version which might cause the 
behaviour that you see. Could you please try your example with Q 7.1? Or 
with the latest release candidate, Q 7.3 RC1, which is available here:

http://prdownloads.sourceforge.net/q-lang/q-7.3rc1.tar.gz?download

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

Re: [q-lang-users] Just starting with Q

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

/me wrote:
> There's definitely something strange going on there. Are you running Q 
> 7.2? Unfortunately, there's a bug in that version which might cause the 
> behaviour that you see. Could you please try your example with Q 7.1?

Hmm, actually the bug was probably introduced already with Q 7.1. You 
can try your example with Q 7.0, or wait until I release Q 7.3 later 
today. Sorry for the hassle.

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] Just starting with Q

[Burton S. <kr...@gm...>]

On 8/21/06, Albert Graef <Dr....@t-...> wrote:
> /me wrote:
> > There's definitely something strange going on there. Are you running Q
> > 7.2? Unfortunately, there's a bug in that version which might cause the
> > behaviour that you see. Could you please try your example with Q 7.1?
>
> Hmm, actually the bug was probably introduced already with Q 7.1. You
> can try your example with Q 7.0, or wait until I release Q 7.3 later
> today. Sorry for the hassle.

I just tried it with a freshly built 7.3 and I still have the same
results.  I really have to head to bed, but I will try with 7.0
tomorrow.

Thanks for the help.

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

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

Burton Samograd wrote:
> I just tried it with a freshly built 7.3 and I still have the same
> results.  I really have to head to bed, but I will try with 7.0
> tomorrow.

Ok, please let me know what you get. A complete log of a session with 
the debugger would help, too. E.g., you can try something like the 
following in a Unix shell:

q cat -d -c 'cat (fopen "cat" "r")' >log.txt

The log will end up in log.txt, please attach to your reply.

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] Just starting with Q

[Burton S. <kr...@gm...>]

On 8/21/06, Albert Graef <Dr....@t-...> wrote:
> Burton Samograd wrote:
> > I just tried it with a freshly built 7.3 and I still have the same
> > results.  I really have to head to bed, but I will try with 7.0
> > tomorrow.
>
> Ok, please let me know what you get. A complete log of a session with
> the debugger would help, too. E.g., you can try something like the
> following in a Unix shell:
>
> q cat -d -c 'cat (fopen "cat" "r")' >log.txt
>
> The log will end up in log.txt, please attach to your reply.

The code works fine with 7.0 (except for a the missing newline you
mentioned, but that's in my code).  I'll attach the log so that you
can diff it against a newer version to see the differences.

Thanks for the help.

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

[Burton S. <kr...@gm...>]

> The code works fine with 7.0 (except for a the missing newline you
> mentioned, but that's in my code).  I'll attach the log so that you
> can diff it against a newer version to see the differences.

And I just updated to the current CVS code and it also works, so
something must have been fixed in the meantime.  Now back to my
regularly scheduled hacking in my new favorite languge ;-)

Thanks.

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

[Burton S. <kr...@gm...>]

On 8/21/06, Burton Samograd <kr...@gm...> wrote:
> > The code works fine with 7.0 (except for a the missing newline you
> > mentioned, but that's in my code).  I'll attach the log so that you
> > can diff it against a newer version to see the differences.
>
> And I just updated to the current CVS code and it also works, so
> something must have been fixed in the meantime.

Hmmm.  And then I tried it again and it didn't work.  I must have
missed something; I'll look into this further.

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

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

Burton Samograd wrote:
> Hmmm.  And then I tried it again and it didn't work.  I must have
> missed something; I'll look into this further.

If you can produce a debug log of the *errorneous* computation, that 
would be most helpful. I cannot reproduce your problem here, your script 
works fine 100% of the time over here (with Q 7.3, that is).

In any case, if you get that 'cat <<File>>' response you mentioned 
earlier, something is going severely wrong in the interpreter; your 
definition should *never* return that value. It should either bail out 
with an "error in conditional" if feof F fails to evaluate, or return 
(). So if the problem persists, it's most likely an obscure bug in the 
interpreter, and I'd appreciate any info that could help me to find out 
what's going on there.

BTW, what system are you running Q on?

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] Just starting with Q

[Burton S. <kr...@gm...>]

On 8/21/06, Albert Graef <Dr....@t-...> wrote:
> In any case, if you get that 'cat <<File>>' response you mentioned
> earlier, something is going severely wrong in the interpreter; your
> definition should *never* return that value. It should either bail out
> with an "error in conditional" if feof F fails to evaluate, or return
> (). So if the problem persists, it's most likely an obscure bug in the
> interpreter, and I'd appreciate any info that could help me to find out
> what's going on there.
>
> BTW, what system are you running Q on?

I'm on Gentoo Linux, but I think I found the problem (which is my
fault, I would guess, but might be interesting for you to know about).
 I was playing around running q with the --no-prelude option just to
cut down on the defined symbol space.  It turns out the code works
fine without the option, but fails with it (no prelude loaded).

This could be interesting to you since the code I wrote doesn'
actually use any of the prelude functions; maybe there's a bit of code
in the prelude loading code that sets something up in the interpreter
that is causing this problem.  Just a thought.

So I won't be doing that anymore, or at least until it gets fixed or
someone tells me what I might be doing wrong.

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

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

Burton Samograd wrote:
> I'm on Gentoo Linux, but I think I found the problem (which is my
> fault, I would guess, but might be interesting for you to know about).
>  I was playing around running q with the --no-prelude option just to
> cut down on the defined symbol space.  It turns out the code works
> fine without the option, but fails with it (no prelude loaded).

Well, with --no-prelude clib::fgets is not defined, so the modified 
program (with fgets instead of freads) won't work anymore; it will 
(correctly) loop forever, because fgets F is just a normal form and 
hence nothing ever gets read.

The following program, which doesn't depend on clib or anything else in 
the standard library works fine with --no-prelude, though:

cat F = () if feof F;
       = writes (freads F) || writes "\n" || cat F otherwise;

Your code (without the writes "\n") runs fine with --no-prelude, too, 
but of course the newlines are missing.

Could you please check whether the above program works ok for you when 
run with --no-prelude? I.e., the output should be something like:

$ q --no-prelude cat.q

==> def F = fopen "cat.q" "r"; cat F
cat F = () if feof F;
       = writes (freads F) || writes "\n" || cat F otherwise;
()

> This could be interesting to you since the code I wrote doesn'
> actually use any of the prelude functions; maybe there's a bit of code
> in the prelude loading code that sets something up in the interpreter
> that is causing this problem.

There shouldn't be. The above program should work fine without the 
prelude. If it doesn't then there's a bug lurking somewhere, which needs 
to be fixed. I'd be surprised if this was so, because these basic 
examples have been checked on many systems many times. But, C being what 
it is, you can never be sure. ;-)

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] Just starting with Q

[Burton S. <kr...@gm...>]

On 8/22/06, Albert Graef <Dr....@t-...> wrote:

> The following program, which doesn't depend on clib or anything else in
> the standard library works fine with --no-prelude, though:
>
> cat F = () if feof F;
>        = writes (freads F) || writes "\n" || cat F otherwise;
>
> Your code (without the writes "\n") runs fine with --no-prelude, too,
> but of course the newlines are missing.
>
> Could you please check whether the above program works ok for you when
> run with --no-prelude? I.e., the output should be something like:
>
> $ q --no-prelude cat.q
>
> ==> def F = fopen "cat.q" "r"; cat F
> cat F = () if feof F;
>        = writes (freads F) || writes "\n" || cat F otherwise;
> ()
>

I did just check your above code and my own code, and neither of them
run when the --no-prelude option is given (both return the "cat
<<File>>") but both work fine otherwise.

> > This could be interesting to you since the code I wrote doesn'
> > actually use any of the prelude functions; maybe there's a bit of code
> > in the prelude loading code that sets something up in the interpreter
> > that is causing this problem.
>
> There shouldn't be. The above program should work fine without the
> prelude. If it doesn't then there's a bug lurking somewhere, which needs
> to be fixed. I'd be surprised if this was so, because these basic
> examples have been checked on many systems many times. But, C being what
> it is, you can never be sure. ;-)

Yes, that is true; bugs always lurk, and I have to admit, I'm really
good at finding the obscure ones over the course of my lifetime ;-)
Maybe I'll dig a bit into the code and see what I can find in there,
and just to have a look around since I always like to know the
internals of what I'm working with.

For now I'll do my playing around with the prelude enabled, at least
until we can get same behaviour from both; learning is hard with
obscure bugs getting in the way sometimes.

Thanks for your help with this issue.

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

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

Burton Samograd wrote:
> I did just check your above code and my own code, and neither of them
> run when the --no-prelude option is given (both return the "cat
> <<File>>") but both work fine otherwise.

Strange. What's your hardware platform? If you have the time, please do 
send me a debug log of the failing computation, i.e., with --no-prelude 
-d. Maybe I can then figure out what's going on there.

> Yes, that is true; bugs always lurk, and I have to admit, I'm really
> good at finding the obscure ones over the course of my lifetime ;-)

Then you're most welcome here. ;-) What we really need now that Q slowly 
gains more traction is a lot of testing. Q has been quite stable for a 
while now, but in the 7.x series I added a bunch of important new 
features for which I had to touch almost every source module, so some 
fallout from these changes was to be expected.

The new Q Yacc and Lex also keep shaking out compiler bugs, like program 
generators often do, so I'm planning to do another bugfix release as 
soon as I'm finished with those tools. It would be nice if this release 
could also address the issue that you encountered.

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] Just starting with Q

[Burton S. <kr...@gm...>]

I don't have too much time but here's a quick session using my current
Q version, right from cvs (my comments start with a #):  As can be
seen, it works with no prelude, but now it just seems to hang without
the prelude.  This version of Q was pulled from CVS and built last
night.  Hopefully this might be of help.  Oh, and I'm on a Pentium 4
running Gentoo with no wacky CFLAGS other than the -O2 -g defaults.
This seems to be a strange problem, but I don't have any time right
now to look more...I shall later. Hope this helps a bit.

<9> [~] .Wed Aug 23 16:46:05.
cd .q
<9> [~/.q] .Wed Aug 23 16:46:08.
cat cat
cat F:String = cat_file (fopen F "r");
cat F:File = cat_file F;
cat F = cat_file (fopen (str F) "r") if issym F;
      = prints "cat: unsupported type";
cat_file F:File = () if feof F;
	   = putc (fgetc F) || cat F otherwise;

cat2 F = () if feof F;
       = writes (freads F) || writes "\n" || cat F otherwise;
<9> [~/.q] .Wed Aug 23 16:48:12.
q cat -d -c 'cat (fopen "cat" "r")'
**  clib::sys_vars  ==>  (1,2,4,...)
--  def (SIZEOF_CHAR,SIZEOF_SHORT,SIZEOF_INT,...) = (1,2,4,...)
--  def SIG_IGN = -1
--  def SIG_DFL = 0
--  def SIG_TRP = 1
--  def SCHED_OTHER = 0
--  def SCHED_RR = 1
--  def SCHED_FIFO = 2
--  def AF_UNIX = 1
--  def AF_FILE = 1
--  def S_ISUID = 2048
--  def S_ISGID = 1024
--  def S_ISVTX = 512
--  def S_IRWXU = 448
--  def S_IRUSR = 256
--  def S_IWUSR = 128
--  def S_IXUSR = 64
--  def S_IRWXG = 56
--  def S_IRGRP = 32
--  def S_IWGRP = 16
--  def S_IXGRP = 8
--  def S_IRWXO = 7
--  def S_IROTH = 4
--  def S_IWOTH = 2
--  def S_IXOTH = 1
**  this_thread  ==>  <<Thread>>
--  def clib::MAIN_THREAD = <<Thread>>
**  1e+307*1e+307  ==>  inf
--  def inf = inf
**  inf-inf  ==>  nan
--  def nan = nan
--  def i = complex 0 1
--  def NOARG = 0
--  def REQARG = 1
--  def OPTARG = 2
**  fopen "cat" "r"  ==>  <<File>>
  0>  cat, line 2: cat <<File>>  ==>  cat_file <<File>>
cat F:String = cat_file (fopen F "r");
cat F:File = cat_file F;
cat F = cat_file (fopen (str F) "r") if issym F;
      = prints "cat: unsupported type";
cat_file F:File = () if feof F;
	   = putc (fgetc F) || cat F otherwise;

cat2 F = () if feof F;
       = writes (freads F) || writes "\n" || cat F otherwise;
()
<9> [~/.q] .Wed Aug 23 16:49:02.
q cat --no-prelude -d -c 'cat (fopen "cat" "r")'
**  fopen "cat" "r"  ==>  <<File>>
  0>  cat, line 2: cat <<File>>  ==>  cat_file <<File>>
(type ? for help)
: c
  C-c C-c! Break
>>> cat (fopen "cat" "r")
                         ^
# just hangs here, and I have to hit ctl-c
<9> [~/.q] .Wed Aug 23 16:50:18.
q cat --no-prelude -d -c 'cat2 (fopen "cat" "r")'
**  fopen "cat" "r"  ==>  <<File>>
  0>  cat, line 8: cat2 <<File>>  ==>  () if feof <<File>>
(type ? for help)
: c
cat F:String = cat_file (fopen F "r");
  C-c C-c! Break
>>> cat2 (fopen "cat" "r")                          ^
# hangs here too

Re: [q-lang-users] Just starting with Q

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

Hi Burton,

thanks for the log, that cleared things up quite a bit. Looks like the 
computations are going ok now -- no more unevaluated cat applications, 
so I assume that these were actually due to the bug in 7.1/7.2 I 
mentioned, which is now fixed. But there are various bugs in your script 
which cause the behaviour that you see with --no-prelude. The bugs you 
were bitten by are not unusual, and I have some advice on how to avoid 
these pitfalls.

Specifically, it might be a good idea to run your scripts with -w which 
warns you about function symbols that are used but neither defined 
(occurring on the lhs of an equation) nor explicitly declared anywhere. 
(There's also --pedantic a.k.a. -w2 which warns you about all function 
and free variable symbols which are not explicitly declared, but that's 
rather awkward since it forces you to declare each and every symbol.) I 
have my Emacs Q mode configured to always run the interpreter with -w, 
and of course you can also do the same on the command line with an alias.

Running your script with --no-prelude -w gives:

Warning cat, line 10: undeclared function symbol `issym'
Warning cat, line 10: undeclared function symbol `prints'
Warning cat, line 10: undeclared function symbol `putc'
Warning cat, line 10: undeclared function symbol `fgetc'

(The warnings are printed at the end of a script, that's why you always 
see line 10 up there. With --pedantic you get the warnings on the spot, 
for each first occurrence of an undeclared symbol.)

Ok, so issym and prints aren't defined anywhere, but these are not the 
culprits here. But putc/fgetc are not defined either and this breaks 
your script with --no-prelude. These functions come from clib.q, and 
actually they are just aliases for writec/freadc, so replacing these for 
putc/fgetc will make the cat function work as intended, even with 
--no-prelude.

BTW, this kind of bugs is rather symptomatic of Q, because function 
symbols are declared implicitly, and Q is perfectly happy with 
applications of undefined or partially defined functions; they're just 
normal forms. This is actually an essential feature of Q as a term 
rewriting language. In a more conventional language like Lisp or Haskell 
such bugs cause runtime or compile time errors. In Q, they can mostly be 
avoided with -w. Not always; Q is a sharp knife. ;-) More subtle 
problems which cannot be caught with -w/--pedantic have to do with Q's 
dynamic typing and unbounded ad-hoc polymorphism; there's no way to warn 
about these without severely restricting Q's expressiveness, so you'll 
have to resort to the debugger or unit tests to find them.

Burton Samograd wrote:
> [lots of debugger output snipped]
> # just hangs here, and I have to hit ctl-c
> <9> [~/.q] .Wed Aug 23 16:50:18.
> q cat --no-prelude -d -c 'cat2 (fopen "cat" "r")'
> **  fopen "cat" "r"  ==>  <<File>>
>   0>  cat, line 8: cat2 <<File>>  ==>  () if feof <<File>>
> (type ? for help)
> : c
> cat F:String = cat_file (fopen F "r");
>   C-c C-c! Break
> 
>>>>cat2 (fopen "cat" "r")                          ^
> 
> # hangs here too

So what happened here was that with --no-prelude fgetc never read 
anything, because it wasn't defined, hence feof never became true, and 
the cat function looped without actually doing anything else. And you 
saw the same symptom with the second definition, because in the second 
equation for cat2 you didn't recursively call cat2, but the flawed cat 
function. After fixing that cat2 worked ok for me.

Just for the record, here is the corrected script:

cat F:String = cat_file (fopen F "r");
cat F:File = cat_file F;
cat F = cat_file (fopen (str F) "r") if issym F;
       = prints "cat: unsupported type";
cat_file F:File = () if feof F;
	   = writec (freadc F) || cat F otherwise;

cat2 F = () if feof F;
        = writes (freads F) || writes "\n" || cat2 F otherwise;

(Well, obviously you still have to define prints somewhere, and copy the 
definition of issym from the standard library script typec.q if you want 
to run the script with --no-prelude.)

BTW, another way to copy a text file, for the lazy programmer, is to use 
clib::fget which slurps an entire file in at once and returns it as a 
string. E.g.: 'cat F = fputs (fget F);'. There are also various 
low-level I/O functions in clib which allow arbitrary (possibly binary) 
files to be read and written in big chunks.

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] Just starting with Q

[Burton S. <kr...@gm...>]

Hi Albert,

Thanks for the very informative response to my newbie problems :)
I'll be running with -w from now on, and will try not to rush my code
so as to avoid silly typos (3 shows this week, work and remix contests
to enter had me a bit short of time for my study of a new programming
language, but I try and squeeze it in whenever I can find the time and
energy, if only because I think Q is really fascinating and could be a
very important part of my artistic arsenal in the future).

One of the major thing attracting me to Q is the fact that it's "a
very sharp knife" (which I can see from the design), and I know it
will take some experience and practice before I can do some major
surgery ;-)  One of the major issues I have with current languages is
lack of expressiveness, so I'm glad that one finally exists that isn't
putting kid gloves on me (Python), or concrete shoes (Haskell) and
let's one 'hack' like you're supposed to :D (after the initial
learning curve that is)

I appreciate your help very much with these issues; nothing like
learning the language from the designer (and one that saved me 10
years of work by creating the language that I *was* designing until I
found Q).

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

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

Burton Samograd wrote:
> Thanks for the very informative response to my newbie problems :)

No problem. In fact those newbie questions are valuable input for the 
book about Q that I'm writing. I really have to add a "common pitfalls" 
chapter to the book where I describe the usual suspects and how to deal 
with them, and it's nice to have a ml archive which I can harvest for 
that. :) So keep the newbie questions coming...

> 3 shows this week, work and remix contests

Are you a musician? Q has quite a bit of stuff to offer there. Together 
with two colleagues, I'll be giving a talk on some of these interfaces 
at ICMC 2006 in New Orleans.

> so I'm glad that one finally exists that isn't
> putting kid gloves on me (Python), or concrete shoes (Haskell) and
> let's one 'hack' like you're supposed to :D

Yes, Q's certainly intended as a hacker's tool, in Paul Graham's sense. 
I love hacking away on problems, developing stuff from the bottom up, 
and IMHO Q supports that style fairly well.

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] Just starting with Q

[Burton S. <kr...@gm...>]

On 8/24/06, Albert Graef <Dr....@t-...> wrote:
> Burton Samograd wrote:
> > Thanks for the very informative response to my newbie problems :)
>
> No problem. In fact those newbie questions are valuable input for the
> book about Q that I'm writing. I really have to add a "common pitfalls"
> chapter to the book where I describe the usual suspects and how to deal
> with them, and it's nice to have a ml archive which I can harvest for
> that. :) So keep the newbie questions coming.

Ok then, I shall ask without worry :)

> > 3 shows this week, work and remix contests
>
> Are you a musician? Q has quite a bit of stuff to offer there. Together
> with two colleagues, I'll be giving a talk on some of these interfaces
> at ICMC 2006 in New Orleans.

Music is one of the forms of art that I do that is getting the most
attention lately, although I also do visual art, writing, and whatever
else to keep myself busy.  The easiest way to hear my music is through
MySpace (see below in my signature), which I update pretty regularly
with a rotation of songs, and if you google me (kruhft or burton
samograd) you can find more of my music scattered about the 'net, and
if you don't have time for that, I could just send you some links off
list where you can download it from me since you're helping me out
with learning Q :)

One of the reasons I'm learning Q is because of the work you put in
integrating the audio/image libraries that are included.  I've worked
with many different types of audio programing sytems, and they are all
very capable, but I'm very much into 'interactive' and exploratory
programming and most styems really lack any sort of suitable shell
interface, which Q very capable provides and in a novel and very
useful way.  I've also been studying high level programming languages
for the past five years or so and would say that I know the current
state of the art feature set pretty well and 'know what I want from a
language' and you hit the nail on the head with Q, at least from what
I've read in the manual and the papers you've provided.

Basically, it looks like I've found exactly what I've been looking
for, so now I better put in the time to learn it :)

> > so I'm glad that one finally exists that isn't
> > putting kid gloves on me (Python), or concrete shoes (Haskell) and
> > let's one 'hack' like you're supposed to :D
>
> Yes, Q's certainly intended as a hacker's tool, in Paul Graham's sense.
> I love hacking away on problems, developing stuff from the bottom up,
> and IMHO Q supports that style fairly well.

Yes, hacker in the original, Lispy, working with data and code in a
natural sense sort of way, which is the way that my style went after
breaking the shackles of industrial programming (aka corporate and
production).  I write code to get the computer to do things for me,
not programs per se, and a combo shell/high level langauge is going to
open up new things that bash never could, and C was too tedious for
(even with the meta programming system that I came up with).

Ok, back to hacking so I can screw up and ask some more questions :)

-- 
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

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

Burton Samograd wrote:
> Music is one of the forms of art that I do that is getting the most
> attention lately

The nickname kruhft rings a bell, but I don't recall whether I saw it in 
a music context or maybe on LtU... I'll have a look, thanks for the pointer.

Regarding the audio stuff, one project that I'm still working on is an 
improved interface to Faust and SuperCollider, which (1) handles all the 
grunt work of loading Faust DSP plugins into SuperCollider and (2) 
provides a high-level control interface similar to SuperCollider's own, 
but written 100% in Q. I hope that I can still finish this before ICMC. 
The current interfaces to Faust and SuperCollider in the Q-Faust and 
Q-Synth packages are already quite usable, however, and they should let 
you do pretty much any high-fidelity, low-latency, realtime audio 
processing that you want (provided you have enough CPU power).

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] Just starting with Q

[Burton S. <kr...@gm...>]

On 8/25/06, Albert Graef <Dr....@t-...> wrote:
> Burton Samograd wrote:
> > Music is one of the forms of art that I do that is getting the most
> > attention lately
>
> The nickname kruhft rings a bell, but I don't recall whether I saw it in
> a music context or maybe on LtU... I'll have a look, thanks for the pointer.

I do post on LtU from time to time when I know enough about something
to actually have something to say, but my schooling was in Computer
Engineering and my work experience was video eames (a lot of 8 bit
assembly on the Gameboy and lot low level C coding) so my vocabulary
is a bit lacking when it comes to high level language topics.  My
study of computational linguistics has been an obsessive hobby for the
past years (I like to say my own version of self directed grad
school), but I think I've got a lot of the bases covered from what
I've found, read, and studied over the years.

> Regarding the audio stuff, one project that I'm still working on is an
> improved interface to Faust and SuperCollider, which (1) handles all the
> grunt work of loading Faust DSP plugins into SuperCollider and (2)
> provides a high-level control interface similar to SuperCollider's own,
> but written 100% in Q. I hope that I can still finish this before ICMC.
> The current interfaces to Faust and SuperCollider in the Q-Faust and
> Q-Synth packages are already quite usable, however, and they should let
> you do pretty much any high-fidelity, low-latency, realtime audio
> processing that you want (provided you have enough CPU power).

I know about SC, but for some reason I've avoided it since I found it
years ago, probably because I found the sytax very non-familiar at the
time.  I've used a number of other MIDI/DSP langugage system like
KeyKit, PD, Chuck and Common Lisp Music for my works in the past and I
read the docs for Faust and it looks pretty useful (plus there's
builtin support for it in Audacity, which is a pretty nice audio
editor that I recently added to my toolset), so I should probably take
another look at SC and see if I can mentallly translate it bettter now
that I have some more experience with alternate langages.

--
burton samograd                                                kr...@gm...
kruhft.boldlygoingnowhere.org              www.myspace.com/kruhft

Re: [q-lang-users] Just starting with Q

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

Burton Samograd wrote:
> I know about SC, but for some reason I've avoided it since I found it
> years ago, probably because I found the sytax very non-familiar at the
> time.

Yes, SC-Lang needs some time to get used to it, but it has such a great 
realtime sound+synth engine underneath. Good sound, and very low 
latency. That's what I mostly use, and it can be controlled quite 
conveniently from Q via OSC. I also started thinking about a Q API for 
the synth definitions. When that is finished, together with the 
sequencer interface I'm working on, then you will be able to just use Q 
as the SC language client instead of SC-Lang.

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