IRC channel logs

2016-06-20.log

back to list of logs

<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>ok
<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
<galex|713>doc says it’s not for security/crypto
<ijp>I don't think guile's rng is crypto grade anyway, so that's not a problem
<galex|713>ah ok…
<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?
<Petit_Dejeuner>cmhobbs: What languages do you already know?
<cmhobbs>that's quite a list...
<cmhobbs>sticking to "know well"
<cmhobbs>ruby pays my bills, common lisp (sbcl) used to pay my bills, perl (though i'm probably rusty), clojure
<cmhobbs>some dead languages
<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?
<cmhobbs>probably a dumb question
<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?
<Petit_Dejeuner>cmhobbs: geiser is popular
<cmhobbs>Petit_Dejeuner: thanks!
<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>i'm slowly working on that
<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>I started on http://www.scheme.com/tspl4/
<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>ACTION googles "memoize"
<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>i was leaving a port open from it
<cmhobbs>i should close it when i'm done
<cmhobbs>that was the real issue
<cmhobbs>gotta figure out how to get access to sxpath, though
<mark_weaver>galex|713: see srfi-19, a date/time library
<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>cool, thanks
<cmhobbs>i think i got through that
<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
<mark_weaver>something like ((sxpath '(title)) <sxml>)
<mark_weaver>we need better documentation for sxpath
<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
<lfam>Any advice?
<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
<cmhobbs>mark_weaver: good call, thanks
<mark_weaver>yw!
<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>
<mark_weaver>(define (rss-channel rss)
<mark_weaver> (match ((sxpath '(channel)) rss)
<mark_weaver> ((x) x)
<mark_weaver> ((x . xs) (error "More than one channel present"))
<mark_weaver> (x (error "Unable to find channel element"))))
<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
<cmhobbs>hm
<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
<mark_weaver>cmhobbs: (sxpath '(channel)) returns a procedure
<mark_weaver>oh, you want to extract an attribute?
<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>certainly
<mark_weaver>I don't know what you mean by "using [n]"
<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>i'm just tinkering at the moment
<cmhobbs>trying to learn guile
<cmhobbs>mark_weaver: http://paste.lisp.org/display/318807
<cmhobbs>in fact, i'd like to get @xmlUrl out of each of those outline nodes
<mark_weaver>xb
<cmhobbs>emacs fail? :D
<mark_weaver>heh, yes :)
<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))
<cmhobbs>interesting.. what will that change
<mark_weaver>well, it avoids storing the entire contents of the file as a string
<mark_weaver>and I think it looks a bit nicer too, dunno
<cmhobbs>agreed
<cmhobbs>i was unaware of that function
<mark_weaver>but it ends up passing a port to 'xml->sxml' instead of a string
<cmhobbs>great
<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
<mark_weaver>can you remind me what that's supposed to do?
<cmhobbs>it's supposed to select a node
<cmhobbs>so like
<mark_weaver>by index?
<mark_weaver>as in, the first subnode under the 'outline' ?
<cmhobbs> yeah, so: /opml/body/outline[1] should get the first outline
<mark_weaver>well, first child
<cmhobbs>right
<cmhobbs>yep, first child
<mark_weaver>oh, the first outline
<mark_weaver>sounds like you want something like this:
<mark_weaver>well, just remove the "[1]" from the sxpath call, and use 'match' to select the first item in the list
<cmhobbs>interesting
<cmhobbs>the bit i just pasted returns nice results as well
<cmhobbs>((xmlUrl "https://cyberunions.org/feed/") (xmlUrl "http://duffercast.org/feed/podcast/")
<cmhobbs>and so on
<ijp>In sxml, I think you just give the number to specify a child?
<ijp>sxpath*
<mark_weaver>so something like (untested):
<mark_weaver>(match ((sxpath '(// opml body outline)) <sxml>)
<mark_weaver> ((first rest ...) first)
<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>yeah
<cmhobbs>if i could get the strings out of that ((xmlUrl "https://blahblah") ... ) list, that'd be just peachy, too
<cmhobbs>i guess i'll try tinkering with match
<cmhobbs>can i scoot lists around in guile? is there car/cdr and friends?
<mark_weaver>look at srfi-1
<mark_weaver>list library
<cmhobbs>yay!
<cmhobbs>scheme@(guile-user) [1]> (cdr (car (outline-matcher feed-sxml)))
<cmhobbs>$7 = ("https://cyberunions.org/feed/")
<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
<mark_weaver>e.g. things like 'map' and 'fold', etc.
<cmhobbs>i'll look into the reference manual for map
<mark_weaver>ijp: ah, good point! I forgot about (sxml match)
<mark_weaver>cmhobbs: and more generally, I would look at the srfi-1 section of the guile manual
<cmhobbs>that's where i'm digging right now
<cmhobbs>i'm much closer than i was before: http://paste.lisp.org/display/318811
<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>maybe
<cmhobbs>(define outline-matcher (sxpath '(// opml body outline @ xmlUrl)))
<cmhobbs>is the sxpath
<mark_weaver>oh, right, nevermind
<mark_weaver>cmhobbs: (match <your-list-here> ((('xmlUrl urls) ...) urls))
<mark_weaver>returns a list a strings
<mark_weaver>*list of strings
<ijp>... xmlUrl *text*) works
<mark_weaver>ah, even better!
<ijp>to select children you need to do (tag n)
<ijp>i.e. the subcomponent is a list
<cmhobbs>what does the elipsis do?
<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
<cmhobbs>no, i meant in mark's example
<ijp>oh, repetition
<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
<cmhobbs>great, thanks
<cmhobbs>this is very workable
<cmhobbs>i really appreciate the help!
<cmhobbs>on that, i need to get some sleep
<cmhobbs>take care, folks
<mark_weaver>you're welcome!
<mark_weaver>sleep well
<mark_weaver>ijp: thanks for the help and good examples as always, it's good to have you back :)
<ijp>no worries
<civodul>wingo: hurray for 2.1.3! \\o/
<wingo>civodul: :)
***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 :)
<wingo>great
<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 :)
<civodul>indeed, makes sense :-)
<mark_weaver>good morning!
<mark_weaver>wingo: is there an implementation of SCC in guile master?
<mark_weaver>(strongly-connected components)
<civodul>hello mark_weaver!
<wingo>yes there are two iirc
<wingo>or maybe just one
<mark_weaver>where?
<wingo> http://git.savannah.gnu.org/cgit/guile.git/tree/module/language/cps/utils.scm#n390
<mark_weaver>wingo: excellent, thank you! :)
<wingo>np :)
<mark_weaver>wingo: are there any guarantees about the order of the returned components?
<wingo>no
<wingo>if you want a sorted order, there is compute-sorted-strongly-connected-components
<wingo>which follows
<mark_weaver>ah!
<mark_weaver>thanks :)
<wingo>np :)
<wingo>these implementations follow from http://www.cs.umb.edu/~offner/files/flow_graph.pdf
<mark_weaver>I had written my own SCC implementation in my ancient fixing-letrec-reloaded patch, but I'd like to avoid duplicate code
<wingo>ACTION nod
<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 :)
<mark_weaver>yeah, that was terrible
<mark_weaver>so nice to have this fixed so nicely in 2.2 :)
<wingo>:)
<wingo>only thing is, these apis are somewhat internal to the compiler
<wingo>and they use intmaps
<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>coolio :)
<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>wingo: ok, noted!
<civodul>in libguile it would have been somewhat painful
<wingo>i guess you mean stable-2.0
<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>woow, at last!
<civodul>that's awesome
<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.
<paroneayea>ooh
<davexunit>paroneayea: typo in the tweet. it's 2.1.3
<davexunit>sincerely, friendly nitpick guy.
<davexunit>civodul: would it be possible for guile 2.2's manual to use the nicer CSS that guix's manual uses?
<davexunit>IIRC that's a gnulib thing?
<paroneayea>davexunit: oh no
<paroneayea>I looked at the guile news
<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>right?
<civodul>ah maybe, dunno
<wingo>i did update 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
<wingo>i did the cvs commit
<civodul>for the last few days already
<wingo>yeah
<davexunit>ohhh
<davexunit>that would explain it
<civodul>you know what that means, davexunit ;-)
<dsmith>Morning Greetings, Guilers
<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
<civodul>it still is :-)
<davexunit>but it was met with a resounding "no"
<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>soooo
<wingo>who is the guile 2.0.12 release manager
***dsmith is now known as dsmith-work
<dsmith-work>Monday Greetings, Guilers
<paroneayea>morning
<dsmith-work>wingo: When I tried yeasterday, the tarballs were not at the URL's in the release announcement.
<wingo>i did test downloading them
<dsmith-work> https://alpha.gnu.org/gnu/guile/ does not have them..
<wingo>but i tested via wget alpha.gnu.org/gnu/guile/...
<wingo>i.e. without the https
<wingo>dsmith-work: see mail to list; use http.
<dsmith-work>Ahh!
<dsmith-work>Ok. But the announcement does have:
<dsmith-work>Here are the compressed sources:
<dsmith-work> https://alpha.gnu.org/gnu/guile/guile-2.1.3.tar.gz (17MB)
<dsmith-work> https://alpha.gnu.org/gnu/guile/guile-2.1.3.tar.xz (10MB)
<dsmith-work>ACTION get the file.
<dsmith-work>s
<wingo>civodul: are there any blockers to releasing 2.0.12 right not?
<wingo>*now
<civodul>wingo: it would be nice to address http://bugs.gnu.org/20272 for which mark_weaver contributed a patch already
<civodul>so thumbs up if you can review it
<civodul>but regardless, 2.0.12 is greatly needed, with or without this fix
***profan_ is now known as profan
<wingo>that looks tricky to review
<civodul>your call!
<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
<davexunit>as expected
<civodul>heh
<wingo>does anyone want to update NEWS for us for the 2.0.12 release? :)
<civodul>ahem
<civodul>ACTION needs to rush back home :-)
<civodul>i could take a look later if you want to have a rest, tho
<random-nick>I don't get POSIX sockets :/
<random-nick>I am tempted to pipe telnet into my program
<dsmith-work>wingo: Oh is it *so* sweet to have the bootstrap .go file in the tarball.
<dsmith-work>files
<dsmith-work>wingo: 7m39 for my 64bit work machine. Woo
<davexunit>amz3: cool article! http://hyperdev.fr/notes/getting-started-with-guile-parser-combinators.html
<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>I would also like to unlock the GLL parsing abilities of https://github.com/epsil/gll
<davexunit>described in the "continuation-passing style" section.
<cmhobbs>the single quote starts a symbol, yes?
<davexunit>it quotes the form that follows
<ijp>short answer yes, longer answer 'foo means (quote foo) and foo may be more complicated than a symbol
<cmhobbs>ok, cool
<cmhobbs>thanks
<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>would be a fun experiment
<cmhobbs>not something i'd recommend as a general practice, though
<cmhobbs>naturally
<random-nick>in what module is read-line?
<mark_weaver>(ice-9 rdelim)
<cmhobbs>(ice-9 rdelim)
<cmhobbs>yeah
<cmhobbs>that
<random-nick>thanks
<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>moo
<wingo>so!
<wingo>let's squash some bugs
<wingo>anyone can play along!
<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>then add to your .emacs
<wingo>(setq debbugs-gnu-default-packages '("guile"))
<wingo>then M-x debbugs-gnu
<wingo>mark_weaver: excellent!
<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
<mark_weaver>will do
<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!
<mark_weaver>one to add support for 'errno' to the FFI
<wingo>mark_weaver: awesome! we should release 2.0.12 this week
<mark_weaver>one for LLP64 fixes
<wingo>so, also! if someone wants to make sure NEWS is up to date, anyone can do that
<mark_weaver>one for the fat_mutex owner corruption
<wingo>patches welcome
<mark_weaver>which seems to only affect solaris. the original reporter never tested my fixes though.
<wingo>mark_weaver: the fat_mutex thing, is it related to http://debbugs.gnu.org/10225?
<mark_weaver>also a fix for signed integer overflow in numeric conversions
<wingo>maybe not
<mark_weaver>no, it's for bug 22152
<mark_weaver>(the fat_mutex thing)
<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
<wingo>what held you back?
<mark_weaver>well, my fat_mutex fixes only affects solaris, and the OR never tested my patch
<wingo>ah :)
<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>but I fixed it in a better way, I think
<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>the FFI API, I mean
<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>oh yes, I did, thank you!
<wingo>great :)
<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>a lot of the time
<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>heh :)
<mark_weaver>huh, all of the 'documented?' tests are failing for me in my stable-2.0 tree
<mark_weaver>maybe 'make' is failing to rebuild something.
<mark_weaver>ACTION rebuilds guile-procedures.txt
<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
<mark_weaver>where's the makefile for guile-procedures.txt?
<mark_weaver>nvm, got it
<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>:)
<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
<wingo>ACTION tempts fate
<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
<wingo>yep
<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
<wingo>yep
<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
<mark_weaver>:)
<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>ACTION pushed some old fixes to stable-2.0
<mark_weaver>wingo: what ever happened with bug 18604 ?
<mark_weaver>looks like something that should be fixed before 2.2.0, if it's not already fixed.
<wingo>ACTION looks
<wingo>need to fix it!
<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?
<wingo>yes!!!!!!!!!!!!!
<daviid>ACTION also thinks that all bugs releated to goops he sent could[should] be fixed before the 2.2.0 release
<wingo>that's great
<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"
<mark_weaver>(referring to intN_t and uintN_t)
<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>daviid: yep :)
<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
<wingo>excellent!
<wingo>ACTION evil coercion
<mark_weaver>some notable things added to C99 include restricted pointers, variable length arrays, and flexible array members
<mark_weaver>compound literals
<mark_weaver>mixed declarations and code
<wingo>mixed delarations and code! yesssss
<mark_weaver>(i.e. vars don't have to be at the start of a block)
<mark_weaver>macros with varargs
<mark_weaver>inline functions
<wingo>sorta inline functions
<mark_weaver>heh :)
<wingo>iirc they are not a panacea
<mark_weaver>__func__ predefined identifier
<mark_weaver>and // comments
<mark_weaver>many other things too, but those seem most interesting for us
<mark_weaver>"designated initializers", whatever that means
<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 };
<wingo>i closed 11 bugs today!
<ft>Whoo!
<mark_weaver>nice!
<civodul>mark_weaver: sounds good to me
<mark_weaver>excellent!
<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
<mark_weaver>and also things like stdint.h, etc
<civodul>what a nice language ;-)
<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>no
<wingo>because char-ready? should not block
<wingo>is the point
<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.
<mark_weaver>we have it, but under the wrong name :)
<mark_weaver>or at least I thought we did, maybe I'm wrong?
<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
<mark_weaver>well, I agree it's a bad interface
<mark_weaver>but for some simple programs it's okay
<wingo>i am done working on it, if you want to do something different, go ahead and give it a go
<mark_weaver>fair enough! :)
<wingo>i think it is not a good place to put energy, but it's your energy :)
<mark_weaver>you're probably right about that too
<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/
<mark_weaver>np :)
<mark_weaver>sorry for the long delay
<wingo>mark_weaver: please forward-port relevant bits to master also. tx in advance :)
<mark_weaver>will do
<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>we resolved 17 bugs today!
<wingo>some of them with nice patches
<wingo>high fives all around
<mark_weaver>\\o/
<wingo>just a few more sessions and we can have things down to a nice dozen or two bugs
<wingo>that would be nice
<mark_weaver>thanks for all the awesomeness, wingo. you are truly a marvel
<mark_weaver>I really hope to get more productive again soon