IRC channel logs
2013-10-31.log
back to list of logs
<fangism>*sigh* scm_iprlist() is littered with goto's... i'm never going to figure out what's going on <davexunit>should I be using (ice-9 streams) or (srfi srfi-41) for streams? <cky>Lol re davexunit's question. <cky>Too bad he's not here to see the response, but the short version is: (srfi srfi-41) is much more robust than (ice-9 streams). <cky>(Disclosure: I ported SRFI 41 to Guile. But a number of people did heavily encourage me to finish the task and get it shipped, so people do/did care about too, not just me.) <cky>fangism: It may have gotos but it's a pretty short function. Lemme look at it and see what it does. *nalaginrut should evaluate the list of modules for practical using... *ksinkar is new to scheme and using the guile for solving the problems in SICP. He likes being here in this channel where people are doing hard core computer science. He aims to replace bash with guile. <cky>ksinkar: People in this channel do hardcore CS? That's news to me. ;-) <cky>ksinkar: As for replacing the shell, there once was a guile-scsh project, but not sure where it's at.... <ksinkar>cky: maybe my definition of hardcore CS is different from yours. Your bar maybe set higher than mine. I did look at guile scsh and it has been orphaned, it seems. I want to give it some love and see where I can take it further <nalaginrut>ksinkar: why not raise your new gash project (guile replace bash)? now that you're interested on hardcore CS <ksinkar>nalaginrut: kool, I will keep you posted on this channel <mark_weaver>ksinkar: welcome to our small community! and thanks for the kind words :) <mark_weaver>"hardcore CS" is a rather vague term. I have no idea what it means. *nalaginrut think the extreme hardcore CS would be math itself... <nalaginrut>ksinkar: but anyway, if you want to try something harder and interesting, it's fine <ksinkar>mark_weaver: thank you. don't worry, I will be asking many questions as I start working towards replacing bash with guile. <gzg>It would be cool to have an solid alternative shell, say via the repl -- me thinks. :^) <TaylanUB>Many of the core Scheme concepts would seem "hardcore CS" to an average programmer of our day I'm afraid. :P <nalaginrut>when you're hacking 'hardcore CS', it becomes softer and softer ;-D <nalaginrut>do we have any alternative thing to emulate define/contract in Racket? <kurohin>what is the best way to (de)serlize a object to/from a file in guile, lets say a configuration object, I want it to be easy to setup even for those that are not used to scheme and guile. <wingo>kurohin: if you can, use read and pretty-print <kurohin>thanks wingo, I was guessing that might be the best way, but I am a scheme newbie. has only done some elisp before <kurohin>one more newbie question, should i not be able to something like this <kurohin>(make-instance <config (read (open-input-string "#:tada 3"))) <wingo>and leave the port position at <wingo>you should write a little loop <wingo>(define (read-exps port) (let ((x (read port))) (if (eof-object? x) '() (cons x (read-exps port))))) <kurohin>if I used "(#:tada 3)" instead in the string, would that not help me in any way? <wingo>yes, then you would read the whole thing as one datum *mark_weaver just discovered that on 32-bit platforms, the maximum size of a SCM vector is 2^24-1 :-( <wingo>isn't your longsoon a 64-bit machine? <wingo>also that's 16 million but it is 64 MB, fwiw <mark_weaver>wingo: yes, my yeeloong is a 64-bit system, but I use the N32 ABI where int/long/void* are 32-bits, for memory efficiency. (N32 is similar to the new x32 ABI for intel systems) <mark_weaver>davexunit: well, that's a good question. it's certainly doable, but the questions are "if" and "how". <mark_weaver>we could have two different representations for small and large vectors, basically. <wingo>why not add another word to vectors on 32-bit machines? <wingo>and store a 32-bit index there <mark_weaver>we could also use fewer than 8 bits for the type tag in the case of vectors. <mark_weaver>I'd rather not add another word to the representation, for the sake of efficiency of small vectors. <wingo>and i'd rather not add another vector type, for generated code efficiency and complexity <wingo>constraints, yay programming <mark_weaver>so maybe reducing the number of tag bits for vectors is a reasonable compromise? <wingo>maybe, i wouldn't want to do it right now in master <wingo>as there are some rtl things that depend on vectors being a tc7 thing <mark_weaver>wingo: can you give me some pointers to those rtl dependencies ? <wingo>br-if-tc7, assembler.scm:write-constant, etc <wingo>tbh i would say "just add a word" <wingo>to vectors on 32-bit systems <wingo>you're already saving on memory by using crippled pointer spaces <wingo>paying for it with an extra word where you need it sounds reasonable to me <wingo>vectors wouldn't be the only data type with a length in a separate word <wingo>oth a tc3 for vectors might be possible, and that would give you a 31-bit address space... <wingo>(given that each item is 4 bytes) <wingo>doesn't the low bit have to be 1 ? <mark_weaver>the low bit has to be one on heap cells, yes. oh, I see what you mean. <mark_weaver>well, although i was less specific, that was pretty much what I was suggesting, no? :) <wingo>i would be interested in civodul'd thoughts on this too... <mark_weaver>hmm, in the comments of tags.h (line 331 in master), it says that tc3 == 3 is for closures <mark_weaver>well, I suppose we ought to think of the best use we can for tc3 == 3. not sure if that's vectors or not. <wingo>yeah, could be vectors though <wingo>we should use it rather than leaving it fallow <wingo>so i ran into an interesting issue <wingo>the rtl compiler computes liveness info based on solving a data flow graph <wingo>so you start with the tail continuation <wingo>and then you go backwards, where a use adds a variable to the live set, and a definition kills it <wingo>and you iterate until you have a stable solution <wingo>that algorithm fails in one case :) <wingo>see ice-9/futures.scm:206 and guess what it is <wingo>so the issue is that that function doesn't terminate! <wingo>there is no path that reaches the tail continuation <wingo>and so you can't chain back to predecessors of the tail continuation, because there are none <mark_weaver>well, obviously we have to cope with that case. it's not that rare. <wingo>yeah dunno :) going forward, i think, if the tail continuation has no uses <mark_weaver>I guess the algorithm that starts with the tail continuation is just not correct. <wingo>unlike other crack-brained things i did ;) <mark_weaver>there are many ways that a procedure that never returns can affect the state of the process. <wingo>the rtl compiler compiles all of guile now <wingo>sure, this is just for calculating which slots are live <wingo>and there are three files that have infinite loops like this <wingo>so we'll have to be more conservative and do a forward data-flow analysis in those cases <civodul>wingo: so it builds, and does it run? :-) <wingo>solving the available expressions problem instead of the live variables problem <wingo>i remember the feeling when the stack vm landed <wingo>it wasn't elation -- it was "i'm tired" ;) <mark_weaver>wingo: what about procedures written in explicit continuation passing form, where they return by calling one of the arguments? <wingo>mark_weaver: tail calls "use" the tail continuation <wingo>mark_weaver: this case only happens for contified loops that never tail-call out to another procedure <wingo>and where there is no path in the function that ever exits <wingo>either by return or by tail-call <wingo>there are few functions like that, and having a more conservative analysis for them will be fine <wingo>and they are easy to identify -- the tail continuation has no uses. <mark_weaver>well, okay, I guess it's reasonable to handle this case specially. <wingo>maybe the thing to do is to solve liveness precisely in the reverse direction, then go forward and propagate to paths that never leave <wingo>like (.... (if (foo) (let lp () (lp))) ...) <wingo>that case probably happens as well <wingo>and i don't think the current code handles it correctly <wingo>anyway, an interesting issue :) <wingo>i have a stack of unpushed patches because prompt things mean i need to flip the default vm to rtl at the same time as finishing prompts (done in my branch) <wingo>just pushed wip-rtl-halloween fwiw <dsmith-work>mark_weaver: What was the happy version of libgc again? *dsmith-work starting the rebuild of sneeks box <mark_weaver>cool. we miss sneek. maybe make a backup this time after it's all built. <mark_weaver>*nod*, but now that we know that the flash filesystem loses files, it's much easier to occasionally replace those files from a backup than to rebuild. <unknown_lamer>I made a few changes that never really went anywhere, they should make it slightly less thread unsafe <wingo>bootstrap is slow, but the compiler is unoptimized <dsmith-work>wingo: Is bootstrapping faster when rtl is the default? (instead of the stackvm) <wingo>dsmith-work: i don't know tbh <wingo>there are lots of details, like the build order <anddam>mark_weaver: hi, we talked yesterday about the guile 1.8.8 dynamic-link on OS X <anddam>I ended up patching libtool since you told me guile 1.8.8 depended on it <anddam>I'm reluctant pushing a change to libtool tho', is there a way to specify in guile the full path for the library that has to be loaded? <anddam>it's that weird-named libguile-srfi-srfi-1-v-3 <mark_weaver>I think changing libtool is the right fix. many other packages that use libltdl assume that it knows the default system library path. <anddam>I assume it's being pulled from guile because the end-application doesn't have any reference to it in the whole tree <anddam>I'll make a bit of test rebuilding all my ports with the patched libtool <mark_weaver>yes, guile-1.8 splits some of its code into modules that are loaded dynamically. <mark_weaver>it's guile's responsibility to load the srfi-1 module when needed. <mark_weaver>I suspect that the libtool change might fix some other packages elsewhere in the tree that use libltdl. <anddam>and it relies on libtool in 1.8.8, is that right <anddam>that's what I thought too, I've met a little resistance about changin a tool that is so central to programs building <mark_weaver>yes, it relies on libltdl to dynamically load its modules, and libltdl is part of the libtool package. <mark_weaver>libltdl is not generally used when programs are being built. the parts of libtool that are widely used by build systems are not in the libltdl directory. <mark_weaver>I think you should push through the resistance, if possible. it's the right fix. anything else would mean leaving libltdl broken and working around that breakage elsewhere. please, let's not go there. <mark_weaver>now, maybe there's a better way to prepend /opt/local/lib to libltdl's system search path than by patching its configure script. if there isn't a better way to do it, there should be. <anddam>I admit I don't know what libltool is, I'm gonna read it <mark_weaver>but I strongly believe that libtool's system search path should be fixed. <anddam>I see, libltdl is provided by libtool and is a small wrapper for the underlaying, system-specific dlopen implementation <anddam>I never dug too much into the building/running <gzg>ijp: Sub-Atomic Quarks.* *TaylanUB is about to send a long mail to the ML about proposals for better optimizability on top-levels ... <ijp>I'd rather you sent code <ijp>otherwise no-one is going to respond anyway <ijp>(see everything stis posts about guile-log) <TaylanUB>I don't know how the changes in themselves would be received, and I think it would be quite the ride to implement all that I have in mind; depending on feedback I could start actually working on it. <TaylanUB>Sadly I'm a noob in C code-bases, properly version-controlled projects, etc. <TaylanUB>I know I could manage it though, if I'm persistent. <unknown_lamer>once upon a time we had to use cvs and have effectively no local version control, merging was awful, etc. <unknown_lamer>thank gnu for darcs and git making participating in large projects easier <ijp>and thanks to magit for making git usable *TaylanUB entirely deleted a project from his work PC today, running 'svn rm --force project-directory' before committing anything, in a moment of extreme stupidity. :( <TaylanUB>(Co-worker has old version, changes aren't gigantic, is not as catastrophic as it could've been.) <ijp>remember kids, version control does not obviate backups <TaylanUB>Hrm, can the procedural macro system insert variables from the lexical scope of a created macro into the output of the macro in such a way that static analysis cannot see this ? <TaylanUB>I hate it when I realize I *still* miss some fundamental knowledge on Scheme. I thought (define-syntax foo (let ((bar quux)) (syntax-rules () ((foo) <use bar here>)))) would work. <mark_weaver>what *does* work is this: a local macro can expand into references of a lexical variable in its scope, e.g.: <mark_weaver>(let ((bar quux)) (let-syntax ((foo (syntax-rules () ((foo) <use bar here>)))) <use foo here>)) <mark_weaver>the problem with your example is that the macro would be *used* in a lexical scope that does not include 'bar'. <TaylanUB>Thanks, I understand. :) As for my real question, it's difficult to word but, can a macro "procedurally" output a binding to a variable from the scope in which the macro was defined ? I mean, for instance when I (define-syntax foo (syntax-rules () ((foo) (bar)))), then static analysis can easily tell that my macro can output a reference to the `bar' in the scope of that `define-syntax' form; can this be done in such a way that static <TaylanUB>(That would make escape-analysis and the like impossible, wouldn't it ?) <chrisirc>Hi. Is there a way to feed code with location information into Guile? <chrisirc>I want to generate Scheme code (preferably in-memory, i.e. sexprs), but it's important to refer back to the source that was translated to it. <chrisirc>Thus, some kind of |eval| or |load| that can deal with some kind of location-enhanced sexpr data type. <ijp>humour me, how is what you are doing any different from what our macros already do? <mark_weaver>chrisirc: the way you do it is to create a string port (or any kind of port, really), and then call 'set-port-filename!', 'set-port-line!' and 'set-port-column!' on it before reading from it. <chrisirc>ijp, macros are doing that for parts within a Scheme file. But my source might not be Scheme after all. <ijp>well, the way you would usually do that in guile is to generate tree-il rather than scheme, and embed the information directly in the tree-il procedure forms <chrisirc>mark_weaver, hm, that seems ugly, also, when using |read| I wouldn't get a chance to change the position when it recurses. <mark_weaver>well, I guess in the general case you'll have to keep calling those 'set-port-*!' procedures quite frequently, and it might not even be enough. <chrisirc>ijp, that sounds what I want, any pointer? <ijp>and you can always set the procedure properties after the fact <mark_weaver>the other option is to set the source properties on the datums *after* they are 'read'. <TaylanUB>Or (info "(guile) Compiling to the Virtual Machine") in Emacs. :) <mark_weaver>chrisirc: take a look at guile-2.0.x/module/language/* <mark_weaver>for example, the brainfuck language in there is probably simple enough to get a handle on. <dsmith-work>Doesn't autogen mix guile source inside some other file format and need to do that string/file/line hackery? <TaylanUB>(To answer my own previous question: I suppose no such thing is possible, because the only ways to insert bindings to the output are `syntax', whose calls can be analyzed for the variables they capture from the macro-definition-scope, and `datum->syntax', whose `for-syntax' argument necessarily comes from the macro-user-scope and not the macro-definition-scope.) <mark_weaver>TaylanUB: sorry, I'm been mulling over your question. <TaylanUB>No problem, I found it very difficult to word so the question is kind of unclear... <mark_weaver>TaylanUB: first of all, all static analysis happens after macro expansion. that's the only sane way to do things, because the static analyzer can't possibly understand macros that the user defined. <mark_weaver>(it *might* be able to do if all we had was syntax-rules, but with procedural macros, forget about it) <ijp>that was my understanding, but I supposed TaylanUB was talking in general <TaylanUB>Hrm, I was thinking of static analysis being done on e.g. a module, to find out possible "implicit exports". <mark_weaver>well, first of all, top-level module references can be inserted anywhere, with or without macros, because of our '@' and '@@' syntax. <TaylanUB>Indeed, I'm thinking of this with respect to some ideas on changes to the module system, making module imports immutable and all ... <ijp>I have another argument against only making imports immutable <mark_weaver>a few years ago I wrote an email to guile-devel along the lines of '@@' considered harmful, and it was shot down pretty hard. <TaylanUB>Maybe I should just post my e-mail now instead of trying to refine it more and more, and have errors in it corrected there. <TaylanUB>mark_weaver: I would be very interested in that thread, if it's possible to find it. :) <ijp>the module that is bound by the restriction does not gain any of the benefits <ijp>they are doing it only to satisfy other modules <TaylanUB>ijp: The module that makes its exports immutable to others gets satisfaction itself, so to say. :P Is that not good ? <ijp>one problem I have with Andy's response is that he states that is is both lovely and useful, and then suggests that we can reasonably discount it from user code <TaylanUB>(I think it should be a switch that can be changed between development and deployment ... Anyway, the e-mail will make it clear.) <TaylanUB>OK, enough yak shaving, I'll read that thread now and if it doesn't make any radical changes in my thoughts I'll just send it out. <ijp>turning on optimisations just for deployment means you aren't testing your code correctly <ijp>(aside, this is why the people who advocate stalin are insane) <mark_weaver>the reason I dropped this whole line of thought is that I realized that it was possible to implement a more optimizable static module system on top of more-or-less portable scheme (with syntax-case) by creating modules as single-top-level forms. <mark_weaver>within lexical scopes, any variable that is never set! within its scope is immutable, and the compiler knows that. <mark_weaver>and when you want to import immutable and optimizable higher-order functions such as fold, you can just evaluate a macro that expands to a series of internal definitions. <wingo>fixed the (let lp () (lp)) issue, fwiw <wingo>now i just have one failure when bootstrapping... <wingo>the whole system actually feels faster *ijp paints guile with go-fast stripes <mark_weaver>I suspect that a proper 'define-values' (that isn't defined in terms of mutation) would make such a system much more feasible. <ijp>wingo: would we be able to store actual source code in the elf .go files? <ijp>I'm not saying we should, but I think it would be interesting to do <wingo>it would be hackery to thread it through the compiler but there are obvious places it could go in the .go <ijp>technical benefits/issues aside, I think it's an obvious extension of the free software philosophy <wingo>program + source + debugger + repl <dsmith-work>(update: sneeks box is currently compiling psyntax-pp.go 2.0.9 release) <ijp>I was reminded yesterday on #emacs when someone mentioned their emacs didn't have debug symbols <ijp>it was like looking at a betamax <mark_weaver>it's really terrible what the distros like debian do with emacs. everyone should just compile upstream emacs from source. <mark_weaver>well, I guess debian is the only case I know about, where they strip out a lot of the docs because of the GFDL disagreement. <wingo>uf, rtl doesn't do ,locals, and i totally, totally miss it <wingo>that's like my main debugging tool, ,bt + ,fr + ,locals <wingo>,trace is wonky too, somehow goes to negative frames while still displaying useful info, but i was waiting to be all-rtl before fixing that <wingo>too much wonkiness going back and forth from the stack vm otherwise <ijp>if someone would like my eternal gratitude, I'd like an interactive trace filtering tool kthxbai <ijp>I don't even know how it would work, but I want it <ijp>one idea would be a gui popup that gave you an actual navigable tree <wingo>fangism: can you recompile with CFLAGS='-g -O0' ? <wingo>i just want a good backtrace <ijp>it's funny when a crash is a positive thing <fangism>given that it was nondeterministic, i'll re-run and see if I get different stacktraces <mark_weaver>oh, well, hmm.. I guess not. where's that NULL coming from.. <fangism>re-run didn't crash this time (but did error) (paste #10), trying again... *TaylanUB sent out the e-mail, will wait patiently for any feedback. <mark_weaver>fangism: this is a shot in the dark, but did you run 'make check' in gc-7.2d? did it pass all tests? <fangism>4th run didn't even error. :-\\ (exit status 0) <fangism>5th run error out differently than 2nd run <fangism>uh oh, gc failed some tests. i could've sworn I ran them before. (I usually prevent packages with failed tests from installing) <mark_weaver>okay, my tentative guess is that the problem might be there. <fangism>i'll take it up with our gc maintainer *fangism checks to see if it's me... ok whew, no <fangism>oh, haha, gc's package didn't include a testscript, *I* added it locally <mark_weaver>fwiw, guile-2.0.9 seems to be working on homebrew and macports, based on other folks I've talked to.