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

Re: [q-lang-users] Newbie questions and comments

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

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

> > with no file:line-number, and, critically, execution continues
> > regardless.
> 
> Hmm, yes, the portion of the interpreter which executes the init code is
> a bit simplistic right now. The byte code of an initialization should
> contain a reference to the corresponding source line (IIRC that's not the
> case right now), then the interpreter could give more useful feedback.
> 
> But what would the proper behaviour for a failed match in a def be?
> Really exit the interpreter? Raise an exception? I think that right now
> the interpreter simply abandons execution of the remaining init code of
> the script but continues to the read-eval-print loop anyway, so that you
> can try to find out what went wrong. I think that this behaviour is
> appropriate when running in interactive mode, but I agree that it's not
> very useful in batch mode.

Yeah, that could be reasonable.

> Ok, maybe that's a nice opportunity to try out the (still virgin) Bug
> tracker at http://sourceforge.net/projects/q-lang/ ;-) If you have the
> time, please enter a bug report there, then I'll see what I can do about
> this for the next release.

Duly raised. Commiserations on your first sf.net bug :)

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

Re: [q-lang-users] Newbie questions and comments

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

Tim Haynes wrote:
>  | public plot, pi, degsgran, circle, blob;
>  | 
>  | def pi=4*atan 1;
> 
> PI is a useful thing to have, of course, but with a typo like the above
> (failure to remove the leading `def' whilst converting to lowercase) I get
> 
>  | zsh, trough  8:08PM scot-pics/ % ./map.q 
>  | ! Value mismatch in definition

Yes, but the error message is correct: The def will try to match 3.14... 
against the function symbol pi, and this fails.

> with no file:line-number, and, critically, execution continues regardless.

Hmm, yes, the portion of the interpreter which executes the init code is 
a bit simplistic right now. The byte code of an initialization should 
contain a reference to the corresponding source line (IIRC that's not 
the case right now), then the interpreter could give more useful feedback.

But what would the proper behaviour for a failed match in a def be? 
Really exit the interpreter? Raise an exception? I think that right now 
the interpreter simply abandons execution of the remaining init code of 
the script but continues to the read-eval-print loop anyway, so that you 
can try to find out what went wrong. I think that this behaviour is 
appropriate when running in interactive mode, but I agree that it's not 
very useful in batch mode.

Ok, maybe that's a nice opportunity to try out the (still virgin) Bug 
tracker at http://sourceforge.net/projects/q-lang/ ;-) If you have the 
time, please enter a bug report there, then I'll see what I can do about 
this for the next release.

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] Newbie questions and comments

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

Tim Haynes wrote:
> For some reason, I'm getting 
> 
>  | zsh, trough  6:59PM fsm/ % ./seq.q 
>  | state 17, odd
>  | ! Error in conditional
>  | >>>  main || quit
>  |                  ^

Better leave away all the shebang magic until a script has been tested. 
:) That's why you never saw a prompt from the debugger, because the 
interpreter assumed that you want to run in batch mode. You can also 
leave the shebang as it is, but run the script with q -i to force 
interactive mode. (Or just run the script in (x)emacs, that will add the 
-i option for you.)

Ok, let's walk through a typical debugger session. Running the script 
with q -i seq.q, I get:

==> main
state 17, odd
! Error in conditional
 >>> main
         ^

The interpreter tells us that some conditional failed (that's always 
because the condition didn't yield a truth value). Note that this 
message is from the interpreter, the debugger is *not* invoked by 
default. To tell the interpreter that we want the debugger to kick in 
when an exception like "Error in conditional" is encountered, we have to 
turn on "break" mode (you could also enable this by default, either in 
your .qinitrc file, or with the --break command line option of the 
interpreter):

==> break on

==> main
state 17, odd
! Error in conditional
   2>  stdlib.q, line 134: filter ((...) . hd) [(...),(...),(...)]  ==> 
  [(...)|filter (...) [...]] if ((...) . hd) (odd,bounce_odd,_A (...))
(type ? for help)
:

(That ":" at the beginning of the line is the prompt of the debugger.)

This doesn't tell us an awful lot yet, because of all the ...'s. By 
default, the debugger only prints two level of parentheses, but we can 
change this with the .detail command:

: .detail=all

Now just reprint the current rule with the . command:

: .
   2>  stdlib.q, line 134: filter ((=odd) . hd) [(odd,bounce_odd,_A 
(printf "%d\n")),(even,bounce_even,_A (printf "%d\n")),(one,fsm::Stop,_A 
(printf "Stopped! %d\n"))]  ==>  [(odd,bounce_odd,_A (printf 
"%d\n"))|filter ((=odd) . hd) [(even,bounce_even,_A (printf 
"%d\n")),(one,fsm::Stop,_A (printf "Stopped! %d\n"))]] if ((=odd) . hd) 
(odd,bounce_odd,_A (printf "%d\n"))
:

Ok, so there we are: ((=odd) . hd) (odd,bounce_odd,_A (printf "%d\n")) 
is the culprit. Want to see what this actually evaluates to? Simple, 
just reenter the expression in the debugger:

: ((=odd) . hd) (odd,bounce_odd,_A (printf "%d\n"))
hd (odd,bounce_odd,_A (printf "%d\n"))=odd

Right, hd of a tuple doesn't compute. Maybe you actually want a fst 
there? Or, better yet, use top, that works with both lists and tuples:

: ((=odd) . top) (odd,bounce_odd,_A (printf "%d\n"))
odd=odd

Hmm, we got one step further but odd=odd still doesn't compute (you 
can't compare non-const function symbols). You should rather use eq 
(syntactical equality) there:

: (eq odd . top) (odd,bounce_odd,_A (printf "%d\n"))
true

Right, that's what we want to have. Now let's see how we got here (we go 
up one rule in the call stack):

: u
   1>  fsm.q, line 20: fsm::lookup [(odd,bounce_odd,_A (printf 
"%d\n")),(even,bounce_even,_A (printf "%d\n")),(one,fsm::Stop,_A (printf 
"Stopped! %d\n"))] odd  ==>  hd R where R = filter ((=odd) . hd) 
[(odd,bounce_odd,_A (printf "%d\n")),(even,bounce_even,_A (printf 
"%d\n")),(one,fsm::Stop,_A (printf "Stopped! %d\n"))]

Ok, so that's the equation with the wrong filter predicate. If you've 
been running this in xemacs (as I did), you'd now just click on the last 
line above, xemacs then takes you to the equation in fsm.q and you can 
immediately correct it. Maybe it should read more like this:

lookup M S = hd R if R where R=filter (eq S.top) M;
            = false otherwise;

Rerunning the seq.q script now gives the next error:

==> main
state 17, odd
! Error in conditional
   1>  fsm.q, line 20: fsm::lookup [(odd,bounce_odd,_A (printf 
"%d\n")),(even,bounce_even,_A (printf "%d\n")),(one,fsm::Stop,_A (printf 
"Stopped! %d\n"))] odd  ==>  hd [(odd,bounce_odd,_A (printf "%d\n"))] if 
[(odd,bounce_odd,_A (printf "%d\n"))]
(type ? for help)
:

As you see we got one step further: The filter now works ok, but quite 
obviously you can't use the result (which is always a list, and never a 
truth value) as a conditional. "if R" is the culprit here; maybe you 
want something like "if not null R" instead? Or you could use a where 
clause like "lookup M S = R where [R|_] = filter (eq S.top) M;"? As I'm 
not sure what you're actually trying to do there, I leave the rest up to 
you now.

You see, the Q debugger is actually much better than its reputation. ;-) 
With its help, I was able to spot two errors (and fix one of them) in 
just a few seconds.

> which I can't make head or tail of. First, there's a surfeit of ellipses
> where some symbols would've been nicer. Mostly, it's a lack of clarity
> about what you've got versus what you're expecting, particularly as
> pertains to datatypes at a given point in the code. I really want something
> that says `got `foo Integer', using `foo A' as nearest/earliest match' -
> not in so many words, but it should read that way pretty obviously.

As I tried to point out above, there's a lot more to the debugger than 
its default output. You can determine the level of detail that is to be 
printed, you can specify when it should take over (using debug on, break 
on, or by explicitly setting permanent or temporary breakpoints on a 
certain function), you can inspect the entire call stack, you can step 
over reductions, and you can even use it to evaluate expressions on the 
fly in the context of the current rule. All this is described in more 
detail in Appendix D of the manual: 
http://q-lang.sourceforge.net/qdoc/qdoc_16.html#SEC152

When you want to make good use of the debugger, I'd also recommend 
getting familiar with the way that the interpreter evaluates an 
expression by performing reductions on its rule stack: 
http://q-lang.sourceforge.net/qdoc/qdoc_7.html#SEC32

Well, maybe the description in the manual is too terse? Do we need a 
debugger tutorial??

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] Newbie questions and comments

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

Tim Haynes <q...@st...> writes:

[snip]
> > But what's wrong with the debugger? This topic comes up every once in a
> > while, so I'll be glad to improve it. But how?

Here's another really simple one that just cropped up:

 | public plot, pi, degsgran, circle, blob;
 | 
 | def pi=4*atan 1;

PI is a useful thing to have, of course, but with a typo like the above
(failure to remove the leading `def' whilst converting to lowercase) I get

 | zsh, trough  8:08PM scot-pics/ % ./map.q 
 | ! Value mismatch in definition

with no file:line-number, and, critically, execution continues regardless.

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

Re: [q-lang-users] Newbie questions and comments

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

Hi, Tim,

Tim Haynes wrote:
> Yup. No need to slave to the functional purity, here. (For example, I get
> the impression the libxml binding is impure - if you see `||' as a
> side-effect sequential operator, you get snippets of code that look like
> "destructively append a node here, || now return the new tree".)

Yup, actually the xml module is a fairly thin wrapper around libxml, so 
the manipulation of the xml trees indeed involves side-effects.

> Well, there *are* no undefined variables, you just get a symbol-name back

Yes, that's one of Q's ideosyncrasies you just have to get used to. (Not 
the worst one, I'm afraid. ;-)

> One bug-bear I have atm is still the debugger. I've got a classic weak-type
> problem, writing something that handles lists and tuples (a prototype
> generic FSM for my own amusement), and somewhere along the lines I've got
> my datatypes in a twist in the middle of a recursive call, and I just can't
> make head or tail of the debugging...

Sometimes printf is your best friend. But what's wrong with the 
debugger? This topic comes up every once in a while, so I'll be glad to 
improve it. But how?

> A random question: is there anything in Q like haskell's $ ? Ie., a
> right-associative do-very-little operator that obviates surplus
> parentheses?
> 
>  | foo (bar (qux X))  ==  foo $ bar $ qux X

Nope, not yet. Want one in the next release? :)

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] Newbie questions and comments

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

Hi, Matt, welcome to the club! :)

Matt Gushee wrote:
>  * So why isn't Q better known?

Good question. Well, maybe I don't advertise it enough. This year will 
be the first time that I actually present Q at an international 
conference. You see, for a long time Q has just been one of my "hobby 
projects", and it has only been "out there" on SourceForge for about one 
year. But I guess that the most prominent factor is that functional 
languages are still perceived as something fairly exotic, and many 
programmers can't easily wrap their head around this way of programming. 
It just takes time I guess.

>  * So far, the one thing that I really dislike about Q is the
>    limitations of the interactive interpreter. It would be nice, for
>    example, if you could test a function definition interactively before
>    putting it in a script. Maybe not such a problem if you use Emacs,
>    but there are some strange people like me who really prefer vi.

I've actually thought about this quite a bit. The basic code-generation 
algorithms can certainly be adapted to work in an incremental fashion 
(with little or no performance penalty at runtime), making it possible 
to dynamically add and remove equations to the pattern-matching 
automaton at runtime. But I just couldn't come up with a reasonable user 
interface to support this feature. The main difficulty is that the basic 
unit in a Q script is not the "function definition" but the "equation". 
Just imagine that you enter a series of equations in the interpreter, 
and then lateron you discover that the 7th equation must be moved before 
the 3rd one. Things like this happen all the time when programming with 
Q, and performing such editing in an interpreter which is anything less 
than a full screen editor is just too cumbersome.

So this is what the emacs mode is for. Of course it would be nice to 
have something similar for vi, but I never got around implementing it, 
as I don't use vi on a regular basis. (Can you bind a key in vi so that 
it invokes an interpreter on the current file? And can you program vi to 
recognize error messages and look up the corresponding line in a file? 
If so, I might be tempted to also add the necessary syntax highlighting 
magic for vim, that would already make a fairly complete vim-based IDE.)

>  * I see that undefined variables can be a major source of frustration:
>    they can cause expressions not to be evaluated as expected, yet they
>    are not errors so the interpreter doesn't point out your mistake. It
>    would be nice if there were some tool (or interpreter mode) that
>    would find all undefined variables.

You can run q with the -w option to have the interpreter warn you about 
"undefined" function and variable symbols. Due to the 1-pass compilation 
this is a bit cumbersome, since it will warn you about *all* symbols 
which are used (on the rhs) before they are introduced (on the lhs or in 
a declaration), so you need to be careful with the order of definitions 
or use explicit symbol declarations. But I found that this option helps 
a lot with larger projects, so I usually have it enabled in my Emacs Q mode.

>      foo A B C = A + B + C;
> 
>      foo A = lambda B (lambda C (A + B + C));

Yes, lambdas are not a builtin in Q, so they compile to ordinary 
function invokations. You can actually find the definition of lambdas in 
the lambda.q standard library script, it's all just plain Q code, no 
magic involved. One advantage of this approach is that you can tweak the 
implementation of lambdas to your liking. The other main advantage is 
that you can manipulate lambdas in Q itself, as they are just ordinary Q 
expressions, and you can add other stuff like list comprehensions on top 
of them without having to build everything into the interpreter (the way 
it's done in ML and Haskell). OTOH, this means that lambdas don't 
integrate as well and are executed less efficiently than in those languages.

>  * It seems like Q might be a good language for programming handheld
>    devices (just my intuitive notion--I can't really give a good reason
>    for thinking this). Has anyone thought about porting Q to, e.g.,
>    PalmOS?

Actually I have a Zaurus 5500 lying around here, and a port to that 
platform has been on my TODO list for some time. But last time I tried 
I've run into obstacles with the cross-compiling environment, and I 
couldn't get libtool to work on the Zaurus itself, so I've not pursued 
this any further up to now.

> [1] In case it isn't obvious, one example of what I mean by this is that
>     in Haskell you have to understand monads in order to write almost
>     any program that does useful work. I believe, because I have been
>     told by some very smart people, that monads are a very useful tool.
>     But the fact that you need to master such a difficult concept for
>     everyday tasks like reading and writing files makes the learning
>     curve prohibitive.

Yes, Haskell certainly is a beautiful language (probably the most 
beautiful there is right now, IMHO), but those monads can really get in 
your way when you have to do some real-world programming. ;-)

> [2] I need to play around with the language a bit more before committing
>     to anything, but I will probably be willing to help create some
>     "buzz" for Q.

Yes, that's a good idea. But how? Slashdot?

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] Newbie questions and comments

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

Matt Gushee <ma...@gu...> writes:

[snip]
>   * First impression: WOW! Though I'm no expert on language design (no CS
>   degree, just some practical programming experience coupled with an
>   interest in how it all works), Q seems to be one of the best-designed
>   languages I have come across: based on good theory, yet not slavishly
>   adherent to the theory like, say, Haskell[1]; compact, yet powerful;
>   and it has a lot of nice little touches, e.g. symbols that are easily
>   converted to and from strings. Overall, Q strikes a very good balance
>   between theory and practice.

Yup. No need to slave to the functional purity, here. (For example, I get
the impression the libxml binding is impure - if you see `||' as a
side-effect sequential operator, you get snippets of code that look like
"destructively append a node here, || now return the new tree".)

>   * So why isn't Q better known? 

Good question. I also only stumbled across it via a freshmeat update I
spotted - wondered `hello?' and thought it quite cool. Maybe it's because
the set of people for whom ODBC, XML, ImageMagick and audio library
bindings are interesting is comparatively few.

[snip]
>   * I see that undefined variables can be a major source of frustration:
>   they can cause expressions not to be evaluated as expected, yet they
>   are not errors so the interpreter doesn't point out your mistake. It
>   would be nice if there were some tool (or interpreter mode) that would
>   find all undefined variables. Or is there such a thing already? I have
>   to confess I'm not in the habit of reading all documentation in
>   advance--I tend to read a bit, try something, read a bit more, and so
>   on ...

Well, there *are* no undefined variables, you just get a symbol-name back
if you use one, and it can get quite interesting if you're doing various
operations and accidentally hit one (but you soon get used to the forms
that can take). Hmmm. Maybe `issym' or something could come in handy here -
like, um, how do you get it to return false?! :)


One bug-bear I have atm is still the debugger. I've got a classic weak-type
problem, writing something that handles lists and tuples (a prototype
generic FSM for my own amusement), and somewhere along the lines I've got
my datatypes in a twist in the middle of a recursive call, and I just can't
make head or tail of the debugging...

>   * A while back I gave a presentation on OCaml to a local Linux users'
>     group. By way of explaining currying, I demonstrated that the
>     following two function definitions are effectively the same:
> 
>       let foo a b c = a + b + c
> 
>       let foo = fun a -> fun b -> fun c -> a + b + c
> 
>       [ "fun ARGS ->" is the OCaml equivalent of "lambda ARGS" ]
> 
>     The OCaml compiler compiles these two to identical byte code. I tried
>     a similar exercise in Q:
> 
>       foo A B C = A + B + C;
> 
>       foo A = lambda B (lambda C (A + B + C));
> 
>     But if I create two modules, each containing only one of these
>     definitions, and compile them with qc, they produce different byte
>     code. So, assuming the byte compiler is correct, it appears that the
>     first form is not simply syntactic sugar for the second (as was the
>     case in OCaml); there is some substantive difference. Can anyone
>     explain (bearing in mind that I don't have a CS degree) the
>     difference in the two Q definitions?

The first is a function of 3 arguments, the latter one, and one which
doesn't know what B and C are. Lower-case definitions introduce functions,
with upper-case seemingly being handled separately (IME, `def'+uppercase
name leads to the RHS being evaluated once at the time the interpreter
passes by that line of code, while lowercase name leads to once per
invocation).

> Last but not least, thanks to Herr Gräf for all the good work.

Seconded.

> [1] In case it isn't obvious, one example of what I mean by this is that
> in Haskell you have to understand monads in order to write almost any
> program that does useful work. I believe, because I have been told by
> some very smart people, that monads are a very useful tool. But the fact
> that you need to master such a difficult concept for everyday tasks like
> reading and writing files makes the learning curve prohibitive.

Yes, I'm also a haskell newbie, and just can't get my head around the
blighters either. No time, and when there's time, not enough caffeine :/

A random question: is there anything in Q like haskell's $ ? Ie., a
right-associative do-very-little operator that obviates surplus
parentheses?

 | foo (bar (qux X))  ==  foo $ bar $ qux X

> [2] I need to play around with the language a bit more before committing
>      to anything, but I will probably be willing to help create some
>      "buzz" for Q.

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

[q-lang-users] Newbie questions and comments

[Matt G. <ma...@gu...>]

Hello, all--

I have been trying out Q for a few days, and wanted to share my 
impressions so far (mostly very good).

First a bit of background: after working for a while with popular 
languages like Python and Java, I became very interested in functional 
programming about 3 years ago. I tried Erlang but didn't like it, then 
tried Haskell and liked it but didn't understand it ... I was about 
ready to give up when I found OCaml, which I have been using ever since. 
I still think OCaml is a great language for implementing a 
well-thought-out program design (especially when it's a complex design), 
but the strict type system can be very frustrating for simple projects, 
and especially for exploratory coding. For that you need a dynamically 
typed language. Yet, having caught "the FP bug," it's hard to go back to 
the procedural ugliness of something like Python.

Then the other day I ran across Q while browsing the Web for Linux audio 
software. So I've been playing around with the language and will 
probably continue to use it. Meanwhile, in no particular order, here are 
  a few thoughts:

  * First impression: WOW! Though I'm no expert on language design (no CS
    degree, just some practical programming experience coupled with an
    interest in how it all works), Q seems to be one of the best-designed
    languages I have come across: based on good theory, yet not slavishly
    adherent to the theory like, say, Haskell[1]; compact, yet powerful;
    and it has a lot of nice little touches, e.g. symbols that are easily
    converted to and from strings. Overall, Q strikes a very good balance
    between theory and practice.

  * So why isn't Q better known? It's not as if I am some corporate
    JavaBot, sitting in my cubicle just following the patterns and
    collecting my pay (though the pay would be nice--not enough of that
    lately ;-)--I've spent much of the last 3 years actively seeking
    better languages, yet I had never heard of Q until this week. I would
    say that Q is comparable in many ways to Lua--not, obviously, in
    syntax or programming paradigm, but I think the two are very similar
    in size and power, in maturity, and in the problem domains they are
    suitable for--though Q seems to have a decided edge in usable
    multimedia libraries. Yet Lua seems to be rapidly gaining popularity,
    while Q remains obscure. Is it just because Lua is procedural while Q
    is functional, or is this a problem that could be solved with more or
    better publicity?[2]

  * So far, the one thing that I really dislike about Q is the
    limitations of the interactive interpreter. It would be nice, for
    example, if you could test a function definition interactively before
    putting it in a script. Maybe not such a problem if you use Emacs,
    but there are some strange people like me who really prefer vi.

  * I see that undefined variables can be a major source of frustration:
    they can cause expressions not to be evaluated as expected, yet they
    are not errors so the interpreter doesn't point out your mistake. It
    would be nice if there were some tool (or interpreter mode) that
    would find all undefined variables. Or is there such a thing already?
    I have to confess I'm not in the habit of reading all documentation
    in advance--I tend to read a bit, try something, read a bit more, and
    so on ...

  * A while back I gave a presentation on OCaml to a local Linux users'
    group. By way of explaining currying, I demonstrated that the
    following two function definitions are effectively the same:

      let foo a b c = a + b + c

      let foo = fun a -> fun b -> fun c -> a + b + c

      [ "fun ARGS ->" is the OCaml equivalent of "lambda ARGS" ]

    The OCaml compiler compiles these two to identical byte code. I tried
    a similar exercise in Q:

      foo A B C = A + B + C;

      foo A = lambda B (lambda C (A + B + C));

    But if I create two modules, each containing only one of these
    definitions, and compile them with qc, they produce different byte
    code. So, assuming the byte compiler is correct, it appears that the
    first form is not simply syntactic sugar for the second (as was the
    case in OCaml); there is some substantive difference. Can anyone
    explain (bearing in mind that I don't have a CS degree) the
    difference in the two Q definitions?

  * It seems like Q might be a good language for programming handheld
    devices (just my intuitive notion--I can't really give a good reason
    for thinking this). Has anyone thought about porting Q to, e.g.,
    PalmOS?

Last but not least, thanks to Herr Gräf for all the good work.


[1] In case it isn't obvious, one example of what I mean by this is that
     in Haskell you have to understand monads in order to write almost
     any program that does useful work. I believe, because I have been
     told by some very smart people, that monads are a very useful tool.
     But the fact that you need to master such a difficult concept for
     everyday tasks like reading and writing files makes the learning
     curve prohibitive.

[2] I need to play around with the language a bit more before committing
     to anything, but I will probably be willing to help create some
     "buzz" for Q.

--
Matt Gushee
Englewood, CO, USA

Re: [q-lang-users] Build problems with q-6.0

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

Thomas Pasch wrote:
> I'm willing to help. Try to fix what I can. (Do you just
> know that AMD has abolished production of AthlonXPs?)

That's great! I could really use a helping hand with that 64 bit port. 
:) If you have any diffs please send them to me at Dr.Graef (at) 
t-online.de. I think that the best thing would be to first take care of 
those pointer-related warning messages, maybe then some of the 
misbehaviour you reported (wrong module name, error loading an external 
module etc.) would go away.

No, I didn't know that the Athlon XP is discontinued. What kind of cpu 
is this anyway? The Athlon seems to be the main line of AMD processors, no?

>  > Warning: 248 unresolved external symbols
>  > ! Value mismatch in definition
> 
> What do this 2 lines say???

That's the way the interpreter complains when it can't dl-load an 
external C module, that is, a shared library with additional "primitive" 
functions, see Appendix C in the manual. Because the module couldn't be 
loaded, the external C functions in the module can't be "resolved", thus 
the error message. Actually it should display the name of the offending 
module right above this message, but the pointer to that name seems to 
be incorrect, as it's pointing to the "def" symbol, which is in the 
bytecode's static string area (all static string data in the source 
script and the standard library is stored there, including the names of 
predefined function and variable symbols, identifiers and filenames of 
modules, etc.).

If you get this when starting up the Q interpreter as is, i.e. without a 
script, then it's probably the clib module which the interpreter tries 
to load there (which is the only external module imported by the 
standard prelude), so there could be some problem with the dynamic 
module loader (libltdl, from libtool), or, more likely, the module 
filename is thrashed (which is quite probable, as the Q identifier of 
the module is wrong as well). I believe that this is related to some 
wrong pointer conversions, either in the bytecode compiler (qc) or in 
the interpreter. If *all* pointers to static strings in the bytecode 
just point to the first entry "def" (or to some other random entries), 
then the interpreter will surely be in deep trouble. ;-)

Try commenting out the "import clib;" line in prelude.q and see whether 
that message goes away. (It will then most likely bomb immediately 
afterwards, but it's a cheap way to find out whether that module 
filename in the bytecode is wrong.)

> libtool: link: `/usr/lib/libXm.la' is not a valid libtool archive
> 
> Hm, '/usr/lib/libXm.la' does NOT exist at all.

That's ok, there shouldn't be one.

> OpenDx is split in debian. Shared libs are in package libdx4:
> 
> $ dpkg -L libdx4
> [...]
> /usr/lib/libDX.so.4.0.32
> /usr/lib/libDXcallm.so.4.0.32
> /usr/lib/libDXL.so.4.0.32
> /usr/lib/libDXlite.so.4.0.32
> [...]
> /usr/lib/libDX.so.4
> /usr/lib/libDXcallm.so.4
> /usr/lib/libDXL.so.4
> /usr/lib/libDXlite.so.4
> /usr/lib/dx/lib_linux/libDX.so.4
> /usr/lib/dx/lib_linux/libDX.so.4.0.32
> /usr/lib/dx/lib_linux/libDXL.so.4
> /usr/lib/dx/lib_linux/libDXL.so.4.0.32
> /usr/lib/dx/lib_linux/libDXcallm.so.4
> /usr/lib/dx/lib_linux/libDXcallm.so.4.0.32
> /usr/lib/dx/lib_linux/libDXlite.so.4
> /usr/lib/dx/lib_linux/libDXlite.so.4.0.32
> 
> No *.la libtool stuff is part of the installation
> in debian. IMHO, libtool is doomed, and
> should never look for *.la of installed libs.

No libDXL*.la, that's ok.

But no libDXL.a? Even if you have a shared DXL library (on my system 
it's just a static one, IIRC), then there should be an import lib to 
link against. Maybe there is something like an opendx-devel package 
which needs to be installed too?

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] Build problems with q-6.0

[Thomas P. <Tho...@at...>]

Hello,

I'm willing to help. Try to fix what I can. (Do you just
know that AMD has abolished production of AthlonXPs?)

 > Warning: 248 unresolved external symbols
 > ! Value mismatch in definition

What do this 2 lines say???

libtool: link: `/usr/lib/libXm.la' is not a valid libtool archive

Hm, '/usr/lib/libXm.la' does NOT exist at all.

$ dpkg-query -S /usr/lib/libXm.so.*
lesstif1: /usr/lib/libXm.so.1
lesstif1: /usr/lib/libXm.so.1.0.2
lesstif2: /usr/lib/libXm.so.2
lesstif2: /usr/lib/libXm.so.2.0.1

Seems to be part of lesstif (Motif clone).

OpenDx is split in debian. Shared libs are in package libdx4:

$ dpkg -L libdx4
[...]
/usr/lib/libDX.so.4.0.32
/usr/lib/libDXcallm.so.4.0.32
/usr/lib/libDXL.so.4.0.32
/usr/lib/libDXlite.so.4.0.32
[...]
/usr/lib/libDX.so.4
/usr/lib/libDXcallm.so.4
/usr/lib/libDXL.so.4
/usr/lib/libDXlite.so.4
/usr/lib/dx/lib_linux/libDX.so.4
/usr/lib/dx/lib_linux/libDX.so.4.0.32
/usr/lib/dx/lib_linux/libDXL.so.4
/usr/lib/dx/lib_linux/libDXL.so.4.0.32
/usr/lib/dx/lib_linux/libDXcallm.so.4
/usr/lib/dx/lib_linux/libDXcallm.so.4.0.32
/usr/lib/dx/lib_linux/libDXlite.so.4
/usr/lib/dx/lib_linux/libDXlite.so.4.0.32

No *.la libtool stuff is part of the installation
in debian. IMHO, libtool is doomed, and
should never look for *.la of installed libs.

Cheers,

Thomas

Re: [q-lang-users] Build problems with q-6.0

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

Thomas Pasch wrote:
> I report this hier because the bug tracking page at
> sourceforge seems not to be use by this project.

It's supposed to work, but noone has actually entered anything there yet.

> There are some glitches with building q-6.0. On my
> AthlonXp Debian testing system, it is not possible
> to build the opendx (dxl) extension. This is the
> error
> 
> make[4]: Entering directory `/home/tpasch/compile/q-6.0/modules/dxl'
> /bin/sh ../../libtool --mode=link --tag=CC gcc-3.4  -O3 -o dxl.la -rpath 
> /opt/lib/q
> -no-undefined -module -avoid-version dxl.lo ../../libq/libq.la -lDXL  
> -lcrypt -lutil -lnsl -lm
> grep: /usr/lib/libXm.la: No such file or directory
> /bin/sed: can't read /usr/lib/libXm.la: No such file or directory
> libtool: link: `/usr/lib/libXm.la' is not a valid libtool archive
> make[4]: *** [dxl.la] Fehler 1

Hmm, it shouldn't need libXm.la... Wait, I vaguely remember some probs 
with the .la's from the OpenDX libraries. Can you please check whether 
your .../dx/lib_linux directory contains some .la files? If so, try 
moving those temporarily to a directory where libtool won't find them.

> The libtool tries to build static libraries a (even with 
> --disable-static configure
> option!).

I'll have to recheck this, last time I checked --disable-static worked, 
but I've upgraded to a newer libtool since then.

> In addition I think the state of q-6.0 on AMD64 (aka x86_64) is dubious
> at best.

That's true, as I don't have a 64 bit system yet, Q has never been 
tested there before, so there surely are some 64 bit related glitches. 
Your input (preferably patches ;-) would be very valuable! But as I 
cannot test this here, right now you're on your own. :( (Unless someone 
else on this list can help. Anyone?)

> Building opendx-4.3.2 (dxl) extension does not work (no surprise):
> [...]
> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: 
> /usr/dx/lib_linux/libDXL.a(close.o): relocation R_X86_64_32 against `a 
> local symbol' can not be used when making a shared object; recompile 
> with -fPIC
> /usr/dx/lib_linux/libDXL.a(close.o): could not read symbols: Bad value
> collect2: ld returned 1 exit status

Mmh, could that be a libtool bug?

> Building the ImageMagick extension also fails. This is perhaps
> because I'm using a very recent version (6.1.8.8) on AMD64:

Yep, support for ImageMagick 6.x is still on my TODO list. That error is 
probably easy to fix, though. If you can live without that specific 
function, a quick workaround would be to just comment out the stuff 
around the call to GetColorList in magick.c and make the wrapper 
function return __FAIL instead.

> Without this extensions, I managed to build q-6.0. But the
> build failes with:
> 
> PATH=.:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3:/opt/blackdown-jdk-1.4.2/bin:/opt/blackdown-jdk-1.4.2/jre/bin:/usr/qt/3/bin:/usr/kde/3.3/bin:/usr/kde/3.2/bin:/usr/kde/3.1/bin:/usr/games/bin 
> QPATH=../stdlib:../modules/clib:../modules/clib q ./qcwrap.q ./qcwrap.q
> def: error loading module

That looks rather severe. There's no module named "def", "def" just 
happens to be the first symbol in the symbol table, IIRC. So it looks 
like the bytecode compiler generated bogus code. My guess is that some 
pointers in the compiler's symbol table get trashed during pointer 
arithmetic. Maybe it's just a few long long casts that's needed... 
Sorry, I'd need a 64 bit machine, a complete build log, gdb and a big 
can of coffee to find out about this one. ;-)

> Trying to invoke the (partly) build q I got:

Yep, that's the same error.

> regex.c: In function `xxre_match_2':

I don't know whether the bundled version of GNU regex has ever been 
tested on a 64 bit system. Probably not. It should be easy to replace it 
with a more current 64-bit safe version, though.

> odbc.c: In function `__F__odbc_sql_exec':
> odbc.c:610: warning: passing arg 10 of `SQLBindParameter' from 
> incompatible pointer type
> qmfuns.c: In function `ptr_hash':
> qmfuns.c:1974: warning: cast from pointer to integer of different size
> qmfuns.c: In function `ptr_hash':
> qmfuns.c:1974: warning: cast from pointer to integer of different size
> libtool: link: warning: `-dlopen self' is ignored for libtool libraries
> qmfuns.c: In function `ptr_hash':
> qmfuns.c:1974: warning: cast from pointer to integer of different size
> libtool: link: warning: `-dlopen self' is ignored for libtool libraries
> qmfuns.c: In function `ptr_hash':
> qmfuns.c:1974: warning: cast from pointer to integer of different size

More of the same. Most of this should be fairly easy to fix. Sigh. Looks 
like I'll have to buy a 64 bit machine after all. Maybe I should enable 
the "Donate" button on SF. :)

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] Build problems with q-6.0

[Thomas P. <Tho...@at...>]

Hello,

I report this hier because the bug tracking page at
sourceforge seems not to be use by this project.

There are some glitches with building q-6.0. On my
AthlonXp Debian testing system, it is not possible
to build the opendx (dxl) extension. This is the
error

make[4]: Entering directory `/home/tpasch/compile/q-6.0/modules/dxl'
/bin/sh ../../libtool --mode=link --tag=CC gcc-3.4  -O3 -o dxl.la -rpath 
/opt/lib/q
-no-undefined -module -avoid-version dxl.lo ../../libq/libq.la -lDXL  
-lcrypt -lutil -lnsl -lm
grep: /usr/lib/libXm.la: No such file or directory
/bin/sed: can't read /usr/lib/libXm.la: No such file or directory
libtool: link: `/usr/lib/libXm.la' is not a valid libtool archive
make[4]: *** [dxl.la] Fehler 1

The libtool tries to build static libraries a (even with 
--disable-static configure
option!).

In addition I think the state of q-6.0 on AMD64 (aka x86_64) is dubious
at best. Building opendx-4.3.2 (dxl) extension does not work (no surprise):

make[4]: Entering directory `/home/pasch/compile/q-6.0/modules/dxl'
/bin/sh ../../libtool --mode=link --tag=CC gcc  -O3 -fomit-frame-pointer 
-fprefetch-loop-arrays -funroll-loops -mfpmath=sse   -o dxl.la -rpath 
/opt/lib/q -no-undefined -module-avoid-version dxl.lo ../../libq/libq.la 
-L/usr/dx/lib_linux -lDXL  -lcrypt -lutil -lnsl -lm
libtool: link: warning: `//usr/lib/libMagick.la' seems to be moved
libtool: link: warning: `//usr/lib/libltdl.la' seems to be moved
gcc -shared  .libs/dxl.o -Wl,--whole-archive /usr/dx/lib_linux/libDXL.a 
-Wl,--no-whole-archive  -Wl,--rpath 
-Wl,/home/pasch/compile/q-6.0/libq/.libs -Wl,--rpath -Wl,/opt/lib 
-L//usr/lib -L/usr/lib -L/usr/lib64 ../../libq/.libs/libq.so 
-L/usr/dx/lib_linux -lcrypt -lutil -lnsl -lm  -mfpmath=sse -Wl,-soname 
-Wl,dxl.so -o .libs/dxl.so
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: 
/usr/dx/lib_linux/libDXL.a(close.o): relocation R_X86_64_32 against `a 
local symbol' can not be used when making a shared object; recompile 
with -fPIC
/usr/dx/lib_linux/libDXL.a(close.o): could not read symbols: Bad value
collect2: ld returned 1 exit status

(of course I tried './configure --disable-static').

Building the ImageMagick extension also fails. This is perhaps
because I'm using a very recent version (6.1.8.8) on AMD64:

if /bin/sh ../../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I. 
-I. -I../.. -I../../libq      -O3 -fomit-frame-pointer 
-fprefetch-loop-arrays -funroll-loops -mfpmath=sse -MT magick.lo -MD -MP 
-MF ".deps/magick.Tpo" -c -o magick.lo magick.c; \
then mv -f ".deps/magick.Tpo" ".deps/magick.Plo"; else rm -f 
".deps/magick.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../libq -O3 
-fomit-frame-pointer -fprefetch-loop-arrays -funroll-loops -mfpmath=sse 
-MT magick.lo -MD -MP -MF .deps/magick.Tpo -c magick.c  -fPIC -DPIC -o 
.libs/magick.o
magick.c: In function `__F__magick_magick_colors':
magick.c:1154: error: too few arguments to function `GetColorList'
make[4]: *** [magick.lo] Error 1

Without this extensions, I managed to build q-6.0. But the
build failes with:

PATH=.:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3:/opt/blackdown-jdk-1.4.2/bin:/opt/blackdown-jdk-1.4.2/jre/bin:/usr/qt/3/bin:/usr/kde/3.3/bin:/usr/kde/3.2/bin:/usr/kde/3.1/bin:/usr/games/bin 
QPATH=../stdlib:../modules/clib:../modules/clib q ./qcwrap.q ./qcwrap.q
def: error loading module
Warning: 248 unresolved external symbols
! Value mismatch in definition

Trying to invoke the (partly) build q I got:

PATH=.:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3:/opt/blackdown-jdk-1.4.2/bin:/opt/blackdown-jdk-1.4.2/jre/bin:/usr/qt/3/bin:/usr/kde/3.3/bin:/usr/kde/3.2/bin:/usr/kde/3.1/bin:/usr/games/bin 
QPATH=../stdlib:../modules/clib:../modules/clib q
def: error loading module
Warning: 248 unresolved external symbols
Q interpreter version 6.0 (x86_64-unknown-linux-gnu)
Copyright (c) 1991-2004 by Albert Graef
This software is distributed under the terms of the GNU General Public
License version 2 or later; type `copying' for details.
! Value mismatch in definition

Last not least I got the following compiler warnings while
building:

regex.c: In function `xxre_match_2':
regex.c:3765: warning: cast from pointer to integer of different size
regex.c:3765: warning: cast from pointer to integer of different size
regex.c:3771: warning: cast to pointer from integer of different size
regex.c:3771: warning: cast to pointer from integer of different size
regex.c:3918: warning: cast to pointer from integer of different size
regex.c:3918: warning: cast to pointer from integer of different size
regex.c:3971: warning: cast to pointer from integer of different size
regex.c:3971: warning: cast to pointer from integer of different size
regex.c:4077: warning: cast from pointer to integer of different size
regex.c:4077: warning: cast from pointer to integer of different size
regex.c:4110: warning: cast to pointer from integer of different size
regex.c:4110: warning: cast to pointer from integer of different size
regex.c:4123: warning: cast to pointer from integer of different size
regex.c:4123: warning: cast to pointer from integer of different size
regex.c:4291: warning: cast from pointer to integer of different size
regex.c:4291: warning: cast from pointer to integer of different size
odbc.c: In function `__F__odbc_sql_exec':
odbc.c:610: warning: passing arg 10 of `SQLBindParameter' from incompatible pointer type
qmfuns.c: In function `ptr_hash':
qmfuns.c:1974: warning: cast from pointer to integer of different size
qmfuns.c: In function `ptr_hash':
qmfuns.c:1974: warning: cast from pointer to integer of different size
libtool: link: warning: `-dlopen self' is ignored for libtool libraries
qmfuns.c: In function `ptr_hash':
qmfuns.c:1974: warning: cast from pointer to integer of different size
libtool: link: warning: `-dlopen self' is ignored for libtool libraries
qmfuns.c: In function `ptr_hash':
qmfuns.c:1974: warning: cast from pointer to integer of different size
q-q.o(.text+0x3d6f): In function `__qq__rerun':
: warning: the use of `tmpnam' is dangerous, better use `mkstemp'

For me this indicates that the regex and odbc extension will probably 
not work.

Kind regards,

Thomas

Re: [q-lang-users] audio import error

[David C. N. <nor...@co...>]

Thanks, Albert.  Upgrade to SuSE 9.2 resolved this problem, plus a
number of non-Q-related matters as well.

On Mon, 2005-01-24 at 18:52 +0100, Albert Graef wrote:
> David C. Norris wrote:
> > Thanks.  Jack is indeed installed (jack-0.94.0-71), as well as: [...]
> 
> Yes, I can reproduce this problem now. It is because SuSE 9.1 ships with 
> Jack 0.94, but PortAudio needs Jack >=0.98. Solution: Install Jack 0.98 
> or 0.99 from source. (You can leave SuSE's Jack 0.94 installed as well, 
> it is needed by some of the multimedia packages.) The Jack sources are 
> available from http://jackit.sourceforge.net/. Make sure you have the 
> ALSA development package installed, then run ./configure && make && sudo 
> make install. Afterwards, run sudo /sbin/ldconfig, so that ld.so knows 
> about the new Jack library. q audio should then work (at least it does 
> on my SuSE 9.1 system).
> 
> Cheers,
> Albert
> 
> P.S.: Did you consider upgrading to SuSE 9.2 yet? 9.1 comes with a 
> fairly early iteration of the 2.6 kernel, which I found to be still 
> buggy in some respects, especially multithreading (this also affects 
> Jack). 9.2 works *much* better for me. (SuSE 9.2 packages for Q are up 
> already at http://sourceforge.net/projects/q-lang/. I just didn't get 
> around updating the website yet.)
> 
-- 
David C. Norris <nor...@co...>

[q-lang-users] Re: MidiShare rpms

[Albert G. <ag...@mu...>]

Hi, Gabriel,

I'm cc'ing this to the mailing list, as it might be interesting for 
others as well.

> In your q-lang pages, I found the MidiShare rpms, but these do not work in my 
> setup (Suse 9.1 with a newer kernel than SuSE 2.6.5-7.108 through Yast).
> Is there a MidiShare source available that I could compile? The source in the 
> MidiShare site does not compile as it is, so maybe you found a way to apply 
> some patch?

The MidiShare source rpms at the Q website include all the necessary 
sources and patches. Assuming you are using a non-smp kernel later than 
2.6.5-7.108 (from YOU?), the proper source rpm should be this one: 
http://prdownloads.sourceforge.net/q-lang/midishare-1.86-4.src.rpm?download

This stuff still compiles with SuSE 9.2, so any updated 9.1 kernel 
should be ok, too.

You can either install the source rpm and fiddle with the sources in 
/usr/src/packages/SOURCES yourself, or just try to rebuild the binary 
RPM. With the proper development tools installed, the following command 
should do the trick:

rpmbuild --rebuild midishare-1.86-4.src.rpm

(Better run this as root, IIRC it installs some stuff into system 
directories before creating the RPM.)

This should leave the binary RPM somewhere under /usr/src/packages/RPMS, 
ready to be installed on your system.

HTH,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics
Johannes Gutenberg-University Mainz, 55099 Mainz, Germany
Phone:  +49 6131 39-25142, Fax: -24717
Email:  ag...@mu..., Dr....@t-...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

[q-lang-users] New stuff

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

Hi!

Well, it's a new year so it's probably time for some updates. :) As you 
all noticed, I've been a little silent (semester time, so not that many 
updates recently). But, together with Jonas Joebges and Milen Velikov, I 
have been working on some new stuff which is only available in cvs right 
now. If you're into 3d graphics and multimedia, then you might wish to 
check out the new q-opengl and q-xine modules at 
http://sourceforge.net/cvs/?group_id=96881. NOTE: If you want to compile 
these from the cvs sources, you'll also need the Q'ified SWIG version 
available here: 
http://prdownloads.sourceforge.net/q-lang/swig-1.3.22-q.tar.gz

We're currently adding some more examples to q-opengl, and are still 
porting the xine module to Windows. When that is done there will be a 
1.0 release of these modules. Next up on our list is an OpenAL module 
(http://www.openal.org/), which will be nice for doing spatial audio 
stuff. And I'm planning to start work on Q 6.1 as soon as the semester 
is over.

Enjoy!
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] audio import error

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

David C. Norris wrote:
> Thanks.  Jack is indeed installed (jack-0.94.0-71), as well as: [...]

Yes, I can reproduce this problem now. It is because SuSE 9.1 ships with 
Jack 0.94, but PortAudio needs Jack >=0.98. Solution: Install Jack 0.98 
or 0.99 from source. (You can leave SuSE's Jack 0.94 installed as well, 
it is needed by some of the multimedia packages.) The Jack sources are 
available from http://jackit.sourceforge.net/. Make sure you have the 
ALSA development package installed, then run ./configure && make && sudo 
make install. Afterwards, run sudo /sbin/ldconfig, so that ld.so knows 
about the new Jack library. q audio should then work (at least it does 
on my SuSE 9.1 system).

Cheers,
Albert

P.S.: Did you consider upgrading to SuSE 9.2 yet? 9.1 comes with a 
fairly early iteration of the 2.6 kernel, which I found to be still 
buggy in some respects, especially multithreading (this also affects 
Jack). 9.2 works *much* better for me. (SuSE 9.2 packages for Q are up 
already at http://sourceforge.net/projects/q-lang/. I just didn't get 
around updating the website yet.)

-- 
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] audio import error

[David C. N. <nor...@co...>]

Albert,

Thanks.  Jack is indeed installed (jack-0.94.0-71), as well as:
libsndfile-1.0.7-28,
libsamplerate-0.0.15-140,
fftw3-3.0.1-109 (provides libfftw3.so.3)
alsa-1.0.3.37

What else could be the trouble?  What might I do to provide useful
debugging info?

David

On Mon, 2005-01-24 at 02:46, Albert Graef wrote:
> David C. Norris wrote:
> > I have installed the following RPMs on my SuSE 9.1 machine:
> > 
> > portaudio-v19-1su91.i586.rpm
> > q-6.0-1su91.i586.rpm
> > q-audio-2.2-1su91.i586.rpm
> > 
> > But this happens:
> > 
> > ==> import audio
> > /usr/share/q/lib/audio.q: error loading module
> > Warning: 17 unresolved external symbols
> > ! Value mismatch in definition
> >  
> > Any ideas?  What could I do to obtain more useful debug info?
> 
> Do you have Jack installed? The distributed PortAudio wants both ALSA 
> and Jack when loading its drivers. If you want a PortAudio version 
> without Jack support then you have to rebuild the package yourself. But 
> the easiest fix would be to just install the jack package included in 
> the SuSE distribution.
> 
> HTH,
> Albert

Re: [q-lang-users] audio import error

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

David C. Norris wrote:
> Is there some way to identify the "17 unresolved symbols"?

Those are just the external symbols in the audio module, which can't be 
resolved because the module fails to load.

> What does "! Value mismatch in definition" mean?

There's a "def (...) = audio_vars" definition near the beginning of the 
module (see audio.q) which sets some variables. Since the audio_vars 
function is unresolved (being one of the external symbols in audio.q), 
that definition fails.

-- 
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] audio import error

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

David C. Norris wrote:
> I have installed the following RPMs on my SuSE 9.1 machine:
> 
> portaudio-v19-1su91.i586.rpm
> q-6.0-1su91.i586.rpm
> q-audio-2.2-1su91.i586.rpm
> 
> But this happens:
> 
> ==> import audio
> /usr/share/q/lib/audio.q: error loading module
> Warning: 17 unresolved external symbols
> ! Value mismatch in definition
>  
> Any ideas?  What could I do to obtain more useful debug info?

Do you have Jack installed? The distributed PortAudio wants both ALSA 
and Jack when loading its drivers. If you want a PortAudio version 
without Jack support then you have to rebuild the package yourself. But 
the easiest fix would be to just install the jack package included in 
the SuSE distribution.

HTH,
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] audio import error

[David C. N. <nor...@co...>]

Thanks, Tim, but I'm afraid I had no luck.

a) q -d delivered no new info (just same error message on attempt to
import audio, interrupted by same trace shown on entry to q interpreter)
b) every library sought in the strace was eventually found
c) ldd audio.so shows all libs found

Is there some way to identify the "17 unresolved symbols"?

What does "! Value mismatch in definition" mean?

David

On Fri, 2005-01-21 at 20:31, Tim Haynes wrote:
> "David C. Norris" <nor...@co...> writes:
> 
> > I have installed the following RPMs on my SuSE 9.1 machine:
> >
> > portaudio-v19-1su91.i586.rpm
> > q-6.0-1su91.i586.rpm
> > q-audio-2.2-1su91.i586.rpm
> >
> > But this happens:
> >
> > ==> import audio
> > /usr/share/q/lib/audio.q: error loading module
> > Warning: 17 unresolved external symbols
> > ! Value mismatch in definition
> >  
> > Any ideas?  What could I do to obtain more useful debug info?
> 
> You could try a few things:
> 
> a) run `q -d' and then `import audio' from there;
> 
> b) strace -e trace=file -o /tmp/something q
>    import audio
>    ^d
> and then see what files it's been looking for in /tmp/something;
> 
> c) find an audio.so, which I suspect it should be using, and run ldd(1) on
> it to see if all its required libraries are satisfied as well.
> 
> HTH,
> 
> ~Tim

Re: [q-lang-users] audio import error

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

"David C. Norris" <nor...@co...> writes:

> I have installed the following RPMs on my SuSE 9.1 machine:
>
> portaudio-v19-1su91.i586.rpm
> q-6.0-1su91.i586.rpm
> q-audio-2.2-1su91.i586.rpm
>
> But this happens:
>
> ==> import audio
> /usr/share/q/lib/audio.q: error loading module
> Warning: 17 unresolved external symbols
> ! Value mismatch in definition
>  
> Any ideas?  What could I do to obtain more useful debug info?

You could try a few things:

a) run `q -d' and then `import audio' from there;

b) strace -e trace=file -o /tmp/something q
   import audio
   ^d
and then see what files it's been looking for in /tmp/something;

c) find an audio.so, which I suspect it should be using, and run ldd(1) on
it to see if all its required libraries are satisfied as well.

HTH,

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

[q-lang-users] audio import error

[David C. N. <nor...@co...>]

I have installed the following RPMs on my SuSE 9.1 machine:

portaudio-v19-1su91.i586.rpm
q-6.0-1su91.i586.rpm
q-audio-2.2-1su91.i586.rpm

But this happens:

==> import audio
/usr/share/q/lib/audio.q: error loading module
Warning: 17 unresolved external symbols
! Value mismatch in definition
 
Any ideas?  What could I do to obtain more useful debug info?

David

Re: [q-lang-users] silly regex wonderings

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

Tim Haynes wrote:
> Could we FFI-in libfl, using your magic SWIG thing? :)

Sure, but does it export something that you might wish to use directly 
in a Q script? I thought that this lib just contains some internal stuff 
used by a flex-generated lexer?

The cheap way to go about a Q lex/yacc would be to have preprocessors 
for C lex/yacc (or flex/bison) whose input would basically be a lex/yacc 
grammar with the actions and auxiliary code written in Q instead of C. 
The preprocessors would then generate the corresponding C code and use 
lex/yacc and qcc to translate the result to an external Q module with 
yyparse/yylex functions which could be called from a Q script. The first 
version of these tools could implement a minimal subset of the 
preprocessor languages, which would be done by hand, and then we could 
bootstrap the full version from there.

Of course it would be nicer to have tools written entirely in Q (a la 
Alex/Happy for Haskell), but that would be much more work, and it would 
also be difficult to implement the lexer (which is the major bottleneck 
in any parser) in a way which achieves comparable performance to a 
C-based one.

As you can see, I have already spent some time thinking about this, but 
I just can't find the time to implement it. ;-)

> (Can't offer to do this myself atm; I'm going to be quiet a while,
> something to do with buying a house...)

Good luck. :)

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] silly regex wonderings

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

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

[snip]
> Yes, you're right, to properly handle this case you'd need a context-free
> parser. This is an area where Q is still lacking. Hmm, is there someone
> here who knows Haskell's parser combinator library reasonably well? Maybe
> we could port some of this stuff to Q. Writing some kind of Q lex/yacc
> would also be an interesting project. Anyone interested?

Could we FFI-in libfl, using your magic SWIG thing? :)



(Can't offer to do this myself atm; I'm going to be quiet a while,
something to do with buying a house...)

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

Re: [q-lang-users] silly regex wonderings

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

Hi, David!

> BTW, Hi there.
> I'm a maths student, I've been lurking here a while and I just finished my
> exams
> for the year, which gives me more time to play with Q and other nice things

So welcome to the list, and thanks for helping out. How do you like Q so 
far? ;-)

> OK, you've got me playing with these regexes now.
> 
> Based on the regsplit example, a regex search and replace is:
> 	snr Opts OldRE NewRE S = strcat
> 		(regex Opts OldRE S (regskip ++ `NewRE)
> 		++ [regskip]);

This is cute. I'd like to add this to the examples in the docs, ok?

BTW, to make it even prettier, you could declare snr as a special form 
like so:

special snr ~Opts ~OldRE NewRE ~S;

snr Opts OldRE NewRE S = strcat
		(regex Opts OldRE S (regskip ++ NewRE)
		++ [regskip]);

Then you don't need the backquote/quote magic. E.g.:

embolden2 = snr "g" "\\*([^\\*]*)\\*" (tag "bold" (reg 1));

tagify Delim Tag = snr "g" (Delim++"([^"++Delim++"]*)"++Delim)
		   (tag Tag (reg 1));

This works because the evaluation of the NewRE argument of snr is now 
deferred until it is used on the rhs of the snr definition.

> The problem is 
> ==> underline (embolden3 "This has *bold _underlining*_ !")
> "This has <bold>bold <underline>underlining</bold></underline> !"

Yes, you're right, to properly handle this case you'd need a 
context-free parser. This is an area where Q is still lacking. Hmm, is 
there someone here who knows Haskell's parser combinator library 
reasonably well? Maybe we could port some of this stuff to Q. Writing 
some kind of Q lex/yacc would also be an interesting project. Anyone 
interested?

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