IRC channel 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..

IRC channel logs

2019-10-29.log