From j_hearon at hotmail.com Thu Sep 1 10:43:35 2022 From: j_hearon at hotmail.com (James Hearon) Date: Thu, 1 Sep 2022 17:43:35 +0000 Subject: [CM] snd command line Message-ID: Hi, I've upgraded to f36, snd 22.6 and tried configuring and running Snd with no gui. It writes libc_s7.c, and lib_s7.so, but doesn't load lib_s7.so. I recall some pipewire weirdness previously. I'm wondering what the status or workaround might be, if any at all? No harm. Still enjoying using Snd from emacs. Thank you, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Thu Sep 1 12:15:59 2022 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 01 Sep 2022 12:15:59 -0700 Subject: [CM] snd command line In-Reply-To: References: Message-ID: The workaround for the pipewire problem in Snd (or repl.scm in s7) is to (define stderr-buffered #t) in your Snd init file, or if you're not using one, put that line at the top of repl.scm. I run the no-gui Snd in Ubuntu 22.04, and I think it is using pipewire (/usr/bin/pipewire is reported in ps aux), but I don't have to use that workaround. You can get the "dumb repl" by moving repl.scm to some other filename. From j_hearon at hotmail.com Thu Sep 1 17:14:57 2022 From: j_hearon at hotmail.com (James Hearon) Date: Fri, 2 Sep 2022 00:14:57 +0000 Subject: [CM] Snd command line In-Reply-To: References: Message-ID: Yay. (define stderr-buffered #t) at top of repl.com helps load the lib_s7.so. Thank you. It's been a while since I used Snd with no gui. Regards, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders at avinjar.no Wed Sep 7 00:20:20 2022 From: anders at avinjar.no (anders at avinjar.no) Date: Wed, 07 Sep 2022 09:20:20 +0200 Subject: [CM] snd: mouse-wheel up/down in gtk? Message-ID: <87bkrrwszv.fsf@josefk.localdomain> Hi, im trying to bind-key the mouse-wheel to zoom in/out in snd, as in the example for mouse-click-hook in the docs. However, both mouse 4 & 5 (up & down) only zooms in. Any cures? in a gnome desktop -anders From anders at avinjar.no Wed Sep 7 00:21:40 2022 From: anders at avinjar.no (anders at avinjar.no) Date: Wed, 07 Sep 2022 09:21:40 +0200 Subject: [CM] snd: mouse scroll up/down - zoom in/out (in gnome/gtk?) Message-ID: <877d2fwsxn.fsf@josefk.localdomain> Hi, im trying to bind-key the mouse-wheel to zoom in/out in snd, as in the example for mouse-click-hook in the docs. However, both mouse 4 & 5 (up & down) only zooms in. Any cures? -anders From bil at ccrma.Stanford.EDU Wed Sep 7 11:24:37 2022 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 07 Sep 2022 11:24:37 -0700 Subject: [CM] =?utf-8?q?snd=3A_mouse_scroll_up/down_-_zoom_in/out_=28in_gn?= =?utf-8?b?b21lL2d0az8p?= In-Reply-To: <877d2fwsxn.fsf@josefk.localdomain> References: <877d2fwsxn.fsf@josefk.localdomain> Message-ID: <52dfcd895fe33cfb7d8d9f4789070390@ccrma.stanford.edu> I can only find 5 buttons in gdk-enums.h, and I can't remember what those 5 mean. I'd try googling "gtk scroll wheel" and see if anything useful is out there. "GdkScrollDirection" for example. Good luck. From ar at amirrajan.net Sat Sep 10 10:45:47 2022 From: ar at amirrajan.net (Amir Rajan) Date: Sat, 10 Sep 2022 12:45:47 -0500 Subject: [CM] Load S7 source code from `char *`? Message-ID: Not sure if this is the right place to ask: The S7 machinery I'm working on will be used in an environment where file access from standard c libraries isn't available. Is it possible to load S7 source in C by passing in a `char *`? I tried `s7_eval_string`, but it only supports one s-exp at a time. * Amir Rajan ** PS I welcome VSRE emails. Learn more at http://vsre.info/. ** PPS I reply to every legitimate email I get. So, if you don't hear from me within a week. Email me again since there's a high chance that the email got lost in my inbox. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Sat Sep 10 13:00:47 2022 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Sat, 10 Sep 2022 13:00:47 -0700 Subject: [CM] =?utf-8?q?Load_S7_source_code_from_=60char_*=60=3F?= In-Reply-To: References: Message-ID: If you have more than one expression, you can use begin. From chris.actondev at gmail.com Sat Sep 10 13:42:30 2022 From: chris.actondev at gmail.com (Christos Vagias) Date: Sat, 10 Sep 2022 23:42:30 +0300 Subject: [CM] Load S7 source code from `char *`? In-Reply-To: References: Message-ID: s7_load_c_string is what you're looking for! On Sat, 10 Sep 2022, 23:01 , wrote: > If you have more than one expression, you can use begin. > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Tue Sep 13 10:26:27 2022 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 13 Sep 2022 10:26:27 -0700 Subject: [CM] Snd 22.7 Message-ID: Snd 22.7 s7: (*s7* 'number-separator) and heap-analyze|scan and stomping on bugs, of course checked: sbcl 2.2.8 Thanks!: Tito Latini, IOhannes Zmoelnig From chris.actondev at gmail.com Fri Sep 23 11:31:44 2022 From: chris.actondev at gmail.com (Christos Vagias) Date: Fri, 23 Sep 2022 20:31:44 +0200 Subject: [CM] Idea: using handles instead of pointers, s7_clone Message-ID: Greetings all, Just wanted to share with you an idea I had about a possible future (and breaking!) s7 change. Namely: using handles instead of pointers. This means every s7 api method would return a s7_handle instead of a s7_pointer. A s7_handle could be simply: struct { uint32_t index; }; index would point to the index in the s7 storage. I'm a bit confused with s7 heap vs s7 stack, but let's just assume the storage being s7_cell heap[INITIAL_HEAP_SIZE], then, to get the (for internal use) s7_pointer: s7_pointer s7_handle_to_pointer(s7_handle handle) { return heap[handle.index]; } Also any s7 structure (list/vector etc) would store references to s7_handles instead of s7_pointers. When the storage/heap needs to resize it's just a matter of realloc & initializing the new allocated part. My main drive for this change is to make something like s7_clone possible. By using s7_handles one could copy the whole s7 instance just by doing a memcpy of the s7's storage/heap. I'm attaching some contrived code of how one could use this feature. Another possible win from a change like this would be making s7 objects smaller => less cache misses. s7_handle could encode in which storage the underlying s7_cell is stored (eg using bit fields: 2 bits for storage group, 30 for index) Like this, s7_cell could be split into separate groups (& underlying storage), depending in their size. Since the s7_cell type info is 8 bytes: - numbers need only 16 more bytes, making them only 24 bytes in total. - the rest (c-pointers vectors ports etc) could stay together. Right now s7_cell is 48 bytes, but that could go lower since every s7_pointer (8 bytes) could be replaced with s7_handle (4 bytes). For reference, this is the article that inspired me: https://floooh.github.io/2018/06/17/handles-vs-pointers.html I have also used this technique for a classic tree-like data structure, where I'm storing everything in a vector, and passing around indexes instead of pointers. This made copying the whole tree essentially free (memcpy instead of having to traverse down the tree). Looking forward to your input! Best, Christos Vagias -------------- next part -------------- A non-text attachment was scrubbed... Name: s7_clone_example.c Type: text/x-csrc Size: 708 bytes Desc: not available URL: From elronnd at elronnd.net Fri Sep 23 11:59:08 2022 From: elronnd at elronnd.net (Elijah Stone) Date: Fri, 23 Sep 2022 11:59:08 -0700 (PDT) Subject: [CM] Idea: using handles instead of pointers, s7_clone In-Reply-To: References: Message-ID: So you add an indirection to every object, and limit the heap to 1b objects? I don't see this as a win. Checkpointing is cool, though. -E On Fri, 23 Sep 2022, Christos Vagias wrote: > Greetings all, > > Just wanted to share with you an idea I had about a possible future > (and breaking!) s7 change. > Namely: using handles instead of pointers. This means every s7 api > method would return a s7_handle instead of a s7_pointer. > A s7_handle could be simply: > struct { > uint32_t index; > }; > > index would point to the index in the s7 storage. > I'm a bit confused with s7 heap vs s7 stack, but let's just assume the > storage being > s7_cell heap[INITIAL_HEAP_SIZE], then, to get the (for internal use) s7_pointer: > > s7_pointer s7_handle_to_pointer(s7_handle handle) { > return heap[handle.index]; > } > > Also any s7 structure (list/vector etc) would store references to > s7_handles instead of s7_pointers. > When the storage/heap needs to resize it's just a matter of realloc & > initializing the new allocated part. > > My main drive for this change is to make something like s7_clone > possible. By using s7_handles one could copy the whole s7 instance > just by doing a memcpy of the s7's storage/heap. I'm attaching some > contrived code of how one could use this feature. > > Another possible win from a change like this would be making s7 > objects smaller => less cache misses. > s7_handle could encode in which storage the underlying s7_cell is > stored (eg using bit fields: 2 bits for storage group, 30 for index) > Like this, s7_cell could be split into separate groups (& underlying > storage), depending in their size. > Since the s7_cell type info is 8 bytes: > - numbers need only 16 more bytes, making them only 24 bytes in total. > - the rest (c-pointers vectors ports etc) could stay together. Right > now s7_cell is 48 bytes, but that could go lower since every > s7_pointer (8 bytes) could be replaced with s7_handle (4 bytes). > > For reference, this is the article that inspired me: > https://floooh.github.io/2018/06/17/handles-vs-pointers.html > I have also used this technique for a classic tree-like data > structure, where I'm storing everything in a vector, and passing > around indexes instead of pointers. This made copying the whole tree > essentially free (memcpy instead of having to traverse down the tree). > > Looking forward to your input! > > Best, > Christos Vagias > From bil at ccrma.Stanford.EDU Fri Sep 23 13:06:10 2022 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 23 Sep 2022 13:06:10 -0700 Subject: [CM] =?utf-8?q?Idea=3A_using_handles_instead_of_pointers=2C_s7=5F?= =?utf-8?q?clone?= In-Reply-To: References: Message-ID: <61190a5b63340d15114e2047cb812cbd@ccrma.stanford.edu> To expand a bit on Elijah's note: I don't think this will reduce cache misses or make objects smaller. To evaluate anything, you have to access the things being evaluated. Most of the points in the article you mention do not apply to s7 -- s7 manages its own memory, the cells are already packed tightly, etc. In your s7_clone example, having two s7's call a function from one of the s7's is dangerous because you might call s7_free on the source s7; I actually don't know if this would work at all currently. You can't use the s7 heap itself (which seems redundant because the handle is just a pointer to the s7_pointer into the heap), because cells can be removed from the heap (to reduce pointless GC work). The article thinks it can save space by using 32-bit handles, but I have run with 2 billion cells, and if I had a machine with enough memory, I could overflow 32-bits. Newer chips have larger caches -- I've seen 256 MBytes, so cache misses might be solved by newer hardware. When I ran cachegrind, I didn't get the impression that cache misses were a huge problem -- the bigger cache was about 15-20% faster in the cases where it mattered at all. Perhaps you could run with a smaller heap. Why do you need s7_clone? I can call s7_init, load and evaluate some stuff, then s7_free in about 1/2 millisecond. Perhaps you could keep a sort of history in scheme, then evaluate that in the subsequent s7. Or get the functions for the clone from the files loaded in the current s7, and any computed stuff might be passed via the "readable" object->string facility. From bil at ccrma.Stanford.EDU Fri Sep 23 13:17:10 2022 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 23 Sep 2022 13:17:10 -0700 Subject: [CM] =?utf-8?q?Idea=3A_using_handles_instead_of_pointers=2C_s7=5F?= =?utf-8?q?clone?= In-Reply-To: References: Message-ID: <07230119c82c378ac25fec580260b17c@ccrma.stanford.edu> I just noticed your s7_clone is not necessarily making a new s7 instance -- in this case you'll have two views into one s7; if these are in separate threads, the two s7's will be colliding in their use of the evaluator -- it is not thread safe in the sense that any number of threads can be calling into the same s7 instance. There's a note about this in s7.html. And if they aren't in separate threads, you've gained nothing by copying the array of handles, unless I'm missing something. From chris.actondev at gmail.com Sat Sep 24 05:51:11 2022 From: chris.actondev at gmail.com (Christos Vagias) Date: Sat, 24 Sep 2022 14:51:11 +0200 Subject: [CM] Idea: using handles instead of pointers, s7_clone In-Reply-To: <07230119c82c378ac25fec580260b17c@ccrma.stanford.edu> References: <07230119c82c378ac25fec580260b17c@ccrma.stanford.edu> Message-ID: Thank you both for your responses and insight! I was thinking of trying to make this change myself, but after your comments perhaps I'll not. It's still something though that in the long term I'd like to try (given plenty of free time!) The discussion could end now, but in case you're interested I'd like to clarify some things. To Elijah: I didn't get your comment of "limit the heap to 1b objects". Perhaps it's coming from my mistake when writing "s7_cell heap[INITIAL_HEAP_SIZE]". Should be "s7_cell heap[INITIAL_HEAP_SIZE*sizeof(s7_cell)]". A bit more comments on the way the objects would be stored. As it is now, as far as I understand, s7's heap is contained by numerous s7_cell[] blocks. This is because when the heap needs to grow a new block needs to be allocated (when the existing ones are full). In this new scheme (pun not indented), s7's heap just grows with a simple realloc. An example with cons (simplified): Simplified heap: [nil, number(1), number(2), cons_a] cons_a being (1 . ()): C representation: (car and cdr being now s7_handles instead of pointers) {.car : number(1) // heap index 1, .cdr: nil // heap index 0 } Addressing Bil's 2 comments about the s7_clone example and the "2 views of s7". Let's assume the above heap of s7 instance 1, and s7_clone gives us s7 instance 2. Instance 2's heap would be a copy of instance 1's heap. So, in c side if we have an s7_handle for cons_a (obtained by s7 instance 1), it'd be just {.index: 3}. After cloning, the same s7_handle could be used in the cloned s7 instance 2, even if the original s7 instance 1 has freed up cons_a. Instance 2's heap will still have cons_a in index 3. Similarly in the s7_clone example I provided, the "fn" is just a handle, an index to s7_heap. s7_clone gives back a new s7 with its own heap, but the referenced "fn" will be stored in the same index in its heap. Calling s7_call in sc1 and sc2, each 1 will use their own stored version of the reference s7 function. Of course it gets more complicated with symbols, functions etc, since there are references to char* strings. Only if those were also stored similarly (as indexes in some storage) then s7_clone could give completely independent instances. And last but not least, c_objects is another complex beast regarding the c_object lifetime and gc cleanup. On Fri, 23 Sept 2022 at 22:17, wrote: > > I just noticed your s7_clone is not necessarily making a new > s7 instance -- in this case you'll have two views into > one s7; if these are in separate threads, the two s7's > will be colliding in their use of the evaluator -- it > is not thread safe in the sense that any number of > threads can be calling into the same s7 instance. > There's a note about this in s7.html. And if they aren't > in separate threads, you've gained nothing by copying > the array of handles, unless I'm missing something. > > From elronnd at elronnd.net Sat Sep 24 17:13:58 2022 From: elronnd at elronnd.net (Elijah Stone) Date: Sat, 24 Sep 2022 17:13:58 -0700 (PDT) Subject: [CM] Idea: using handles instead of pointers, s7_clone In-Reply-To: References: <07230119c82c378ac25fec580260b17c@ccrma.stanford.edu> Message-ID: <47367c3-344e-4797-6478-befc5daa8dd@elronnd.net> On Sat, 24 Sep 2022, Christos Vagias wrote: > I didn't get your comment of "limit the heap to 1b objects". A handle is an int--that is 32 bits--and you want to steal 2 bits for tagging. 2^30 is approximately a billion. From k.s.matheussen at gmail.com Mon Sep 26 08:41:12 2022 From: k.s.matheussen at gmail.com (Kjetil Matheussen) Date: Mon, 26 Sep 2022 17:41:12 +0200 Subject: [CM] Idea: using handles instead of pointers, s7_clone In-Reply-To: References: <07230119c82c378ac25fec580260b17c@ccrma.stanford.edu> Message-ID: Hi Christos, Thank you for bringing up the topic and for creating an interesting discussion. My thought is that using handles (or pointers to pointers) gives a lot of possibilities to automatically compact memory or improve the garage collector in various ways, maybe so much that it's worth the cost of handling the handlers. For instance, one thing that supposedly (and probably also in reality) sets down the performance of Lisp, is the extensive use of linked lists instead of vectors. By using handles (or pointers to pointers), it's probably possible some way to rearrange the memory so that it looks like a linked list on the outside. For example by using another bit for tagging. If this bit is 1, the "cadr" element of a pair would be positioned on the next memory. Although CPU caches are large in current computers, you always risk cache misses, and especially in a library that is meant to be used as an extension language.