<dsmith>The other day wingo mentioned "compile -t rtl" (from memory). Is that with guild ? as in guild compile -t rtl foo.scm ? ***christianabryant is now known as tomsitprocb
<dje42>Is there an official way to add to the load-path from C, except to construct a string that invokes add-to-load-path and call scm_c_eval_string ? <adu>while raket might be the most user friendly of all the schemes I think that the most easy of all of the schemes is guile because it is the most memory-efficient <mark_weaver>dje42: why do you want to do it from C? why not include an initialization procedure, written in Scheme, and call it from C? <mark_weaver>adu: Is Guile the most memory efficient? I've not heard that claim before. <dje42>This is the point where I *want* to call out to Scheme. <dje42>I was thinking of having it in a file, so I need to tell Guile where to find it. <adu>I haven't done anything with droscheme yet <adu>but I do think it's a possibility <adu>sometime in the next 3 months <dje42>[I've been using scm_c_primitive_load to load the file, but files loaded with it aren't compiled, so I thought I'd try calling (use-modules ...) from C to effect the load of the Scheme code. <mark_weaver>dje42: you could use 'scm_c_primitive_load' to load the initialization file, though keep in mind that it will not compile that file, so procedures that need to be more efficient should be located elsewhere. <adu>youlysses: half-way between "easy" and "controllable" <dje42>My plan B was to have a boot.scm file that I scm_c_primitive_load'd, and then go from there. <dje42>I was looking to see if I could skip that step. <youlysses>Also, yeah -- I've not heard such claims of speed/efficency regarding Guile being the "fastest", "memory efficient", or what have you. <adu>if I were to define Guile I would certainly use "memory effieicnt" <mark_weaver>dje42: if you really want to augment %load-path (and %load-compiled-path) then please don't try to construct a string that contains both the scheme code and the directory names, because that will either lead to headaches with escaping the string or else breakage when the filenames contain certain characters. <mark_weaver>dje42: instead, you could actually modify those variables directly from C. <adu>so mark_weaver, have you looked at droscheme at all? <dje42>thx. I think I'll try with scm_c_primitive_load'ing a boot.scm, and then have boot.scm do the rest. <mark_weaver>dje42: so, you'd use something like: scm_c_public_variable ("guile", "%load-path") <youlysses>adu: I mean, for the most-part, a scheme implementation, is a scheme implementation, is a scheme implementation -- though some projects have more of a focus in a certain area (Racket right now is the premiere learning platform of the lisp-world -- and is really good at defining sub-languages; Guile is a great extension language, and has a really cool ffi system, etc, etc) Pick your poison, but I'm not sure about one making grandiose <youlysses>statements like the "friendliest", or what have-you, when at the core, they share many commonalities. Are you talking about the tools they make, like Racket has Dr.Racket, which is "user-friendly"? <mark_weaver>to get the variable object, and then 'scm_variable_ref' and 'scm_variable_set_x' to access the variable object. <mark_weaver>and 'scm_cons' to add to the front of the load path. <youlysses>adu: So making such claims, without a further backing of what specifically what you mean, is hard to follow what you're talking about. :^P <mark_weaver>dje42: and to convert a C string to a Scheme string, you'd use either 'scm_from_locale_string' (if the string came from I/O), or 'scm_from_utf8_string' (if the string is written as a C string literal) <mark_weaver>adu: I might have looked briefly at droscheme long ago, but I've forgotten the details. <dje42>I have a few more TODOs and then I'll send a status report with patchset to the gdb-patches list. I'll probably cc guile-users so that y'all can see what's there. <mark_weaver>adu: what are the distinguishing characteristics of droscheme? why another scheme implementation? <dje42>[I always wanted to do my own. :-)] <mark_weaver>dje42: I'd be glad to look over your patches, when you think they're ready. Maybe I'll be able to find ways to simplify or improve the code. *youlysses keeps on thinking that the "o" in "droscheme" is a period, so he keeps thinking y'all are referencing older versions of Dr.Racket. :^U <adu>youlysses: what am I talking about? <adu>droscheme is disctinguished by being implemented by Go <adu>I'm not a big fan of grandiose <adu>in case anyone forgot <adu>mark_weaver: by depending on gccgo <adu>gc may or may not implement tail recursion <youlysses>adu: Well you don't seem to be anymore, but comparatively you mentioned -- in passing your perceived differences between Racket and Guile. I'm just wondering what makes something, in the case of Racket, more "user friendly" -- in Guile's case, you mention being more memory efficient, which may be the case (I'm not sure) -- comparative to other implementations out-there though -- I'm dubious. Hopefully you don't view me as hostile, jus <adu>gccgo 90% implements tail recursion <adu>gccgo does not implement tail recuesion when one of it's arguments is a pointer to a function <adu>if it can't prove that that function is tail-recursive <adu>mark_weaver: no, it depends on the Go compiler <cky>adu: Time to implement CPS transformation! ;-) <youlysses>adu: I'm saying it sounded grandiose, because you really didn't go into detail why this was so (especially in-terms of the user-friendly aspect), so big claims, without stated evidence and/or reasons for which you believe do, to me at least, sound this way. (Not to say you don't have such info, you just chose not to state in prior.) <mark_weaver>adu: I wonder if it might make sense to use the Cheney-on-the-MTA method, like Chicken does. <adu>mark_weaver: I've considered that <adu>mark_weaver: I've also considered CPS <adu>but I'm trying to comprimise between purity and comprimise <youlysses>adu: To make it blunt as I possibly can; Why specifically do you think Racket is more user-friendly than other Schemes? <mark_weaver>I imagine that opinions vary on this, but IMO proper tail calls is a very important defining characteristic of Scheme. <adu>youlysses: Racket has Scribble documentation <mark_weaver>I know that there are some popular implementations that don't guarantee it, but I don't really consider them proper schemes. <mark_weaver>mainly, I dislike its decision to make modules immutable by default, and its single-dispatch OO system. <youlysses>adu: Guile has Skribilo, which is more-or-less the equivalent -- so I'm guessing it's more-so due to it's amount of use and/or importance it has in Racket? <mark_weaver>I can respect the immutability decision, but I prefer a system that can be patched and modified in arbitrary ways at runtime. <cky>mark_weaver: As you can see with many Ruby projects, the ability to monkey-patch can be a slippery slope. ;-) <mark_weaver>I don't have much nice to say about the single-dispatch OO system, though :) <adu>youlysses: it has more to do with the fact that all of autoconf, automake, m4, mustache, ant, make, jam, various other build systems, are all possibly with MUSTACHE <mark_weaver>cky: I agree that it's bad practice for modules to monkey patch each other. However, *I* want to be able to make modifications to arbitrary Scheme procedures at runtime. <adu>mark_weaver: mee tooo <cky>mark_weaver: That's a fair point. I guess the question would be, how to enable user-level patching while discouraging the level of monkey-patching that you commonly see in Ruby. <youlysses>Nor can I find anything immediately available describing it in a greater depth. :^P <adu>youlysses: the internet? <mark_weaver>cky: to my mind, it's a cultural issue. we look down our noses at code that does monkey patching, and avoid using such code :) <youlysses>adu: Yes, what is this "Inter netting", is it a euphemism for ladies' wear? Nah, MUSTACHE. <adu>mustache is {{variable}} nothing more <mark_weaver>cky: I don't think it's possible to enforce good programming style. If we want to build robust systems, we cannot avoid reviewing the code and making sure it's sane. Disallowing monkey patching might automatically prevent one kind of stupidity, but it can't prevent all kinds :) <youlysses>On a somewhat related not, I probably should look into Racket again -- I'm still fairly heart-broken that I lost my introductory text and should probably take the opportunity to branch-out and see how it's done via other courses like HTDP. :^P <cky>mark_weaver: I 100% agree that this has to be enforced at a social level. My concern is about shifting social norms, but I guess that makes me sound like a dinosaur, so I'll stop. ;-) <mark_weaver>I agree that shifting social norms can be a serious problem if they go in the wrong direction. There are important battles to fight there :) <mark_weaver>cky: thanks for the signed key, btw. did you receive a signed key from me? <dje42>If C code does a scm_define_gsubr to provide a procedure, what's the right way to export it on the Scheme side so that the compiler doesn't print "foo possibly unbound" warnings when loading Scheme code that uses it ? <cky>mark_weaver: I gave my card to RMS but I haven't received his signature yet. <mark_weaver>cky: I think you should email your key to him, ASAP, and hope that he hasn't yet lost your card :) <cky>mark_weaver: I like caff, by the way. Makes bulk-signing keys a breeze. <cky>mark_weaver: Ah, makes sense. Is that what you did? <mark_weaver>I emailed him the say day I gave him my fingerprint on paper. <cky>I'll mention in the email that you suggested I do this, because he knows you, whereas he doesn't know me from a bar of soap. <mark_weaver>cky: btw, how do you deal with encrypted email when using gmail? <mark_weaver>I assume you do so in such a way that google cannot see the plaintext? <cky>I use mutt to connect via IMAP. <mark_weaver>btw, if you can manage to avoid using MIME attachments or encodings, that would be probably be nicer for RMS to deal with. <cky>That's fine. text/plain it is. :-) <cky>I know that rms didn't have cards with the new fingerprint on Saturday. Did you manage to verify his new fingerprint somehow? <mark_weaver>that's not true. he gave me his card with his new fingerprint on it. <cky>I thought I heard him say he was giving someone a card with his old key because that was all he had. Hmm. <cky>If you take a photo of the card (I trust you not to doctor the card or impersonate him), I'll probably sign his key (and I'll upload directly rather than send via caff, just to reduce his workload). <mark_weaver>cky: if you trust me, and trust a signed email from me with the picture, then you might as well trust the signature I already made on his key with mine, no? :) <mark_weaver>though really, it probably makes more sense for you not to sign without having to trust anyone. <cky>Fair enough. I just don't know when I'm likely to bump into rms again. <cky>But I do take your point. <cky>I guess he usually attends LibrePlanet. So if I attend one, I guess I could meet him then. <mark_weaver>cky: I suppose there's one reasonable justification for asking for a picture of RMS's card: to guard against the possibility that I was lazy and didn't get a card from him at all :) I'll send you a picture. <mark_weaver>his new pleasure card is not nearly as pretty as his old ones. <mark_weaver>(he still has some old ones, and I saw him give one to a woman after he gave me the less pretty one, but the less pretty one doesn't have his new fingerprint) <cky>mark_weaver: Really, in this case, whether I physically have the card or I just get a picture I trust, it's still a "level 2" signature since I didn't see any ID, just going off of his well-knownness. (Whereas for "level 3" signatures, I do prefer to have the fingerprint on something I physically have on hand.) <cky>mark_weaver: Yeah, I did see the prettier-but-old card. <mark_weaver>to my mind, your recognition of him is far more reliable than any national ID. <cky>That is true, but through my time as a Thawte Web of Trust notary, I've been conditioned to rely on (preferably multiple) official IDs. <mark_weaver>well, if you have nothing better to rely on, that's the best you can do. <mark_weaver>but I consider national IDs rather unreliable. They can be quite easily faked. <cky>(I was one of the very, very first Thawte notaries, and notarised over 50 people during the life of that programme.) Yes, that is true, about fake IDs. <mark_weaver>bah, this webcam can't take a good picture of this card. either it's too close to focus properly, or too far to see the small digits clearly. <mark_weaver>well, it's probably not terribly important for you to sign his key. <mark_weaver>well, after some experimentation (hanging the camera from a lamp shade to act as a tripod, and positioning the fingerprint near the part of the field where the lens abberations are least bad) I got a picture that is *somewhat* readable. I'll send it to you. <cky>Okie dokie. Thanks! I'm sorry it was such a pain. <dje42>I was thinking of some syntactic sugar to easy the typing load for those familiar with gdb's python interface. <dje42>Dunno if it's a good idea, just thinking about it. <cky>dje42: Also read HACKING. <cky>mark_weaver: Thanks! :-) <dje42>E.g. in Python one can do value.type to the the type of a value. Currently, in the guile API it's (gdb:value-type value). ***Fuuzetsu is now known as Guest78251
<wingo>DWARF in master with line numbers <wingo>for a text size of 0xa2e4 on a test file, the .debug_line size is 0x07c4 <wingo>0x078e for the .debug_info section <wingo>also this file has 4 pages of writable data, and 12 of read-only shareable data <wingo>not all would be paged in though <wingo>afaict only 4 pages would be paged in initially <wingo>until someone asks for a docstring, a procedure arity, source info, etc <cky>wingo: It's a good idea. It's not often that high-performance code would be trying to get procedure metadata anyway. :-) <wingo>high-performance is one thing, memory and startup time is another <wingo>using elf and dwarf effectively is about the latter <cky>Right, let's make sure boot-9 doesn't use procedure metadata either. ;-) <wingo>anyway, that was pretty neat <wingo>dwarf specifies source locations using a little virtual machine <wingo>so i got to interactively develop the assembler and the vm :) <wingo>and check results using objdump -g ***Guest78251 is now known as Fuuzetsu
***Fuuzetsu is now known as Guest5215
***Guest5215 is now known as Fuuzetsu`
***Fuuzetsu` is now known as Fuuzetsu
<dsmith-work>wingo: When you mentioned compile -t rtl the other day, was that for guild ? <dsmith-work>wingo: Hmm. I'll check again, but that failed for me yeterday. Didn't like rtl. Maybe I wasn't on the correct branch.. <b4283>i've got a question about guile's regular expressions <b4283>i was writing something with (string-match) today and discovered that guile <b4283>does not support non-greedy matching with .*?, is this correct? <b4283>also there's no "discard group": (?:) <b4283>of course the latter is trivially important.. <wingo>b4283: i don't recall details, but guile uses the libc's regexp facilities <wingo>so the real docs as to regexp capabilities are there <b4283>wingo: okay, thanks for the info, will look there <ijp>cky: what's the status of defmacro->hygienic? <mark_weaver>b4283: if you want a nicer regexp library, I recommend using Alex Shinn's irregex package, which is conveniently available through guildhall. <b4283>cool, a package manager for guile <mark_weaver>I wonder if we should just import irregex into core guile and be done with it. <mark_weaver>also, I recommend considering the use of SREs: Scheme Regular Expressions, written as s-expressions instead of strings, especially for more complex regexps. <ijp>one advantage of emacs's backslash heavy regexps is that it has greatly promoted rx usage :) <ijp><fsbot> hmm, backslashitis is "\\\\(\\\\\\\\\\\\||\\\\)" -- match \\ or | <ijp>that's kind of a joke entry, but it is a common complaint <ijp>9/10 when someone has a regexp problem, the solution is to add more backslashes <ijp>statistics courtesy of mybullshitstats.example.com <mark_weaver>wingo: Thanks for the work on dwarf! (catching up on backlog :) <wingo>currently wiring it into the (system vm program) interfaces <mark_weaver>Sorry I've not been more helpful lately. I've been distracted by ditching my Intel box and returning to a Yeeloong. <cky>ijp: It's partially done. I should commit what I have. <cky>But, it may be later this week, rather than right now. <cky>I planned to work on it during GNU30, but I roped in by the Tor people instead. ;-) <mark_weaver>well, I'm fully migrated at this point, but just trying to get my home-built-from-scratch Yeeloong system up to snuff.. and learning to use things like OTR and gpg2 properly. <ijp>cky: make sure to add an update to the tracker when you do thanks :) <mark_weaver>really, I'd like to switch it to Guix as soon as possible, but that's another project. <mark_weaver>I did something of a security reset, generating all new keys and revoking the ones that my Intel box had access to. <b4283>i've run into some trouble with wak-irregex with guildhall, (use-modules (wak irregex)) gives me "ERROR: no code for module (wak private include)", can someone help? <mark_weaver>It's reasonably clear that all modern Intel-based systems have back doors built into the hardware itself. scary stuff. <b4283>there's some weird *.sls files in my ~/.local/share/guile/site/2.0/wak/private <b4283>i'm not sure what to do from now <ijp>b4283: I would swear on my mother's grave I fixed them all :( <cky>Is that the thingy on Savannah? <mark_weaver>strange. I've used irregex myself from guildhall. I thought all those .sls files were already renamed. <b4283>hmm, so my installation is flawed <b4283>"guild list-packages" shows "i wak-irregex 0.8.1-2" is this the version you've got? <mark_weaver>hmm, I haven't yet installed guildhall on this new system I'm using now. time to do that. <ijp>b4283: hmm, unless your install downloaded the old version (which shouldn't happen) <ijp>because I'm looking at the .zip just now <ijp>b4283: what is the version of wak-common? <wingo>guildhall and guix are at odds, somehow... <ijp>there are no .sls files in the zip for 0.1.1 <ijp>guix will win because it has users :/ <davexunit>well people use pip, rubygems, pear, and cpan in addition to their regular package manager. <b4283>somehow installing wak-irregex directly will get me wak-common-0.1.0 <b4283>have to run an additional command to install newer wak-common <cky>davexunit: I can't remember, did we do any key exchanges during GNU30? <ijp>b4283: hmm, that makes no sense unless... <davexunit>cky: we did not because I had no key to exchange at the time. <ijp>...nope it doesn't specify a particular version <davexunit>zak from the fsf walked me through it afterwards. <cky>*nods* I did trade keys with Zak. :-) <ijp>davexunit: the hard part is getting people to package for it <ijp>I have _a lot_ of ! in my gnus for guile packages that have been released that I just haven't gotten around to trying, let alone packagin <ijp>and the guile lua parser is continuing to drive me insane <ijp>I'm about ->||<- close to just reimplementing it <wingo>didn't we need to re-do it in peg or something? <wingo>the peg stuff in master hasn't been used, that i know of <ijp>I have some notes on peg lying around <wingo>perhaps it would make sense to publish it as a package for guildhall at some point <wingo>i don't have time for that tho <ijp>I think peg can only match strings at the moment <mark_weaver>ugh. On my Yeeloong system (MIPS-compatible, currently running with 32-bit pointers), (fxarithmetic-shift -1 29) returns a value that should be a fixnum but is actually represented as a bignum :-( <ijp>adding peg would be an okay solution to the regex situation <ijp>but it's a case of too many plans, not enough hands I think <mark_weaver>I seem to recall that there was some reason why we didn't want to commit to peg's API at present, but I forgot the details. <mark_weaver>(ash -1 29) works properly when run directly from the REPL, but if I do (define (my-ash x y) (ash x y)), then (my-ash -1 29) does the wrong thing. presumably due to the latter not being folded by peval or something :-( <mark_weaver>where "the wrong thing" means that it returns -536870912 as a bignum even though it should be a fixnum. <mark_weaver>I guess the bignum is being canonicalized to a fixnum when it gets reified, but that the ash VM instruction has a bug in it. <mark_weaver>well, I guess it would surely be scm_ash that has the bug, since the ash VM code never generates bignums. <ijp>gah, I'm not sure how it happened, but I killed my emacs <ijp>well re: peg, one problem I remember is that define-peg-string-patterns fails silently <ijp>which is NOT GOOD™ for a function that adds top-level functions <ijp>s/function that/macro that/ <ijp>I'm also not convinced that it is a good idea to expose context-flatten or keyword-flatten <ijp>"The Third Homomorphism Theorem" contains a neat derivation of merge sort from insertion sort <ijp>any of you fancy responding to that Johan Ceuppens chap? I'm not quite sure what to say to them <mark_weaver>I'm willing to respond to him, if no one else wants to (I promise to be nice :) <mark_weaver>I guess the gist would be to say that generally we don't give commit access until someone has already submitted several patches and established themselves as sufficiently knowledgable, or something to that effect.. and as for the example: where is 'make-dictionary' defined? <ijp>I'm sure we must have an example of those ghastly functions-as-objects somewhere in the repo already <ijp>(info "(guile) OO Closure") <mark_weaver>IMO, data-directed dispatch is occasionally a useful technique (although VASTLY overused) <davexunit>any of you fancy responding to that Dave Thompson chap? he posted a patch on sunday. :P <mark_weaver>davexunit: I already think the patch is good (although perhaps some more thought is needed on where exactly to put the wrapper), but I've since realized that the new REPL option should probably be documented.f <mark_weaver>However, I think it's probably safe to say that something very close to that patch will be in 2.0.10. <mark_weaver>assuming that wingo or civodul have no objection to the basic idea :) <ijp>one possible problem is that by passing in the thunk, it may be evaluated multiple times <mark_weaver>well, we could simply say that the thunk should be called only once, and if it's called more than once, the results are unspecified. <ijp>and for the repl, we already have before and after eval hooks, don't we? how does this differ <mark_weaver>before and after hooks are not sufficient to run the thunk in the different thread, or more generally a different dynamic context. <ijp>could they be made sufficient? <ijp>then that's one issue down <ijp>if we want to forbid multiple forces, we could pass in a promise directly <mark_weaver>davexunit: perhaps you should post the code that uses the read-wrapper, so that people can see the problem we're trying to solve. maybe someone will have a better suggestion. <davexunit>mark_weaver: sure. hopefully I can do that tonight. <ijp>assuming they can return multiple values (can they?) it'd kill that other issue with no gentleman's agreement necessary <wingo>i'm a bit behind fwiw, but in general i trust mark_weaver's judgment :0 <mark_weaver>wingo: thanks, although I confess that this issue is not entirely clear cut. <mark_weaver>but basically, we need some kind of solution for running a REPL as a cooperative thread within an event-driven program, I think. <mark_weaver>and this read-wrapper REPL option is one way to acheive that. *civodul trusts mark_weaver too :-) <ijp>me too, but I do enjoy playing devils advocate <civodul>davexunit: i looks at the patch and that makes sense *stis does not do nice hacks, just insane ones. <davexunit>with a little bit of guile-2d specific code I had a cooperative REPL. :) <mark_weaver>davexunit: we might want to arrange for *repl-stack* to be propagated automatically, without the 'read-wrapper' having to do that job itself. <mark_weaver>forcing the 'read-wrapper' to do that job leaks that implementation detail, and would be best avoided. <davexunit>that sounds like a good idea. it will make it easier for anyone else that wants to use it. <mark_weaver>davexunit: would you like to work on revising the patch? <wingo>aleix: you think we should have one soon? <stis>wingo: re: 2.1.0, do you think that it is a good idea to simulate a stack when doing function evaluations in rtl? <stis>and add another possibility to do a funciton call without copying like the tail call? <stis>consider hoe expressions are evaluated on the old VM, you can simulate that as well with rtl no? <aleix>wingo: well, not really. but there seems to be quite some changes in the web module <mark_weaver>there are some important bugs fixed since 2.0.9. I think we should have a 2.0.10 in the next few weeks. I'm willing to do most of the work to make that happen. *mark_weaver goes afk again <stis>wingo: (f (g x)) : mov x 3, mov g 2, call g 1, move f 1, call f 1 <aleix>wingo: having non-specific language modules in the language tarball itself sometimes causes interest conflict i guess <aleix>wingo: i am not complaining btw ;-) <stis>wingo: the example is buggy and not optimized, but I think you know what I mean :) <wingo>aleix: yes there are plusses and minuses; please poke us repeatedly if you want a release soon <wingo>i think in this case sure, let's do a release <wingo>stis: yeah, dunno; so you usually should resolve f before evaluating (g x) <aleix>wingo: cool, thanks. and thanks to mark to who's willing to do the work <wingo>but we could change the calling convention <wingo>stis: but that penalizes multiple-value returns <wingo>anyway fwiw i am happy with things as they are right now <stis>Today we must move all values returned, also in mv, but not so in many cases if we employ (call start-pos size) <wingo>it's not necessarily the case that you move all return values <wingo>or even that you have to move any values <wingo>depends on how the values are used <wingo>(+ (f) 1) doesn't move the result of (f) <wingo>stis: basically a call-with-values will leave the values in place <wingo>and a single-value call won't move the value if it's directly used by a primop <wingo>we could change that to leave call results in place, but that might have bad gc effects; dunno <stis>Ok, I see what you meean that the values returned eis not protected from gc, or do you mean memory leaks? <stis>wingo: I also agree that it's fine with what we have, but also we might be able to improve. <stis>and this is a sugested focus point! <aleix>is there anyway to check for specific (2.0.Z) guile version with the m4 macros? couldn't find it or did something wrong. <wingo>i mean if you keep more slots around than you have live values, you might end up keeping things alive too long <stis>we do stack nulling, I do not think that we will lose anything important in relation to how much nulling we need to do today no? <wingo>stis: stack nulling is turned off, and also in rtl since vars aren't allocated in a stack discipline but instead by liveness ranges, that would mean clearing slots would have to be manually inserted instructions <aleix>wingo: i'll see if i can do something about it then <wingo>otoh we could make the gc read maps about what variables are live <wingo>that's what most other languages do, and it's not a bad options <stis>ah cool, both the maps and that we do not need that today! <stis>anyway, have to go now, nice talking to you! <civodul>mark_weaver: re 2.0.10, thanks for the offer! :-) <wingo>hoo boy, very tricky to change scheme code that's called by error handling code :) <wingo>civodul: e.g. program-source <wingo>you can end up in recursive exception throws <civodul>no choice but to get it right from the start ;-) <wingo>ok, so now anonymous rtl functions print with their source locations <wingo>i think that might even work in backtraces, with frame-source <wingo>so the only debugging thing that's really missing is local var info, and perhaps we can do without that for a little while <wingo>i know how to do it but it will take some time <wingo>though i do often do ,locals these days when debugging :) <wingo>so i think from now over the next few weeks i'll look at getting more things to compile with rtl <wingo>prompts first, then eval.scm, then everything else <wingo>you saw we do .debug_line sections now, with all line info :) *wingo still pleased about that <civodul>so actually "guild compile -t rtl" doesn't work <wingo>meta/uninstalled-env guild compile -t rtl foo.scm <wingo>maybe something isn't getting installed <wingo>now try readelf -a foo.go :) <civodul>oooh, lots of nice section names with objdump -x :-) <wingo>there are some errors with the .debug_loc section -- currently empty <wingo>and misinterpreted by that tool <wingo>and the sections are actually laid out in a sane way <civodul>wingo: that'd be great if "objdump -S" would just work <civodul>perhaps now with source location info it might work? <wingo>there's good reason to expect that only the right part of the file gets paged in, if debug info isn't ever asked for <wingo>civodul: it might, it certainly will work when we do native comp., but i think it won't do anything if it can't disassemble <wingo>perhaps we could call the section .text instead of .rtl-text <dsmith-work>Obviously, binutils needs to be updated for rtl opcodes. <wingo>surely we can get it to work eventually <wingo>dsmith-work: i was thinking about that and i don't know tbh <civodul>actually yes, it may be using libopcode to disassemble the thing <civodul>so there's nothing it can do with bytecode <wingo>machine ISAs are more stable than our format <wingo>civodul: well you set a different ELF architecture, would be the thing <civodul>we just need a plug-in mechanism in bfd :-) <wingo>and then the .text would get disassembled according to the arch <civodul>yes, but provided that arch is known to libopcode, right? ***bubble_ is now known as bubbleman
<wingo>civodul: right, we'd have to register it with DWARF folks <wingo>anyway i don't think it's worth it <wingo>because it would only be valid in the next 2-5 years, by that time ~everything should be native <wingo>on any arch worth thinking aobut <civodul>and we (will) have our own tools to fiddle with that data <wingo>and the places you'd want gdb are the places we'd be doing native code <wingo>it's still useful to talk to dwarf people to register new language codes <wingo>for scheme, lua, elisp, ecmascript