IRC channel logs


back to list of logs

<ArneBab>Starting next week, there will be new votes to cast on r7rs-large — this time for macro systems:
***rt is now known as robin
<alextee[m]>I'm trying to figure out what's the easiest way for creating guile bindings for my c code without having to write interfaces manually like in the manual
<alextee[m]>I just discovered swig
<alextee[m]>There's also that nyacc ffi helper thing. What would you recommend?
<alextee[m]>Swig seems easier and better documented imo
<manumanumanu>ArneBab: I don't think people's stance on syntax-case has changed much.
<manumanumanu>Marc wrote this in the chez issue tracker, which I in many ways find more exciting than r7rs-large:
<manumanumanu>I don't think much of that is actually very controversial. except the immutable cons pair thing (which IMO is a great thing).
<manumanumanu>So... optional arguments are not always a good thing. I just spent 20 minutes looking at ,traces and what-not not understanding why my recursive function was not working properly. The error was in the simplest clause not propagating an argument :( :(
<manumanumanu>But now it works! I have a small program reading scribble-like syntax into SXML (with a slightly diverging at-expr).
<lloda>wingo: ok to push;a=commitdiff;h=81f12bf86eed96c7ecdf6c9ce40d5abe6c729457
<lloda>i mean, to merge
<wingo>lloda: sgtm
<lloda>thx, done
<manumanumanu>lloda: well done. you have been at this for some time, iirc.
<lloda>it will take a while yet
<tohoyn>can you estimate when we will have Guile 3.0.7 in debian (testing/unstable)?
<tohoyn>new debianized version 0.1.0v5-2 of G-Golf has been released. Support for Guile 3.0 has been improved. See
<dsmith-work>UGT Greetings, Guilers
<manumanumanu>I just released this for no real reason:
<manumanumanu>It is not quite compatible with racket's version, but close enough for what I'm using it for.
<tohoyn>Theme-D version 4.0.1 has been released, see
<tohoyn>new versions of Theme-D-Golf and Theme-D-Gnome have also been released
<leoprikler>manumanumanu: how come @{1} => 1, but @{a} => "a"? Is there some deeper meaning behind that?
<manumanumanu>What? Which guile?
<leoprikler>i mean it breaks the + example if you don't special-case numbers but it's still weird not to be documented
<leoprikler>The Guile interpreter in my head while reading the documentation :P
<manumanumanu>Ah. No: there is a difference. Everything between [] or () is scheme
<manumanumanu>everything between {} is string unless an at-expr
<leoprikler>okay, my bad, my squiggly detection sucks ._.
<leoprikler>regarding the hash extension, can't you simply (fix-atexp (read-atexp port)) ?
<manumanumanu>I don't know what you mean. read-hash-extend extends the guile reader so that it calls my procedure when it finds #@
<leoprikler>sure, I mean the code inside the read-hash-extend
<leoprikler>looks weird with the define first
<manumanumanu>yup. I had to add a (pk ...) there during development
<manumanumanu>don't look too closely at the source. it is pretty awful
<manumanumanu>I start with point A, where I am now, and some vague vision of point B, where I want to be, and i spaghetti myself between the two.
<manumanumanu>And this code I broke out from a larger project.
<manumanumanu>no intellectual rigour at all
<leoprikler>haha, point taken
***apteryx_ is now known as apteryx
***chris is now known as Guest3569
<lloda>(scheme base) redefines a lot of core bindings, shouldn't it be using #:replace ?
<lloda>like srfi-43 does
<lloda>also i dislike srfi-43 intensely
<manumanumanu>that should probably replace, yes.
<manumanumanu>why hate srfi-43?
<lloda>it's weird
<manumanumanu>or dislike was the word you used.
<lloda>vector-map with index
<lloda>vector-copy where end can be > the size of the source
<manumanumanu>yes. it is clunkier to use for most cases.
<manumanumanu>that last one seems... not great...
<leoprikler>how would that work? With python-style wraparound? :P
<lloda>no, it just makes a bigger result and fills it with a filler
<lloda>i mean it just fills it with a filler, sorry
<leoprikler>hmm, that sounds somewhat useful tho
<leoprikler>albeit only somewhat
<lloda>when there are many ways to extend the meaning of something, it's time to stop
<leoprikler>imagine you want to grow your vector to some larger size while retaining the existing elements
<lloda>give your extensions some other names
<leoprikler>well, you could name it vector-copy/extend
<lloda>you can just make the big vector yourself and vector-copy! in it
<leoprikler>that's ew
<lloda>it's not
<leoprikler>everything with ! is instant +1 ew
<lloda>that's what vectors are for /shrug
<lloda>and that's what the extension was doing anyway
<leoprikler>sure, but you have to differentiate between API and internals
<leoprikler>internals can be ew when no one looks at them :P
<lloda>fair enough
<lloda>i still don't think it's a good extension
<leoprikler>Well, it doesn't break compatibility with the existing thing and does extend it in a very defined manner.
<leoprikler>Think of SRFI-1 iota
<leoprikler>you could achieve the same thing with map and basic arithmetic, but having it built-in makes the code read much nicer
<lloda>for review;a=shortlog;h=refs/heads/wip-vector-cleanup-2
<lloda>only nit is that the C versions cannot be extended compatibly :-\
<lloda>but the same thing happened already with scm_vector_fill_partial_x
<lloda>not sure how to solve it tbh
<leoprikler>wdym "extended compatibly"?
<leoprikler>iiuc the partial copy assumes the destination to be smaller than the source, right?
<leoprikler>hmm, seeing how this is defined in terms of vector-move-left!, does vector_move_left_x exist in C?
<dsmith-work>leoprikler: libguile/vectors.c:372
<lloda>leoprikler: logically it's fine and in Scheme there are no issues
<leoprikler>fair enough
<lloda>but in C, adding arguments means breaking the previous interface
<lloda>that's why i left the C as it is
<leoprikler>oh, I didn't know there existed a procedure beforehand
<lloda>it's funny in a way bc vector-fill! was already r7rs compliant, but the doc doesn't say it, so the r7rs libraries had their own implementation
<manumanumanu>lloda: is that vector fill slower than the C one? I have noticed that some string functions I have rewritten in scheme have been just as fast as the ones in C in guile. If there is no performance penalty, maybe rewriting them in scheme wouldn't be a bad idea.
<manumanumanu>I haven't talked to Andy about that, but I have a feeling he wouldn't disagree if there is no real performance impact.
<lloda>yeah I don't disagree with that. If the perf is similar Scheme is ofc better
<lloda>when you need to provide a C binding then it's a bit more difficult
<lloda>tbh I think functions such as scm_vector_fill_x are a bit superfluous since they're just a for loop in C. You can just give the pointer and the size and let C users figure it out
<lloda>but once they're in the public interface you have bear them
<lloda>I think functions that are loops in C that call Scheme functions are likely always going to be better in pure Scheme
<lloda>vector-fill!, vector-copy etc aren't like that, they are raw C
<lloda>but I didn't benchmark them
<ArneBab>manumanumanu: what is the stance on syntax-case?
<ArneBab>manumanumanu: I now provided my enter-three-witchen macros as a benchmark for expressiveness of other macro systems.
<manumanumanu>Lets just say some people still whine about it since r6rs :)
<manumanumanu>If I would say anything it is that syntax-case is not hygienic enough. Srfi-72 solves a real problem with syntax-case. If I ever understand guile's syntax-case, I will write a (extra-hygienic-quasisyntax
<manumanumanu>that will always introduce bindings hygienically unless you are unquoting the same syntax object.
<manumanumanu>anyway. Now to bed!
<daviid>vijaymarupudi: I just pushed a fix for the bug you reported, g-golf develbranch, please pull, autotool danse :), try and let me know ...
<leoprikler>syntax-case is pretty hygienic by default tho, no?