IRC channel logs

<grothoffhome>mark_weaver asked me to add an IRC log bot for #guile.

<grothoffhome>So here it is (public logs): https://gnunet.org/bot/log/guile/

<mark_weaver>hey guys, grothoffhome has kindly agreed to log this channel and make them public :)

<mark_weaver>thanks grothoffhome! :)

<grothoffhome>If the community wants this disabled, please let me know.

<ijp>great, that's one less thing I can strike off my todo list

<ijp>one more, rather

<grothoffhome>Note that there is no page linking to the log on gnunet.org, so if you want Google to index it, you'll have to link to it from Guile pages somewhere.

<mark_weaver>sounds good. we've never advertised the irc logs very publicly, and I'm not sure we want to.

<mark_weaver>but they've long been accessible to those who know where they're kept.

<cky>grothoffhome: Do you need to seed the logs with previous stuff? I have logs here you can fill the bot with.

<cky>That's the nice thing about being logged on 24/7. :-)

<mark_weaver>cky: I suspect that would be more work for grothoffhome, and probably not worth his time.

<cky>mark_weaver: Okay then. :-)

<cky>mark_weaver: BTW, reading scrollback now. Good job on getting srfi-41 into stable-2.0. :-)

<mark_weaver>thanks to you too :)

<cky>Always my pleasure. :-)

<cky>Speaking of changes to THANKS, I should probably change bipt's name to hir preferred name. :-)

<mark_weaver>what's his preferred name?

<cky>BT Templeton (run git log and grep for Templeton).

<wingo>greets

<cky>wingo: o/

<mark_weaver>hi wingo!

<wingo>grothoffhome: thanks!

<grothoffhome>cky: importing logs into Drupal doesn't sound like fun...

<cky>Wow. That does sound hardcore.

<grothoffhome>Nah, not hardcore, just more work than I planned to do.

<cky>Yeah, no worries. :-)

<grothoffhome>You'd likely just have to convert each line of logs to some kind of SQL statement. Still, not fun.

<mark_weaver>grothoffhome: your time would be better spent hacking gnunet :)

<grothoffhome>Exactly ;-)

<cky>mark_weaver: Okay, I've compared the srfi-41 branch and stable-2.0 and they pretty much line up, so I guess I'll clean up and nuke off the srfi-41 branch.

<mark_weaver>cky: sounds good

<cky>Done.

<mark_weaver>it's good to have that item off the TODO list :)

<cky>Yes, at long last. :-)

<mark_weaver>wingo, civodul: I just sent a proposed patch to add a private port structure. If you could take a look soon, that would be super helpful, since I'd like to immediately start building on top of it.

<mark_weaver>(hoping to get BOM handling into 2.0.8)

<wingo>okeysmokes

<mark_weaver>thanks :)

<mark_weaver>maybe 'encoding_type' should be renamed to 'encoding_method'. (I always have trouble with names :)

<mark_weaver>gotta go afk for a bit

<wingo>haha, was commenting on that ;)

<mark_weaver>encoding_type vs encoding_method you mean? :)

*mark_weaver is currently incorporating civodul's feedback

<wingo>mark_weaver: reviewed

<mark_weaver>wingo: awesome, thanks much! :)

<wingo>thank me later; i don't think you will like the review ;)

*mark_weaver looks

<civodul>mark_weaver: BTW, we usually use @defvr {Scheme Variable}, not @defvr {Constant}

<mark_weaver>civodul: okay, would you like to fix it?

<mark_weaver>wingo: all good points. my "thanks" still stands :)

<wingo>cheers :)

<mark_weaver>wingo: I'll try to come up with something that's in better harmony with master.

<mark_weaver>(though I don't see how I can avoid adding an extra indirection to some of those new fields in master, which will be a pain)

<mark_weaver>(but it can certainly be made much more harmonious than what I'd started to do)

<civodul>mark_weaver: in master the contents of scm_t_port_private can be inlined in scm_t_port (but with opaque types, of course)

*civodul is happy to see srfi-41.scm landing on his disk :-)

<wingo>i'm ok with having scm_t_port_internal in master too

<wingo>and not installing ports-internal.h

<wingo>the indirection doesn't bother me at all fwiw, and actually hiding more things there is better for us

<mark_weaver>yeah, I think we should have the infrastructure needed to add more fields within a stable series. we'll want that for 2.2 as well.

<mark_weaver>I'm thinking that I should start by writing patches for master, and then backport to stable-2.0

<mark_weaver>taking scm_t_ports completely internal would be even better, but I don't know whether some users would scream.

<mark_weaver>one thing that doesn't sit entirely well with me is that we always allocate both input and output iconvs, even though many (most?) ports are used only in one direction.

<mark_weaver>well, one thing at a time.

<mark_weaver>our UTF-16 and UTF-32 handling is broken in both stable-2.0 and master.

<mark_weaver>(because the input and output iconvs can choose different endianesses)

<Mike121>UTF-16 is broken in other ways as well, if I recall correctly. w.r.t read-line

<mark_weaver>Mike121: how so?

<Mike121>I'm operating on dim recollection. There is or was some presumption of 8-bit chars in readline.

<Mike121>Or maybe that's OBE.

<mark_weaver>Mike121: do you mean libreadline?

<wingo>we can't take scm_t_port internal i don't think

<wingo>at least not now, and probably not in 2.2

<Mike121>Just a moment. Let me find it

<mark_weaver>wingo: okay

<mark_weaver>wingo: how about making a prefix of the structure public, and a larger internal structure that we can change freely after the public prefix?

<mark_weaver>(I'm not sure quite why we can't do that today, for that matter)

<civodul>mark_weaver: scm_t_port cannot be completely internal because that's the official API to implement new port types :-/

<civodul>having an internal "suffix" is the way to go IMO

<mark_weaver>when users create a new port type, do they allocate the scm_t_port themselves, or do they just use fields in the struct that we allocate?

<civodul>the latter, IIRC

<mark_weaver>in that case, I don't understand why we can't freely add new fields to the end.

<civodul>you can look at, say, r6rs-ports.c for examples

<civodul>ah, hmm

<civodul>users could still fiddle with sizeof (scm_t_port) and such

<civodul>it's really hard to make assumptions

<mark_weaver>if we always allocate the scm_t_port struct, I don't see how that could affect us.

<mark_weaver>I think it's worth putting some thought into this question, because it's going to be a non-trivial amount of work and code complexity to work around this problem. and maybe there's no need to.

<civodul>in theory, you're probably right

<civodul>in practice, i'm uneasy changing the size of a public structure

<mark_weaver>civodul: how would you recommend implementing the "internal suffix" idea?

<mark_weaver>I suppose we could just make an internal copy of the scm_t_port structure, and then add fields to only our internal copy.

<mark_weaver>or make a macro with the contents of the public prefix, and use it to build both the internal and external versions of the structure.

<mark_weaver>I'm trying to think of ways that do not involve mucking up all of the C code with extra redirections.

<mark_weaver>but of course all of these ideas are somewhat gross.

<mark_weaver>the best solution would be to determine that it's safe, in practice, to add to the end of the public structure, given that the users never allocate it themselves.

<mark_weaver>hmm, how about putting the new fields within #ifdef BUILDING_LIBGUILE ?

<civodul>that would be doable

<civodul>but again, i'm not completely confident changing the structure size

<mark_weaver>civodul: what are you worried about? (that's a serious question, so I can investigate and report back)

<mark_weaver>since you suggested an internal suffix, isn't this equivalent to that?

<civodul>for master, yes

<civodul>you're taking about extending scm_t_port in 2.0, right?

<mark_weaver>right

<mark_weaver>we need to do it somehow, in order to fix some bugs.

<civodul>yes, i know ;-)

<mark_weaver>what would be different in 2.2, that would make it okay there but not in 2.0?

<civodul>in 2.2 we can break the ABI; not in 2.0

<civodul>so the question is: does appending new fields break the ABI?

<civodul>as you say, probably not

<civodul>but my concern is that we could overlook cases where it actually breaks the ABI

<mark_weaver>it certainly won't change the structure offsets of the shared prefix. I can tell you that much.

<civodul>yes, sure

<civodul>normally, users don't rely on sizeof (scm_t_port) and such

<civodul>normally...

<mark_weaver>what could they possibly do with sizeof (scm_t_port)?

<civodul>not much

<civodul>they could allocate scm_t_port on the stack, but again, not very useful

<mark_weaver>suppose they did. if we don't ever see it, then it doesn't affect us.

<civodul>heh, right

<mark_weaver>we have no public APIs that take a scm_t_port argument.

<civodul>yeah

<civodul>if wingo is fine, so feel free to try it this way

<mark_weaver>civodul: thanks :)

<civodul>welcome :-)

<mark_weaver>wingo: what do you think? iiuc, civodul has given a green light to adding new fields to the end of scm_t_port in 2.0. (did I get that right civodul?)

<civodul>it's not blinking, but it's green, yes ;-)

<mark_weaver>:)

<Mike121>If all the major Guile-using clients are being built in Nixos or gsrc, then whether you'll break something wouldn't be idle speculation

<civodul>exactly

<civodul>Guix FTW!

<civodul>:-)

<Mike121>Just, for the love of God, don't break autogen. I can't take the angry e-mails. ;-)

<mark_weaver>hehehe

<civodul>haha :-)

<Mike121>mark: wrong about bug. fixed already

<mark_weaver>Mike121: ah, good. thanks for looking into it!

<mark_weaver>well, this makes life in 2.0 much easier.

<wingo>i don't think it would break abi

<wingo>because the standard oo-in-c hack is common

<wingo>where you have struct derived { struct base base; int derived_member; ... }

<wingo>so we could have struct scm_t_port_internal { struct scm_t_port base; iconv foo; ... }

<wingo>guile is in charge of allocating scm_t_port, for many reasons, so that should be fine

<mark_weaver>the question is, do we need even that much? can't we just add to the end of the public scm_t_port?

<wingo>hummmmmm

<civodul>wingo: there are strict aliasing issues with this idiom though...

<civodul>i was thinking of adding the fields in scm_t_port, but with opaque types

<wingo>civodul: are there? you never end up dereferencing one location with different types

<wingo>if you cast as scm_t_port_internal you only access the extra fields

<civodul>you can't do scm_t_port_internal *i = (scm_t_port_internal *) p where p is a scm_t_port *

<wingo>and access to port fields always goes through a scm_t_port pointer

<wingo>sure you can -- aliasing is about dereferencing, not about pointers themselves, right?

<civodul>you're not allow to have two pointer variables of a distinct type pointing to the same thing

<mark_weaver>I think wingo is right on this one, but I guess I'd have to look into it.

<wingo>i don't think that can be correct, as scm_t_port* p = &internal->port is valid

<mark_weaver>but in any case, the aliasing issue doesn't arise at all if we just add to the end of scm_t_port.

<civodul>wingo: yes, this one is correct

<wingo>and in that case internal would be == to port though they are of different types

<mark_weaver>it would be nice to not have to muck up the code with indirections or casts.

<mark_weaver>and it seems to me unnecessary.

<wingo>i'd like to avoid more members exposed in scm_t_port

<mark_weaver>wingo: how about putting the private tail within #ifdef BUILDING_LIBGUILE ?

<wingo>uf, then sizeof_scm_t_port changes...

<mark_weaver>right, but what could a user possibly do with sizeof (scm_t_port) ?

<wingo>dunno

<mark_weaver>I realize these are somewhat messy questions, but the alternative is messy code.

<civodul>wingo: crazy ref: http://thread.gmane.org/gmane.os.hurd.l4/1519

<wingo>wow.

<wingo>reinterpret_cast<>() ;)

<mark_weaver>well, I guess the idea of scm_t_port_internal containing an instance of scm_t_port at the beginning is reasonable.

<wingo>anyway, i need to sleep

<mark_weaver>okay. g'night!

<wingo>night :)

<civodul>mark_weaver: see the thread referenced above

<civodul>it's problematic

<mark_weaver>civodul: reading now, thanks

<mark_weaver>civodul: okay, so maybe wingo's idea is the way to go.

<mark_weaver>that is: <wingo> so we could have struct scm_t_port_internal { struct scm_t_port base; iconv foo; ... }

<mark_weaver>well, I guess we'll all need to sleep on this.

<civodul>yeah :-)

<mark_weaver>it's going to be hard to achieve harmony between the port code in master and stable-2.0.

<civodul>i haven't followed what happened in master

<civodul>that's bad news if things diverge

<mark_weaver>they already have, of course.

<mark_weaver>master has freely added fields to scm_t_port, and moved the iconv pointers into a different structure, with its own finalizer.

<mark_weaver>of course we could change master to be closer to stable-2.0, if we can find a solution that's not too gross.

<mark_weaver>maybe the key is to have two common macros, to get the internal and public ports structures.

<mark_weaver>how those macros work would be different in the two branches, but that's localized.

<mark_weaver>in master, we could do wingo's idea above, and in stable-2.0 we could follow the 'internal' pointer.

<mark_weaver>I'll think on it.

<civodul>yeah

<civodul>g'night/day!

<mark_weaver>good night!

<djcb>ah, nice fedora-19 will have g2

IRC channel logs

2013-03-27.log