<galex|713>How to get only some bits from a port? like not a multiple of 8bits <galex|713>Also, how to use numbers to feed the random-state? what’s its format? I’d like to seed that from /dev/random <ijp>there is no way to get less than a byte from a port <galex|713>ijp: and how to seed *random-state*? can’t understand the “datum” format from random-state->datum <ijp>as for seeding, you probably want random-state-from-platform <galex|713>ijp: random-state-from-platform take it from /dev/urandom, not /dev/random <ijp>I don't think guile's rng is crypto grade anyway, so that's not a problem <galex|713>ijp: is there a library bound to guile that can do that? and provide normal or exp distribution? or should I just hope /dev/urandom+guile-RNG are not predictable enough? <cmhobbs>i've tried to pick up guile twice now but never stuck to it because i tend to get hung on some obscure corner of it and spiral down the rabbit hole. where's the best entrypoint for learning the language? <cmhobbs>ruby pays my bills, common lisp (sbcl) used to pay my bills, perl (though i'm probably rusty), clojure <cmhobbs>and i know a half dozen other languages well enough to be dangerous <cmhobbs>either due to the fact that i haven't used them in ages or i only cracked the surface of them <cmhobbs>i was just curious if there was a general tour of the language. an intro tutorial <cmhobbs>i can probably go back through the reference manual but htat's where i run into trouble. i find shiny objects :D <cmhobbs>also, can i get a guile repl inside emacs without opening a terminal? <galex|713>Hi, is there a way to get a date/calendar place from a time like a year in floating-point format? or from a number of second since EPOCH? <cmhobbs>for what it's worth, i think "teach yourself scheme in n days" might be a good structured intro <masoudd>cmhobbs: I went through it. But I still have no idea how to write useful programs in scheme <cmhobbs>currently trying to read an opml file with sxml but it's nuts because opml isn't technically valid xml i don't think <masoudd>Nowhere in "teach yourself scheme..." it teaches how to use external libraries <cmhobbs>is there a way to memoize a value? i seem to recall something for define but it only gets called once <cmhobbs>i thought it was let but i don't recall <cmhobbs>if you call a variable set with define, it'll evaluate everytime, yes? <masoudd>cmhobbs: Do you mean like in (define x (thunk)) (display x) (display x) thunk will be evaluated more than once? <ijp>you can use delay & force <cmhobbs>yeah, i'd like it to be evaluated only once <cmhobbs>but i think i figured out a better way <cmhobbs>gotta figure out how to get access to sxpath, though <mark_weaver>galex|713: file and stream I/O on POSIX, and most other systems, is defined in terms of bytes, not bits <mark_weaver>you could certainly convert that to a stream of bits, if you choose a bit ordering convention <mark_weaver>cmhobbs: delay and force ensure that the expression passed to force is evaluated at most once <cmhobbs>i'm trying to figure out how to translate xpath to sxpath now <cmhobbs>can't seem to select individual child nodes <cmhobbs>but with a little effort, i'll get there <mark_weaver>I recommend using the srfi-45 versions of delay, force and related bindings <lfam>I'm trying to do something like this: (date->string (time-utc->date (make-time time-utc 0 (getenv "SOURCE_DATE_EPOCH"))) "~Y ~m ~d") <lfam>But, (getenv) returns a string, "1" <cmhobbs>mark_weaver: i got that far, but i'm trying to get to individual children <lfam>While (make-time) expects an unquoted 1 <cmhobbs>sxpath.scm is pretty well documented, though <lfam>(locale-string->integer) looks like the right thing <mark_weaver>cmhobbs: sxpath returns a list of matches. you might consider using (ice-9 match) on that list <mark_weaver>for example, here's a procedure that, given an rss feed (as sxml), returns the channel, enforcing that only one may be present: <mark_weaver>I probably should have used _ instead of x on that last line <mark_weaver>if I were paying more attention to efficiency, I would arrange for (sxpath '(channel)) to be evaluated only once <mark_weaver>lfam: we schemers usually use the portable 'string->number' in cases like that <cmhobbs>my exercise here is to extract the feed urls from an opml file. right now i'm stuck on getting the sxpath right to get to the urls <lfam>mark_weaver: I'd just found it :) <cmhobbs>mark_weaver: yeah, that's what i'm trying to nail down <cmhobbs>hell, i'd settle for a single child at this point <mark_weaver>cmhobbs: I found this in my code: ((sxpath '(enclosure @ url)) item) <cmhobbs>it doesn't seem to honor the node[n] syntax <cmhobbs>using [n] on anything, i get sxml/xpath.scm:459:18: In procedure car: Wrong type argument in position 1 (expecting pair): 1 <mark_weaver>cmhobbs: it would be more helpful to provide us with scheme expressions that you tried <cmhobbs>i need to trim down this opml file first, thought <cmhobbs>it's pretty big, which makes things cumbersome :D <cmhobbs>alright, i'll set up a paste, hold on <mark_weaver>if you're looking to access a child by index, that's not something I've wished to do. I'm not sure how that can be used in robust code <cmhobbs>in fact, i'd like to get @xmlUrl out of each of those outline nodes <cmhobbs>i hate it when i'm heavily focused on coding and then jump over to my browser only to find the emacs keybindings make the internets do weird things <cmhobbs>i'm in too many channels to use erc, heh <mark_weaver>cmhobbs: (define feed-sxml (call-with-input-file "/home/cmhobbs/gpodder.opml" xml->sxml)) <mark_weaver>well, it avoids storing the entire contents of the file as a string <mark_weaver>but it ends up passing a port to 'xml->sxml' instead of a string <mark_weaver>also, it closes the file immediately after 'xml->sxml' returns, whereas yours doesn't explicitly close the port, leaving it to the garbage collector.. which might be okay, but unfortunately file descriptors are sometimes in short supply <cmhobbs>yeah, this was an issue i had previously <cmhobbs>geiser was getting unhappy when i was using a much larger opml file <cmhobbs>i wasn't sure how to close it the way i had it previously written <mark_weaver>anyway, the "outline[1]" syntax is certainly wrong, but I'm not sure off-hand how that should be written. <cmhobbs>(define outline-matcher (sxpath '(// opml body outline @ xmlUrl))) is getting me all the xmlUrls <cmhobbs> yeah, so: /opml/body/outline[1] should get the first outline <mark_weaver>well, just remove the "[1]" from the sxpath call, and use 'match' to select the first item in the list <cmhobbs>the bit i just pasted returns nice results as well <ijp>In sxml, I think you just give the number to specify a child? <cmhobbs>ijp: i gave just a number but it says invalid step <ijp>oh well, it's been so long since I've used it <mark_weaver>and you might add other cases like the empty list (no matches) <cmhobbs>i guess i'll try tinkering with match <cmhobbs>can i scoot lists around in guile? is there car/cdr and friends? <cmhobbs>scheme@(guile-user) [1]> (cdr (car (outline-matcher feed-sxml))) <ijp>can you use *text* to get the text? <cmhobbs>time to define a recursive function, hehe <mark_weaver>there is 'car' and 'cdr' also, but they can be misused <ijp><aside>there is also the sxml matcher</aside> <mark_weaver>sometimes they are appropriate, but more often it is better to use higher-level facilities for list processing <cmhobbs>ijp: i'm not familiar with any of this. i'm just getting my feet wet with guile <cmhobbs>i'll look into the reference manual for map <mark_weaver>cmhobbs: and more generally, I would look at the srfi-1 section of the guile manual <cmhobbs>working on mapping those strings now <cmhobbs>if i can get a list of those strings, i think i'm golden <mark_weaver>cmhobbs: just add 'xmlUrl' to the end of the list passed to sxpath, maybe? <cmhobbs>(define outline-matcher (sxpath '(// opml body outline @ xmlUrl))) <mark_weaver>cmhobbs: (match <your-list-here> ((('xmlUrl urls) ...) urls)) <ijp>... xmlUrl *text*) works <ijp>to select children you need to do (tag n) <ijp>i.e. the subcomponent is a list <ijp>I knew it was something like that, but I needed to check the code <ijp>cmhobbs: it indicates I was too lazy to type the rest <mark_weaver>cmhobbs: the pattern (('xmlUrl url) ...) matches a list of elements of the form (xmlUrl <url>), and it binds the variable 'url' to a list of those <url>s <ijp>(let ((wibble '((splat 3) (pzzit 4) (gronk 5)))) (match wibble (((tag value) ...) (list tag value)))) -> ((splat pzzit gronk) (3 4 5)) <mark_weaver>cmhobbs: in the pattern, ellipsis here is handled more or less the same as it is in macros <mark_weaver>ijp: thanks for the help and good examples as always, it's good to have you back :) ***C_Keen is now known as C-Keen
<wingo>ecraven: good sir! if/when you have time, guile 2.1.3 would like to play your benchmarks game :) <ecraven>wingo: will do, later today I hope :) <civodul>wingo: what new optimizations would you expect to make a difference? <wingo>civodul: nothing, but previously it was a git checkout <wingo>the only interesting recentish update was char->integer / integer->char optimizations, but which aren't worth all that much without some other things like automatically "switch"-ifying chained conditionals <wingo>but i was just noticing that the git checkout fell off the test for some reason, so having a proper release is a good reason to get it back on :) <mark_weaver>wingo: is there an implementation of SCC in guile master? <mark_weaver>wingo: are there any guarantees about the order of the returned components? <wingo>if you want a sorted order, there is compute-sorted-strongly-connected-components <mark_weaver>I had written my own SCC implementation in my ancient fixing-letrec-reloaded patch, but I'd like to avoid duplicate code <mark_weaver>my code was fast but very ugly, and worked around the limited stack size in 2.0 <wingo>if you did it again, feel free to recurse to your heart's content :) <wingo>only thing is, these apis are somewhat internal to the compiler <mark_weaver>that's okay, my intended use case is in the compiler anyway :) <wingo>i reckon we will have to support them through the 2.2 series but since they are part of the compiler perhaps it's not necessary to support then in e.g. 3.0/2.4/* <wingo>civodul: heya :) if you find yourself with a couple hours for guile hacking, it should be pretty easy to add make-custom-input/output-port to master <wingo>which would unblock gnutls/https in http-get et al <wingo>would be nice to have another eye on the C port internals as well <wingo>taylan: you still waiting on the and-let* patch? <wingo>and other patches! please resend them all :) <wingo>that goes for everyone! anything that needs to go in, send it on, and i'll take a look <civodul>in libguile it would have been somewhat painful <wingo>anyway in master it should be pretty straightforward, the handlers map pretty directly to guile's port functions <civodul>yeah i meant in 2.0's libguile/r6rs-ports.c <wingo>oh neat, apparently upstream libgc has a facility to walk heap objects. <civodul>the paper on heap profiling by Boehm & Serrano relied on a custom patch <civodul>well, it's actually more than just walking the heap <civodul>for some time, i considered implementing a heap-traversal function as a GDB extension <davexunit>guile land is *very* exciting right now. nice to come back from vacation to a new Guile release. <davexunit>civodul: would it be possible for guile 2.2's manual to use the nicer CSS that guix's manual uses? <davexunit>the website hasn't been updated since the announcement <davexunit>I think someone just needs to press the build button and upload the new site with updated news <civodul>davexunit: yes, it just needs to be generated with current Gnulib's gendocs.sh <civodul>wingo: when time permits, could you regenerate the manual with gendocs.sh? ↑ <wingo>civodul: i think only the html version of `master' is hosted on the web site <wingo>but i haven't checked to see if it "took" <civodul>oh but there's SNAFU with the web site CVS update thing <civodul>you know what that means, davexunit ;-) <davexunit>in my short time as a gnu webmaster, I attempted to make the case for ditching CVS for this because it's crazy <civodul>it's been reported to sysadmin@ but it's not always the best approach <davexunit>that's when I realized the webmasters live in the stone age and I wanted out <civodul>stone age was a charming time, too ;-) <ArneBab_>I guess webmasters live in the “it works, don’t touch it or we have to debug again” :) <davexunit>if I could have made real change happen there, I think giving each project access to rsync to their piece of the gnu.org website would have been very nice <davexunit>but the idea of some web pages being things that are programmatically generated and thus not suitable for a version control system was also a controversial topic <wingo>who is the guile 2.0.12 release manager ***dsmith is now known as dsmith-work
<dsmith-work>wingo: When I tried yeasterday, the tarballs were not at the URL's in the release announcement. <wingo>but i tested via wget alpha.gnu.org/gnu/guile/... <wingo>dsmith-work: see mail to list; use http. <wingo>civodul: are there any blockers to releasing 2.0.12 right not? <civodul>but regardless, 2.0.12 is greatly needed, with or without this fix ***profan_ is now known as profan
<wingo>i am going through bug-guile mails right now, knowing that i probably have to go through debbugs later, so i will see that mail in a bit <wingo>i bet with some effort we could get down to a dozen bugs total <wingo>lol at all these acidic mails from david kastrup :P <wingo>does anyone want to update NEWS for us for the 2.0.12 release? :) <civodul>i could take a look later if you want to have a rest, tho <dsmith-work>wingo: Oh is it *so* sweet to have the bootstrap .go file in the tarball. <davexunit>I didn't realize anyone would use my little hack so much <davexunit>which makes me realize that it should be implemented efficiently sometime, with a better data abstraction. <davexunit>guile-syntax-highlight uses a similar sort of parser combinator implementation. <davexunit>I think using SRFI-41 streams, while elegant, is not efficient enough. <davexunit>I don't yet know what should replace them, though. <davexunit>described in the "continuation-passing style" section. <cmhobbs>the single quote starts a symbol, yes? <ijp>short answer yes, longer answer 'foo means (quote foo) and foo may be more complicated than a symbol <cmhobbs>all that messing about with sxml last night was quite an exercise <cmhobbs>i also noticed that paste.lisp.org provides xml links <cmhobbs>i briefly considered building a thing to read those links and eval code from pastes <cmhobbs>not something i'd recommend as a general practice, though <alezost>random-nick: hint: when I need to find such things I search the manual <dsmith-work>random-nick: Starting on an index page (like Concept or Function) <wingo>the easiest way is to install emacs-debbugs <wingo>which on guix you can do with guix package -i emacs-debbugs and then restart emacs <mark_weaver>I have preliminary fixes for some of the filed bugs. need to look through what I have here. <wingo>(setq debbugs-gnu-default-packages '("guile")) <wingo>you refer to fixes you've already submitted or other ones? <wingo>anyway i think anyone can join in <wingo>all 110 of you if you like :) <mark_weaver>I might have some that aren't reflected in the bug tracker yet <wingo>once you have the bug list you can choose a range of 10 or so <wingo>let us know in the channel which ones you are working on or so <wingo>if the bug has a test case to reproduce, see if you can reproduce with stable-2.0; if you can't repro there then it's fixed <wingo>and you can send a mail to NNNN-done@debbugs.gnu.org, where NNN is the bug number <wingo>thanking the person and saying it's going to be fixed in 2.0.12 or has been fixed before or whatever <mark_weaver>I have 5 preliminary bug fix patches in my local stable-2.0 branch that aren't yet pushed <wingo>and if you can still reproduce it, that's valuable too! <wingo>mark_weaver: awesome! we should release 2.0.12 this week <wingo>so, also! if someone wants to make sure NEWS is up to date, anyone can do that <mark_weaver>which seems to only affect solaris. the original reporter never tested my fixes though. <mark_weaver>also a fix for signed integer overflow in numeric conversions <wingo>i'll hold off on any fat_mutex things <mark_weaver>I should just push these, I guess. I almost did a few months ago <mark_weaver>well, my fat_mutex fixes only affects solaris, and the OR never tested my patch <wingo>well, we do what we can then ;) <mark_weaver>although he tested his own different fix that showed what the problem was, anyway. <mark_weaver>(the code was very confusing, making such bugs likely, and I hopefully made it more clear) <mark_weaver>on the FFI 'errno' thing, I got cold feet about whether that was the right approach, or whether we should instead make some guarantees about 'errno' not being modified by low-level scheme operations <mark_weaver>but I guess there's no harm in it, besides adding some complexity to the FFI <mark_weaver>and the LLP64 fixes were probably good, but not sufficient to get LLP64 working. <wingo>btw mark_weaver! have you gotten master to build yet? <mark_weaver>I also built it successfully on mips64el, after applying my ancient patch to change the page size to 64 KiB <mark_weaver>wingo: also, I wanted to thank you for removing the locks from port operations, and the NEWS about it in the latest release. that issue had weighed heavily on me for a long time. <mark_weaver>I'm sorry I've had so little time to work on guile lately. I hope to get my ass in gear soonish though. <mark_weaver>I've been reviewing my old fixing-letrec-reloaded patch, and am thinking about how to generalize it to handle internal 'define-values' efficiently. <mark_weaver>the other blocker on that patch is that it ends up top-sorting the initializers of 'letrec', and yet doesn't yet add any checks to enforce the 'letrec' restriction (accessing the vars before the body is entered), so in its current state, it has the effect of making incorrect code work a lot of the top. <mark_weaver>and I want to make sure we don't end up in a situation where we need to preserve that behavior forever <wingo>mark_weaver: you're welcome, and thanks for the prodding! <wingo>you saved me from having to document all those damned _unlocked procedures :) <mark_weaver>huh, all of the 'documented?' tests are failing for me in my stable-2.0 tree <wingo>yeah i had that problem oddly on a cross-build <wingo>i didn't understand it at all <wingo>maybe no makeinfo or something? dunno <mark_weaver>hmm, yeah. many numeric procedures (implemented in C) are not getting added to guile-procedures.txt <wingo>i wonder when we could release 2.2.0 <wingo>what about next week, that sounds too soon but i don't know why <wingo>i want to drive the bug count down and get more testing <wingo>weird that there are no compiler bugs that i know of at the moment <mark_weaver>I don't think we should do it quite so soon, but I agree that it's time to focus on getting 2.2.0 out. <mark_weaver>from my perspective, the main thing to be careful about is API promises that we effectively make by making such a release <mark_weaver>and also, the time before 2.2.0 is our last chance to make other incompatible changes that would otherwise need to wait until 2.4.0 <mark_weaver>on the other hand, I'm aware that things have been dragging way too much, and I accept the blame for that to a large extent. <wingo>hah! you can't take that blame from me! :) <wingo>we should merge bipt / paroneayea's elisp branch certainly <davexunit>wingo: some anecdotal evidence: 2.1.2 was solid for me while I fiddled with performance hacks and wrote my lisp game jam entry awhile ago. <mark_weaver>my documentation problem turned out to be that some binaries in libguile/* were pointing to shared libraries that no longer exist on my system. making clean in libguile fixed it. <wingo>davexunit: that's good! 2.1.2 had some compiler bugs tho :) <mark_weaver>looks like something that should be fixed before 2.2.0, if it's not already fixed. <mark_weaver>wingo: also, I noticed that emacs-25 now requires C99, so I think we can make the same assumption in guile-2.2. wdyt? <daviid>ACTION also thinks that all bugs releated to goops he sent could[should] be fixed before the 2.2.0 release <wingo>does that mean we get to use uint64_t etc in the API? :-) <wingo>daviid: they're reported, I'm getting to them :) <daviid>wingo: fantastic! thanks for the great work and so much dedication for us, guilers <wingo>in exchange, you can prepare NEWS :) <wingo>just check all the commits since 2.0.11 and make sure they have NEWS entries. no sweat :) <wingo>if they are user-visible changes anyway <wingo>that's great, we have a NEWS volunteer :) <mark_weaver>wingo: C99 includes stdint.h, see section 7.18 of the C99 spec. it looks like the uintN_t types are optional, but uint_least64_t and uint_fast64_t are both required <daviid>wingo: you mean you would like I help preparing NEWS for 2.0.12? [I'am confused because we were talking about goops bugs fix for 2.2.0 <mark_weaver>well, it says that "if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two's complement representation, it shall define the corresponding typedef names" <daviid>have to run, I'll be back in less then 1h <mark_weaver>anyway, I'm sure that quite a bit of compatibility cruft could be removed by assuming C99 <wingo>so nice of you to agree to do it for us :) <daviid>wingo: ok, will try and will let you know, for 2.0.12 then <mark_weaver>some notable things added to C99 include restricted pointers, variable length arrays, and flexible array members <wingo>mixed delarations and code! yesssss <mark_weaver>(i.e. vars don't have to be at the start of a block) <mark_weaver>many other things too, but those seem most interesting for us <mark_weaver>ah, that enables initializers like: int a[6] = { [4] = 29, [2] = 15 }; <mark_weaver>which is equivalent to int a[6] = { 0, 0, 15, 0, 29, 0 }; <mark_weaver>civodul: I was just mentioning to wingo that emacs-25 requires C99, so I think we can add the same requirement to guile-2.2. wdyt? <wingo>only difference is our users might not be c99. but prolly it's ok to require that they upgrade to get guile 2.2 goodness <ft>also: struct foo bar = { .thing = 1, .fish = 23 }; <mark_weaver>among other things, that will give us compound literals, mixed declarations and code, // comments, inline functions, macros with varargs, variable length arrays, flexible array members, and designated initializers <dsmith-work>ACTION wonders what's the minimal gcc version that supports C99 <mark_weaver>wingo: I don't understand the difficult implementing char-ready? properly. it seems to me that char-ready? could be implemented in terms of u8 peek, get, and unget, no? <wingo>because char-ready? should not block <mark_weaver>I agree, it should not block. if it would block, then the result should be #f, and we're done. <wingo>peek blocks; you can't use peek. <mark_weaver>the difference is what we do if the u8-ready? test returns #t <wingo>there is no u8-ready? currently afaiu <mark_weaver>in that case, instead of passing that along as the result of char-ready?, we instead read the byte, and then, based on its value, either return #t or check to see if the next byte is ready. <wingo>char-ready? is just not a good interface. it's possible to do marginally better but i think it's not where we should focus energies <wingo>char-ready? is not an interface on which we should build non-blocking anything <wingo>i am done working on it, if you want to do something different, go ahead and give it a go <wingo>i think it is not a good place to put energy, but it's your energy :) <mark_weaver>yeah, if I pick this up at all, it will be another time... <wingo>these older bugs are the toughest to chew on, yarrrr <ft>mark_weaver: Thanks for taking on the errno thingy in the FFI! \\o/ <wingo>mark_weaver: please forward-port relevant bits to master also. tx in advance :) <mark_weaver>wingo: sorry for the noise about char-ready?. on second thought, I think you're right on all counts. <wingo>mark_weaver: i know what you mean tho, it seems within grasp but then it's a big mess :) <wingo>some of them with nice patches <wingo>just a few more sessions and we can have things down to a nice dozen or two bugs <mark_weaver>thanks for all the awesomeness, wingo. you are truly a marvel