IRC channel logs


back to list of logs

<Kleptocracy>Is there a way to make guile not complain about the same binding being imported from multiple libraries and just use the latest imported one?
<mark_weaver>if a module uses #:replace instead of #:export, then it indicates that it is expected that those bindings will replace previous bindings, and it will not warn.
<mark_weaver>for example, this is used in module/srfi/srfi-6.scm
<mark_weaver>on the import side, you can use #:duplicates to tell guile how to handle duplicate imports.
<mark_weaver>see section 6.19.3
<ijp>it can often be cleaner, and more future proof to explicitly import only the subset of bindings you are using, if the subset is small enough
<Kleptocracy>I suppose the latter also works
<Kleptocracy>Given that I only use string-take from srfi 13 here, that's probably quite elegant
<ijp>Kleptocracy: guile includes srfi 13 (and 14) in its base library
<ijp>so it shouldn't need imported
<ijp>(r6rs libraries excepted)
<Kleptocracy>I am using guile in r6rs mode.
<ijp>makes sense
<ijp>only is the way to go
<mark_weaver>so use the (import (only (srfi-13) string-take)) syntax
<Kleptocracy>Especially when you only use one function yeah I guess
<Kleptocracy>Yeah, I just did, works well.
<mark_weaver>s/srfi-13/srfi srfi-13/
<Kleptocracy>srfi :13 it is I believe actually
<mark_weaver>there's also 'except'.
<mark_weaver>right, that's more portable.
<mark_weaver>Kleptocracy: out of curiosity, what duplicate binding was reported?
<mark_weaver>If R6RS libraries can't import SRFI-13 without a warning, we should probably fix that.
<ijp>mark_weaver: the r6rs string functions may be different because they throw different errors
<ijp>I'd need to double check the source
<mark_weaver>we really ought to unify this, along the lines of the R6RS exceptions work I recently pushed.
<ijp>the only one I see being redefined in (rnrs base) is string-for-each
<mark_weaver>hmm, I wonder why
<ijp>it takes different arguments
<ijp>it can take multiple strings, srfi 13 string-for-each can take a range
<mark_weaver>we should probably change our SRFI-13 module to export 'string-for-each' using #:replace.
<dje42>Various Scheme code that I've read use a "make" function to create an object of a certain class. E.g., the GOOPS section of the manual has (define c (make <my-complex>)).
<dje42>Is it at least not uncommon for a "make" function to have side effects?
<dje42>I'm guessing not, but figured I'd ask.
<dje42>I ask because my current version of the gdb/guile port has a function named make-breakpoint that creates a breakpoint object and has the side-effect of installing it in gdb.
<dje42>I'm thinking its misnamed, and something like define-breakpoint or create-breakpoint would be better.
<mark_weaver>I wouldn't worry about a make procedure having side effects, but personally I don't like any of those names.
<mark_weaver>well, I certainly don't like 'define-breakpoint'. create and make are pretty much synonyms, so I don't see either one as better than the other.
<mark_weaver>but admittedly, coming up with good names is often hard.
<dje42>One thought I had was make-breakpoint (no side effects) + install-breakpoint!. But I can't really think of a need to split up the steps.
<mark_weaver>I think the name should indicate not that something is being created or defined, but rather that it's being installed or set or something.
<mark_weaver>install-breakpoint! seems reasonable to me.
<dje42>Not that we aren't into bikeshed territory here :-) but how about create = make + install. That way I can have just create-breakpoint today, leaving make+install for some hypothetical future when the separation is useful.
<dje42>[I like create over install ...]
<mark_weaver>okay :)
<dje42>Naming is hard. But I do like to spend some time on it.
<mark_weaver>in my experience, coming up with good names is often the hardest part of any hacking job.
<mark_weaver>one question though: you're tying together creation of these objects with installation of breakpoints, but what about removing the breakpoints?
<mark_weaver>what happens if your breakpoint object is GCed?
<dje42>It's scm_gc_protect_object'd until the breakpoint is deleted from gdb.
<mark_weaver>I guess the closest analogue would be ports, which are always opened as part of creation, and it's possible to close them explicitly, but they're also closed automatically if GCed.
<mark_weaver>if no references to the breakpoint object remain, is there any way for the breakpoint to be deleted?
<dje42>There is the breakpoint-delete! function. It's akin to doing "delete bp#" from the gdb command line.
<Kleptocracy>mark_weaver, well, I used srfi-1's make-list and srfi-13's string-take
<mark_weaver>I guess I'm not sure why you'd deliberately keep the object alive if there's no way for the program to get at it.
<Kleptocracy>And a lot of bindings exported by those libraris were reported as dupes from rnrs (6)
<ijp>Kleptocracy: can you paste a list?
<mark_weaver>Kleptocracy: thanks for bringing this to my attention. we should change a bunch of those exports to use #:replace instead
<ijp>mark_weaver: I'd be a little wary about that in r6rs code
<Kleptocracy>Truth be told, I don't really like the srfi naming scheme all that much, I'd rather the string library just exported 'take' instead of string-take, then you could just string:take as a prefix, string:string-take looks a bit silly.
<ijp>it wouldn't be portable
<ijp>Kleptocracy: they predate a portable module system
<Kleptocracy>Yeah, I know.
<dje42>A reference to the breakpoint exists inside gdb. One way to get a reference is with the (breakpoints) function which returns a list of all breakpoints (that are created in gdb).
<ijp>that said, I do the same in pfds, and I don't have that excuse
<Kleptocracy>I really like how OCaml does this, you just use Float.from_int where Float. is the module namespace
<Kleptocracy>The function itself is called 'from int'.
<mark_weaver>ijp: I'm not talking about r6rs code though. I'm talking about our srfi-1 and srfi-13 libraries, and perhaps some others.
<Kleptocracy>Someone make an SRFI which defines how to rename other SRFI!
<Kleptocracy>mark_weaver, well, this is SRFI
<Kleptocracy>Ehh, r6rs
<Kleptocracy>I'm not sure the problem also exists in normal guile code, I use the r6rs module system
<ijp>mark_weaver: for srfi-13, this is not a problem in guile
<ijp>srfi 1 might be
<mark_weaver>my point is that people should be able to import the SRFIs into R6RS libraries without getting a bunch of warnings.
<mark_weaver>historically, we've decided whether to use #:export or #:replace depending on whether the export conflicts with something already in (guile). I'm saying that we should use #:replace whenever an export would conflict with either (guile) or (rnrs base).
<ijp>I'd like to see the list
<mark_weaver>and R7RS (scheme base) in the future as well
<Kleptocracy>mark_weaver, map is a culprit on srfi1
<ijp>for some, it may be a red herring, and that is a bug
<ijp>map is redefined in (rnrs base)
<ijp>it was for cycle detection, but we do that in guile now
<ijp>but to take the example above, I would *not* like to see string-for-each replace without a warning
<ijp>the two have different behaviours, and the user should know about that
<mark_weaver>another difference between various 'map' implementations is whether they raise an error when given lists of different lengths.
<mark_weaver>I had to implement a bunch of new procedures for R7RS because R7RS stops at the shortest list/vector/string/whatever.
<Kleptocracy>WARNING: (guile-user): `map' imported from both (rnrs) and (srfi srfi-1)
<Kleptocracy>this is one
<ijp>dje42: this seems to be the preferred behaviour in scheme, and haskells zipWithN does the same
<ijp>Racket disagrees; I'm on the fence.
<dje42>I dunno. I could be misunderstanding, but what if there's a difference in length due to a bug?
<dje42>I can see having lazy-map or some such. But plain map should be strict (IMO I think).
<mark_weaver>I think that R6RS/R7RS should be able to import a SRFI without getting a bunch of warnings that aren't easy to silence.
<Kleptocracy>I think that the srfi's should have a re-export option rather
<Kleptocracy>That, or that a user should be able to define an order.
<ijp>mark_weaver: 1 and 13 are probably the only real offenders
<Kleptocracy>43 as well
<ijp>(in practice)
<Kleptocracy>And 1 and 13 are the most commonly used
<ijp>Kleptocracy: why 43?
<Kleptocracy>THat's the vector one no?
<ijp>yes, but the only overlap would be vector-for-each
<mark_weaver>Guile doesn't have that one yet, but yeah, that one too.
<ijp>which should be the same
<Kleptocracy>and vector-ref and vector-length
<ijp>right, but these should all be the *exact* same procedure
<Kleptocracy>Guile doesn't have 43?
<Kleptocracy>I thought it was super ubiquitous
<mark_weaver>not yet.
<ijp>at which point, multiple imports are harmless
<Kleptocracy>Well yeah, but it will still complain
<mark_weaver>I have a partial implementation.
<Kleptocracy>It is harmless
<Kleptocracy>But it still complains.
<mark_weaver>I think it won't complain if the binding is to the same variable.
<Kleptocracy>mark_weaver, it shouldn't be hard to steal another implementation right?
<ijp>where they *differ* (as with map, and string-for-each above) this should be an error
<Kleptocracy>How does map in srfi1 differ from r6rs?
<mark_weaver>Kleptocracy: I'd guess that the reference implementation probably works as-is.
<ijp>Kleptocracy: length checking
<Kleptocracy>ijp, explain?
<Kleptocracy>mark_weaver, so why not steal it?
<Kleptocracy>Theft is cool
<ijp>(map list (list 1 2 3) (list 4 5 6 7))
<ijp>what should it be?
<ijp>(@ (rnrs base) map) says error, (@ (srfi :1 lists) map) says ((1 4) (2 5) (3 6))
<ijp>what we could do, is suppress the warnings if the procedures aren't used (which we may do already)
<Kleptocracy>r6rs says that should be an error?
<ijp>Kleptocracy: I'd need to double check, but our *implementation* says it errors
<ijp>"Implementation responsibilities: The implementation should check that the lists all have the same length. The implementation must check the restrictions on proc to the extent performed by applying it as described. An implementation may check whether proc is an appropriate argument before applying it."
<Kleptocracy>"Implementation responsibilities: The implementation should check that the lists all have the same length. "
<Kleptocracy>I had no idea
<Kleptocracy>Everywhere I encounter map it has always defaulted to the shorest list for me
<Kleptocracy>Doesn't like almopst every scheme implementation just default to the length of the shortest in that case?
<ijp>I defer to rfc 6919 on this matter
<ijp>Kleptocracy: racket does not
<ijp>srfi 1 does
<ijp>the r5rs is silent IIRC
<ijp>well, it says "they must all be the same length", but everyone does what they like
<ijp>the point was: different procedures, different behaviours, silent errors are a no go (IMO)
<Kleptocracy>Hmm, racket gives me no error in r5 mode but does in r6.
<Kleptocracy>Did this change with r6?
<Kleptocracy>I don't think errors should ever be silent, I just think there should be a flag in the import itself to be able to assign a praecedence to imports
<ijp>Kleptocracy: the r5rs says they must all be the same length, but r5rs error behaviour is "do what you like"
<mark_weaver>ijp: so then there's no way to import any of the changed bindings from SRFI's into R6RS code without getting warnings that cannot be silenced?
<ijp>mark_weaver: they can be silence by not importing those bindings
<mark_weaver>what if you want the changed bindings?
<Kleptocracy>I feel that at the very least different length behaviour should be unspecified in r6
<Kleptocracy>Silly standard girls
<ijp>mark_weaver: then don't import them from rnrs base
<ijp>(import (except (rnrs base) map) (srfi :1))
<Kleptocracy>That creates pretty convoluted syntax thoughj
<Kleptocracy>If there are multiple.
<mark_weaver>I really find that unfriendly.
<ijp>don't error if they aren't used is fine with me
<Kleptocracy>(import overwrite (rnrs base) (srfi :1))
<Kleptocracy>would be better
<ijp>but if the binding is used, we shouldn't just pick one
<Kleptocracy>Later imports' bindings overwrite formers
<ijp>Kleptocracy: why use r6rs modules if you are going to invent nonstandard syntax?
<Kleptocracy>Well, I'm saying it should be part of the r6 module system
<Kleptocracy>A way to deal with conflics
<mark_weaver>Kleptocracy: that ship has sailed.
<ijp>if this were any other library than srfis, you would not even be arguing with me
<Kleptocracy>Time machine, ez
<Kleptocracy>I would.
<Kleptocracy>At least about the part that there should be a way to resolve conflict ambiguities
<ijp>there are four ways to resolve it. only, except, rename, prefix
<Kleptocracy>THose do not resolve them, those stop them from happening
<mark_weaver>what do other R6RS implementations do when you import SRFI-1 or SRFI-13?
<Kleptocracy>Resolving a conflict ambiguity is just defining a system that unambiguously defines which binding should be imported in the event that two bindings with the same name get imported
<ijp>the only other one I have installed at the moment is racket, and they do what we do
<Kleptocracy>Racket just refuses in this case
<ijp>but I'd bet good money on the rest doing the same
<Kleptocracy>You cannot import srfi1 and rnrs base at the same time without rename or prefix or that stuff.
<Kleptocracy>Well, guile gives you a warning but does it anyway, racket just refues to compile
<mark_weaver>okay. well, fair enough. if you want to write portable R6RS code, you have to avoid importing the same binding from two libraries, so I guess I'm okay with leaving things as they are.
<Kleptocracy>I don't think this is something guile should change but something that should've been in the r6rs module system from the start.
<ijp>I know haskell doesn't let you, but won't complain unless you use them
<Kleptocracy>Haskell's praefixes are also actual namespaces though
<Kleptocracy>Not some ad hoc thing attached to the identifier.
<ijp>excuse me?
<Kleptocracy>As in, in Scheme it is possible to have a library export list:map and still get a conflict even though someone used a praefix.
<Kleptocracy>You can't have full library hygiene if you will, it's always possible to break it.
<ijp>list:map is an identifier
<Kleptocracy>Yeah, therein lies the problem.
<ijp>: is not special
<Kleptocracy>Indeed, . in Haskell is
<ijp>right, now I get you
<Kleptocracy>You can't just name a function, List. is the namespace, map the name
<ijp>well, there are "philosophical" reasons for that
<Kleptocracy>The proper way would be (namespace list map) but that would get exceedingly verbose
<ijp>which is (apparently) that all identifier unniceness goes in #
<Kleptocracy>Well, say existed as reader macro for (namespace list map)
<Kleptocracy>Or something like that
<mark_weaver>Kleptocracy: Guile has a syntax (@ (srfi srfi-1) map) that does what you want, i guess.
<Kleptocracy>Hmm, I guess that's kind of nice, it's not even a reader macro looking at it
<mark_weaver>it's core syntax
<ijp>(also not portable)
<Kleptocracy>I figured as much.
<Kleptocracy>OCaml, if you just use Foo.bla it actually looks for a file named in the same directory. No need to import it.
<Kleptocracy>It's kind of handy.
<mark_weaver>with the guile '@' syntax, you don't have to import either.
<ijp>there is also @@, which is @'s naughty cousin
<mark_weaver>however, I'm not advocating its use.
<Kleptocracy>So (@ (bla) foo) looks for foo.scm in the same dir?
<ijp>and load path
<mark_weaver>no, it looks for bla.scm in the %load-path
<Kleptocracy>I don't really mind that stuff, I think these modules with massive importas at the top often onky importing one binding are overrated
<Kleptocracy>If you only use one binding just using something like (@(srfi :13) substring/shared) doesn't hurt
<mark_weaver>you can't use the (srfi :13) style with that syntax, nor with most of the guile module import stuff.
<mark_weaver>module names like (srfi :13) are only converted to (srfi srfi-13) as part of the R6RS 'import' syntax.
<mark_weaver>I'm thinking of changing that though.
<mark_weaver>In R7RS, the module name is (srfi 13)
<ijp>which is more sensible
<mark_weaver>so many standards to choose from :)
<Kleptocracy>Why is it changed in r7?
<Kleptocracy>I mean, is there anyhing wrong with :13?
<Kleptocracy>13 isn't really a number in that sense as much as a name anyway
<ijp>Kleptocracy: while they were changing the module system, they figured they'd fix that little detail
<ijp>the : was added to the numbers in srfi 97 because module name lists could only contain identifiers (and numbers are not identifiers)
<Kleptocracy>Yeah, I know, but I guess the point is that they aren't really numbers in srfi
<Kleptocracy>THey don't make much sense as numbers
<ijp>the nice thing about srfi 97 was they gave them names as well as numbers
<mark_weaver>This conversation involves way too much bikeshedding for my taste.
<Kleptocracy>What's bikeshedding?
<ijp>Kleptocracy: arguing about irrelevant details, rather than bigpicture stuff
<Kleptocracy>Well, it is.
<Kleptocracy>Completely and utterly irrelevant
<Kleptocracy>But you raised it and I disagree so I make my case
<ijp>so say you design a module system, there are many important points to cover: namespacing, module lookup, existence or lack thereof of module functors, etc. etc.
<ijp>they will get 10% of the conversation, and 90% will go to the syntax
<Kleptocracy>You have to admit that you will never use the srfi identifiers as numbers, you don't add them, compare them, subtract them.
<Kleptocracy>This is true.
<Kleptocracy>But still
<Kleptocracy>THey actually invested time into changing it from srfi :1 to srrfi 1
<Kleptocracy>While the old solution worked fine and is arguably semantically better because they aren't numbers
<ijp>they did change more than that
<Kleptocracy>Well yes, but they still invested time on changing that part
<Kleptocracy>But do you agree or not that they aren't numbers?
<ijp>I really don't care
<ijp>as long as you don't propose a unary syntax, I'm happy
<ijp>i.e. no (srfi (s (s (s (s (s (s (s (s (s (s (s (s (s z))))))))))))))
<mark_weaver>Why are we wasting time talking about standards that have already been published? Especially given that no one active here on channel had much to do with their creation?
<Kleptocracy>We're not talking about standards
<mark_weaver>This is just a waste of time.
<Kleptocracy>We're talking about whether it's numbers
<ijp>I just assumed it *was* meant as idle chat
<Kleptocracy>It is neurotic.
<ijp>since it's 3am and I have nothing better to do
<Kleptocracy>Either you defend the position that you are numbers, relent that they are not numbers, or I will go crazy, thatis how it works.
<Kleptocracy>that they are numbers*
<mark_weaver>Yes, R7RS allows both identifiers and exact integers in the module name lists. I don't know why they wasted time on that, but frankly I think it's an improvement.
<mark_weaver>in most areas, however, I prefer R6RS.
<ijp>ditto for #true and #false
<ijp>as loath as I am to see more go under #
<Kleptocracy>It's an improvement insofar numbers are part of the name. If it makes sense to perform arithmetic on them
<Kleptocracy>#true and #false have supplemented #t and #f?
<mark_weaver>R7RS recognizes #true and #false as alternative syntax for #t and #f.
<ijp>I've had bindings for false and true in my utils for a while, but since they don't print that way, it's of limited utility
<mark_weaver>btw, I have a fairly complete implementation of R7RS on Guile now.
<Kleptocracy>Did they invent that or did implementations actually support that before r7?
<mark_weaver>they invented it.
<ijp>Kleptocracy: with chibi involved, it's hard to say
<Kleptocracy>Who's chibi?
<Kleptocracy>Sounds like a drawing with a large head.
<ijp>alex's shinns scheme implemenation, which aims to be the r7rs reference implementation
<mark_weaver>Alex Shinn was the chair of the working group that created R7RS small.
<ijp>it's plausible he could add something to chibi, and then propose it, but that's close to conspiracy mongering
<Kleptocracy>Ahh, well.
<Kleptocracy>The real issue is though, is there a need for r7?
<ijp>I'm not getting into that discussion
<Kleptocracy>Like, the Dutch language academy publishes a new standard every 5 years it seems and a lot of the changes are seemingly just to amke random changes and get paid for it.
<mark_weaver>I think R6RS is superior, but some implementors didn't like it, so R7RS was created by the folks that didn't like R6RS, basically.
<Kleptocracy>Well, I like the small separation
<Kleptocracy>I don't know, it seems like python 3 all over agian.
<Kleptocracy>r6 had a major reason to move over from r5, portable modules.
<mark_weaver>What really sucks is that R7RS is gratuitously incompatible with R6RS in a number of respects.
<Kleptocracy>Is there a super good reason to move to r7?
<mark_weaver>I think not.
<mark_weaver>personally, I'd stick with R6RS.
<Kleptocracy>Would there be if r7 introduced a way to solve the naming conflict?
<mark_weaver>what naming conflict?
<ijp>the duplicates issue earlier
<mark_weaver>oh please, that's totally trivial compared to the substantial differences between R6RS and R7RS.
<Kleptocracy>The reason we are talking about nothing at 04:15:26 in the morning
<Kleptocracy>I'd totally switch if it solved that.
<ijp>the promotion of cond expand was weird I though
<Kleptocracy>What is that
<mark_weaver>it's very silly to declare that you'd switch to R7RS for a single reason, without having any idea what the other differences are.
<Kleptocracy>mark_weaver, this reason is very important though.
<ijp>Kleptocracy: srfi 1, a way to expand conditionally based on certain aspects of the implemenation
<ijp>in guile it mostly gets used for 1/2 differences
<mark_weaver>srfi 0 you mean
<ijp>uh, of course
<ijp>I actually typed in 0 first, and then changed it
<mark_weaver>Kleptocracy: I think you'd find that there are far more important reasons to favor R6RS.
<Kleptocracy>mark_weaver, such as?
<Kleptocracy>Where does it go wrong in your opinion.
<ijp>being well defined
<ijp>having a standard library that is not completely optional
<Kleptocracy>This namespace thing is like non hygienic macros, it's a big deal breaker.
<Kleptocracy>That's a good thing
<Kleptocracy>standard libraries are bad
<ijp>a portable procedural macro system
<Kleptocracy>r7 does not have syntax-case?
<ijp>small doesn't
<Kleptocracy>THat's good.
<Kleptocracy>As long as it's in large or in some srfi it's cool
<ijp><Kleptocracy> standard libraries are bad
<Kleptocracy>Small shouldn't have a macro system really.
<Kleptocracy>libraries are good
<ijp>but standards are bad?
<mark_weaver>okay, I'm done with this conversation.
<Kleptocracy>but a standard should not proscribe which libraries to have
<Kleptocracy>No, standards are good
<ijp>anyway, this conversation will only rile me up, so I'm off
<Kleptocracy>But a standard shouldn't say "You must support this standard!", it should say "If you support it, we'd like to ensure that everyone supports it in the same way."
<Kleptocracy>I'm perfectly fine wityh scheme implementations existing that only support integers as long as they advertise it
<ijp>just FYI <ijp> leppie: suppose I import two different functions with the same name in iron scheme <ijp> does it error, warn, or pick one? <leppie> in the repl it will bind to whatever was loaded at that point of time, in a program/library it will error as required by the spec
<ijp><ijp> leppie: does it error, even in the name isn't used? <leppie> ijp: yes, if it was imported and clashes
<ijp><leppie> it also depends where it was imported <leppie> local imports will shadow
<mark_weaver>R6RS section 7.1 states "An identifier can be imported with the same local name from two or more libraries or for two levels from the same library only if the binding exported by each library is the same (i.e., the binding is defined in one library, and it arrives through the imports only by exporting and re-exporting). Otherwise, no identifier can be imported multiple times, defined multiple times, or both defined and
<mark_weaver>I'm okay with that. I guess strictness is good.
<mark_weaver>ah, I see that got truncated. It ends with "or both defined and imported."
<mark_weaver>so portable code will have to avoid duplicate imports anyway.
<mark_weaver>mainly, I just wanted to avoid unavoidable warnings on standards-conforming code.
<mark_wea_>Emacs' mode for editing C is extremely inefficient, to the point that it's very painful to use on less powerful hardware.
<mark_wea_>I've actually resorted to switching to fundamental mode just to get work done.
***Kleptocracy is now known as Dolfje
<ArneBab__>mark_wea_: regarding multi-language guile: I realized that “keep the language by default” should actually produce the correct results most of the time, because built-in and installed modules should already be precompiled. So it would only become problematic when people mix projects written in different languages and do development in both projects at the same time.
<ArneBab__>I had wondered for some time, why I did not experience the problems I expected when I worked with wisp-at-the-REPL. The answer was, that I only used guile-built-in modules and guile-www - both of which where installed via my distro.
<ArneBab__>so I think a general automagic solution isn’t necessary. For people who actually need to do cross-language development (like guile-developers who use a different language for testing guile modules), the issue could either be solved with a build-system (dependency on module.go) or some option for use-modules - but most regular users will never need to touch this, even if they use different languages than guile scheme
<civodul>Hello Guilers!
<wackonline>Hi all, I want to ask the define-syntax _ and...Symbols are what mean
<wackonline>hi all,i want ask _and... is what mean of define-syntax
<wackonline>hi,you online?
<civodul>test ok
<waxysubs>The thing is, I'm logged into freenode from my server via waxysubs, and from my laptop via mark_weaver, but mark_weaver can't see that waxysubs is logged in.
<waxysubs>must be some netsplit within the freenode network I guess.
<waxysubs>also, mark_weaver can't see some of the recent comments on #guix
<waxysubs>I logged mark_weaver off and on again, and it still can't see waxysubs, nor any of this conversation, and I can't see the test that mark_weaver just posted.
<waxysubs>well, I'm sure they'll sort it out eventually...
<mark_weaver>ah, looks like things are back to normal now.
<mark_weaver>both mark_weaver and waxysubs just saw all the messages they've been missing from each other.
<civodul>mark_weaver: there have been series of disconnects; that could be an indication that something is wrong with Freenode
***micro` is now known as Guest3074
<mark_weaver>hmm. does anyone know how to display the contents of a guile hash table from gdb?
<mark_weaver>I guess I can come up with something based on the 'pp' macro in gdbinit.
<mark_weaver>ah, looks like that macro can be simplified now that we have scm_c_public_ref
<civodul>mark_weaver: maybe call scm_c_eval_string("(hash-fold ...)")