***catonano_ is now known as catonano
***apteryx is now known as Guest7992
***apteryx_ is now known as apteryx
<tohoyn>daviid: it seems that gtk-tree-model-get-value is implemented as a generic function. Is it possible to access the nongeneric version of the function? <leoprikler>tohoyn: you can always use GOOPS internals to access specific methods <leoprikler>(generic-function-methods FUNC) yields a list of <method>s, which you can then further inspect <tohoyn>another thing: gtk-tree-model-get-value does not accept a value returned by gtk-tree-view-get-model as an argument <leoprikler>can you paste the method specializers and the class-of model for me? <leoprikler>I suspect it has to do with interfaces still being rather fresh <randart>Morning guilers! Can anyone tell me why (and (file-exists? "guile.rc") (load "guile.rc")) <randart>(trying to have a local rc in my current project directory) <randart>Fails with "no such file or dir: "my/home/dir/./guile.rc" <leoprikler>is this "/my/home/dir" or is the first slash really missing? <randart>Fails with "no such file or dir: "/my/home/dir/./guile.rc" <randart>I don't understand why file-exists finds the file, then load looks in the wrong place (~) for it. <leoprikler>try (let ((guile.rc (canonicalize-path "guile.rc"))) (and (file-exists? guile.rc) (load guile.rc))) <randart>Wow, that worked! Can you explain why? <leoprikler>Because guile.rc is an absolute file name and therefore no relative lookup will take place <randart>but file-exists? finds it nonetheless <randart>so some inconsistency between the behaviour of f-e? and load <leoprikler>you might also try (string-append (getcwd) "/guile.rc") instead, that should also work <leoprikler>I don't think load is supposed to be used that way <randart>I just want the convenience of loading some relevant modules into the repl. The f-e? test need wrap the let incase the local.rc does not exist, but this solves my problem. Thx for the help. <leoprikler>Again, it should work fine as long as you supply absolute file names to both. <leoprikler>btw. for projects you might also want to do recursive lookup (i.e. find local.rc in the project root) <tohoyn>leoprikler: yes, the model is not accepted as an argument <tohoyn>leoprikler: what information do you need? <tohoyn>leoprikler: I was away for some time <leoprikler>tohoyn: (map method-specializers (generic-function-methods get-value)) <tohoyn>(class-of tm) gives: #<<class> <foreign> 7f0977f7cd80> <tohoyn>leoprikler: (map ... gtk-tree-model-get-value) gives: ((#<<gobject-class> <gtk-tree-model> 7f096f0613c0> #<<class> <top> 7f0977f53bd0> #<<class> <top> 7f0977f53bd0>)) <tohoyn>leoprikler: it seems that (class-of tm) is incorrect <leoprikler>yep, probably not correctly handled in the return ***str1ngs_ is now known as str1ngs
<ManDay>Not a day goes by that I don't get at least one entirely incomprehensible error message from Guile :-( <ManDay>What is one supposed to do with this kind of error? <ManDay>emacsen: Glad to hear I'm not the only one puzzled by that <emacsen>I mean one could probably read it and figure it out, but not something you can read and just know off hand <civodul>ah, probably the only thing related to your code in this backtrace is the "eval" stack frame <civodul>meaning that the error comes from interpreted code <civodul>interpreted code leads to terrible debugging because the backtrace shows source code locations of the interpreter, not locations of the interpreted code <ManDay>I'm not sure whether it's the things that I'm doing (they really aren't anything that much out of the usual; perhaps complicated but entirely pure and without exotics like call/cc), or why I am so tormented by Guile's debug output, almost every single day <RhodiumToad>the "wrong type to apply" thing I guess means that something that should have been a procedure was actually #f ? <ManDay>RhodiumToad: Yes, I admit I didn't go into any depth, I just stopped when I got perplexed by the meaninglessness of that error <ManDay>I should probably be able to figure it out, let me see... <ManDay>Well, nope. It's not as easy as I thought. At least on the top level, where I invoke (test), `test` is a procedure indeed (and not #f) <ManDay>So this error happens somewhere deeper in the code <ManDay>civodul: I don't have any (eval)s in my code. Do you suggest I'd get a better output by invoking guile (or guild, to come back to that) differently? <maav>ManDay: i think so, 'GUILE_AUTO_COMPILE=0 guild compile -o mod.go mod.scm' and adding that to %load-path should give better info <leoprikler>Somewhere deeper in your code, you invoke #f and you have no idea where that might be? I do have to wonder at which point your libraries become big enough for you to consider compilation in advance. <ManDay>leoprikler: Perhaps now... Though honestly, if just Guile would support an adequate set of options to perform compilation accordingly that would suffice <ManDay>(i.e. pass on the -O0 or what it was) <maav>ManDay: you already have -O[0123], what do you mean? <ManDay>maav: W.r.t to what leoprikler said, we had that discussion recently about whether I'm using Guile wrongly (I typically only invoke 'guile' and let it compile for me). leoprikler insists that the correct way to develop with Guile is to invoke the compiler directly (usually via a build system), which I find too tedious (and Guile actually already acts as a build system to figure out *what* to <ManDay>recompile, it just doesn't allow to specify -On on the command line like guild) <leoprikler>just because gcc doesn't warn without -Wall doesn't mean your code is correct <maav>so that's the file calling #f as a procedure <maav>it's being used through use-modules or with a direct load, so you can check that <maav>that file is being loaded, and that file is calling #f, as in (#f something), but usually through some variable and so on <leoprikler>You might want to increase COLUMNS to see the full file name <ManDay>(display "test = ") (display test) (newline) <maav>which means that your error is before that <ManDay>If I remove the three lines of code, no error happens <maav>i've added a (define (test) (#f)) line before your example and the exception is shown after, not before, the I am here line <maav>it could be an autoload, perhaps <maav>but no, your code doesn't provide enough info <ManDay>I don't know what it is that you are saying. <ManDay>Are you still saying it's a top-level problem? I'm calling #f? <leoprikler>Between you unintentionally calling #f and Guile deliberately calling #f because it hates you, which is the likelier one? <leoprikler>I'm sure that's all of the code and there's nothing else to it. <ManDay>I can give you the entire code, if you like, but you're entirely besides the whole point here <ManDay>The error message of Guile is complete bollocks <leoprikler>I'm pretty sure #f is not something you should apply. <ManDay>And quite honestly (like usual) there is nothing out of the ordinary in my code. How am I supposed to work like that? <ManDay>leoprikler: Sorry but you're being the opposite of helpful here <leoprikler>I don't think "My code is correct, the interpreter is messed up." is a sane approach to debugging. <ManDay>I never said any such thing. I do not dispute that there is an error my code. <leoprikler>Okay, given that there might be an error in your code, would it not be helpful to know which file it is in [perhaps by increasing COLUMNS]? <maav>ManDay: i've tested the code you have provided and it doesn't throw the error you say, the error message is really useful; the thing is that you don't provide a case to reproduce it <ManDay>maav: I'll upload the entire code (obviously not a test-case), it's three files, hold up please <maav>ManDay, that's asking us to do your job, which some people can do, but it isn't fair at all <maav>you provided code, three lines, and it doesn't raise the issue <ManDay>Obviously it doesn't. It was just meant to prove that I am, indeed, not calling (#f) <maav>i told you what did i used to show the exact same message you get, but after the lines, not before <maav>you simply don't know where, that's the issue <ManDay>And the problem here is Guile's incomprehensible and thoroughly broken diagnostics <maav>how am i so sure you're calling #f if they are incomprehensible? <ManDay>I don't understand your question. <maav>that you should be more polite if you're requesting help <maav>it wasn't a question, but a pointer to start being a bit more helpful <ManDay>maav: I think you mistunderstand. There isn't any help that I'm requesting other than Guile be fixed. We figure out this error and I fix it? Fine. That doesn't mean anything because in three hours from now Guile will produce another incomprehensible error. <ManDay>The problem is not that I have an error in my code, I will be able to find that. The problem is that Guile is unsuited for developing if you can't go 2 hours on fairly simple code without Guile's diagnostic messages blowing up in your face. <ManDay>I'm not saying it's easy to get that right; I'm not saying it's an easy fix to Guile. I'm simply observing that it's an immense problem. <ManDay>And frankly, to get back at your all attempt's to help here, although appreciated, your allegation that this was caused "top-level", just because the error message is as incomprehensible as to infer any deeper level, as well as the allegation that I would be calling #f on top-level and be incapable of isolating it there, this is not productive and not at all helpful. <leoprikler>I doubt there is a deeper level you can go without it showing up in the backtrace. <leoprikler>Of course the "true root" of the issue is elsewhere, but it affects something at the top-level of your module. <leoprikler>E.g. you (define something <incredibly-deep-let-that-returns-#f>) [...] (something [possibly arguments]) <ManDay>no, I am not. If you don't believe me you can look at the code, but that you refused. So be it. <maav>ManDay: I refused, not leoprikler, don't bundle us together *RhodiumToad would like to see the code <leoprikler>W.r.t. the tone, requesting that Guile "be fixed" is (in my opinion) a rather rude way of asking for help. <ManDay>leoprikler: It's true, I shouldn't be "requesting" anything. But it would be the help that I need. <taylan>ManDay: FYI link seems to require a GitHub account. (I have one but others might not.) a fairly good pastebin that requires no account is paste.ubuntu.org. <ManDay>taylan: Thanks, I'd like to be able to delete the files afterwards (I don't want them to float around without control), that's why I put it on Github <taylan>I think paste.ubuntu.com lets you set a time limit <taylan>oh and it's .com not .org, my bad <ManDay>Ah good, if anyone w/o GH account would like to have a look please let me know <taylan>ManDay: what error message do you get again? (I joined in the middle of the discussion) <taylan>ManDay: this is when you load the module, right? don't know if others said this already but "Wrong type to apply: #f" means that at some point, the code tries to use "#f" as if it were a procedure. if it's while loading the module, then it ought to be one of the definitions at the bottom, since they're the only ones that will execute code during module load. <taylan>ManDay: nevermind the module load question, didn't notice it was two files <ManDay>one code, idg.test.ss and 2 modules which are being used <dsmith-work>echo '(#f)' > /tmp/foo; guile -c '(primitive-load "/tmp/foo")' <taylan>ManDay: my suggestion would be to add some type checks to your code. i.e. make some of the procedures explicitly check if the arguments they're getting are of the types you'd expect. like via (if (not (procedure? my-arg)) (error "Should be procedure." my-arg)) <taylan>I agree that it's pretty bad that Guile doesn't give more details on where exactly the error occurs. not sure if there's a way to make it tell more. <leoprikler>I have no idea what it's supposed to do, but the cdr of this thing is called as a function. <RhodiumToad>I think the cdr is supposed to be the iterator function, but that can be returned as #f by an earlier call <RhodiumToad>so I guess the question is, how should that have shown up in the backtrace <taylan>it's a good idea to use SRFI-9 record types instead of cons/list to store data. causes much less confusion. <leoprikler>[or srfi-41 streams instead of home-baked iterators] <ManDay>leoprikler: RhodiumToad: Let me just say it again: I don't expect you to find my error. I can manage that. <ManDay>The code should just prove that the error is not inferrable from Guile's output <RhodiumToad>how are we supposed to investigate why the error is not being reported more clearly without finding it first? <ManDay>RhodiumToad: Well be my guest, I'm just saying I'm not asking you for that. You can wait until I found it, if you like <ManDay>But I think it's symptomatic of a severe Guile problem. Every other day I have a problem like that with Guile. <dsmith-work>One issue with building informative error messages is that not all objects in guile have source properties. <leoprikler>It could also be a symptomatic problem of your code base. I can't blame the Guile numeric tower for my broken implementation of Peano arithmetics. <taylan>leoprikler: well I think Guile should certainly tell during which procedure call the error arises <taylan>if at all possible, that is. I have no idea what other implementations do in a situation like this. <leoprikler>taylan: that's going to be super difficult with optimizations though, especially inlining <RhodiumToad>Exception thrown while printing backtrace: In procedure frame-local-ref: Argument 2 out of range: 1 <leoprikler>Okay, there is not much information to be gained here. <leoprikler>The difference between 2.2 and 3.0 is one layer of TCO. <RhodiumToad>so as I see it, part of the problem here is that it's calling #f in tail position, which means that the details of where it is called from have already been thrown away <leoprikler>lampilelo: you can debug guile at C level with GDB, so that should not be an issue <leoprikler>*Understanding* Guile at the C level on the other hand… takes time. <leoprikler>okay, but that won't work if your problem is at the top level ;P <dsmith-work>Oh how wonderful it would be to have that emacs stepper/debugger thing in Guile! Never even knew it existed. <dsmith-work>You needed to instument the function in question, IIRC <RhodiumToad>maybe the debugger (at least the debug version of the VM) should keep a trace history of tail calls <RhodiumToad>after all, scheme code that does really long strings of tail calls wouldn't exactly be unusual or considered bad <ManDay>dsmith-work: There is a letrec alright, but that's about as complicated as it gets. My program is purely functional, it can't get anymore stupid than that: Step into a function, calculate arguments, step into a function, calculate arguments. If a problem occurs, report back where in the stack you are. That's the absolute basis of scheme or any programming language. And yet Guile, with any <ManDay>optimization turned off!!!, can't figure out how to do this correctly. This gives a very poor impression of Guile to me. <leoprikler>You give a very poor impression of yourself to me. <RhodiumToad>ManDay: tail calling always presents a problem for reporting errors <leoprikler>IIUC tail call optimization is *required* by RnRS, so there's little Guile can do with that. <dsmith-work>Yeah, Guile has lots of rough edges. And growing pains. Some of the old clothes^code don't fit right anymore... <RhodiumToad>right, and tail-calling has to be done properly even when all optimization is disabled <RhodiumToad>because otherwise perfectly correct code would just blow the stack and die <dsmith-work>I've heard some Schemes (Racket?) keep a circular log of last tail calls for debugging. <leoprikler>I think a better way of figuring out the problem would be to begin tracing at a given point. <RhodiumToad>no. the need for some kind of tail call trace is clear <ManDay>leoprikler: Here is your well-deserved medal for personal attacks. Now please stop it or stop talking alltogether. Thanks. <ManDay>That RnRs requires tail-recursive optimizations is very poor excuse, if errors in tail-recursive functions can't be properly traced by the interpreter. <ManDay>The lack of stack context is in no way a reason that no source location is being associated with an error on -O0 <RhodiumToad>uh, well it is if the stack is being examined to find the source location. <terpri>dsmith-work, mit scheme is such a scheme, iirc (it would make sense if racket had it too, given its use in education) <ManDay>RhodiumToad: You don't need the entire stack to do that, obviously. <ManDay>If I, a thinking person, step through the program, I also tail-optimize and yet I know where the fuck I am <RhodiumToad>you do that by remembering where you tail-called from. <ManDay>No, I remember that by know which line of source code I'm currently reading. <terpri>i think mit scheme is where i learned of that technique <ManDay>Note this is not even about showing the correct stack, but only a source location! <ManDay>dsmith-work: it is in a trivial example as mine. <ManDay>If there is no source location, then so be it. <ManDay>But this is the most simple programs of all, like I said: All verbatim in source code, step into a func, calc, step, calc, return. <terpri>dsmith-work, edebug works in guile-emacs fwiw :p but only for elisp, as i believe it depends on a code-walker for instrumentation <RhodiumToad>you're not thinking about how tail calling has to work from the VM's perspective <ManDay>RhodiumToad: I'm thinking about how I'd implement it: The way that I'd do it as a person. And there is no excuse whatsoever for me to forget where in the source (or the stack, as far as it has not been optimized out) the error occurs. <RhodiumToad>it's probably not hard to construct a trivial example. <terpri>ManDay, do you think a partial history of tail calls might be useful? <ManDay>leoprikler: Yes it is, as far as the involved programming semantics are concerned. There is no eval, no explicit continuations, etc. Just a chain of functions. I can rewrite this in C, I WILL get tail-optimizations, and I promise you: GDB will debug this just fine. <ManDay>terpri: you mean only show what's left of the stack after proper-tail recursions? If that's what's left, of course that's better. What's obligatory though is the source location. <ManDay>FWIW, GDB is a good example. You may wanna look at this for a proper tail recursive call. <ManDay>You will see, GDB does it correctly. Of course it does. It's damn trivial. <ManDay>That's why I can't fathom how Guile breaks over it. <leoprikler>((@ (system vm trace) call-with-trace) (lambda () (tail-call #f))) <RhodiumToad>ManDay: hm? gdb can't show tail calls in a backtrace <ManDay>RhodiumToad: What I'm saying is it does't break. You will get the stacktrace (with tail-recursions pointed out) and a source location. <ManDay>PLUS you can turn off optimizations, if you like. then you get the entire stack. <ManDay>(which also, Guile can't do, apparently) <ManDay>(which, fair enough, you may blame on RnRS though that's a matter of taste, I'd say) <RhodiumToad>in C, tail calling is a relatively rare optimization; in scheme, it's how most things work <justin_smith>turning off TCO in a scheme isn't really viable outside toy situations <justin_smith>it's not just "tail call", it's the rewriting of the stack <terpri>ManDay, do you have a small example that makes guile forget the source location? i have a good guess at what might cause that (apologies if you already posted a test case, i only skimmed the scrollback) <ManDay>terpri: no i don't. i will probably have one when I found the error <leoprikler>((@ (system vm trace) call-with-trace) (lambda () (tail-call #f))) <leoprikler>I'm not sure if call-with-trace is even allowed on a file context to be honest. <davexunit>calling it an "optimization" is misleading. tail calls are part of the semantics of Scheme. it's not an optimization be toggled on and off. <maav>exactly, it's like calling java class inheritance an optimization <justin_smith>davexunit: sorry, that's the term I learned in the context of comparing languages, I can see how it can mislead in the scheme context <leoprikler>You're not the only one at fault here. It's been taught that way in universities too. <maav>justin_smith: i have the same issue, but i guess ellision it's more appropiate <lampilelo>this is the simplest example of the error ManDay has: ((lambda () (#f))) <davexunit>wasn't trying to call anyone out or anything. everyone calls it TCO so it's confusing. people think it could be disabled. <leoprikler>also prepare to pipe this into head -n5, because it's going to throw a huge trace at you <ManDay>lampilelo: Nice! Thanks very much! <ManDay>Was that an actual question or rhetorical? <ManDay>I.e. are you suggesting that it is reasonable for Guile to not being able to associate the error with a source location? <leoprikler>From what I understand, Racket's trace works similar but with slightly different syntax. <leoprikler>And it probably doesn't blow up in your face when an exception occurs. <davexunit>guile is not without its issues in the debugging department, but I work on rather large guile programs and real world backtraces have always lead me to my problem. <ManDay>davexunit: my problem also comes from the real world ;) <RhodiumToad>I have to say, finding the error in ManDay's actual example from the backtrace was not at all trivial <ManDay>RhodiumToad: Did you find it (as in: the line of source)? <RhodiumToad>last line of tree-iterator-strip is the one that actually generates the error <ManDay>RhodiumToad: Thanks very much. How did you do it? Just following the code along in your head? <terpri>i wonder if read.c has anything to do with this, in particular maybe_annotate_source, scm_i_set_source_properties_x, etc. <ManDay>RhodiumToad: I see. Well thanks a lot, again. It wouldn't have been necessary but you helped me a lot! <terpri>because guile cannot set source properties on all data types <lampilelo>ManDay: i mean, you have a point that these backtraces often aren't very helpful, but the problem doesn't seem to be trivial to solve <dsmith-work>Another thing that sometimes happens, is an error happens when attempting to print a backtrace. Causes lots of confusion. <leoprikler>If backtracing doesn't work, you need to forward trace ;) <dsmith-work>It's the lack of implmenting "come from" that's the realy problem. <ManDay>lampilelo: It might not be given the way Guile was designed (I don't know anything about its internals so I can't judge that, but I readily believe it), but it should be, because it's the most basic concept, so I dare to say it's a design flaw. <davexunit>we can say anything if we're just going to wildly speculate. <terpri>hm, if i have bad.scm with (define foo '(() . ())) (define (bar) (foo)), the backtrace isn't terrible helpful (only refers to ice-9/boot-9.scm) <leoprikler>then you should get the same issue as everyone else here <dsmith-work>ISTR that Guile could only associate source positions with cons cells. Not sure about newish Guile. <terpri>but i suspect that's a consequence of calling something uncallable rather than source location tracking per se <leoprikler>the point here is, that we would like to know, that (foo) is the uncallable thing <terpri>it's a bit of an edge case, but surely an annoying one if you run into it unexpectedly <leoprikler>dsmith-work: because read errors happen before anything else <leoprikler>I don't think procedures are being formed at that step yet. <dsmith-work>Yep. The reader got that one, and reader knows where it's reading. <leoprikler>The compiler could catch ((lambda () (#f))) through symbolic execution, but that's it. <leoprikler>is there a way of disabling terminal echo (as with stty) for password reading et al.? <dsmith-work>Hmm. Maybe using something in readline? Or. Isn't there a curses interface for Guile? Maybe someting in there.. <RhodiumToad>it has tcsetpgrp/tcgetpgrp but not tcgetattr/tcsetattr