IRC channel logs


back to list of logs

<mark_weaver>didi: no
<didi>mark_weaver: Oh. That's unfortunate.
*didi hates thread primitives
***ijp is now known as GNU-ijp
<DeeEff>dsmith-work: installing from source
<nalaginrut>morning guilers~
<zacts>mark_weaver: also, I'm still waiting to hear back from kwm on the FreeBSD side of things, in regards to porting guile2.
<zacts>he has been busy lately, apparently
<mark_weaver>such latencies are not unusual in volunteer projects; I see no reason for concern at this point.
***GNU-ijp` is now known as ijp
<mark_weaver>the important thing is that the recipes are in good shape and hopefully ready to include.
<b4283>nalaginrut: nice introduction to r7rs, haha
<mark_weaver>nalaginrut: it's not true that #e converts it to an inexact number. rather, it makes sure that it was never inexact to begin with. #e2e3 is not equivalent to (inexact->exact (* 2.0 (expt 10 3))), but rather to (* 2 (expt 10 3))
<nalaginrut>mark_weaver: but 2e3 is 2.0*10^3, right?
<nalaginrut>my understand is #e convert it to exact, no?
<mark_weaver>an example of where this makes a difference is when the number you typed cannot be represented exactly as an IEEE double, for example a number that is too large or too small, or something that's.
<mark_weaver>#e makes it so that the entire conversion is done exactly, without anything ever being inexact.
<nalaginrut>yes, I can understand you
<mark_weaver>or something that's not representable in binary, such as 1/10.
<nalaginrut>mark_weaver: but do you think it's an optimization that treat 2 as exact directly? rather than convert it from inexact?
*nalaginrut is modifying the post
<mark_weaver>I'm sorry, I don't understand what you just wrote.
<nalaginrut>mark_weaver: I guess inexact->exact is eliminated because of optimization, no?
<mark_weaver>nalaginrut: but to see an example of why it's important to never use inexacts in the intermediate calculations, try "#e3e-3" vs "(inexact->exact (* 3.0 (expt 10 -3)))"
<mark_weaver>no, it's not an optimization
<mark_weaver>the reader simply does all the math using exacts.
<mark_weaver>it reads #e3e-3 and basically computes it as (* 3 (* expt 10 -3))
<mark_weaver>so it's doing exact rational arithmetic.
<nalaginrut>mark_weaver: can I thought that #e actually means "treat it as exact", not "convert it to exact from inexact"?
<mark_weaver>well, it instructs the reader to produce an exact rational, instead of an inexact floating point.
<nalaginrut>and I see your example code, I think the problem is that it can't promise the exactness if you convert it from inexact
<b4283>okay, does the <x>e<y> syntax support an inexact as y ?
<ijp>inexact is contegious
<mark_weaver>yes, anytime you use inexacts, it may change the value. if you use only exacts, you are guaranteed that the result is exactly correct.
<nalaginrut>ok, is it proper if I describe #e as "produce an exact number"?
<mark_weaver>nalaginrut: yes
<nalaginrut>thank you very much
<ijp>b4283: try it and see, I think it should
*nalaginrut is modifying...
<mark_weaver>you're welcome!
<mark_weaver>b4283: no, the number after the 'e' must be an exact integer. no decimal point allowed.
<b4283>ijp: i've tried it without r7rs reader, seems like it doesn't
<ijp>mark_weaver: I stand corrected
<b4283>mark_weaver: you know your compiler
<mark_weaver>well, I've worked on this part of the code.
<mark_weaver>(I recently rewrote the number->string and string->number procedures for inexacts)
<nalaginrut>mark_weaver: oh~can you please explain "15##" magic? it's undocumented black magic
<nalaginrut>although it's useless in practical IMO
<mark_weaver>nalaginrut: the original idea was that ## represented unknown digits, so that 15## is equivalent to 1.5e3
<mark_weaver>e.g. if the value came from an experiment and the value is only known to 2 significant digits.
<mark_weaver>however, it was hardly ever used in practice.
<nalaginrut>mark_weaver: is it defined in RnRs? I asked so because I tested in racket/guile/chicken, all meet this feature
<nalaginrut>but Scheme48 treat # as 5, so strange, but intended from code
<mark_weaver>in theory, it could be used in a numeric representation that keeps track of how precisely each value is known.
<ijp>it's not really defined in the rnrs
<mark_weaver>nalaginrut: probably only the first # is treated as 5. the others after that are probably treated as 0.
<mark_weaver>but if you think about it, it makes sense. if the # could be any digit from 0 to 9, then the midpoint is 5.
<nalaginrut>mark_weaver: no, I read the code of scheme48, it's intended converting all # to 5
<nalaginrut>well, looks like some kind of metaphor
<nalaginrut>anyway, even treat it as 0 looks some kind of metaphor ;-P
<ijp>the totality of the specification in the r5rs, as far as I can tell is
<ijp>1) the entry in the grammar for numbers
<ijp>2) the example in number->string
<ijp>3) "It is inexact if it contains a decimal point, an exponent, or a "#" character in the place of a digit, otherwise it is exact"
<nalaginrut>this is done by string->number, and only be mentioned a little in R5Rs (as my article described)
<nalaginrut>the later RnRs never mention this IIRC
<ijp>it shouldn't have been there in the first place
<ijp>if # is supposed to be a standin for an undefined number, then that example was misleading
<mark_weaver>yes, the example is wrong, I think.
<ijp>it would be like having (random 10) => 3 in the standard
<mark_weaver>and indeed, I just checked scheme48, and 15## => 1555
*nalaginrut think 'undocumented black magic' is a proper word
<mark_weaver>anyway, I think the purpose of # was more for human readers than for the computer: a way of avoiding writing '0' when you don't know.
<mark_weaver>scientific notation can be used for the same purpose though.
<nalaginrut>hmm...then let Scheme to guess for you?
<ijp>I don't know about r7rs, but the r6rs did explicitly remove this
<mark_weaver>nalaginrut: it's no different than 1.5e3 vs 1.500e3
<ijp>Appendix E -- Language changes -- # can no longer be used in place of digits in number representations.
<nalaginrut>alright, I believe I read R7Rs carefully last night, there's no any info for this feature. Seems the reason is that it's removed in R6Rs
*nalaginrut should add this note...
<nalaginrut>mark_weaver: I can understand filling 0, but filling 5 is ambiguous
<mark_weaver>nalaginrut: R7RS made support for # in numeric literals optional.
<mark_weaver>it's mentioned in the "Language Changes" section, page 77.
<nalaginrut>ah, I should read it again ;-)
<nalaginrut>mark_weaver: I found another mention: "Support for the # character in numeric literals is no longer required."
<mark_weaver>that's what I was just referring to.
<nalaginrut>I'll add this after my lunch ;-)
<nalaginrut>ijp: would you mind a link exchange with my humble new born blog? ;-)
<ArneBab>and would it be possible to integrate snow packages into guildhall?
<ArneBab>nalaginrut: argl…
<ArneBab>nalaginrut: you should add the minimum required version of guile for this
<ArneBab>(your post)
<nalaginrut>I said 'the latest' vaguely
<ArneBab>and your link changed:
<ArneBab>ah ☺
<nalaginrut>oops, the date changed
<ArneBab>I did not recognize “latest” as version specifier ☺
<nalaginrut>I'll add it
<ArneBab>guile 2.0.11 would ensure that people know whether they can run the code
<ArneBab>otherwise i shudder at |2+3|… the reader is still getting more complex
<nalaginrut>well, I should clear the date option to confirm the date won't be changed
<ArneBab>why do you need |2+3| instead of 2+3?
<ArneBab>just to make it look more complex?
<nalaginrut>yes, it's a chaos code play ;-)
<ArneBab>ok ☺
<nalaginrut>in other word, the purpose of the code is to frighten readers ;-D
<ArneBab>(if you want to drive people crazy who don’t know scheme: (define 2+3 4)(+ 1 2+3) )
<nalaginrut>anyway, it's my brand new blog built with Guile
<nalaginrut>welcome ;-)
<nalaginrut>ArneBab: btw, would you mind a link exchange ?
<ArneBab>I’ll gladly link your blog in a text on guile - my current site does not have a real link exchange section
<ArneBab>but as you know I have two guile articles in the worrks
<nalaginrut>ArneBab: yeah, that's better, but I want to talk something about r7rs, I hope readers can learn something
<atheia>top of the mornin' to all.
<ArneBab>nalaginrut: that would also be a list of interesting articles
<ArneBab>(to link to)
<nalaginrut>seems link exchange is no longer popular nowadays
<nalaginrut>ArneBab: can you point me out your blog link?
<nalaginrut>I want to add it, then I can memorize it
<ArneBab>that’s due to Google, I think - though this means that Google destroys its own information base, because Googles original algorithm used links to find the best sites per topic…
<nalaginrut>thanks, that's one of the utility of link exchange section ;-)
<ArneBab>yes ☺
<ArneBab>nice ☺
<civodul>Hello Guilers!
<artyom-poptsov>Hi civodul
<ArneBab>Hi civodul
***wingo_ is now known as wingo
<wingo>whither civodul
<wingo>gross, we expose string-every-c-code and string-any-c-code in the default environment
<wingo>quite a few gross things in our string code (substring-fill!, substring-move! being duplicates of string-fill! / string-copy!)
<wingo>and of course string-set! :P
<davexunit>ew, mutable strings.
<davexunit>wingo: do you think that strings can be made immutable at some point?
<wingo>depends on our collective desires :)
<wingo>emacs could be a big limit on any immutability goal
<wingo>there's very little string-set! in guile itself
<wingo>about 82 string-[a-z-]+! instances in guile
<wingo>perhaps emacs strings are a separate type though
<wingo>they can only hold bytes and have a bunch of other metadata
<wingo>given that, i think that if we build consensus we could deprecate mutable strings in 2.2
<wingo>so technically it's not hard; just tricky socially :)
<ArneBab>wingo: strings are immutable in python - but that provides lots of tools to make string modification easy without having to mutate them (lots of re-creation via string-slicing).
<ArneBab>wingo: did you see my question on snow and guildhall?
<wingo>i didn't see the question, no
<ArneBab>are snow¹ and guildhall² compatible? ¹: ²:
<ArneBab>if guildhall could be kickstarted with automatically transformed snowballs, it could get more traction right away
<ArneBab>(maybe it could even serve snowballs transparently)
<wingo>no idea; i think snow is pretty dead right now
<wingo>also i wouldn't link our fortunes too much with a cross-scheme effort; that's hard and there are many more ways to fail
<wingo>the problem with guildhall isn't related to snow :) though a good guildhall status mail and such would be welcome
<wingo>we have never used the to my knowledge
<wingo>and there are ongoing questions about the relationship to guix
<wingo>so i invite you to mail guile-user and start a discussion :)
<ArneBab>…if I had the time for an email discussion right now - that’s much harder to do on the side than an IRC discussion ☺
<ArneBab>I used guildhall successfully to install foof-loop
<ArneBab>that’s why I thought that it is current
<ArneBab>for snow my question would be whether the snowballs would easily work in guile
<ArneBab>that would kickstart the number of packages in guildhall
<ArneBab>wingo: sidequestion: Would you like to write a paragraph on Guile Scheme beyond Python?
<wingo>i'm afraid i'm a bit busy; will have to decline
<wingo>thanks for the invitation though :)
<ArneBab>no problem ☺
<ngz`>Out of curiosity. I'd like to learn Scheme (Guile actually) a bit. I wrote quite a lot of Elisp already, so I know my way within parens, but I'm clearly not ready for more advanced concepts. I think I need to read code to understand it more. Do you know any library or program using not too advanced but still idiomatic code that I could browse?
<davexunit>wingo: given what you've said, I think strings in emacs could have their own special type and normal guile strings can be immutable.
<wingo>sounds good to me
<davexunit>I understand that the difficulty lies in how the community will react to such a change.
<wingo>ngz`: hum, good question :)
<davexunit>maybe I'll post to guile-user to get an idea of how welcome such a change would be.
<wingo>ngz`: not sure how idiomatic it is, but parses apache log files
<wingo>it's a suitably restricted use case
<ngz`>wingo: Thank you. It's rather short too, which is good.
*wingo brb
<jbdatko>I noticed that guile-2.0 is not in debian-wheezy for armhf. I downloaded the src, built it and it's working. I'd be happy to help package this (although, I've not package an official debian pkg before)
<jbdatko>It's running on a BeagleBone black
<zacts>jbdatko: nice! that's really cool
<jbdatko>Yeah… I'm trying to make some c extensions for some i2c devices and would *like* to try guile…
<jbdatko>but it was a PITA to compile locally, so it'd be nice if it was in debian :)
<dsmith-work>jbdatko: Ooo. You have one? Still waiting for mine. (beaglebone black)
<davexunit>how many blobs does the beaglebone need to run?
<jbdatko>dsmith-work: Yeah, inventory is tight. I have a couple actually…
<jbdatko>davexunit: Well, Ive seen the claim "no binary blobs"
<jbdatko>davexunit: but the ROM on the AM335x is obviously a blob that boots MLO and then uBoot
<jbdatko>It took a few hours to compile guile-2. I went to bed, so I'm not sure how long
<davexunit>oh. :(
<jbdatko>davexunit: It's better than the Pi… and you couldn't change the ROM anyway. It just loads an address. but yeah: it's properitery AFAIK
<dsmith-work>jbdatko: I was *very* impressed with the available boot options.
<jbdatko>dsmith-work: It's nice b/c it's nearly impossible to brick. You can alwasy boot from the microSD or eMMC.
<jbdatko>I'm tired of writing in C all the time :) So my idea was to make these low level I2C calls as C extensions and then use guile on top of that
<DeeEff>Hey guilers, is there a smart way to extract an entire row or column from a 2D array type? Currently I'm converting to a list, and then back into a vector, but that doesn't sound like the smartest way to go about it, since larger matrices will obviously take forever to convert back and forth between lists and vectors.
<dsmith-work>And ethernet! It can boot from ethernet using it's internal rom.
<jbdatko>dsmith-work: oh yeah, that's nice. Haven't used that yet.
<davexunit>jbdatko: yeah it is a lot better than the pi. (I have buyer's remorse)
<davexunit>my pi just gathers dust on a shelf
<dsmith-work>jbdatko: Yes, Guile extensions, or just use the ffi.
<dsmith-work>Guile has a great C api.
<dsmith-work>*My* pi just eats sd cards.
<jbdatko>That's what I'm learning. The issue I'm having is that I want to open a file descriptor and then call a very specific ioctl function on it
<jbdatko>I'm calling the ioctl command in an extension, and that's working, but I'm trying to return the fd (or port?) back to guile.. and that's tripping me up
<dsmith-work>Do you want to manage opening the fd in guile?
<dsmith-work>And just have the extension do the ioctl?
<jbdatko>I tried that and then passed the FD into the extension, but when I passed it in, I got a bad fd error. Let me find the API I used, mabye it was wrong
<dsmith-work>(see port->fdes )
<dsmith-work>(or fileno )
<jbdatko>Ok, that's probably what I was screwing up. I think I was passing the port in
<jbdatko>I'll have to give it a try later, but the strategy of open fd in guile, have c extenstion call iotcl should be a valid approach?
<dsmith-work>I think so. The alternative is to open it and manage it from C right?
<jbdatko>true. Ok, I'll have to give it another go
<dsmith-work>Will you ever need to use that port from scheme? (other than the ioctl)
<jbdatko>dsmith-work: I'd like to. Once the ioctl is set, I'd like to read / write from that port
<dsmith-work>Oh yeah, then a guile port is the way to go.
<jbdatko>Ok, got it. Passed in (fileno fd) to the c extension. Thanks!