<ruffni>is it possible to get the value of a variable by querying a symbol? reference manual on "Binding Reflections" intends to inform (subtitle: Querying variable bindings) but there's only method (defined?) mentioned.. chapter 6.6.6.3 (Symbols as Denoting Variables) mention unquoting a symbol (but `(unquote 'my-symb)' fails). <daviid>ruffni: there is no "Binding Reflections" entry in the manual, there is a Module System Reflection entry, which has all the answers to your quiz, i thing :) <ruffni>i saw that, but what is this "module" object? <ruffni>is `(chickadee math)' such an object? <daviid>(resolve-module '(chickadee math)) <ruffni>btw sorry, it's referred to as "Binding Reflection" in 6.12 "Definitions and Variable Bindings", but the page is called differently (Querying variable bindings) <Sheilong>I am having trouble to import custom file module <Sheilong><unnamed port>:39:7: In procedure module-lookup: Unbound variable: brute-force-xor <tohoyn>any opinions on the improved statprof (see guile-devel mailing list)? ***janneke_ is now known as janneke
<Sheilong>How do I convert something like this ("49" "43" "45") to this "494345"? I tried with (list->string) but In procedure string: Wrong type (expecting character): "49" <Sheilong>RhodiumToad: I want to concatenate them without adding spaces <Sheilong>RhodiumToad: I just want to convert a string in the hexadecimal representation <Sheilong>well, if I can concatenate those values I am done. <RhodiumToad>you mean, given a string, you want to construct another string of the hex values of the bytes? <RhodiumToad>that's more complex than you think because of encoding <Sheilong>RhodiumToad: acually I am converting it to decimal ascii and then enconding as hexadecimal <RhodiumToad>so the problem there is that characters aren't bytes, and that a character might have a value > 0xFF <mwette>maybe string->pointer, pointer->bytevector, bytevector-ref, number->string <Sheilong>Yeah. I just want to work with raw bytes <Sheilong>It was just a matter of converting the characters of the text to a 8 bit representation. <RhodiumToad>a while back I wrote optimized versions of hex encode/decode of bytevectors <RhodiumToad>in particular, lookups tables for the hex to bytes conversion can give a fair speedup <mwette>sneek: later tell wingo What is JIT_TMP0? <mwette>wingo: what is JIT_TMP0? Is that the arch always-zero register? <RhodiumToad>it's not an always-zero register since many arches don't have one of those *RhodiumToad spent some time grovelling around inside lightening to track down the arm bugs <mwette>Ah. I'm taking a rookie shot at the riscv target. <DadeBonetti>Wrong type argument in position 1: #<primitive-builtin-macro! and> <RhodiumToad>anyway, the "and" of a list is false if and only if the list contains #f, so you could use memq maybe? <RhodiumToad>(assuming you want to treat an empty list as true, which is usually what you want) <rlb>(...or srfi-1 every if you need more flexibility) <ft>There's also ‘every’ in srfi-1. <DadeBonetti>no, (memq and mylist) returns #f even if mylist is '(#t #t #t), so I'm doing something wrong <ft>(every identity '(#t #f #t)) <rlb>(not (memq #f mylist)) <ft>‘every’ short-circuits, btw. When something in the list doesn't fulfil the predicate, it returns #f and disregards the rest. <rlb>wingo: fwiw excise-ltdl (assuming I wasn't accidentally picking the system guile, and I think I probably wasn't) works fine with lokke too. <rlb>civodul, wingo: wondering about https://debbugs.gnu.org/46001 -- it's preventing 3.0.5 from migrating to testing in debian since it sometimes fails on the buildds. Assuming we don't track it down soon, wondered if you have any opinion offhand about the risk of marking it flaky for now. <rlb>Hmm, I guess I could/should try that test loop against the current debian version -- i.e. if it fails there too intermittently, then perhaps I have my answer. <civodul>rlb: oh, that one doesn't ring a bell <civodul>i remember the stack-overflow test is flaky, but i don't remember seeing this one before <civodul>but yeah, maybe you could mark it as such <rlb>First time I saw it was the 3.0.5 upload, but it'd easy to reproduce (see the one-liner in the bug). <Sheilong>(number->string b 16) converts to base 16 but does not add a 0 before the first character <Sheilong>I can't reproduce a string here because this zero is lacking <Sheilong>RhodiumToad: I need to convert a numeric bytevector to a string hexadecimal representation. I can get the same resulting string as here https://cryptopals.com/sets/1/challenges/5 but the 0 at the first position is missing. However, in python with 'hexlify' it does return the string with that 0. I know that zero is meaningless... <RhodiumToad>it's not number->string's job to pad the result or otherwise do formatting <RhodiumToad>you can do the padding yourself in many different ways <rlb>Maybe it was already mentioned, but depending on what you need, (ice-9 format) might also be interesting... <RhodiumToad>e.g. using (ice-9 format), you could use (format #f "~2,0x" b) <RhodiumToad>the code I linked above instead uses a lookup table for performance <Sheilong>RhodiumToad: thanks so much. Sorry for being noob <mwette>Sheilong: if you are doing one at a time you can also do (define (hx->st ch) (vector-ref #("00" "01" ... "FF) ch) ; I think RhodiumToad suggested that, maybe. *mwette is still working riscv port, wondering what happened to jit_node_t *mwette sees that there is lots to do still ... <rlb>Where do we document our versioning policy? I wanted to make sure I follow it, and I *think* we're not being strict with respect to Z releases? i.e. we may well add (and have added) new features in Z releases? <rlb>I guess we just added mkdtemp, without a new Y so perhaps that answers my question... <spk121>rlb: major releases have usually coincided to changes to the VM <rlb>Are you talking about "X" releases or "Y" releases? <rlb>I'm just trying to make sure I understand what's allowed without needing a Y increment. <spk121>1.x was no VM and no unicode, 2.x was VM and unicode 3.x was JIT <spk121>the 2nd level is fuzzier but associated with breaking existing code <spk121>the 3rd level should not break existing code, but, sometimes they do