IRC channel logs

2019-10-29.log

back to list of logs

***Server sets mode: +nt
<str1ngs>daviid: right I get it. I guess I'm just being pragmatic and think that in term. typelibs still even for C++ is still more usable now then even SCM_DEFINE and guile's dynamic FFI. I will ponder your input some more. It's an intriguing and interesting discussion and problem to solve.
<dsmith-work>The thing with C++ that concerns me is exceptions. And how that fits in with Guile catch/throw or the r{6,7}rs stuff.
<str1ngs>though is it not normal for C++ libraries to a extern a C interface?
<dsmith-work>Desired, but not normal I would think.
<dsmith-work>I've been seeing a lot of C++ "header only" libs.
<str1ngs>I've been using https://isocpp.org/wiki/faq/mixing-c-and-cpp for reference myself
<dsmith-work>Not that I'm looking! I tend to avoid C++.
<str1ngs>I prefer C to C++ myself as well. and maybe when I reach scheme nirvana I can forgo that too :)
<dsmith-work>Yeah. C is my native tongue.
<dsmith-work>Though $DAYJOB as been mostly Python for the past 4-5 years.
*jcowan is a monoglot speaker and a polyglot programmer
<jcowan>I have no idea what my "native" programming language might be
<daviid>dsmith-work: yes, c++ exception is the problem, and vigra_c, imo, does the right thing
<daviid>str1ngs: most c++ lib do not have a C api, which is why it is a 'problem' for us, schemers, till a genius writes an automatic c++ to c wrapper or a libffi++ that takes care of c++ exceptions ...
<dsmith-work>daviid: This? https://github.com/BSeppke/vigra_c
<jcowan>Fortunately, it's a whole lot of "scripting" languages that can't talk to C++
<jcowan>not just Scheme
<str1ngs>I think swig attempts that :P. but not exactly dynamic either
<jcowan>Does anyone know how Clasp does it? C++ is its native language
<daviid>dsmith-work: yes, that vigra_c is, imo, the right way to handle the problem, but it needs someone to write it 'maually' ...
<mwette>the nyacc ffi-helper is SWIG for Guile
<daviid>jcowan: yes, but if we could, we'd have octave and opencv 'in our hands' ...
<mwette>or at least intended to be
<jcowan>Chicken gave up on Swig a long time ago, I'm not even sure exactly why
<daviid>mwette: bcan nyacc ffi-helper provide c++ binding? if so, does it make guile c++ exceptions aware?
<mwette>daviid: no, C++ is too hard to parse, I looked into C++ parsing for a bit but decided too hard and I have little experience w/ C++
<daviid>mwette: ok
<jcowan>the only thing you should parse C++ is a C++ compiler.
<nisstyre>does guile have a way of writing hash literals, better than doing (alist->hash-table '( (foo . bar) )) ?
<dsmith-work>No read syntax for hashes
<nisstyre>fair enough
<dsmith-work>nisstyre: See https://www.gnu.org/software/guile/manual/html_node/SRFI_002d10.html near the end
<nisstyre>dsmith-work: yeah, that's what I want
<nisstyre>kinda
<nisstyre>but it looks like the srfi is not recommended
<nisstyre>I'm trying to make it easy to configure a bunch of values
<nisstyre>maybe I should just create my own macro for that
<mwette>Right: clang is able to dump a parse tree. One could try that but it will be a moving target in terms for parse tree format.
<mwette>isn't hash-comma (#,) used by syntax case?
<dsmith-work>mwette: unsyntax
<jcowan>mwette: Yes
<dsmith-work>nisstyre: fwiw, The racket hash read syntax seems to just be a macro and an alist.
<dsmith-work>nisstyre: https://docs.racket-lang.org/reference/reader.html#%28part._parse-hashtable%29
<daviid>dsmith-work: the vigra_c author is the author of vigracket, which is why he wrote vigra_c in the first place :)
<dsmith-work>That name is always looking like something getting past spam filters..