IRC channel logs


back to list of logs

<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>these are unsafe tho
<lloda>but i don't think there's a way to make a bitvector out of 'memory'
<lloda>in the public API that is
<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
<mwette>lloda: 29845
<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.
<dsmith-work>Hey Hi Howdy, Guilers
<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>hmm.. says: Resource not found: when searching for a string
<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)
<rekado>ruffni: it’s a faulty redirect to
<rekado>(there’s an extra “/guile”)
<ruffni>rekado: this doesn't work either
<rekado> certainly works
<rekado>(with the extra “/guile” removed)
<rekado>it looks like the search index is a little outdated, though
<ruffni>nvm got it
<wingo>good evening
<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
<ft>Gold. :)
*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
<RhodiumToad>(e.g. init-keyword: #:mything )
<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.
<rekado>it’s bug 45914
<wingo>rekado: tx for that
<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
<wingo>> #@-(1 2 3)
<wingo>$3 = #(1 2 3)
<davexunit>is the reader being rewritten?
<davexunit>C -> scheme, I presume?