IRC channel logs


back to list of logs

<daviid>mark_weaver: it compiles fine against 'git branch -> * (detached from v2.0.10)'
<daviid>will try v2.0.11 later, have to go, bbl
<mark_weaver>daviid: okay, thanks!
<mark_weaver>at this point, it's probably best to just do a git bisect. it's generally the most efficient method once you know a commit that works and another that fails.
<paroneayea>mu-guile is pretty cool
<paroneayea>though I'm only using the builtin stuff :)
<davexunit>heh, just did a funny thing: (dynamic-link "libffi")
<zacts>what is mu-guile?
<davexunit>anyone here use the foreign structs procedures often? make-c-struct, parse-c-struct
<davexunit>I have a struct that contains the following: char proxy_address[256]
<davexunit>I'm not sure how to account for that space.
<davexunit>a list with 256 uint8s in it?
<mark_weaver>davexunit: libffi doesn't support vector types directly, but you can represent structs within a struct. I just need to remember how. probably a sublist.
<mark_weaver>davexunit: so yeah, a list with 256 uint8s is the best option I know offhand.
<davexunit>mark_weaver: thanks
<davexunit>I'll just write some code that converts a string to a list of 256 uint8s.
<davexunit>a bit silly but it will do.
<mark_weaver>yeah, not the most efficient.
<mark_weaver>I suppose another way would be to do pointer arithmetic yourself, and use pointer->bytevector to get access to the proxy_address. less convenient but maybe more efficient.
<davexunit>I actually don't think I need to read the struct, just build it.
<mark_weaver>hmm, I guess a list of 256 uint8s is the thing then. obviously this stuff could use improvement :)
<davexunit>the code isn't performance critical so it will work fine for now.
<civodul>Hello Guilers!
<taylanub>what exactly is the use of `integer-expt'? `expt' seems to fall back to it pretty quickly anyway in the case the power is an integer; is it really useful in Scheme code?
<wingo>it produces exact answers
<wingo>expt doesn't necessarily do that
<taylanub>(integer-expt 2.0 2) => 4.0 here (as for expt), and e.g. (expt 2 2) => 4 (as for integer-expt). what's an example where they differ?
<bipt>i think they can't, since expt calls integer-expt when its arguments are legal integer-expt arguments
<taylanub>hm, I think I'd discourage its use then, for portability (don't laugh :( )
<bipt>my project euler solutions are guile-only, fortunately (:
<bipt>looks like it may come from SCM
<bipt>er, SLIB
<lloda>taylanub: maybe it was useful at a time when expt didn't deal with exactness correctly. You could propose deprecation.
<bipt>in 2001 (commit 0137a31b73db65302aa6081e1096faead7343f49), numbers.c defined both integer-expt and a $expt function that just called pow
<bipt>ice-9/boot-9.scm defined expt which called one of those as appropriate (or did `(exp (* power (log base)))' for negative base)
<bipt>so perhaps they were thought of as separate primitives
<wingo>we should optionally integrate with guile
<wingo>i.e. via a runtime gnutls lookup
<wingo>or perhaps something that allows reusing sessions also...
<dsmith-work>Happy Friday, Guilers!!
<davexunit>dsmith-work: happy friday!
*davexunit updated his Tox bindings last night
<taylanub>the documentation for (round-quotient x y) says it returns Q in X = Q*Y + R, where Q is chosen by rounding X/Y to "the nearest even integer." yet (round-quotient 3 4) returns 1, not 2. the implementation seems to just use `round', and (round 3/4) => 1. am I missing something?
<lloda`>taylanub: maybe it refers to and it's just poorly worded.
<taylanub>lloda: it doesn't do that though. if it's explaining that, then it's explaining it just fine, just doesn't do it
<taylanub>wait .. never mind, I'm stupid. can't do arithmetic right now :P
<daviid>mark_weaver: hello! git bisect follow-up, guile-gnome compiles fine against 'git branch -> * (detached from v2.0.11)'
<taylanub>wow, I actually managed to equate 3/4 with 1.5. brain fried.
<paroneayea>taylanub: go home brain, you're drunk
<paroneayea>that said, I've done worse :)
<daviid>mark_weaver: it fails with git branch '* (detached from eb6ac6e)'
<daviid>i wish i could find a very concise weldone python/guile comparison [i'm aware of this link but it is not what i'm lokking for], hint/links welcome
<mark_weaver>daviid: if you could use "git bisect" to find the exact commit that introduced the problem, that would be super helpful!
<daviid>mark_weaver: th's what i'm doing, noing trying '* (detached from e0da53b)'
<mark_weaver>taylanub, lloda: I wrote that, and I agree it's poorly worded, sorry about that. I'll try to remember to fix it before 2.0.12
<mark_weaver>I meant "rounding to the nearest integer, with ties going to the nearest even integer", or something to that effect. (suggestions for wording are welcome)
<taylanub>mark_weaver: actually I don't think it's poorly worded. I understood what it meant, and wrongly thought it doesn't do what it says it does.
<mark_weaver>oh wait, now that I look at the docs, it seems fine, and not what you quoted above.
<mark_weaver>it says "and Q is X/Y rounded to the nearest integer, with ties going to the nearest even integer."
<taylanub>indeed, I quoted it wrong. sorry for the confusion
<mark_weaver>no worries :)
<daviid>this looked interesting but unavailable
<DeeEff>daviid: why are you trying to find comparisons between scheme and python?
<daviid>DeeEff: that's not a good link :)
<DeeEff>what? I haven't linked anything.
<DeeEff>( ???)
<daviid>tx but ... URL cannot be shown
<DeeEff>you can't open it?
<daviid>tah'ts right i can not open it
<DeeEff>enjoy the google webcache
<daviid>using epiphany
<daviid>ah thanks that 1 worked
<DeeEff>well no wonder, I don't think epiphany supports ftp://
<daviid>DeeEff: tx, but that link is really not good enough. i'm saying this to not having other guilers who would think of other possibility to compare to let me know... and I said scheme/python but i realize it really should be guile/puthon, because of the unumbered superior capabiblites of guile against 'just' scheme, goops being the principal one [for me]...
<taylanub>do we not have a logarithm function for arbitrary bases? log is natural, log10 is 10. R7RS log takes an optional base argument but ours doesn't seem to
<taylanub>apparently neither does e.g. <math.h>. I guess it's less common than I thought (that being said, R7RS-small has it)
<daviid>mark_weaver: it compiles fine againt '* (detached from e0da53b)', now trying * (detached from a7ee7f7)
<DeeEff>taylanub: you can make a log of arbitrary bases: (/ (log n) (log base))
<taylanub>ah, didn't know that
<mark_weaver>taylanub: R6RS has a two-argument 'log' procedure, but the core doesn't. you have to do (/ (log x) (log base))
<mark_weaver>and as you say, R7RS also has it.
<DeeEff>I don't believe any (mainstream at least) language provides logs of arbitrary bases
<mark_weaver>ah, should read the entire backlog before answering :)
<DeeEff>indeed :)
<mark_weaver>there is one advantage to two-argument log over the division formula: it can be made more precise, and in the unusual case of scheme with its exact arithmetic, it's even possible to sometimes return exact rational answers when the base is rational.
<mark_weaver>for example, it would be nice for (floor (log n 10)) to always be correct, never off-by-one, and that's certainly doable if you provide a two-argument log.
<mark_weaver>hmm, well, I take that back. it's not always possible. you need a dedicated log-floor procedure to do it.
<DeeEff>I suppose, but I don't think most logarthimic algorithms worry about that tbh, since you tend to multiply by rational numbers anyways (limits, derivatives, etc)
<mark_weaver>(it's not uncommon to use log10 to compute the number of decimal digits, but that's not a good method)
*mark_weaver goes afk
<paroneayea>daviid: python's winning feauture these days is its ridiculously robust stdlib though :)
<paroneayea>not just stdlib
<paroneayea>3rd party libraries too
<paroneayea>especially, even
<DeeEff>I would argue that 3rd party libraries aren't robust, but rather that there's simply so many of htem
<paroneayea>DeeEff: Lots of them are *very* robust, especially in the web development world anyway
<DeeEff>yeah in the data science world I would not argue that they are robust
<DeeEff>try matplotlib for python 3.4 on windows, for instance
<DeeEff>3wtf_am_i_doing.jpg about sums it up
<lloda`>one advantage of having direct (log x base) is that you don't get
<lloda`> spurious warnings such as this one:
<lloda`>>>> import numpy as np
<lloda`>>>> np.log2(0)
<lloda`>__main__:1: RuntimeWarning: divide by zero encountered in log2
<lloda`>(it is understood 0 -> 0.)
<lloda`>sorry, my mistake, since there's no division by 0 anyway; I don't know why numpy does that.
<paroneayea>DeeEff: there's an upside to python's main advantage being the set of libraries written, as far as guile is concerned... assuming guile's community can continue to grow, and a way of distributing 3rd party libraries can grow, it's more likely guile can fill a similar space I think
<paroneayea>case-lambda is pretty swank
<DeeEff>lloda`: you're proving my point about robustness methinks
<DeeEff>not that the code doesn't work, it's just not sane in all cases
<cky>paroneayea: Yes, it's awesomesauce.
<DeeEff>paroneayea: I'd like to see scheme become more ubiquitous, but I have not misplaced any hope in the idea.
<daviid>mark_weaver: it compiles againt '* (detached from e0da53b)', and fails against '* (detached from a7ee7f7)'
<daviid>trying '* (detached from fa1a307)'
<mark_weaver>lloda`: what did you mean by "it is understood 0 -> 0" ?
<mark_weaver>daviid: okay, no need for intermediate results, just let me know when you've identified the precise commit :)
<lloda`>mark_weaver: everything is floating point in numpy
<lloda`>well, that's not right. but everything is fixed size type
<lloda`>like 'f64 's32 etc in Guile.
<davexunit>paroneayea: match-lambda is even swanker :)
<mark_weaver>(also see match-lambda*)
<paroneayea>davexunit: hm! looks cool, though not documented in the manual...
<paroneayea>there's an example with the file-system-tree function
<davexunit>oh, that needs to be documented sometime.
*davexunit goes afk for awhile
<daviid>mark_weaver: this is the 'culprit' commit: