<daviid>what email would you like me use to send to patches for review? <daviid>wingo: it pass make distcheck here ***Menche is now known as dcmenche
<amz3`>bummer the archives.org hackernws dump is a single json array I can't load it fully in memory. I'll need to dump hn myself <amz3`>while using guile-curl I stuble upon this error <amz3`> 0 (apply-smob/1 #<catch-closure 4490f40>) <amz3`>ERROR: In procedure apply-smob/1: <amz3`>ERROR: In procedure free-handle: Wrong type argument in position 1: #<finalized smob 51f7050> <mark_weaver>amz3`: could be related to commit 8dff3af087c6eaa83ae0d72aa8b22aef5c65d65d <mark_weaver>maybe that commit has uncovered a long-standing use-after-free bug in guile-curl that has gone previously unnoticed, dunno. <mark_weaver>I should say that I was not able to convince myself that the theory behind wingo's fix (which came from kastrup, as I recall) was a satisfactory solution to the bug. <mark_weaver>but I have swapped those details out of my mind long ago, so I've forgotten the details. <amz3`>I'll try my script without the patch <mark_weaver>as I recall, I couldn't find a solution that satisfied me that didn't involve modifying bdw-gc. <mark_weaver>but maybe wingo was right and I worry too much, that's possible :) <amz3`>actually that commit is only in master and I am not on master <amz3`>I'm trying to compile master, but it failed, I will retry, maybe I did a mistake ***dsmith is now known as dsmith-work
***dje_ is now known as xdje
<rubdos>Is there ongoing effort to create a guile C++11 or C++14 binding? <ft>I vaguely remember a thread on one ofthe mailinglists about C++ bindings. <rubdos>main problem will probably be creating the GOOPS objects, although I'm not sure there <rubdos>I can write scheme, but never touched GOOPS.. :) <Amynka>mark_weaver: for now it looks good thank you very much for fix <dsmith-work>rubdos: It's possible to call into libguile from C++ (bobot++ does this, which our frendly neighborhood bot, sneek, runs on) <rubdos>I know that, but I was looking for more C++ style bindings. I already call into the C library :) <dsmith-work>rubdos: But Guile currently can't handle C++ exceptions, so wrapping a C++ lib will probably fail miserably if there are any exceptions. <rubdos>so the binding should catch exceptions... :) <cmhobbs>i've got a couple of free days in september and i know just enough guile to be dangerous. what are a few projects i could hack on in about 16 hours that would help me learn and contribute to the community? i've already got guix as a potential option on my list <sapientech>hi guys, when i create my own macro, then compile it in geiser, i notice that when i use it in a buffer, the syntax highlighting doesn't change its color like other macros <ijp>most aren't coloured differently from any other identifier <sapientech>ijp: right i noticed that only the core macros like if, cond, etc are colored. is there a reason for this? i would think that i would be helpful to know when one is using a proc vs macro <ijp>it's not generally decidable, and not always helpful <ijp>e.g. how do you classify inlineable functions <random-nick>sapientech: those specially highlighted are special forms, not macros <random-nick>sapientech: for example when is a core macro that doesn't get specially highlighted <ijp>"special form" is a murky phrase <sapientech>if im not mistaken, isn't letrec just a straightforward macro? <ijp>less straightforward than you think <sapientech>you are right with if, but when and unless are macros yea? <ijp>that's why you have to 'fix' it <ijp>that pun is very problematic <sapientech>ijp: sure i shouldn't have assumed letrec is straightforward, since i imagine there are subtleties, but how about when or unless? <ijp>very straightforward <ijp>well, that's not how when is implemented <ijp>but the basic point is, these identifiers are specially handled by your editor, and there is a list you can tweak. Their macroness is not determined dynamically <ijp>this is also why they get indented specially <ijp>indents are handled by the 'scheme-indent-function property on the symbol, I don't know about highlighting <sapientech>ijp: okay thanks for the info, do you think highlighting all macros would be a good idea? <ijp>Rust has different syntax for macro invocations than function calls and they seem happy enough. But, it means you can't replace functions with macros transparently, like we do with inlinables <sapientech>ijp: so inlinables turns a function with an inlinable inside into a macro that builds a new function with the inline function as a direct call? <dsmith-work>In guile "load" is actually a macro. Should that be highlighted specially? (I suggest "no" is the correct answer) <ijp>sapientech: I'm referring to define-inline, which technically defines a macro, but for all intents and purposes, defines a function <ijp>e.g. record accessors are usually define-inline'd, but that is an implementation detail, and not really important to a uer