IRC channel logs

<nalaginrut>morning guilers~

***michel_mno_afk is now known as michel_mno

***wleslie is now known as little_sizzling_

***little_sizzling_ is now known as wleslie

***michel_mno is now known as michel_mno_afk

***michel_mno_afk is now known as michel_mno

<civodul>Hello Guilers!

<attichacker>Good morning

<wingo>greets :-)

<wleslie>(map greets #guile)

*wingo ported about half of the compiler to cps2

<civodul>wingo: yay!

<civodul>so that makes it easier to work with, right?

<wingo>civodul: yeah, a lot easier, usually

<wingo>there are some challenges like for example when you are building a CPS term, which is a label -> cont map, sometimes you need to thread that term through the entire transformation

<wingo>because it's a functional map

<wingo>but there are some utilities to help with that

<wingo>s/term/program

<wingo>i'm currently porting cse

<wingo>should be interesting, given that i can chuck all the code related to scoping :P

<wingo>i'm also going to try to use a worklist instead of a fixed-point iteration; it seemed to work well for type inference

<wingo>and is more optimal, in theory at least

<wingo>probably at some point we will have to port some inner bits of e.g. intmap-ref to C, at least until we have native compilation :)

<wingo>unfortunately i won't know until the very end if this port will fix the excessive memory use at bootstrap time

<wingo>i am thinking that it will, but my instincts here have often led me astray :/

<amz3>héllo guilers :)

<wingo>greets :)

<duud``>wingo: what is your opinion about r7rs? Will guile support it? I know there is a branch but it seems to be incomplete.

<sneek>duud``, you have 3 messages.

<sneek>duud``, nalaginrut says: sorry I was leaving for a meeting. And yes, it's not mapping a table but a connection, I planed an abstract level to hold a table with a helper function, so maybe my-table is not a proper name ;-)

<sneek>duud``, nalaginrut says: and please make sure it's 2.0.11+

<sneek>duud``, nalaginrut says: FPRM is working-in-progress, so yes, there's no relations mechanism between tables yet, I'm trying to find good way to design, but slowly ;-P

<wingo>duud``: dunno, not real excited about it, but i reckon guile will support it eventually. not sure who is driving the branch; been off in the weeds myself for the last while.

<taylanub>last I remember mark_weaver was questioning the worth of continuing it at all, given that R7RS-large seems to be heading a weird direction. IIRC there weren't many significant missing pieces though.

<civodul>wingo: okay, sounds nice!

<daviid>hello guilers!

<taylanub>duud``: https://gnunet.org/bot/log/guile/2014-11-15#T513742

<taylanub>(er, best scroll up a little bit from that point; seems to scroll into the middle/end of the post it actually tries to link)

<duud``>taylanub: oh I see, thx

<duud``>taylanub: what's wrong with r7rs-large?

<duud``>taylanub: I'm reading r7rs-small at the moment, i can't see anything wrong about it, however it should improve portability. I seems to me that the big scheme implementations don't really care about portability. That's sad - so I'm really interested why they are not excited about r7rs.

<taylanub>duud``: I think R7RS's main problem is R6RS incompatibility: https://gnunet.org/bot/log/guile/2014-11-16#T514469

<taylanub>-small that is. so far the R7RS-large effort has led to some weird SRFIs, like 113 and 116.

<duud``>taylanub: there is some work going on to port r6rs on top of r6rs. https://github.com/larcenists/larceny/tree/master/tools/R6RS

<duud``>r7rs on top of r6rs

<taylanub>that's just some of the R6RS libraries (I'm contributing by the way :) ). perhaps the biggest problem is the library syntax; you can't write a Scheme library that's both R6RS and R7RS compatible; you *have* to choose.

<taylanub>as in, those R6RS libraries there are just the APIs of R6RS libraries, implemented as R7RS libraries.

<duud``>taylanub: oh :)

<taylanub>maybe an SRFI or so could be written that endorses R7RS implementations to allow the keyword "library" as a 1-to-1 synonym of "define-library". I think that alone would make it possible to write a library that's a combined R6RS/R7RS library.

<duud``>taylanub: so that means the library syntax issue you mentioned before isn't really an issue?

<taylanub>I'm looking for details ATM. I think there was an R7RS ticket about it, and I don't remember why it was rejected and whether it means such an SRFI would be rejected as well, though I don't seem to remember any actual technical issues with it :\\

<taylanub> http://trac.sacrideo.us/wg/ticket/536

<taylanub>so it comes down to "In the general case, no library can work exactly unchanged on both R6RS and R7RS systems because of the differences in the names and contents of the libraries they need to import. At the very least, each needs to import the base library, which means that an [R6RS] library will begin with (import (rnrs base)) and an R7RS library with (import (scheme base))."

<paroneayea>hei hei wingo

<duud``>taylanub: thx for the explanation - btw how do you search in guiles irc logs?

<wingo>greets paroneayea :)

<dsmith-work>Tuesday Greetings, Guilers

<taylanub>duud``: I search my own logs, then visit that date in the gnunet logs

<duud``>taylanub: ok

<duud``>taylanub: Concerning portability - I think there should be an srfi describing an ffi to c. What do you think?

<ijp>bear in mind that srfis are not actually standards

<duud``>ijp: practically some of them are

<ijp>very few

<duud``>ijp: so you think its a better approach to specify an ffi in a rnrs

<taylanub>R7RS-large works through SRFIs anyway, regarding libraries

<ijp>duud``: for r6rs scheme, there was a library that wrapped most of the individual ffis

<ijp>but most of them worked in roughly similar ways using libffi

<duud``>ijp: that's interesting do you know the name of the library?

<ijp>well, in typical scheme fashion there were actually two

<ijp>(spells foreign) by rotty, and the other one by will farrington

<ijp>hmm, I can't find the latter now

<davexunit>pizza. that is all. http://www.catonmat.net/images/100-favorite-books/pizza.jpg

<ijp>good old little schemer

<paroneayea>I still have to make it through reasoned schemer

<paroneayea>after I do that I'll probably get seasoned schemer and little prover when they come out

*amz3 is way too fully too lazy to read all that jazz

<ijp>I'm looking forward to the little prover, but it's a shame I no longer need it

<paroneayea>wingo: btw I've taken an interest in http://wingolog.org/archives/2011/03/24/storage-primitives-for-the-distributed-web which might be relevant for a project of mine. did you ever do anything more on it I should look at? even if not, I might ping you on things if I move into implementation mode

<wleslie>woo, capabilities

<wingo>paroneayea: i didn't end up doing any more there unfortunately, i think many of us dream of something like that tho :)

<wingo>happy to hear of your explorations in that regard :)

<ArneBab>wingo: I did not see that yet, but from what I see the cloud-part of that could be done easily via Freenet

<ArneBab>(which adds one part I’m missing in your writeup: ensuring that it’s not visible whether or when something was stored)

***michel_mno is now known as michel_mno_afk

***michel_mno_afk is now known as michel_mno

<paroneayea>there probably isn't, but is there any way to prevent (slot-set!) from working on a GOOPS class?

<paroneayea>or am I doomed to my users mutating whatever they want :)

<davexunit>keep in mind that you are also doomed to user mutating which cons cells they want ;)

<paroneayea>that's true davexunit :)

<davexunit>sooo

<paroneayea>maybe the appropriate route is a skull and crossbones in the doc.

<davexunit>yeah

<davexunit>we can't exactly enforce immutability in certain places

<davexunit>just don't do it. :)

<paroneayea>the more I'm thinking of the stuff I want to do with my activitystuff project

<paroneayea>the more I think (define-method) will be nice

<paroneayea>I made both GOOPS and functional records based impelmentations

<paroneayea>I might hit a middle ground soon.

***michel_mno is now known as michel_mno_afk

<paroneayea>I guess the guile convention is foo-bar.scm. Gotta get out of my python habits of foo_bar.scm...

<paroneayea>would (vhash->hash-table) be a useful contribution to guile?

<paroneayea>since I just wrote it anwyay :P

<paroneayea>simple utility

<ijp>how do I regenerate just the makefile for the module/ directory?

<mark_weaver>ijp: it should happen automatically

<mark_weaver>the Makefile includes rules to regenerate the Makefile from Makefile.am

<mark_weaver>(I just tried "touch module/Makefile.am" and "make" and it did it)

<ijp>I thought so too, so I must have messed something up accidentally

<wingo>paroneayea: it's possible to make slot-set! not work

<wingo>but struct-set! is a different kettle of fish

<paroneayea>wingo: ah I don't care about struct-set! :)

<wingo>hmmm :)

<paroneayea>I don't expect goops users are going to try to hack that low-level

<paroneayea>the thing is

<paroneayea>slot-set! seems like you "are free to use" on a general goops class

<wingo>yeah

<paroneayea>but it's not necessarily safe

<paroneayea>I want to take advantage of GOOPS' method dispatch but also provide a fairly functional API

<wingo>you can try adding #:class <protected-read-only-slot> to the slot definition

<paroneayea>wingo: oh nice

<paroneayea>I'll look.

<wingo>or you can add a setter that errors out

<wingo>that might slow things down tho

<wingo>not sure

<paroneayea>wingo: but you can still use slot-set! to skip the setter right?

<paroneayea>ohhh

<paroneayea>nope

<paroneayea>I see.

<paroneayea>oh no

<paroneayea>I am right :)

<paroneayea>I think :)

<paroneayea>wingo: I dunno, when I look at goops.scm it says

<paroneayea> (define (@slot-set! o n v)

<paroneayea> (struct-set! o n v))

<paroneayea>so it looks like that doesn't really behave differently per class?

<daviid>wingo: it seems wrapset.api wre not updated for 1 or some of the previous guile-gnome updates, and I'm doing it now to get a clean 2.16.3 ready to release, all fine but i have 2 quizz

<wingo>paroneayea: that's a different thing

<wingo>@slot-set is different

<paroneayea>wingo: ah ok

<daviid>^ this is without having changed any .defs. ok, so it seems to extract twice certain items, i wonder why. for example atk/tests/wrapset.api will now list twice <symbol> [it always list twice <symbol> for any module that refers to it

<wingo>daviid: humm, that is strange

<daviid>let me paste a git diff to see if you have an idea

<paroneayea>wingo: where *does* slot-set! get defined?

<paroneayea>I can't really find it

<wingo>paroneayea: dunno, in master it's in scheme :)

<wingo>i think in 2.0 it's in goops.c

<paroneayea>ohhh

<paroneayea>okay

<paroneayea>that would be why I can't find it :)

<wingo>it's pretty tough reading tho

<paroneayea>wingo: thanks for clarifying :)

<daviid>wingo here are some of the api updates diffs http://paste.lisp.org/+36Z7