IRC channel logs

2014-07-31.log

back to list of logs

<mark_weaver>:)
<rlb>does anyone here know if it's possible to combine EPL and LGPL works, i.e. distributing EPLed libs that depend on guile -- or EPLed guile modules?
<rlb>(I know EPL/GPL are incompatible.)
<mark_weaver>you might want to ask RMS directly
<mark_weaver>if I had to guess, I'd be surprised if it would violate the LGPL, but I'm not sure whether or not it would violate the EPL.
<mark_weaver>if you prefer, I can ask him myself.
<rlb>sure if you don't mind.
<mark_weaver>okay
<rlb>And thank -- for anyone who cares, I was just speculating about the possibility of various levels of clojure support for guile -- everything from a new dialect to just bringing over useful libraries/features in a more piecemeal manner. There are certainly situations when a clojureish/guile might work better for me than clojure/jvm.
<rlb>s/thank/thanks/
<rlb>s/was just/have been/
<rlb>And of course the job would probably be much harder (to near impossible) if you can't combine EPLed code and guile code at all.
<mark_weaver>I would like to add more data structures inspired from clojure.
<rlb>mark_weaver: right -- and if we had a guile-clojure-core, we might be able to reuse various bits of clojurescript (and/or clojure/jvm)
<rlb>(and other attendant libs)
<rlb>clojurescript's a lot more likely since it's further along the CinC route than clojure/jvm.
<mark_weaver>hmm
<mark_weaver>what do you mean by "guile-clojure-core" ?
<rlb>after some help from wingo I started poking at a gil-based dialect, but didn't get all that far before getting side-tracked
<mark_weaver>does clojure support guaranteed tail calls? I'm guessing not.
<rlb>nope
<rlb>not on the jvm anyway
<rlb>(not until/unless the jvm supports it in some hypothetical future)
<rlb>you use various more restricted forms to cover the common cases
<rlb>most of the time it's not an issue, but I think they'd like to have it eventually (it's a pragmatic concession)
<mark_weaver>my guess is that any intermediate language or compiler that doesn't support guaranteed tail calls won't be a particularly good target for guile.
<mark_weaver>ijp had an interesting idea: to write an interpreter for Guile's own VM code in javascript.
<rlb>I'd assumed targeting guile as a platform might actually be easier on that front (or no more difficult) since clojure's more limited than guile.
<mark_weaver>yeah, I'd think so too
<rlb>ideally, I suppose I'd want a clojure/guile dialect with really clean access to the platform (i.e. to guile functions) a la clojure/jvm and clojurescript, and even better if guile could share use of some of the more significant bits like the persistent data structures.
<rlb>i.e. make as many things as possible bidirectional -- though some things obviously wouldn't work
<mark_weaver>the more I think about it, I almost feel silly wasting RMS's time with this. I think it's nearly obvious that it wouldn't violate Guile's license to combine it with EPL'd code.
<mark_weaver>Guile can be linked with proprietary code, for example.
<rlb>mark_weaver: well, certainly don't if you'd rather hold off -- I can always badger him if I think I need to, and if I get past the purely speculative phase.
<mark_weaver>the only reason GPLv2 is a problem is that it violates the GPLv2 to link with LGPLv3.
<mark_weaver>the only real question in my mind is whether it would violate the EPL to link with LGPLv2 code. I'm not at all familiar with the EPL.
<rlb>mark_weaver: well, there's also the question of whether or not you can take an epled lib (say hiccup or compojure or...) and ship it with guile (or even combine it) wrt the EPL. Though perhaps that's fine -- I'm just wary where licenses are concerrned.
<rlb>ah, right -- what you said
<ijp>mark_weaver: clojure has a recur form iirc for stupid-case tail calls
<rlb>right
<rlb>and trampoline for mutual recursion (hackish, but it works)
<mark_weaver>sure, you can always do that sort of thing, but it tends to kill performance.
<rlb>right
<rlb>I'd like to have the persistent data structures, laziness, and the sequence abstraction (among other things)
<ijp>mark_weaver: did you see I released pfds again recently with hamts?
<rlb>also wouldn't mind the STM/agents/atoms/etc.
<mark_weaver>rlb: yes, I really want those things too
<ijp>and also, I have a new idea about guile->js
<rlb>ijp: emscripten? ;>
<mark_weaver>ijp: yes, I did. that's great news!
<mark_weaver>alas, I haven't had a chance to look at them yet.
<ijp>namely, I think it might be easier to just write a tree-il -> js
<ijp>except for the tail calls :/
<rlb>btw, do we already have decent persistent map/set/list/vector data structures avaialble for guile anywhere?
<mark_weaver>ijp: well, I've long thought that tree-il->js (or maybe cps->js) would allow a more performant implementation, but perhaps more work.
<ijp>anyway, I intend to start hacking on it REAL SOON NOW(tm)
<rlb>i.e. wonder if I could just borrow those from elsewhere...
<ijp>rlb: http://github.com/ijp/pfds/ is my attempt
<rlb>ijp: umm -- OH, ok, nice
<rlb>ijp: any idea offhand how what you have compares to what you might need for clojure?
*rlb looks more carefully
<mark_weaver>rlb: we have vlists and vhashes, and wingo recently added intmaps and intsets to master that are at least somewhat inspired from clojure.. I'm not sure if he documented them yet as a public API, but he uses them in the compiler.
<mark_weaver>there's some mention of them in his most recent blog entry at http://wingolog.org/
<rlb>mark_weaver: ok, thanks
<ijp>rlb: hamts in there are what clojure uses for maps
<rlb>(I'm not at all sure a clojure/guile is feasible without a lot of help -- but it'd also be handy to have a clojure dialect that's much faster wrt startup.)
<mark_weaver>but I agree it would be nice to have a much larger set of persistent data structures. patches welcome :)
<ijp>I don't remember how their vectors differ
<ijp>sequences might cover it, probably not
<rlb>fwiw: http://hypirion.com/musings/understanding-persistent-vector-pt-1
<mark_weaver>ijp: iirc, their persistent vectors are basically trees with branching factor 32, vaguely similiar to what's in HAMTs.
<mark_weaver>ijp: btw, out of curiosity, in your hamts, how do you cope with the possibility of two unequal elements with equal hashes?
<rlb>and frankly it probably doesn't really matter if the first pass matches the behavior exactly -- just need to match the language-level semantics
<mark_weaver>that seems like the one non-trivial aspect to implement without hacking guile's hashing code.
<ijp>mark_weaver: like clojure, I fall back to an alist when you have a collision
<rlb>s/behavior/implementation/
<ijp>it's the only way to do it portably
<mark_weaver>ah, I didn't realize clojure did that. I read a bagwell paper, which assumed that you could generate an arbitrary length stream of bits as the hash, with the guarantee that no two unequal objects had equal hash streams.
<ijp>mark_weaver: I think clojure is contrained by one of java's hashing apis
<mark_weaver>makes sense.
*rlb asked about LGPL/EPL on #clojure, just to see if anyone there happens to have clear knowledge...
<ijp>rlb: anyway, if you want to pull anything from pfds, I have an assignment for guile, so there is no problem there
<ijp>and bug me if you need anything
<rlb>ok, thanks
<mark_weaver>rlb: btw, would it be possible to get a newer version of guile in wheezy-backports?
<rlb>mark_weaver: I don't know -- I've been hesitant to commit to backports myself (wrt time). But if I get a chance, I'll see what might be involved.
<rlb>(and of course I'd be just fine with someone else producing one if they like)
<rlb>first I have work that needs doing for the currrent emacs and guile packages...
<mark_weaver>I'd be willing to help with the debian packages, but I'd need a sponsor of course.
<mark_weaver>there are a lot of other guile packages that it would be great to upgrade to guile-2.0.
<rlb>my main focus there has been on getting 1.6 (and 1.8) removed from jessie -- that's taken a chunk of my debian time recently
<rlb>(filing requests, bug reports, escalating, etc.)
<mark_weaver>*nod*
<rlb>but we're making progress -- think 1.6 is finally almost gone
<mark_weaver>thanks for working on that :)
*rlb cheers
<rlb>that was a (historical) mess -- had to keep 1.6 around for far longer than appropriate because of the threading ABI breakage in 1.8...
<rlb>but 2.0 fixes all that (more cheering)
<mark_weaver>:)
<cky>When 1.6 is finally gone (sans "almost"), I'm sure 2.2 will be finally released (sans "almost"). :-)
<cky>mark_weaver: I did finally implement your "pure Newton-Raphson" approach. It takes at least 7 iterations, though, and that's starting at 4. (With a starting value of 1, even 10 iterations won't get the right result.) :-D
<cky>I know you've mentioned in the past that you don't like GitHub's web UI. In that case, feel free to clone this repo: git://gist.github.com/ce369da77b6ddf4753dc.git
<mark_weaver>thanks!
<mark_weaver>going afk for a while, ttyl!
<cky>Have fun!
<nalaginrut>morning guilers~
<nalaginrut>how can I apply a list to a macro? like a function
<TheBrayn>guile: uncaught throw to out-of-range: (#f Value out of range ~S to ~S: ~S (-128 127 10000) (10000)) <- how can I check for these if I use, for example scm_to_int8?
<TheBrayn> http://codepad.org/1fXSBy1B with (define square (lambda () (* sc_arg sc_arg)))
<nalaginrut>TheBrayn: you may use SCM_T_INT8_MIN, SCM_T_INT8_MAX to check it in C code
<nalaginrut>it's similar for others
<TheBrayn>nalaginrut: I don't understand, SCM_T_INT8_{MIN,MAX} are the min/max values for a int8, but how do I know if the SCM contains a i8 within these boundaries?
<nalaginrut>you may check min < n < max, scm_to_int8 does the same check but throw an exception if not cool
<taylanub>what C identifier holds the < and > Scheme procedures?
<taylanub>s/identifier holds/identifiers hold/
<nalaginrut>scm_i_num_gr_p for > , I think
<nalaginrut>scm_i_num_less_p for <, and you may need the eq in this case, it's in libguile/number.c
<nalaginrut>TheBrayn: you can do this check before you convert SCM to C object
<TheBrayn>nalaginrut: do you mean the scm_i_num_gr_p?
<nalaginrut>yes
<TheBrayn>it takes 3 arguments, which do what?
<nalaginrut>it's actually '>' in Scheme which let you check two numbers in SCM
<nalaginrut>TheBrayn: the third is the rest args, you may not need it
<TheBrayn>where is this documented?
<TheBrayn>I just got source code listings through google
<taylanub>looks like scm_i_num_gr_p is not directly documented in the manual
<nalaginrut>TheBrayn: unfortunately, there's no docs for this one, I think part of the reason is the scm_i_* prefix
<TheBrayn>and it's not in the headers
<nalaginrut>it's for inner lower-level apis
<nalaginrut>so maybe reasonable unexported
<taylanub>huh, wait, (info "(guile) Comparison") *does* document C functions, but they're not scm_i_*
<taylanub>indeed, does the _i_ not stand for "internal"?
<nalaginrut>oh, so there's better choice
<nalaginrut>TheBrayn: https://www.gnu.org/software/guile/manual/guile.html#Comparison
<nalaginrut>there're better choices
<nalaginrut>sorry for confusing
***micro` is now known as Guest44207
***Lajjla is now known as turbo_islaam
<ijp>FYI closed #17703
<mark_weaver>ijp: thanks for the bug fixes! :)
<mark_weaver>also, it makes it easier to update the NEWS file if the commit log includes the bug number. it's also good if the bug report mentions the commit number.
<ijp>mark_weaver: I was thinking about this earlier but, if we are doing the cps route on master, then we could probably do cheney on the mta in a guile->js
<ijp>which would solve the tail recursion problem
<mark_weaver>sounds reasonable to me
<davexunit>guile->js? :D