From salutis at me.com  Sat Jun  4 12:53:59 2022
From: salutis at me.com (Rudolf =?utf-8?Q?Adamkovi=C4=8D?=)
Date: Sat, 04 Jun 2022 21:53:59 +0200
Subject: [CM] Unicode support
In-Reply-To: <73536df67148ceff749e9c1d178ee98e@ccrma.stanford.edu>
References: <m2bkwd4h50.fsf@me.com>
	<dbf95441544d7ff8670a07994b1d0abc@ccrma.stanford.edu>
	<m25ylwts2x.fsf@me.com>
	<73536df67148ceff749e9c1d178ee98e@ccrma.stanford.edu>
Message-ID: <m2mtesdx2g.fsf@me.com>

bil at ccrma.Stanford.EDU writes:

> I thought from your example that you wanted to see a filled
> square.

I apologize for not communicating with clarity.  I wanted to "see" the
square in the source code, during debugging, in test failures, and also
in the native UI that s7 feeds at runtime.

In other words, I took "has Unicode" to mean what it normally means
these days , including in Guile or Emacs Lisp, where Unicode "just
works" end-to-end for most practical purposes.  Looking at your
suggestion to hand-craft Unicode byte-vectors, I must have misread "has
Unicode" the way I misread "compatible with R7RS".  :)

I will give those byte-vectors a try.  Thanks!

Thank you!

Rudy
-- 
"Strange as it may sound, the power of mathematics rests on its evasion
of all unnecessary thought and on its wonderful saving of mental
operations."
-- Ernst Mach, 1838-1916

Rudolf Adamkovi? <salutis at me.com> [he/him]
Studenohorsk? 25
84103 Bratislava
Slovakia



From wdouglass at carnegierobotics.com  Tue Jun  7 06:47:11 2022
From: wdouglass at carnegierobotics.com (Woody Douglass)
Date: Tue, 7 Jun 2022 13:47:11 +0000
Subject: [CM] (*s7* 'stack)
Message-ID: <f5ffd73069153e3523c3929e1800142a3fe24504.camel@carnegierobotics.com>

All,

I'm running s7 with a libev event loop, and I just noticed a behavior
that I didn't expect. The stack seems to be growing infinitely. Most of
the entries in the stack are catches -- it seems like something is
wrong but i'm not sure what.

I'm currently investigating that catch specifically to see if my event
loop is recursing where it shouldn't or something, but I wanted to
mention it to this list to see if anybody has seen anything similar.
let me know if anything jumps out to you guys. thanks.

-Woody



From wdouglass at carnegierobotics.com  Tue Jun  7 07:36:45 2022
From: wdouglass at carnegierobotics.com (Woody Douglass)
Date: Tue, 7 Jun 2022 14:36:45 +0000
Subject: [CM] (*s7* 'stack)
In-Reply-To: <f5ffd73069153e3523c3929e1800142a3fe24504.camel@carnegierobotics.com>
References: <f5ffd73069153e3523c3929e1800142a3fe24504.camel@carnegierobotics.com>
Message-ID: <bdc5c04bff35527821894a40b521a8f7a8c14f35.camel@carnegierobotics.com>

I think i may have found the issue, see the attached test code

it appears that "s7_call_with_catch" doesn't pop as much off the stack
as it should before returning. it may be as simple as calling
`pop_stack` before the end of that function, but i'm not sure.

Thanks for any advice!
-Woody

On Tue, 2022-06-07 at 09:47 -0400, Woodrow Douglass wrote:
> All,
> 
> I'm running s7 with a libev event loop, and I just noticed a behavior
> that I didn't expect. The stack seems to be growing infinitely. Most
> of
> the entries in the stack are catches -- it seems like something is
> wrong but i'm not sure what.
> 
> I'm currently investigating that catch specifically to see if my
> event
> loop is recursing where it shouldn't or something, but I wanted to
> mention it to this list to see if anybody has seen anything similar.
> let me know if anything jumps out to you guys. thanks.
> 
> -Woody
-------------- next part --------------
A non-text attachment was scrubbed...
Name: catch-test.c
Type: text/x-csrc
Size: 1359 bytes
Desc: catch-test.c
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220607/162b1709/attachment.bin>

From rpjherman at gmail.com  Tue Jun  7 08:54:47 2022
From: rpjherman at gmail.com (Robert Herman)
Date: Tue, 7 Jun 2022 11:54:47 -0400
Subject: [CM] Please unsubscribe me
Message-ID: <CABVY+WuHUq2PPGjADn2-H0FwD4K-cShnNYOkmamftmpGg7x+WA@mail.gmail.com>

I forgot my password, and it is not being emailed to me with the remind me
button.

Thanks!

Robert Herman
rpjherman at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220607/91d4bfbd/attachment.html>

From bil at ccrma.Stanford.EDU  Tue Jun  7 10:06:37 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Tue, 07 Jun 2022 10:06:37 -0700
Subject: [CM] (*s7* 'stack)
In-Reply-To: <bdc5c04bff35527821894a40b521a8f7a8c14f35.camel@carnegierobotics.com>
References: <f5ffd73069153e3523c3929e1800142a3fe24504.camel@carnegierobotics.com>
	<bdc5c04bff35527821894a40b521a8f7a8c14f35.camel@carnegierobotics.com>
Message-ID: <a595e2ed8c5355f7440731e65667d1d0@ccrma.stanford.edu>

Thanks for the very clear test program!  I'll check it
out.  Two things that might help you debug these sorts
of bugs: there's a macro SHOW_EVAL_OPS in s7.c -- if
it is 1, s7 prints out a ton of detail about what it's
doing; and there's a function s7_show_stack that is
not static, but also not in s7.h -- if you add its
declaration to catch-test.c and call it in your
print_statck_top function, it will show the scheme
stack. The end of the printout for catch-test.c is:

TEST
catch (513), code: #<catch>
eval_done (510), code: #<unused>
TOP 1
stack:
s7_call_with_catch[50584]: push eval_done
s7_call_with_catch[50586]
TEST
TOP 3
stack:
   catch
   eval_done
s7_call_with_catch[50586]
TEST
TOP 4
stack:
   catch
   catch
   eval_done
s7_call_with_catch[50586]
TEST
TOP 5
stack:
   catch
   catch
   catch
   eval_done
stack_reset[7747]: push eval_done
s7_quit[52367]: push eval_done



From bil at ccrma.Stanford.EDU  Tue Jun  7 11:07:14 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Tue, 07 Jun 2022 11:07:14 -0700
Subject: [CM] (*s7* 'stack)
In-Reply-To: <bdc5c04bff35527821894a40b521a8f7a8c14f35.camel@carnegierobotics.com>
References: <f5ffd73069153e3523c3929e1800142a3fe24504.camel@carnegierobotics.com>
	<bdc5c04bff35527821894a40b521a8f7a8c14f35.camel@carnegierobotics.com>
Message-ID: <eca6d1c74b8eede4adde6344e741c4ed@ccrma.stanford.edu>

In normal use, the s7 evaluator pops off irrelevant entries as it
calls functions and whatnot, but here everything is happening in C,
so, as you suggested, I think s7_call_with_catch does need to pop
the stack if it hasn't already been popped; something like:

s7.c ca line 50611

       else
	{
	  /* we've replaced our jump point, fix it in this catch too */
	  catch_cstack(p) = &new_goto_start;
	  push_stack(sc, OP_CATCH, error_handler, p);
	  result = s7_call(sc, body, sc->nil);
	  if (((opcode_t)sc->stack_end[-1]) == OP_CATCH)
	    unstack_with(sc, OP_CATCH);
	}
       restore_jump_info(sc);
     }
   else
     {
       push_stack(sc, OP_CATCH, error_handler, p);
       result = s7_call(sc, body, sc->nil);
       if (((opcode_t)sc->stack_end[-1]) == OP_CATCH)
	    unstack_with(sc, OP_CATCH);
     }

I haven't tested this very much...



From wdouglass at carnegierobotics.com  Tue Jun  7 11:15:24 2022
From: wdouglass at carnegierobotics.com (Woody Douglass)
Date: Tue, 7 Jun 2022 18:15:24 +0000
Subject: [CM] (*s7* 'stack)
In-Reply-To: <eca6d1c74b8eede4adde6344e741c4ed@ccrma.stanford.edu>
References: <f5ffd73069153e3523c3929e1800142a3fe24504.camel@carnegierobotics.com>
	<bdc5c04bff35527821894a40b521a8f7a8c14f35.camel@carnegierobotics.com>
	<eca6d1c74b8eede4adde6344e741c4ed@ccrma.stanford.edu>
Message-ID: <31ab29a3793d27aed20d465c66b416f62c9731b1.camel@carnegierobotics.com>

Very cool, thanks. I'll do some experimentation with this as well

-Woody

On Tue, 2022-06-07 at 11:07 -0700, bil at ccrma.Stanford.EDU wrote:
> In normal use, the s7 evaluator pops off irrelevant entries as it
> calls functions and whatnot, but here everything is happening in C,
> so, as you suggested, I think s7_call_with_catch does need to pop
> the stack if it hasn't already been popped; something like:
> 
> s7.c ca line 50611
> 
>        else
> 	{
> 	  /* we've replaced our jump point, fix it in this catch too */
> 	  catch_cstack(p) = &new_goto_start;
> 	  push_stack(sc, OP_CATCH, error_handler, p);
> 	  result = s7_call(sc, body, sc->nil);
> 	  if (((opcode_t)sc->stack_end[-1]) == OP_CATCH)
> 	    unstack_with(sc, OP_CATCH);
> 	}
>        restore_jump_info(sc);
>      }
>    else
>      {
>        push_stack(sc, OP_CATCH, error_handler, p);
>        result = s7_call(sc, body, sc->nil);
>        if (((opcode_t)sc->stack_end[-1]) == OP_CATCH)
> 	    unstack_with(sc, OP_CATCH);
>      }
> 
> I haven't tested this very much...
> 



From wdouglass at carnegierobotics.com  Wed Jun  8 13:40:36 2022
From: wdouglass at carnegierobotics.com (Woody Douglass)
Date: Wed, 8 Jun 2022 20:40:36 +0000
Subject: [CM] possible bug in hook invocation
Message-ID: <ded64a06c7ba46e7e8f0e4b1a9c29be41053251c.camel@carnegierobotics.com>

Bill et all,

I'm currently trying to debug a peculiar issue -- i create a hook by
calling `(make-hook 'samples)`, assign to it's `hook-functions` to a
list of lambdas (in scheme), and then try to invoke the hook from C
with `s7_call(s, hook, s7_cons(s, samples_list, s7_nil(s));`

sometimes, when the hook is invoked, i get a segfault in
`op_safe_closure_p_a_1` in s7.c

is a lambda created in scheme automatically a "safe closure"? i've been
trying to make sure i'm not being bitten by the GC, but I haven't found
evidence of that yet

Thanks for any advice,
Woody Douglass



From bil at ccrma.Stanford.EDU  Wed Jun  8 14:45:09 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Wed, 08 Jun 2022 14:45:09 -0700
Subject: [CM] possible bug in hook invocation
In-Reply-To: <ded64a06c7ba46e7e8f0e4b1a9c29be41053251c.camel@carnegierobotics.com>
References: <ded64a06c7ba46e7e8f0e4b1a9c29be41053251c.camel@carnegierobotics.com>
Message-ID: <b2f9b0918318ee2ef7a4adcbe0151002@ccrma.stanford.edu>

This could be a GC problem, but it's a circuitous path if so.
Can you send me enough code to try to recreate the segfault?
On the other question, a lambda form is only deemed safe
if its body is safe.  If you hit the segfault in gdb,
a stacktrace would be helpful.  To see if the GC is
the problem, build s7 with -g3 and S7_DEBUGGING=1, then
when you crash in safe_closure_p_a_1

p sc->code[0]

It should be a "closure" in s7 terminology (type==39 in the gdb
output).  If it's free (type==0), go to the end of the gdb
printout, and you'll see where the GC freed it and so on.
(Actually S7_DEBUGGING will tell you most of this before
falling into gdb).



From wdouglass at carnegierobotics.com  Wed Jun  8 16:15:37 2022
From: wdouglass at carnegierobotics.com (Woody Douglass)
Date: Wed, 8 Jun 2022 23:15:37 +0000
Subject: [CM] possible bug in hook invocation
In-Reply-To: <b2f9b0918318ee2ef7a4adcbe0151002@ccrma.stanford.edu>
References: <ded64a06c7ba46e7e8f0e4b1a9c29be41053251c.camel@carnegierobotics.com>
	<b2f9b0918318ee2ef7a4adcbe0151002@ccrma.stanford.edu>
Message-ID: <d5feb72028d096005ba0791e24f1aeb83dfe5891.camel@carnegierobotics.com>

It's a small part of a big program, so i may not be able to boil it
down to a small example but i'll try. in the meantime, i'll try your
other suggestions and report back. thanks for your help!

-Woody

On Wed, 2022-06-08 at 14:45 -0700, bil at ccrma.Stanford.EDU wrote:
> This could be a GC problem, but it's a circuitous path if so.
> Can you send me enough code to try to recreate the segfault?
> On the other question, a lambda form is only deemed safe
> if its body is safe.  If you hit the segfault in gdb,
> a stacktrace would be helpful.  To see if the GC is
> the problem, build s7 with -g3 and S7_DEBUGGING=1, then
> when you crash in safe_closure_p_a_1
> 
> p sc->code[0]
> 
> It should be a "closure" in s7 terminology (type==39 in the gdb
> output).  If it's free (type==0), go to the end of the gdb
> printout, and you'll see where the GC freed it and so on.
> (Actually S7_DEBUGGING will tell you most of this before
> falling into gdb).
> 



From wdouglass at carnegierobotics.com  Thu Jun  9 07:15:01 2022
From: wdouglass at carnegierobotics.com (Woody Douglass)
Date: Thu, 9 Jun 2022 14:15:01 +0000
Subject: [CM] possible bug in hook invocation
In-Reply-To: <b2f9b0918318ee2ef7a4adcbe0151002@ccrma.stanford.edu>
References: <ded64a06c7ba46e7e8f0e4b1a9c29be41053251c.camel@carnegierobotics.com>
	<b2f9b0918318ee2ef7a4adcbe0151002@ccrma.stanford.edu>
Message-ID: <8d25ba4879b95f5f691f2958e3bce915f2c26e72.camel@carnegierobotics.com>

with the current master of s7 git, i'm still having the problem. when
the system crashes, the following is printed

```
op_safe_closure_p_a_1[83596]: opt2: 0x2cac0b30->(nil) wants opt2_fx,
debugger bits are 20000004  opt3_set opt3_location but expects 262144
opt2_fx
```

the type is 1, so maybe it's been gc'd and then reallocated?
```
(gdb) p sc->code[0]     
$3 = {tf = {flag = 13979174299934918657, signed_flag =
-4467569773774632959, type_field = 1 '\001', sflag = 2049, opts = {
      unused_low_flag = 14944257, opt_choice = 246, high_flag =
49664}}, object = {number = {integer_value = 749583392, 
      real_value = 3.7034340268035228e-315, fraction_value = {numerator
= 749583392, denominator = 749452976}, complex_value = {
        rl = 3.7034340268035228e-315, im = 3.7027896861508425e-315}},
number_name = {unused1 = 749583392, unused2 = 749452976, 
      name = "\260\n\254,", '\000' <repeats 12 times>,
"\371\000\000\003\340s\002"}, prt = {port = 0x2cadbc20, 
      data = 0x2cabbeb0 "\001", size = 749472432, point = 0, block =
0x273e0030000f9}, chr = {c = 32 ' ', up_c = 188 '\274', 
      length = 0, alpha_c = 176, digit_c = 190, space_c = 171, upper_c
= 44, lower_c = false, 
      c_name = "\000\000\000\260\n\254,\000\000\000\000"}, cptr =
{c_pointer = 0x2cadbc20, c_type = 0x2cabbeb0, info = 0x2cac0ab0, 
      weak1 = 0x0, weak2 = 0x273e0030000f9}, vector = {length =
749583392, elements = {objects = 0x2cabbeb0, ints = 0x2cabbeb0, 
        floats = 0x2cabbeb0, bytes = 0x2cabbeb0 "\001"}, block =
0x2cac0ab0, vget = 0x0, setv = {vset = 0x273e0030000f9, 
        fset = 0x273e0030000f9}}, stk = {length = 749583392, objects =
0x2cabbeb0, block = 0x2cac0ab0, top = 0, 
      flags = 690355913621753}, hasher = {mask = 749583392, elements =
0x2cabbeb0, hash_func = 0x2cac0ab0, loc = 0x0, 
      block = 0x273e0030000f9}, iter = {obj = 0x2cadbc20, cur =
0x2cabbeb0, lc = {loc = 749472432, lcur = 0x2cac0ab0}, lw = {len = 0, 
        slow = 0x0, hcur = 0x0}, next = 0x273e0030000f9}, fnc = {c_proc
= 0x2cadbc20, ff = 0x2cabbeb0, required_args = 749472432, 
      optional_args = 0, all_args = 690355913621753}, cons = {car =
0x2cadbc20, cdr = 0x2cabbeb0, opt1 = 0x2cac0ab0, o2 = {opt2 = 0x0, 
        n = 0}, o3 = {opt3 = 0x273e0030000f9, n = 690355913621753,
opt_type = 249 '\371'}}, sym_cons = {unused_car = 0x2cadbc20, 
      unused_cdr = 0x2cabbeb0, hash = 749472432, fstr = 0x0, location =
690355913621753}, func = {args = 0x2cadbc20, 
      body = 0x2cabbeb0, env = 0x2cac0ab0, setter = 0x0, arity =
50331897}, string = {length = 749583392, svalue = 0x2cabbeb0 "\001", 
      hash = 749472432, block = 0x0, gensym_block = 0x273e0030000f9},
sym = {name = 0x2cadbc20, global_slot = 0x2cabbeb0, 
      local_slot = 0x2cac0ab0, id = 0, ctr = 50331897, tag = 160736},
syn = {symbol = 0x2cadbc20, op = 749452976, 
      min_args = 749472432, max_args = 0, documentation = 0x0}, slt =
{sym = 0x2cadbc20, val = 0x2cabbeb0, nxt = 0x2cac0ab0, 
      pending_value = 0x0, expr = 0x273e0030000f9}, envr = {slots =
0x2cadbc20, nxt = 0x2cabbeb0, id = 749472432, edat = {efnc = {
          function = 0x0, line = 50331897, file = 160736}, dox = {dox1
= 0x0, dox2 = 0x273e0030000f9}, key = 0}}, unq = {
      car = 0x2cadbc20, cdr = 0x2cabbeb0, unused_let_id = 749472432,
name = 0x0, len = 690355913621753}, undef = {
      name = 0x2cadbc20 "\n", len = 749452976}, eof = {name =
0x2cadbc20 "\n", len = 749452976}, ctr = {result = 0x2cadbc20, 
      list = 0x2cabbeb0, env = 0x2cac0ab0, slots = 0x0, cap =
690355913621753}, rng = {seed = 749583392, carry = 749452976}, c_obj =
{
      type = 749583392, value = 0x2cabbeb0, e = 0x2cac0ab0, sc = 0x0},
cwcc = {block = 0x2cadbc20, stack = 0x2cabbeb0, 
      op_stack = 0x2cac0ab0, stack_start = 0x0, stack_end =
0x273e0030000f9}, rexit = {goto_loc = 749583392, op_stack_loc =
749452976, 
      active = 176, name = 0x0}, rcatch = {goto_loc = 749583392,
op_stack_loc = 749452976, tag = 0x2cac0ab0, handler = 0x0, 
      cstack = 0x273e0030000f9}, winder = {in = 0x2cadbc20, out =
0x2cabbeb0, body = 0x2cac0ab0, state = DWIND_INIT}}, 
  current_alloc_line = 90969, previous_alloc_line = 0, uses = 1,
explicit_free_line = 0, gc_line = 0, current_alloc_type = 2097153, 
  previous_alloc_type = 0, debugger_bits = 536870981,
current_alloc_func = 0x7fefd8 <__FUNCTION__.69573> "eval", 
  previous_alloc_func = 0x0, gc_func = 0x0}

```


On Wed, 2022-06-08 at 14:45 -0700, bil at ccrma.Stanford.EDU wrote:
> This could be a GC problem, but it's a circuitous path if so.
> Can you send me enough code to try to recreate the segfault?
> On the other question, a lambda form is only deemed safe
> if its body is safe.  If you hit the segfault in gdb,
> a stacktrace would be helpful.  To see if the GC is
> the problem, build s7 with -g3 and S7_DEBUGGING=1, then
> when you crash in safe_closure_p_a_1
> 
> p sc->code[0]
> 
> It should be a "closure" in s7 terminology (type==39 in the gdb
> output).  If it's free (type==0), go to the end of the gdb
> printout, and you'll see where the GC freed it and so on.
> (Actually S7_DEBUGGING will tell you most of this before
> falling into gdb).
> 



From bil at ccrma.Stanford.EDU  Thu Jun  9 09:10:30 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Thu, 09 Jun 2022 09:10:30 -0700
Subject: [CM] possible bug in hook invocation
In-Reply-To: <8d25ba4879b95f5f691f2958e3bce915f2c26e72.camel@carnegierobotics.com>
References: <ded64a06c7ba46e7e8f0e4b1a9c29be41053251c.camel@carnegierobotics.com>
	<b2f9b0918318ee2ef7a4adcbe0151002@ccrma.stanford.edu>
	<8d25ba4879b95f5f691f2958e3bce915f2c26e72.camel@carnegierobotics.com>
Message-ID: <9d60b62810589133015087328c16c1f7@ccrma.stanford.edu>

It's saying it got a pair (type=1) when it expected
a function, and that the cell in question has never
been touched by the GC (gc_func=null).  Also that
the pair in question is straight from the reader
(the location business), so this almost has to be an
optimizer problem.



From elronnd at elronnd.net  Fri Jun 10 15:25:10 2022
From: elronnd at elronnd.net (Elijah Stone)
Date: Fri, 10 Jun 2022 15:25:10 -0700 (PDT)
Subject: [CM] Readably printing circular closures
Message-ID: <879220a6-9494-a9a6-c291-7edfa629b8e7@elronnd.net>

> (letrec ((f (lambda () f))) (object->string f :readable))
"(let () (lambda () f))"

bug?


From mike at eggheadgames.com  Fri Jun 10 23:45:45 2022
From: mike at eggheadgames.com (Michael Mee)
Date: Sat, 11 Jun 2022 14:45:45 +0800
Subject: [CM] Suggested r7rs.scm change for get-environment-variable
Message-ID: <17A658C8-2D29-4E60-B5F5-2093967EF67D@eggheadgames.com>

It appears there was a 6 may 22 change to `getenv` to make it more 
compatible with r7rs.

Accordingly, perhaps the current r7rs.scm file can be modified from:

(define (get-environment-variable x)
    (let ((val ((*libc* 'getenv) x)))
      (and (string? val)
       (> (length val) 0)
       val)))

to:

(define get-environment-variable getenv)

I could be missing some subtlety here, but I came across this today and 
thought it best to mention it.

Cheers, Michael

PS: Thanks as always for s7 and the ongoing efforts!


From dave at sleepmap.de  Sat Jun 11 02:02:26 2022
From: dave at sleepmap.de (David Runge)
Date: Sat, 11 Jun 2022 11:02:26 +0200
Subject: [CM] 22.4: Issues building with pulseaudio
Message-ID: <YqRaKZaLC0SSk2yM@hmbx>

Hi!

I'm maintaining snd for Arch Linux.
Upon upgrading to 22.4 I ran into issues and am unable to build the
project.

I noticed that `pulseaudio_sample_types` is implicitly declared:

```
audio.c: In function ?mus_audio_device_sample_type?:
audio.c:5689:5: warning: implicit declaration of function ?pulseaudio_sample_types?; did you mean ?alsa_sample_types?? [-Wimplicit-function-declaration]
 5689 |     pulseaudio_sample_types(dev, mixer_vals);
      |     ^~~~~~~~~~~~~~~~~~~~~~~
      |     alsa_sample_types
```

Later on the linker is not able to find the reference:

```
/usr/bin/ld: /tmp/ccSWTc8d.ltrans32.ltrans.o: in function `mus_audio_device_sample_type':
/usr/src/debug/snd-22.4/audio.c:5689: undefined reference to `pulseaudio_sample_types'
collect2: error: ld returned 1 exit status
make: *** [makefile:83: snd] Error 1
```

For the entire build log please refer to https://pkgbuild.com/~dvzrv/logs/snd-22.4-build.log
The diff for audio.c between 22.3 and 22.4 can be found here: https://pkgbuild.com/~dvzrv/bugs/2022/06/snd-22.3-22.4-audio.c.diff

This is a regression from 22.3 to 22.4 (I am still able to build 22.3
successfully).

Any hints and patches are much welcomed.

Best,
David

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220611/9c0f5b0f/attachment.sig>

From bil at ccrma.Stanford.EDU  Sat Jun 11 03:29:26 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Sat, 11 Jun 2022 03:29:26 -0700
Subject: [CM] 22.4: Issues building with pulseaudio
In-Reply-To: <YqRaKZaLC0SSk2yM@hmbx>
References: <YqRaKZaLC0SSk2yM@hmbx>
Message-ID: <5081ecc56787e808e110b674611f8a70@ccrma.stanford.edu>

As you can see from your diff file, pulseaudio_sample_types
is in audio.c.  I can't tell what configuration switches
you use, but as your log shows, you got alsa+jack, and
somehow pulseaudio as well -- I don't think this
combination will work.  Use just --with-pulseaudio.
Your mus_config.h file might help.

This may have worked in the past because you were actually
gettting alsa+jack, and the new procedure was not in 22.3,
so the compiler and loader were happy.



From bil at ccrma.Stanford.EDU  Sat Jun 11 05:25:25 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Sat, 11 Jun 2022 05:25:25 -0700
Subject: [CM] Suggested r7rs.scm change for get-environment-variable
In-Reply-To: <17A658C8-2D29-4E60-B5F5-2093967EF67D@eggheadgames.com>
References: <17A658C8-2D29-4E60-B5F5-2093967EF67D@eggheadgames.com>
Message-ID: <557952940ee1b697c612d6d780c951f2@ccrma.stanford.edu>

Thanks -- I have made that change to my versions.



From bil at ccrma.Stanford.EDU  Sat Jun 11 07:02:40 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Sat, 11 Jun 2022 07:02:40 -0700
Subject: [CM] Readably printing circular closures
In-Reply-To: <879220a6-9494-a9a6-c291-7edfa629b8e7@elronnd.net>
References: <879220a6-9494-a9a6-c291-7edfa629b8e7@elronnd.net>
Message-ID: <471bfbd54e15c684c90c10f11ffca1f3@ccrma.stanford.edu>

I think I can distinguish that from (let ((f (lambda () f))) f),
and in any case the empty "let" is inelegant.  I'll poke at it.



From cm at jrigg.co.uk  Sat Jun 11 07:16:30 2022
From: cm at jrigg.co.uk (John Rigg)
Date: Sat, 11 Jun 2022 15:16:30 +0100
Subject: [CM] 22.4: Issues building with pulseaudio
In-Reply-To: <YqRaKZaLC0SSk2yM@hmbx>
References: <YqRaKZaLC0SSk2yM@hmbx>
Message-ID: <YqSjvtvBVqUzNhWi@jrigg.co.uk>

On Sat, Jun 11, 2022 at 11:02:26AM +0200, David Runge wrote:
> Hi!
> 
> I'm maintaining snd for Arch Linux.
> Upon upgrading to 22.4 I ran into issues and am unable to build the
> project.
> 
> I noticed that `pulseaudio_sample_types` is implicitly declared:
> 
> ```
> audio.c: In function ???mus_audio_device_sample_type???:
> audio.c:5689:5: warning: implicit declaration of function ???pulseaudio_sample_types???; did you mean ???alsa_sample_types???? [-Wimplicit-function-declaration]
>  5689 |     pulseaudio_sample_types(dev, mixer_vals);
>       |     ^~~~~~~~~~~~~~~~~~~~~~~
>       |     alsa_sample_types
> ```
> 
> Later on the linker is not able to find the reference:
>

FWIW snd-22.4 builds without a problem here on a week-old snapshot
of Void Linux (gcc-10.2) using --with-alsa and --with-jack. (I don't
have any pulseaudio development stuff installed).

John.


From dave at sleepmap.de  Sat Jun 11 09:12:49 2022
From: dave at sleepmap.de (David Runge)
Date: Sat, 11 Jun 2022 18:12:49 +0200
Subject: [CM] 22.4: Issues building with pulseaudio
In-Reply-To: <5081ecc56787e808e110b674611f8a70@ccrma.stanford.edu>
References: <YqRaKZaLC0SSk2yM@hmbx>
	<5081ecc56787e808e110b674611f8a70@ccrma.stanford.edu>
Message-ID: <YqS/CJpAgPCSGeDy@hmbx>

On 2022-06-11 03:29:26 (-0700), bil at ccrma.Stanford.EDU wrote:
> As you can see from your diff file, pulseaudio_sample_types
> is in audio.c.  I can't tell what configuration switches
> you use, but as your log shows, you got alsa+jack, and
> somehow pulseaudio as well -- I don't think this
> combination will work.  Use just --with-pulseaudio.
> Your mus_config.h file might help.

If I understand this correctly I can not build snd with ALSA, JACK *and*
pulseaudio support at the same time?

> This may have worked in the past because you were actually
> gettting alsa+jack, and the new procedure was not in 22.3,
> so the compiler and loader were happy.

That is probably correct, but shouldn't the build system prevent one
from building ALSA, JACK *and* pulseaudio support at the same time then?

Are these combinations tested somewhere in CI, or how is made sure that
builds with all features work? Sorry for my ignorance, but I was under
the impression that these features can be built together (the build
system and documentation does not suggest otherwise).

Is the course of action then to remove pulseaudio support or to provide
a separate binary that provides only pulseaudio support? This does not
sound like an approach that scales too well. :)

Best,
David

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220611/fb83ff03/attachment.sig>

From bil at ccrma.Stanford.EDU  Sat Jun 11 09:29:15 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Sat, 11 Jun 2022 09:29:15 -0700
Subject: [CM] 22.4: Issues building with pulseaudio
In-Reply-To: <YqS/CJpAgPCSGeDy@hmbx>
References: <YqRaKZaLC0SSk2yM@hmbx>
	<5081ecc56787e808e110b674611f8a70@ccrma.stanford.edu>
	<YqS/CJpAgPCSGeDy@hmbx>
Message-ID: <18e4c889b627cd3621e5c1cd06011299@ccrma.stanford.edu>

Choose one.  I test a ton of configurations (see tools/testsnd).
I don't care what "scales well", and I don't know what "CI"
stands for.  You were probably getting alsa+jack before --
run snd --version.




From dave at sleepmap.de  Sat Jun 11 10:13:26 2022
From: dave at sleepmap.de (David Runge)
Date: Sat, 11 Jun 2022 19:13:26 +0200
Subject: [CM] 22.4: Issues building with pulseaudio
In-Reply-To: <18e4c889b627cd3621e5c1cd06011299@ccrma.stanford.edu>
References: <YqRaKZaLC0SSk2yM@hmbx>
	<5081ecc56787e808e110b674611f8a70@ccrma.stanford.edu>
	<YqS/CJpAgPCSGeDy@hmbx>
	<18e4c889b627cd3621e5c1cd06011299@ccrma.stanford.edu>
Message-ID: <YqTNPYf0J5FXOypw@hmbx>

On 2022-06-11 09:29:15 (-0700), bil at ccrma.Stanford.EDU wrote:
> Choose one.  I test a ton of configurations (see tools/testsnd).

I see.
There seem to be none yet for --with-alsa, --with-jack or
--with-pulseaudio. It is not instantly obvious whether any of those are
tested implicitly (alsa seems to be the default though).

> I don't care what "scales well",

I was merely pointing out that building for several features in a
packaging context leads to several executables and I'm not sure if that
is the desired outcome or not - several executables for features
objectively do not scale well (e.g. what should they be named? will
downstreams use the same names? how are users on downstream
distributions made aware of this?).
Anyways, there is no need to get rude over this. Users of snd will care
and will ask questions to understand the projects intentions better (so
here we are).

> and I don't know what "CI" stands for.

CI - Continuous Integration (e.g. see
https://en.wikipedia.org/wiki/Continuous_integration#Run_tests_in_CI)

> You were probably getting alsa+jack before -- run snd --version.

```
snd --version
This is Snd version 22.3 of 23-Apr-22:
    s7: 10.4 (23-Apr-2022), Xen: 4.2
    Jack
    Sndlib 24.8 (5-Oct-21)
    CLM 6.19 (17-Nov-18)
    GSL 2.7.1
    fftw-3.3.10-sse2-avx
    Motif 2.3.8 X11R6
    OpenGL  (snd gl: 08-Mar-19)
    Xpm 3.4.11
    Ladspa: 1.1
    gmp: 6.2.1, mpfr: 4.1.0-p13, mpc: 1.2.1
    Compiled Apr 23 2022 08:14:22
    C: gcc 11.2
    Linux 5.17.14-hardened1-1-hardened x86_64
```

I guess the version output depends on what audio backend is currently
detected?
Either way, snd seems to link against both libasound.so and libjack.so,
so that is fine.
I will remove pulseaudio from the list of configure options for 22.4.


Closing I would like to add, that I am currently building twice to have
s7 and ruby support in the same snd package (see the build script here:
https://github.com/archlinux/svntogit-community/blob/packages/snd/trunk/PKGBUILD).
Initially it was not clear to me that --with-s7 and --with-ruby are
mutually exclusive (the build system does not prevent the user from
supplying both). This is a similar problem to --with-alsa/--with-jack
and --with-pulseaudio I guess.

Best,
David

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220611/83b4baf4/attachment.sig>

From j_hearon at hotmail.com  Thu Jun 16 10:54:03 2022
From: j_hearon at hotmail.com (James Hearon)
Date: Thu, 16 Jun 2022 17:54:03 +0000
Subject: [CM] out
Message-ID: <BYAPR10MB25366851D68B1774BF5993A5E5AC9@BYAPR10MB2536.namprd10.prod.outlook.com>


Hi,
I think I've had a basic misunderstanding re: re stereo and using out such as outa, outb, outc, outd. It seems to sum rather than provide discrete outs?  I'm just checking I'm not going bonkers looking at the fft of the output signal.  I know locsig works differently

ex.1 results in 880 hz on a and b, but would expect 440 on a and 440 on b.
(with-sound (:play #f :channels 2)
  (let ((gen (make-oscil 440.0)))
    (do ((i 0 (+ i 1)))
        ((= i 48000))
      (outa i (* 0.5 (oscil gen)))
      (outb i (* 0.5 (oscil gen)))
      )))

ex.2 but to have have the same signal on both channels I need to use 2 gens?
(with-sound (:play #f :channels 2)
  (let ((gen (make-oscil 440.0))
          (gen2 (make-oscil 440.0)))
    (do ((i 0 (+ i 1)))
        ((= i 48000))
      (outa i (* 0.5 (oscil gen)))
      (outb i (* 0.5 (oscil gen2)))
      )))

Or how do you best do stereo using out?
This seems to sum as well.

(with-sound (:play #f :channels 2)
  (let* ((gen (make-oscil 440.0))
             (gen2 gen))
    (do ((i 0 (+ i 1)))
        ((= i 48000))
      (outa i (* 0.5 (oscil gen)))
      (outb i (* 0.5 (oscil gen2)))
      )))


Regards,
Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220616/ddd9b75d/attachment.html>

From bil at ccrma.Stanford.EDU  Thu Jun 16 11:29:33 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Thu, 16 Jun 2022 11:29:33 -0700
Subject: [CM] out
In-Reply-To: <BYAPR10MB25366851D68B1774BF5993A5E5AC9@BYAPR10MB2536.namprd10.prod.outlook.com>
References: <BYAPR10MB25366851D68B1774BF5993A5E5AC9@BYAPR10MB2536.namprd10.prod.outlook.com>
Message-ID: <d16272fd5f6bf8bd7154e8bfcc1ac735@ccrma.stanford.edu>

When you call

       (outa i (* 0.5 (oscil gen)))
       (outb i (* 0.5 (oscil gen)))

you're calling the "gen" oscillator twice
so you get one sample in outa, then its next sample
in outb, etc -- from the channel's point of view
it's seeing an oscillator running twice as fast
(880 Hz).



From irvise_ml at irvise.xyz  Tue Jun 28 11:58:49 2022
From: irvise_ml at irvise.xyz (Fernando Oleo Blanco)
Date: Tue, 28 Jun 2022 18:58:49 +0000
Subject: [CM] S7 questions and libc issue
In-Reply-To: <ffa712991385a399ab75bf0c33b6e49f@ccrma.stanford.edu>
References: <20220511214626.12298fda@linux.fritz.box>
	<20220512230843.7fe3a1e6@linux.fritz.box>
	<8cf0c94ec8ae93d9f2d8888d5be1613c@ccrma.stanford.edu>
	<20220514211334.1f9a7f01@linux.fritz.box>
	<f899d65b140a520dda45682218f6ff9a@ccrma.stanford.edu>
	<20220514223039.4dc6a68b@linux.fritz.box>
	<2f79c63f3ef87800b17bc926e35e9616@ccrma.stanford.edu>
	<20220514235236.062ed60c@linux.fritz.box>
	<ffa712991385a399ab75bf0c33b6e49f@ccrma.stanford.edu>
Message-ID: <20220628205846.149e7f66@linux.fritz.box>

Hello!

Sorry if you receive this email duplicated. I forgot to "Reply All".

I am back and I bring some extra information regarding the
compilation/cross-compilation of S7 with support for libc.scm. My
motivation to continue digging was [1]. S7 has great performance and it
also has outstanding R7RS support if we follow those results. I
personally thought it had worst support.

A bit of background first. When Chibi wants to compile itself
"staticly", with all of its libraries as part of the executable, it
requires a two step compilation process.
- First it compiles itself normally (dynamic linking, only the
  interpreter) for the host.
- Then using the native Chibi executable that was just created, it
  generates a C file which is just the translation of all of its Scheme
  libraries and dumps them together.
- Finally, the compilation of Chibi is ran again but this time, it
  links itself with the new generated C file that contains absolutely
  everything. The resulting binary is all of Chibi in one binary.

So that got me thinking... Can this be done for S7 if I want to
cross-compile it with libc support and link it staticly?

So here is what I did:

- Compile S7 for the host normally.
- Run the interpreter ala "./s7 r7rs.scm" so that it generates the
  libc_s7.{c,so} files.
- Cross-compile S7 for my RISC-V board staticly (which as previously
  said, it works) and WITH_C_LOADER so that it can read .so files.
- Generate a libc_s7.so for the target architecture. Basically, another
  cross-compilation.

However, I am running into a problem... or maybe a few of them. I
actually do not know how S7 generates the libc_s7.so. I took a look at
the cload.scm and I think I reverse engineer what it is trying to do.
However, in the end, my staticly compiled S7 in my RISC-V board always
fails to run with libc... It either fails because it cannot find some
symbols (such as s7_f) even though I used GCC and passed
-DWITH_C_LOADER=1 or it aborts... I know the generated .so is for
RISC-V and it has the symbols.

Has anybody tried this before? I think it should just work... I have
also documented this process in the Scheme comparison table (currently,
footnote 25) [2]. The exact execution commands are also in [2]

I may be extremely slow to respond, as my worklife is currently a
black hole.

[1] https://ecraven.github.io/r7rs-benchmarks/
[2] https://irvise.xyz/Blog/scheme-implementation-comparison.html#fn.25

Best regards, and thank you for your time!
Fer




From bil at ccrma.Stanford.EDU  Tue Jun 28 13:00:35 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Tue, 28 Jun 2022 13:00:35 -0700
Subject: [CM] Fwd: Re:  S7 questions and libc issue
Message-ID: <22b45512b8da75a40292b1e506aa69e7@ccrma.stanford.edu>

I also forgot to reply all


-------- Original Message --------
Subject: Re: [CM] S7 questions and libc issue
Date: 2022-06-28 12:58
 From: bil at ccrma.stanford.edu
To: Fernando Oleo Blanco <irvise_ml at irvise.xyz>

I think I would use something like repl.c, rather
than the -DWITH_MAIN switch.  Then in that file,
I would

#include "libc_s7.c"

and in the main repl.c function, after s7_init,
I would call libc_s7_init(sc); this ties the libc
library into the repl without all the dynamic loading
and *.so stuff.  nrepl.c uses this process to load the
stuff in notcurses_s7.c.

The s7_f error should have something to do with -Wl, export-dynamic,
but I can't immediately remember the details.  Once that's
fixed, the ELF business will also be fixed.


The so-called standard benchmarks test little of r7rs,
or little of r5rs for that matter -- I think they are
useless as benchmarks.  I get pissed off every time
I look at that code.


From j_hearon at hotmail.com  Wed Jun 29 10:51:48 2022
From: j_hearon at hotmail.com (James Hearon)
Date: Wed, 29 Jun 2022 17:51:48 +0000
Subject: [CM] make-bandpass xcoeffs
Message-ID: <BYAPR10MB253606420DC3BA9A40DE012DE5BB9@BYAPR10MB2536.namprd10.prod.outlook.com>

Hi,
It seems make-bandpass doesn't have the mus-xcoeffs feature as general make-filter does, but I was trying to get the numbers to do some comparisons all in one definstrument, define, or let.  It seems calling the make-bandpass function as a generator and trying to place the output into a vector is the wrong approach, or maybe I have the inp variable wrong?  Also it seems one can use a bandpass or fir-filter call interchangeably?

How can I best get accurate xcoeffs numbers in-line, so to speak, from the make-bandpass gen?

(define (gentest amp flo1 fhi1 order)
 (let ((flt1 (make-bandpass (hz->radians flo1) (hz->radians fhi1) order)) ;flow, fhigh, order
         (v (make-float-vector order))
         )
   (do ((l 0 (+ l 1)))
       ((= l order))
(float-vector-set! v l (bandpass flt1 l))  ;or (fir-filter flt1 l)
(format #t "~%l: ~F bandpass: ~0,6F v: ~0,6F" l (bandpass flt1 l) (v l))
    ) ))

(with-sound (:srate 48000 :channels 2 :header-type mus-riff )
           (gentest .5 200 400 3 )
                )

As a test, I modified make-bandpass from dsp.scm to be able to print the coeffs which makes me believe the float-vector-set! approach above doesn't give the coeffs I was hoping to see.

(define (mymake-bandpass flo fhi order)
   (let* (
          (len order)
          (arrlen (+ 1 (* 2 len)))
          (arr (make-float-vector arrlen))
          )
(do ((i (- len) (+ i 1))) ;-len to +len
   ((= i len)
    (make-fir-filter arrlen arr)) ;order xcoeffs
 (let* ((k (+ i len))
(denom (* pi i))
(num (- (sin (* fhi i)) (sin (* flo i)))))
   (set! (arr k)
 (if (= i 0)
     (/ (- fhi flo) pi)
     (* (/ num denom)
(+ .54 (* .46 (cos (/ (* i pi) len)))))))))
   (do ((l 0 (+ l 1)))
       ((= l arrlen))
(format #t "~%l: ~F  xcoeffs: ~0,6F" l (arr l))
    )) )

(mymake-bandpass (hz->radians 200)  (hz->radians 400) 3)


Thank you for any suggestions,
Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220629/56f11366/attachment.html>

From bil at ccrma.Stanford.EDU  Wed Jun 29 12:04:42 2022
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Wed, 29 Jun 2022 12:04:42 -0700
Subject: [CM] make-bandpass xcoeffs
In-Reply-To: <BYAPR10MB253606420DC3BA9A40DE012DE5BB9@BYAPR10MB2536.namprd10.prod.outlook.com>
References: <BYAPR10MB253606420DC3BA9A40DE012DE5BB9@BYAPR10MB2536.namprd10.prod.outlook.com>
Message-ID: <4bc1a174e5c876e81b11ac36a08865dd@ccrma.stanford.edu>

make-bandpass is a wrapper around make-fir-filter, returning
an fir-filter generator, so mus-xcoeffs does work with it;
there's an example in snd-test.scm around line 7706.
make-bandpass is not itself a generator; it returns one.
If you look at the code in dsp.scm you'll see
(define bandpass fir-filter) -- this says the
bandpass generator is an fir-filter.  In the
first case, I think you're setting a vector to the
output of the bandpass generator, and in the second
it looks like you've copied the make-bandpass code
to set the vector, so you're setting the vector to
two different things.