IRC channel logs


back to list of logs

<dsmith-work>wingo: Yeah, asyncs.test is hanging about half the time. Like 4 out out 8 runs
<dsmith-work>out of
<lloda>wingo: applicable structs, why isn't there more info in the manual? how much of a hack are they? can they be defined from Scheme? do they require GOOPS? would it make sense to make some of the standard data structures applicable (say, hash tables)? wdyt
<wingo>mm, they are not a terribly bad hack, dunno. there's no reason for them to be slower as long as you're already doing an indirect procedure call
<wingo>you can make them in scheme, yes
<wingo>ACTION looks for incantation
<wingo>scheme@(guile-user)> (define <my-applicable-record> (make-struct/no-tail <applicable-struct-vtable> (make-struct-layout "pw")))
<wingo>scheme@(guile-user)> <my-applicable-record>
<wingo>$7 = #<<applicable-struct-vtable> 1d55fa0>
<wingo>scheme@(guile-user)> (make-struct/no-tail $7 pk)
<wingo>$8 = #<struct:1d55fa0 pw 1cbba20 proc: #<procedure peek stuff>>
<wingo>($8 'foo)
<wingo>;;; (foo)
<wingo>$9 = foo
<wingo>you can give them printers too
<wingo>it's not a bad facility
<wingo>as to whether more data types should be applicable, that i don't know :) it is a bit of a language design question :)
<lloda>ah, thanks :)
<lloda>I suppose it is a language design question.
<lloda>anything that you'd do DATA[FIELD] or DATA[SUBSCRIPTS...] in other languages might be a good candidate...
<wingo>clojure's a good inspiration, i think
<davexunit>the idea that only a procedure can be applicable seems... draconian, in a way.
<davexunit>what did you say once in a talk, wingo? "god gave us lambda, and lambda will suffice"?
<wingo>dunno :)
<wingo>i mean it's enough but you want more than that; numbers are a win, for example :)
<davexunit>I think you said this after bringing up clojure's applicable data structures and how they seemed like a good idea.
<wingo>could be. procedural data certainly makes flow analysis harder
<wingo>if you see (foo 0) you don't know much about what happens
<wingo>whereas if you see (vector-ref foo 0) you know, provided that vector-ref is bound to its normal value
<wingo>that has an impact on readability too. but, i dunno, there are other good points in this design space :)
<davexunit>yeah I'm not sure which side of the fence I fall on.
<wingo>yeah and there's also things like having a nice iteration protocol
<wingo>like racket's for
<wingo>which is also moving in the direction of a more generic programming model
<lloda>isn't that what annotations or inference are for. Most of the time the compiler should know that foo is a vector, it could tell your editor, etc.
<wingo>lloda: currently the things that tell you that "foo" is a vector are the vector-length etc accessors
<wingo>s/you/the compiler/
<wingo>a function that only uses vectors procedurally might never require that it be a vector at all
<wingo>could be entirely generic
<wingo>which is cool for the programmer; bad for the ahead-of-time compiler :)
<davexunit>maybe this doesn't make sense, but it would be nice if the code (#(1 2 3) 0) was "expanded" (for lack of a better term) to (vector-ref #(1 2 3) 0)
<wingo>davexunit: when would you write that tho?
<wingo>i mean you never put a literal in the operator position
<davexunit>oh, this was just a trivial example
<wingo>heh but the real example is (foo 0)
<davexunit>replace #(1 2 3) with "foo", a variable containing a vector
<davexunit>right, so you need to know that "foo" is a variable whose value is a vector
<davexunit>it all makes sense now. thanks for bearing with me.
<wingo>hmm :)
<lloda>I'd still prefer to have an annotation at the top of the function and save all the -ref for the rest of it, I think
<davexunit>I don't understand what that means
<davexunit>"annotation" sounds not good.
<lloda>(define (f vector-but-the-compiler-wouldnt-know: VECTOR) (+ (f 0) (f 1)))
<lloda>(define (fun vector-but-the-compiler-wouldnt-know: VECTOR) (+ (f 0) (f 1)))
<lloda>(define (fun f: VECTOR) (+ (f 0) (f 1)))
<davexunit>I wouldn't like applicable structs if the cost was some weird annotation syntax
<lloda>or something
<lloda>the annotation is not required, but you can't use it if the compiler has no other means of figuring it out
<lloda>I think racket has them
<lloda>you can't/you can, wow
<davexunit>this sounds like a separate issue to me
<davexunit>static typing
<civodul>the dreaded words!
<lloda>static type with inference -><- dynamic type with annotations :p
<lloda>or you could just put (unless (vector? v) (error)) at the top of the function, which should have the same effect
<dsmith-work>Wednesday Greetings, Guilers
<wingo>lloda: yes that would be sufficient. would require some more compiler passes to be optimal tho.
<wingo>dsmith-work: hey
<wingo>do you have access to the failure?
<wingo>i.e. to the machine that's hanging in async.test
<wingo>alternately is anyone else experiencing that problem
<dsmith-work>I do
<OrangeShark>hello everyone
<wingo>good evening OrangeShark
<wingo>i can think of one reason that maybe it wouldn't work, but that reason doesn't really apply on x86
<wingo>so, weird.
<wingo>dsmith-work: is this a system built without threads, perhaps?
<dsmith-work>wingo: Just plain ./configure
<dsmith-work>wingo: amd64
<dsmith-work>wingo: 4 cores
<wingo>dsmith-work: so you have it built then tho
<wingo>and you can run ./check-guile async.test ?
<paroneayea>watching this really nice talk on webassembly while I crunch through my unread email
<dsmith-work>wingo: Yes, I have it hung right now.
<paroneayea>the s-expression syntax they have is pretty nice IMO, though they said it's temporary and hope to replace it with curly braces and etc "but we realize that's what the lisp people said back in the day"
<paroneayea>ACTION wouldn't mind that staying the representation...
<wingo>dsmith-work: i assume it's hung at 100% cpu, yes?
<wingo>ah no? interesting
<wingo>can you gdb -p PID
<wingo>and thr apply all bt
<wingo>and throw that in a ?
<wingo>oooh i have one too
<wingo>not always, but just got one
<wingo>hubris, rewriting the interrupt-handling code :P
<wingo>yes that is my bt also
<dsmith-work>two read's and a cond_wait
<wingo>dsmith-work: do you know the revision at which this problem appeared?
<wingo>i think it's stuck in the join-thread at the bottom of asyncs.test
<dsmith-work>wingo: No sorry.
<wingo>np :)
<wingo>i have it here so that's good enough
<dsmith-work>Somewhere between that last fix for the other problem and now. ;^)
<OrangeShark>I am wondering what would be the best way to handle these foreach C functions in libgit2. They take a callback function that returns an int, if the callback returns a 0, it stops the iteration. Was wondering if the scheme bindings should be the same for the callback or should the callback return #f or a symbol to indicate when to stop.
<wingo>the best part about threading bugs is when you add a printf and the prob goes away
<dsmith-work>Oh the joy!
<paroneayea>wingo: so I think a lonnnnng time ago I pinged you about asm.js and webassembly as guile outputs, and I think you mentioned one challenge being the gc, and having a separate heap from the js heap... it looks like that stuff is being considered/addressed, sorta
<paroneayea>wingo: for one thing, it looks like about 45 minutes into the linked talk they talk about exposing the browser garbage collector
<paroneayea>anyway, not super important or urgent to anything, just interesting
<wingo>i am following that at a distance but afaiu that's not yet a thing
<wingo>dsmith-work: you found a deep threading bug! nice :-)
<paroneayea>wingo: yah, not a thing yet
<paroneayea>but interesting to watch develop!
<paroneayea>I still have hope for guile -> browser
<dsmith-work>wingo: Nah. Your async.test found it
<dsmith-work>That's why it's there
<wingo>well, it found a bug that might have been there for a while
<wingo>or maybe i introduced it
<wingo>will find out soon :)
<dsmith-work>wingo: Do you know how to get rid of those "press return to contine" prompts from gdb?
<wingo>dsmith-work: in a backtrace? i can't remember
<wingo>blah this is a deep bug :P
<ft>dsmith-work: set the height variable to "unlimited" IIRC
<dsmith-work>ft: Thanks!
<dsmith-work>Setting this to "unlimited" or zero causes GDB never pause during output.
<sapientech>wingo: lloda: fyi parameters are an applicable struct you can reference
<sapientech>wingo: lloda: one limitation to the above method, is that its impossible to make an applicable struct meta-vtable
<davexunit>I thought parameters were just procedures
<sapientech>i added that functionality in structs.c though if yall are interested in adding it
<sapientech>for example, i wanted to modify records to be applicable, which required i change the rec meta-vtable to be applicable
<sapientech>davexunit: boot-9.scm:1318
<sapientech>or around there :)
<wingo>neat :)
<sapientech>civodul: looking over your monads module, really cool! Real interesting how you define a monad macro, that changes >>= and ret with syntax-parameterize
<sapientech>question about syntax-parameters: in the manual it says how they are useful for making a lambda with an optional return literal
<sapientech>but earlier on, the manual shows how to do anaphoric if, and uses (with-syntax ...)
<sapientech>could you not use syntax parameters in place of with-syntax, and sometimes vis-versa?
<sapientech>sorry 4 the wall of text!
<wingo>ACTION looks
<wingo>sapientech: yes -- advantage of syntax-parameters is that they can be renamed
<wingo>i think that "best practice", such as it exists, is to use syntax-parameters where possible for things like anaphoric if
<wingo>because it lets you rebind the "it" variable
<wingo>but they are both available :)
<sapientech>wingo: thanks for checking. so for instance if we had nested aif, w/syn would have issues?
<wingo>sapientech: i think it's less for nested aif -- in that case you could bind different lexical vars -- than for different macros using the "it" identifier in different ways
<wingo>but maybe there i don't have that right :)
<wingo>been a while since i paged this in...
<wingo>as usual racket probably has something coherent to say in this area that we should steal
<sapientech>wingo: yeah just tried nested, since each macro lexically defs it, we dont have probs
<paroneayea>here's a talk I submitted to LibrePlanet
<paroneayea>"The Lisp Machine and GNU"
<paroneayea>I also submitted a federation one, so either (or both?) would be good.
<sapientech>i see though in terms of wanting to change core functionality of an existing syn-param. thanks!
<sapientech>paroneayea: very cool!
<paroneayea>thanks sapientech :)
<wingo>dsmith-work: pushed a fix i think
<wingo>give it a go!