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>yeah i've seen that part
<civodul>arf, dejagnu :-)
<civodul>dje42: is (eq? (lookup-global-symbol x) (lookup-global-symbol x)) ?
<civodul>i think it should
<dje42>Feels like it.
<dje42>Though I can imagine times when it won't be true (gdb's symbol handling is not the best).
<civodul>ok
<dje42> https://github.com/dje42/gdb/issues/25
<civodul>it's about memoizing the c->smob mapping in general
<dje42>yeah.
<dje42>Have to be careful. gdb can be used to debug really large programs (think 1M symbols, 10K .o files, or 5K shared libraries).
<civodul>yeah, right
<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.
<dje42>[local to gdb/guile]
<civodul>usually, is better when cptr1 == cptr2 ⇒ smob(cptr1) eq? smob(cptr2)
<civodul>*it's
<dje42>righto
<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?
<civodul>*than
<dje42>(eq? 'main 'main) where main is from two different programs is problematic.
<dje42>Sorry, bad example.
<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. :-)
<dje42>Yeah, not so easy.
<nalaginrut>morning guilers~
<gzg`>nalaginrut: Evening. o/
<nalaginrut>gzg`: heya~
<ZombieChicken>Is there a database interface for guile?
<nalaginrut>ZombieChicken: try guile-dbi
<ZombieChicken>nalaginrut: ty
<nalaginrut>np ;-)
<TaylanUB>amgarching: dje42: Maybe help me finish http://taylanub.github.io/doc/Guile%20and%20Elisp%20booleans%20and%20nil.txt :P
*TaylanUB should fix those weird path-names ...
<nalaginrut>hmm...
<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
<TaylanUB>Ah, hrm ..
<wingo>pipe it to xmllint if you like
<wingo>*pipe it
<TaylanUB>I guess I'll do that.
<wingo>otherwise there's nothing built-in that does it
<TaylanUB>OK, thanks.
<nalaginrut>wingo: thanks for the hint, I need it too ;-P
<wingo>heh, np
<nalaginrut>it's strange to learn for/* things when we have delimite-continuation...
<civodul>Hello Guilers!
<nalaginrut>heya ludo
<wingo>moin
<amgarching>TaylanUB: maybe dont use #true and #false in http://taylanub.github.io/doc/guile-elisp-nil.txt #t, t, #f, #nil, sheme-f, nil all in one place is already confusing enough
<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 ?
<TaylanUB>Well, I see it indeed doesn't.
<amgarching>from which lang are those?
<amgarching>I see, nevermind.
<amz3>héllo :)
<amz3>I'm back again to guile
<amz3>I was wondering is there anybody that tried to translate guile to javascript using https://github.com/kripken/emscripten
<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
<wingo>to js
<amz3>Gambit does it for instance
<wingo>craziness, that.
<amz3>Also, Mozilla is trying to translate PyPy
<amz3>anyway
<amz3>I also think it's a bad idea
<nalaginrut>libgc -> js ? sounds crazy but interesting ;-P
<amz3> http://biwascheme.org/ is the most advanced javascript implementation of scheme
<amz3>there is also HOP from INRIA which is GPL licensed but requires Bigloo to run/compile
<stis>evening guilers!
<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>add up to*
<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> http://ceaude.twoticketsplease.de/js-lisps.html 34 on there
<ijp>and that's the lower bound
<TaylanUB>Apparently some of them are CL though.
<wingo>evening
<TaylanUB>Evening!
<dsmith-work>Hej hej
<wingo>so, (list (a) (b) (c)) isn't the same as (cons (a) (cons (b) (cons (c))))
<wingo>er
<wingo>so, (list (a) (b) (c)) isn't the same as (cons (a) (cons (b) (cons (c) '())))
<ijp>wingo: I'll bite. How?
<TaylanUB>Something something eval order ?..
<wingo>ijp: same reason as the make-vector / vector-set! thing
<TaylanUB>Oh that makes sense.
<wingo>does the continuation of (a) include the allocation of a pair with A in its car or not?
<wingo>er
<wingo>hum
<wingo>the other way around
<wingo>does the continuation of (a) include the allocation of a pair with B in its car or not?
<wingo>(right?)
<TaylanUB>Do you mean (c) maybe ?
<wingo>or are we save by indeterminate eval order
<wingo>*saved
<ijp>well, I would have assumed that it was an undefined eval order thing
<wingo>there is that
<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>you get a value
<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>er
<wingo>the reverse
<wingo>and a returns twice
<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
<ijp>I suppose so
*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
<wingo>er
<wingo>regardless, actually...
<wingo>fumble fumble
<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>right
<wingo>i'm not sure how much i care, is the thing...
<wingo>which is a dangerous slope
<TaylanUB>Do the standards say that argument evaluation order needs to be consistent ?
<ijp>no
<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
<wingo>but it cuts the wrong way.
<TaylanUB>BTW excuse my ignorance, is our goal to transform list to conses, or conses to list ?
<kurohin> /join #emacs
<wingo>:)
<wingo>TaylanUB: both actually
<ijp>TaylanUB: the formal semantics explicitly declaims that idea
<TaylanUB>OK ..
<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"
<TaylanUB>I see, thanks.
<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
<wingo>evening civodul
<civodul>heya!
<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 ?
<kurohin>yes, that is true. :-(
<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?
<fangism>(moving HEAD forward, that is)
<tupi>how do i move HEAD forward?
<fangism>tupi: you'd need the commit id of that state, is it in your history?
<fangism> http://stackoverflow.com/questions/2510276/undoing-git-reset
<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>git reset --hard <commit-id>
<tupi>tx
<fangism>heh, I just learned about the lost-and-found: git fsck −−lost-found
<fangism>from http://www.programblings.com/2008/06/07/the-illustrated-guide-to-recovering-lost-commits-with-git/
<ijp>ideally you would never lose commits in the first place
<ijp>that's supposed to be the point of a vcs