<spk121>civodul: hmm. Well, it is hard to get m4/autoconf right on the first try <daviid>spk121: fwiw, I received great and friendly help on ##workingset, when i was patching guile-lib to use -O0 for guile-3.0, compile src/md5.scm (only this file ...) <daviid>spk121: not the same problem of course, but as we quickly get rusty when it comes to autotools, worth asking for help there (and #autotools as well) ***nckx[2] is now known as nckx
<rlb>What's a preferred representation for a 128-bit value in guile right now? Just a 128-bit integer, or a homogeneous vector or...? (I forget how 128-bits is arranged by guile/gmp.) <wingo>rlb: depends on how you want to use it -- if you want to use it as an integer or as bytes <wingo>former case would be integer, latter is bytevector <wingo>on 64-bit machines, 128 bits will be two machine words for the data plus an additional 3 or so of overhead <rlb>In this case I was toying with uuids, so bit-ops, so maybe integer? <rlb>(Though easy to manipulate as #u64 too...) ***apteryx is now known as Guest63552
***apteryx_ is now known as apteryx
<leoprikler>does guile have an array->bitvector or int->bitvector function? <lloda>bitvectors are arrays so you can use array-copy! between them <lloda>but this is conversion, not casting <lloda>for bytevectors and arrays there are a bunch of ways to cast contents such as pointer->bytevector, or scm_take_xxx in the C API <lloda>but i don't think there's a way to make a bitvector out of 'memory' <mwette>lloda: Long ago I submitted a bug report asking for more bitvector routines, but later closed it. If important to you maybe open again. I needed bitvector-copy (e.g., copy first 100 bits into new bitvetor sized 200 bits), bitvector-tas, etc. I ended up rolling my own C code. <lloda>wingo refactored the bitvector stuff a few months ago <lloda>so now could be a good time to add stuff <lloda>but slicing can be done with arrays, so imo it's not the best idea to add slice args to every vector type out there <mwette>The slice-copy part for me ended up just wanting to extend a bitvector by 1 bit. I had 10,000 bits and needed one more. <lloda>i miss a -resize sometimes but i'm not sure if it would make sense to have that in the API <lloda>i mean if there's an advantage to use the internals to implement that as opposed to just make- & -copy <mwette>with 32 (now 64) bit increments the chance of adding one bit w/ ~zero cost is 31/32 (63/64) <lloda>if you remember your bug number we could reopen it and have a discussion there <lloda>array-copy from (ice-9 arrays) can be used to copy bitvectors <lloda>the result will be a bitvector <lloda>but really having bitvector-copy looks like a no brainer <mwette>I don't need it anymore, so don't open for my sake. <manumanumanu>mwette: ok, so I see no mention of any limits of the optimizer, at least not in the DCE. I am just curious if it has some kind of limit to how much it does for an expression. An (if #t ...) should be a pretty obvious optimization candidate. <fnstudio>hi! anyone has any recommendation in terms of guile and autotools (in the context of a guile toy project)? i know there's hall, which automates large part of the tasks (and which looks great in many regards), but i think i'd be more interested in a minimalist (and purely manual) approach, to familiarise myself with the mechanism <fnstudio>autotools - or any recommended build mechanism, but i suppose autotools is the recommended one <ruffni>anyhow, reading through "Guile Implementation" in the docs and scripting on a dependency-graph tool i'm wondering where in guile code is (load) defined? where and how is guile-code lexed? i have this strong feeling in my gut that i'm reinventing major parts of the wheel (which is kinda unnecessary) <ruffni>rekado: this doesn't work either <rekado>(with the extra “/guile” removed) <rekado>it looks like the search index is a little outdated, though <wingo>so you know the usual keyword syntax, #:foo <wingo>also the prefix syntax, :foo <wingo>and the postfix syntax, foo: <wingo>but did you know about the spaced-out syntax, #: foo *RhodiumToad actually likes using the postfix syntax and the usual syntax together - #:foo when referring to the keyword "foo" itself, and foo: when actually _using_ the keyword to identify something else <ft>wingo: so you're going for bug-for-bug compatibility, rewriting the reader? :) <wingo>yeah unfortunately, bug-for-bug compat for now <ft>Probably for the better, you never know what depends on all those precious bugs. :) <ft>But I can see how that's frustrating. <rekado>wingo: I met the spaced-out syntax recently when trying to extend wisp for the GWL. Had to scrap it all because it would clash with wisp’s use of “:” as wrapping the rest of the line in parentheses. <wingo>honestly i think it is just a bug and we should fix it <wingo>i am keeping a list of things to fix once i get out of this hole