IRC channel logs
2016-11-30.log
back to list of logs
<dsmith-work>wingo: Yeah, asyncs.test is hanging about half the time. Like 4 out out 8 runs <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>you can give them printers too <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>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>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>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>a function that only uses vectors procedurally might never require that it be a vector at all <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 <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. <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 <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>the annotation is not required, but you can't use it if the compiler has no other means of figuring it out <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 <wingo>lloda: yes that would be sufficient. would require some more compiler passes to be optimal tho. <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 <wingo>i can think of one reason that maybe it wouldn't work, but that reason doesn't really apply on x86 <wingo>dsmith-work: is this a system built without threads, perhaps? <wingo>dsmith-work: so you have it built then tho <wingo>and you can run ./check-guile async.test ? <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>not always, but just got one <wingo>hubris, rewriting the interrupt-handling code :P <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 <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 <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 :-) <wingo>well, it found a bug that might have been there for a while <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 <ft>dsmith-work: set the height variable to "unlimited" IIRC <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 <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>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? <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>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! <wingo>dsmith-work: pushed a fix i think