IRC channel logs

<Javyre>Hi, I'm working on porting guile to rust. It's in early stages and I'm porting foreign objects but I have a couple of questions

<cmaloney>Go ahead and ask your questions

<Javyre>Since im making safe bindings, I want to make slot types type-safe at compile-time, this turned out to be extremely complicated to do in rust and im considering just using one slot and having it point to a rust tuple type to have the same behaviour as having multiple slots

<Javyre>does using individual slots have any benefit in this case?

<amz3>Javyre: welcome, response time can be slow, I recommend you to stay around or come back later and say hi. We have sneek, a bot, that store messages for later retrieval

<amz3>Javyre: I have a few questions for you related to you work, may I ask them?

<amz3>sneek: botsnack

<sneek>:)

<CherryMan>amz3: I'm working with him, what do you need to know?

<amz3>the first question is: is there a public repository?

<Javyre>(here too)

<CherryMan>yes

<CherryMan>wait

<Javyre>github.com/tim-editor/guile-rs

<Javyre>low level bindings are auto generated with rust bindgen in /guile-rs-sys/

<amz3>ok, I saw that repo around, I was not sure if it has real or serious, I am glad it is actually

<amz3>second question: does it allow to rust from guile or guile from rust?

<amz3>or both

<amz3>second question: does it allow to call rust from guile or call guile from rust?

<Javyre>well the goal is to bring the guile c api to rust with all of its functionality

<amz3>it seems to me, that what you are trying to achieve is allow guile to script and editor. Somewhat like elisp does with emacs

<amz3>ah ok

<Javyre>exactly like elisp yeah

<Javyre>but with a tiny core in rust

<Javyre>heavily inspired by emacs and vim of course

<amz3>very cool

<amz3>I wish you good fortune

<Javyre>thank you

<amz3>I am fiddling with databases, myself, using wiredtiger, I might need at somepoint to translate my code to rust and use guile as query language

<amz3>so our interest interect quite nicely

<CherryMan>feel free to contribute :)

<Javyre>well contributions would be very welcome :D

<amz3>also, I will gladly use a emacs-like editor

<Javyre>the goal is to be 'background agnostic'

<Javyre>so there would be an 'emacs-emulation' configuration module as well as a vim one

<amz3>:D

<Javyre>i love both editors and we wanted to bring the positive elements of both together

<Javyre>checkout our open issues on the guile-rs repo if you ever feel like contibuting c:

<amz3>I would like right now to contribute but 1) I don't know rust well enough yet 2) I don't know guile C api for embedding, that is I will contribute some day in the future...

<amz3>out of curiosity, why did you choose guile?

<CherryMan>there aren't many other projects we found like guile

<CherryMan>Guile is really well suited for our needs

<CherryMan>Javyre did try another rust-only lisp interpreter

<CherryMan>however there were some limitations

<Javyre>guile was truly perfect for our use-case yeah

<amz3>ACTION glad to hear that

<amz3>ACTION need to go back to my hacking now

<amz3>feel free to send a mail on the mailling list https://lists.gnu.org/mailman/listinfo/guile-user/

<amz3>with your question(s)

<amz3>maybe guile-devel is better suited to your question

<CherryMan>didnt know that was a thing! thank you

<djcb>in ancient times, there was (ice-9 base64)... what do people use these days?

<amz3>industria

<amz3>sneek: what is industria

<amz3>sneek: what is industria?

<amz3>sneek: industria is a set of cryptographic libraries for r6rs, see https://github.com/weinholt/industria/

<sneek>Okay.

<amz3>they are also libgcrypt bindings floating around, but I don't know if they support base64

<djcb>thanks! but that requires external libs it seems; hmmm.

<amz3>seems like I need to know more about git internals to achieve what I want

<amz3>I have something that works like svn where every users have a exact copy of the remote server

<amz3>so, imagine there two users Alice and Bob

<amz3>we will assume they share a common repository, with same history, without branches

<amz3>Both alice and bob have access to three procedures, (add assoc1) -> uid

<amz3>___

<amz3>Both alice and bob have access to three procedures:

<amz3>a) (add assoc1) -> uid

<amz3>b) (ref uid) -> assoc

<amz3>c) (rm uid)

<amz3>d) (set uid assoc2)

<amz3>4 procedures actually

<amz3>'set' procedure is only valid if there is already an assoc with the given UID

<amz3>that must be returned previously by 'add' procedure, which returns a randomly generated identifier

<amz3>so, imagine alice and bob 'add' assocs to their database each on their own copy, the issue is it's not possible to avoid conflicts between parallel calls to 'add'

<amz3>since parallel calls to 'add' can return the same identifier

<amz3>it's even more obvious when 'add' instead of returning random identifiers, was returning autoincrementing integers

<amz3>so say bob, runs 'neon pull alice master' where neon is the name of the program I trying to come up with

<amz3>wow

<amz3>so, pull-ing will require to build a mapping of remote assoc ids with local assoc ids

<amz3>that's a good moment for someone to chime and say "use monadic crdts"

<amz3>also I will need a way to distinguish Foreign Key values, and change FK coming from alice with their equivalent locally

<amz3>afaiu there is no way to come up with a hash function, that will make thing easier aka. like git

<amz3>aka. content-adressable

<amz3>I am not sure where to look for more information

<amz3>this is a distributed peer-to-peer database issue

<amz3>I will try #gnunet

<amz3>O<

<amz3>_o<

<amz3>I think i have a solution

<rlb>guile-2.2 has been removed from debian testing (buster).

<rlb>I'll probably continue to poke at the crashes myself off and on, but if anyone upstream would like to help, I'll be happy to assist. Of course another option would be to skip the offending tests for the moment if they're deemed not critical.

<jlicht>hi guile! How can I deal with a pointer-to-a-pointer (**) in C using the dynamic FFI module of guile?

<Javyre>is the guile-devel list for devs of guile or ppl using the guile c api?

<ft>I think all usage related discussions are supposed to go to guile-users@. But I don't think I've seen that enforced too heavily. Some people also just cross post to both.

<amz3> jlicht what do you want to do with the double pointer?

<amz3>jlicht: can you provide the C code that you need to bind?

<jlicht>amz3: I got it to work in a way that is way simpler, so no need anymore

<jlicht>context: I was playing around with signalfd in guile programs

<jlicht>hmm, I am running into something silly though; my signal handlers are properly ignored according to my sigprocmask if I call e.g. `(raise SIGCHLD)', but if do `(kill <mypid> SIGCHLD)', they are triggered regardless of my sigprocmask. Does guile do some weird things with its threads and signal handling perhaps?

<mwette>try sec 6.22.3 async interrrupts: it implies Guile uses levels of masking

<jlicht>thanks mwette, I'll have a look

<justin_smith>the docs mention a value _IOFBF which is used as a port mode, and this is used by a library I am trying to use, but guile built from master git complains it is not bound - is this a known thing?

<justin_smith>if I run 2.0.9 _IOFBF is bound to 0

<daviid>justin_smith: you should not use master, unless you are willing to help to work on the compiler... checkout stable-2.2 instead, then see in the NEWS for diffs between 2.0 and 2.0 ...

<justin_smith>daviid: oh, that makes sense - I was trying to make sure scsh works with up to date guile which is why I built from master, but I'll check out the stable 2.2 branch instead

<amz3>master is Guile 3.0

IRC channel logs

2018-02-10.log