IRC channel logs


back to list of logs

<grothoffhome>mark_weaver asked me to add an IRC log bot for #guile.
<grothoffhome>So here it is (public logs):
<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, 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).
<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
<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)
<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>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
<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>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 ;-)
<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>Guix FTW!
<Mike121>Just, for the love of God, don't break autogen. I can't take the angry e-mails. ;-)
<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?
<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) ?
<mark_weaver>I realize these are somewhat messy questions, but the alternative is messy code.
<civodul>wingo: crazy ref:
<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.
<mark_weaver>good night!
<djcb>ah, nice fedora-19 will have g2