<didi>mark_weaver: Oh. That's unfortunate. *didi hates thread primitives ***ijp is now known as GNU-ijp
<DeeEff>dsmith-work: installing from source <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)) <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. <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 <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>it reads #e3e-3 and basically computes it as (* 3 (* expt 10 -3)) <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"? <ijp>b4283: try it and see, I think it should *nalaginrut is modifying... <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>(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 <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. <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>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) <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 <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. <ijp>I don't know about r7rs, but the r6rs did explicitly remove this <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>mark_weaver: I found another mention: "Support for the # character in numeric literals is no longer required." <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: you should add the minimum required version of guile for this <ArneBab>I did not recognize “latest” as version specifier ☺ <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? <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) ) <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 <ArneBab>nalaginrut: that would also be a list of interesting articles <nalaginrut>seems link exchange is no longer popular nowadays <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 ;-) ***wingo_ is now known as wingo
<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>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>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 guildhall.gnu.org 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 <wingo>i'm afraid i'm a bit busy; will have to decline <wingo>thanks for the invitation though :) <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. <davexunit>I understand that the difficulty lies in how the community will react to such a change. <davexunit>maybe I'll post to guile-user to get an idea of how welcome such a change would be. <wingo>it's a suitably restricted use case <ngz`>wingo: Thank you. It's rather short too, which is good. <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) <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 <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) <dsmith-work>jbdatko: Yes, Guile extensions, or just use the ffi. <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 <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 <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 <jbdatko>Ok, got it. Passed in (fileno fd) to the c extension. Thanks!