IRC channel logs
2013-11-04.log
back to list of logs
<civodul>dje42: are there example gdb/guile scripts in the repo? <dje42>There are some in the testsuite. gdb/testsuite/gdb.guile/*.scm <dje42>There's also a few things in gdb/guile/lib. <civodul>dje42: is (eq? (lookup-global-symbol x) (lookup-global-symbol x)) ? <dje42>Though I can imagine times when it won't be true (gdb's symbol handling is not the best). <civodul>it's about memoizing the c->smob mapping in general <dje42>Have to be careful. gdb can be used to debug really large programs (think 1M symbols, 10K .o files, or 5K shared libraries). <dje42>For most things I can keep the memoization internal to gdb/guile, but for symbols and types it's not clear. It may be better to add something to, e.g. the gdb struct symbol, but that's unlikely to get accepted. <dje42>For now though, I think we could just stick with a local memoization scheme. <civodul>usually, is better when cptr1 == cptr2 ⇒ smob(cptr1) eq? smob(cptr2) <civodul>so it's just that you need a way to go from a C object to its associated SMOB, if any <civodul>it'd be ideal if struct symbol & co. had a void* field that could be used for that <civodul>otherwise you need a hash table and that's not so great <dje42>One tricky bit is the file one is debugrging can go away, but any values kept in gdb's history are kept. When that happens we make a deep copy of, e.g., the type. If one later debugs a program in the same session with the "same" type, we'd need to reconnect them. <dje42>re: void* vs hash table, exactly what I was thinking. <dje42>Plus gdb can debug multiple different programs at the same time. <civodul>do i understand correctly that a SMOB can live longer that its underlying gdb object? <dje42>(eq? 'main 'main) where main is from two different programs is problematic. <dje42>A type would be a better example. <dje42>correct: smob can live longer than it's underlying gdb object. When that happens,e.g. when an objfile goes away, we mark the smob as "invalid". <dje42>Another example is when the function of a frame smob returns. <civodul>and it's not possible to retain the underlying gdb object until the smob itself dies? *civodul guesses it's not so easy <dje42>Interestingly, I implement equal? for symbols using gdb_symbol_ptr1 == gdb_symbol_ptr2. :-) *TaylanUB should fix those weird path-names ... <TaylanUB>Is there a way to make SXML pretty-print XML ? <wingo>do you mean with angle brackets? <TaylanUB>Inserting newlines and indentation, basically. <wingo>newlines and indentation are significant in xml, in general <wingo>pipe it to xmllint if you like <wingo>otherwise there's nothing built-in that does it <nalaginrut>it's strange to learn for/* things when we have delimite-continuation... <TaylanUB>Hrm, I guess I should refrain as long as Guile doesn't support them. <wingo>guile doesn't do #true? we shold fix that <TaylanUB>Oh I don't know .. I kind of assumed it doesn't because I think it's an R7RS-small thing, which isn't even released yet ? <amz3>I takes C input and translate it to Javascript <wingo>it would be terrible, because of gc. better to use an implementation of scheme that targets javascript directly. <wingo>but it would be possible; i heard of people cross-compiling libgc <amz3>Gambit does it for instance <amz3>Also, Mozilla is trying to translate PyPy <amz3>I also think it's a bad idea <amz3>there is also HOP from INRIA which is GPL licensed but requires Bigloo to run/compile <TaylanUB>Yet another Scheme in JS ? We already have literally around two dozen IIRC. <dsmith-work>Everyone knows what's *really* needed is a JS in Scheme. <TaylanUB>Takes a hell lot of time to merely add to 100k in a simple loop. <TaylanUB>1M causes the JS-hanging popup of FF. I'm on a 2.0 GHz machine with FF 18. <ijp>TaylanUB: I presume you've seen the giant list? <TaylanUB>Yeah, was at least around two dozen I reckon. <TaylanUB>Some very complete, too, with call/cc and hygienic macros. <ijp>must be nearer 40 surely <TaylanUB>Could be, I'm taking care not to exaggerate. :P <ijp>and that's the lower bound <wingo>so, (list (a) (b) (c)) isn't the same as (cons (a) (cons (b) (cons (c)))) <wingo>so, (list (a) (b) (c)) isn't the same as (cons (a) (cons (b) (cons (c) '()))) <ijp>wingo: I'll bite. How? <wingo>ijp: same reason as the make-vector / vector-set! thing <wingo>does the continuation of (a) include the allocation of a pair with A in its car or not? <wingo>does the continuation of (a) include the allocation of a pair with B in its car or not? <wingo>or are we save by indeterminate eval order <ijp>well, I would have assumed that it was an undefined eval order thing <wingo>i'm trying to think of a useful test <wingo>maybe they are the same but i smell something <wingo>so in (list (a) (b)) versus (cons (a) (cons (b) '())) <wingo>if you make a call with a == (lambda () 'a) , and same for b <wingo>assume a and b save their continuations <wingo>then you make a return again, and get that result <wingo>then make b return again, and get that result <wingo>in one of those cases, if you are doing conses instead of list, the cdr will be the same -- or something like that? <wingo>regardless of evaluation order <wingo>actually no, you would only have the same cdr if (a) is evaluated before (b) <wingo>point being, there is no way you could make those return values have eq? parts if it's list, and it is possible with cons *wingo fumbles towards truth <TaylanUB>But since the order is undefined, one can never *expect* anything to be eq?, so converting the cons calls to the list call would be legal, but not the other way around ? <wingo>i don't think so -- list isn't cons implies cons isn't list <wingo>if shared structure is visible to cons, and not to list, you can't transform cons into list <wingo>depending on your implementation of "list" of course <ijp>you could still implement list in terms of cons, because arguments are evaluated before the function body is <ijp>but you couldn't do the macro-conversion <wingo>i'm not sure how much i care, is the thing... <TaylanUB>Do the standards say that argument evaluation order needs to be consistent ? <wingo>TaylanUB: no, but tree-il has no way to express argument evaluation order <wingo>so if you need a particular order to ensure correctness for one transform... <wingo>well, i guess you could make a bunch of lets <TaylanUB>BTW excuse my ignorance, is our goal to transform list to conses, or conses to list ? <ijp>TaylanUB: the formal semantics explicitly declaims that idea <wingo>peval works best when a cons string is a list, and rtl works best when it's a bunch of conses <ijp>TaylanUB: "The order of evaluation within a call is unspecified. We mimic that here by applying permutations *permute* and *unpermute*, which must be inverses, to the arguments in a call before and after they are evaluated. This is not quite right since it suggests, incorrectly, that the order of evaluation is constant throughout a program (for any given number of arguments), but it is a closer approximation to the intended semanti <ijp>than a left-to-right evaluation would be" <kurohin>Is there any good module/library for doing stuff with graphs in guile? after it is created I don't need to change it, only query it. I need to connect data to both nodes and edges. It may contain at most 100 000 nodes, around 5-10 edges per node. <wingo>kurohin: nope, probably best to build something yourself <wingo>my graph knowledge is limited to compiler-related things, and those are very custom-built <kurohin>wingo: i was afraid of that, found graphviz module but don't think it does what I need. <ijp>it's hard to write a generically useful graph module <kurohin>ijp: I am going to hate myself for asking this, but why? <ijp>too many conflicting uses <kurohin>you mean things like directed/not directed. performance on different operations, or are you thinking about something else? <ijp>it's basically a truism of data structures that the more general something is, the slower it is <TaylanUB>When argument evaluation is left to right, then a series of cons calls can't get any shared structure through continuation-fiddling, right ?.. If that's true, then any such series could be turned into a list call, "claiming" that the eval order just so happened to be left to right ? <ijp>directed and undirected, weighted vs unweighted. if directed, should an edge know about incoming arcs,... <wingo>TaylanUB: that's probably true, yes -- but doing it that way is a lose -- that's precisely when you want to take advantage of unspecified order of evaluation and do it the other way <wingo>i'm trying to decide how much i care tho <kurohin>ijp: maybe simplier to wrap some C library that fits my use case then. <ijp>maybe, or maybe you could call out to a graphdb <wingo>dunno, it seems to me that if you know graphs, making data structures and algorithms from textbooks is not so bad <ijp>chances of a wrapper for those are probably slim <wingo>perhaps i'm too optimistic tho <wingo>surely there is a scheme graph lib somewhere <kurohin>Have not found any graph lib in scheme yet. I will have to look on creating one as good exercise. <tupi>folks, just did 'reset head' in magit, but that was a mistake. now i have an unpulled commit [why is it not called 'unpushed'], what is the appropriate git ot magit command to push that commit again ? <fangism>tupi: can you reset back to the commit-id you want? <tupi>how do i move HEAD forward? <fangism>tupi: you'd need the commit id of that state, is it in your history? <tupi>it surely is still on the remote i guess let me check <tupi>fangism: i found it yes [and tx for the help] <tupi>now what the reset head unset command ? <fangism>heh, I just learned about the lost-and-found: git fsck −−lost-found <ijp>ideally you would never lose commits in the first place <ijp>that's supposed to be the point of a vcs