IRC channel logs

<davexunit>any figl users here? I'm having an issue with it on just one of my computers.

<davexunit>the examples run, but when I run a known working guile-2d example, I get an exception because the dynamic-link to libGL is #f

<davexunit>I can't figure out what the hell is going on with figl that would make the dynamic-link fail with my code but not with their examples.

<davexunit>and only on my laptop...

<davexunit>I am having the most difficult time debugging this.

<davexunit>importing (figl glx) causes my program to run... but nothing renders and I have to kill the process in order to stop it.

<davexunit>and that's from my terminal. when I try to run in emacs via M-x compile, it immediatley exits with a status code 139

<nalaginrut>morning guilers~

<sneek>Welcome back nalaginrut, you have 2 messages.

<sneek>nalaginrut, amk9 says: I came to the same point as you in artanis regarding templating, there is probably the django template style way, but I think tpl->html is more powerful. The only thing I would have liked is to be able to use brackets to delimit strings like in skribilo because it is more readable see my enlightenment here http://lists.nongnu.org/archive/html/skribilo-users/2013-08/msg00004.html

<sneek>nalaginrut, amk9 says: what do you think ?

<nalaginrut>amk9: dunno, square-brackets is delimiter of Scheme now, according to rnrs, so I'm not sure if it's a proper way

<nalaginrut>even if we can disable brackets-as-delimiter in guile's reader-option, it may become strange

<nalaginrut>sneek: later tell amk9 I think it's cool to have a try, could you raise an issue as feature-request on github? in case I forget it later

<sneek>Got it.

<nalaginrut>how can I get the keyword value from a list like (#:a 1 #:b 2 #:c 3)

<nalaginrut>just like parsing args of lambda*

<mark_weaver>(apply (lambda* (#:key a b c) ...) <the-list>)

<mark_weaver>there's also the undocumented 'kw-arg-ref', defined in boot-9.scm, but I wouldn't recommend using that.

<nalaginrut>sounds nice

<mark_weaver>if you can assume that it will be there, a simple (cadr (memq #:b lst)) will do

<nalaginrut>where is the definition of lambda*?

<mark_weaver>it's primitive

<nalaginrut>does it use 'match' to parse the args?

<mark_weaver>no

<nalaginrut>so it parse the args one by one?

<mark_weaver>the VM has special instructions to parse the keywords, optionals, etc.

<mark_weaver>those instructions are part of the procedure prologue.

<nalaginrut>OK, I'll take advantage of lambda* for that purpose

<nalaginrut>thanks

<mark_weaver>no problem. happy hacking!

<nalaginrut>mark_weaver: do you think it's proper to have a IR between RTL and ASM, which could provide multi-platform asm generation

<mark_weaver>yes, and we have it. it's CPS.

<nalaginrut>nice

<mark_weaver>oh, sorry.

<mark_weaver>CPS is between tree-il and rtl.

<mark_weaver>yeah, I dunno, it's a good question.

<nalaginrut>I think you hit something, GCC uses MD for that, and I think it's related to SSA

<mark_weaver>I think maybe it makes sense to have one, yes.

<nalaginrut>and when you mentioned CPS, I have some idea

<nalaginrut>OK, just guessing...maybe it's not

<mark_weaver>yeah, I don't know either.

*nalaginrut keep learning...

<mark_weaver>the thing is, for a VM it makes sense to minimize the number of instructions, because each one has a high dispatch cost to run.

<nalaginrut>but the machine-independent IR maybe useful, I was hit by this idea when sleeping last night

<mark_weaver>but when generating ASM you want something much finer grained I think.

<mark_weaver>I think maybe we'll want a very fine-grained IR, such that each RTL instruction maps to multiple nodes in the IR. and then multiple nodes in the IR will map to single native instructions typically.

<nalaginrut>yes, and I could start such a work even when RTL wasn't done

<mark_weaver>so the RTL instructions would be broken up into smaller pieces, and then those smaller pieces will maybe have some peephole optimizations done to them, and then they'd be recombined into ASM instructions.

<mark_weaver>do you have much experience with compilers? I wonder if you have the needed skills.

<mark_weaver>anyway, the tiger book talks about this, although things are made somewhat more complex by having the VM layer in between.

<nalaginrut>if I don't try, I never have needed skills

<nalaginrut>I could try it for a Guile independent project

<nalaginrut>so you don't worry about breaking Guile

<mark_weaver>I certainly wouldn't discourage you from trying, but I don't want you to get your hopes up that your compiler code would be included in core guile.

<nalaginrut>I planed an external AOT compiler, I mentioned in channel, though wingo think it's better an inner one

<nalaginrut>it means it don't have to integrated into Guile core

<nalaginrut>people could use it from guild after installed

<mark_weaver>the main problem is that any such compiler will have to make lots of assumptions about guile internals. assumptions that are likely to break at various points in the future.

<mark_weaver>I think it would be a great learning experience to hack around with it, but be prepared for the possibility that it won't be used much by others, at least not after we have native compilation in guile core.

<nalaginrut>will AOT in Guile core support multi-platform asm generation?

<mark_weaver>yes, I intend to make sure that X86, ARM, and MIPS are well-supported, at least.

<mark_weaver>(MIPS mainly because of Loongson)

<nalaginrut>ok, can I get involved something with that work?

<nalaginrut>I don't think I have to do another redundant work

<mark_weaver>I don't know, I'd have to think about how you might be able to help in a way that didn't drain too much of our time helping you with it.

<mark_weaver>is there a reason why you want to work on the compiler in particular? there's certainly *lots* of useful things you can do for guile. artanis is a great thing to work on, imo.

<mark_weaver>Keep in mind that I didn't start contributing to Guile on the compiler either. I started with simpler stuff, and slowly worked to gain confidence and experience.

<mark_weaver>I think you are trying to start at some of the most complex work there is in Guile, and I don't think you know enough yet to be helpful there.

<nalaginrut>it's a bit slow for current Guile, I think it's better to do something with the performance before other work. Let alone I'm interested in backend develop

<nalaginrut>I know it's a complicated work, that's why I was attracted

<mark_weaver>heh, I can sympathize with the desire to jump into the deep end of the pool :)

<mark_weaver>the problem is that you don't yet know nearly enough about how guile works internally. we'd spend an enormous amount of time teaching you what you need to know.

<nalaginrut>when I came to Guile community, I know little about programming. Now I learn much than that time, you know, such a desire make me progress, actually, even myself can't stop it

<mark_weaver>that's good! I hope you continue, and maybe in a few years you'll be able to help more with the compiler.

<mark_weaver>I just think you have to take it in smaller steps.

<mark_weaver>it took me about 2-3 years of hacking things all over the source tree, learning as I went, before I got to the point where I could help somewhat with the compiler.. also, I've studied compilers on and off for about 20 years, starting as a teaching assistant for a compiler design course at university.

<mark_weaver>so it's not a question of intelligence. I don't doubt that you can get there. but there's a lot of studying between here and there.

<nalaginrut>I know you mean in reasonable way, but I realized small steps can't feed me, but I know I should prepare my way better, for long term

<nalaginrut>thanks for you advices, I'll think about it

<nalaginrut>but for the AOT, it worth to try it for me anyway, it's not about bigger patch for reputation. There's some reason I have to try such a challenge because of another guy, which is more personally. Guile is a good platform for me.

<mark_weaver>okay. again, you're of course welcome to hack your own native compiler for guile, and that would probably be a great learning experience. the main thing is that there's a limited about of time we can spent helping you through that process.

<mark_weaver>s/spent/spend/

<nalaginrut>I'll try to not waste your time as possible ;-)

<mark_weaver>and if you do that, then you should think of it as solely an educational experience, without expectation of integration in core guile. It's hard for me to say this, because I don't want to be unfriendly, but I think it's kinder to tell you this now than later.

<nalaginrut>yes, it's educational experience

<mark_weaver>and I hope you don't take any of this as an insult. there's no reason to take it that way. wingo and I have been studying compilers for many years.

<mark_weaver>you are simply at an earlier point in your journey.

<mark_weaver>there's no shame in that.

<nalaginrut>there's an entry point for any journey

<mark_weaver>indeed!

<nalaginrut>better than just worship

<mark_weaver>heh, I agree!

<nalaginrut>actually, I just worship many years, finally I found it's wasting my time

<nalaginrut>quit or jump into, I don't want to waste my time any more

<mark_weaver>that's a good step to take!

<nalaginrut>there's rarely hope to expect many users for any compiler, right? People won't change language or compilers usually ;-)

<mark_weaver>true

<mark_weaver>regarding our earlier discussion about IRs before ASM, it occurs to me that it might well make more sense to compile ASM from the CPS.

<mark_weaver>going through the RTL layer mucks things up somewhat

<mark_weaver>RTL is designed to be a good software VM. it's not designed to be a good intermediate language for native code gen.

<nalaginrut>mark, there's same question I want to ask you, I think you're facing the same situation of mine. It could be little users choose Guile, and what's your expectation? ;-P

<mark_weaver>yes, if you want lots of users, Scheme is not the right language to choose :)

<mark_weaver>that's not why I do it.

<mark_weaver>I'm more interested in building something that (I hope) will stand the test of time better than the favorite languages of today.

<nalaginrut>yeah, I should throw this question to answer it, there's no reasonable reason sometimes

<nalaginrut>when I chose Scheme, I avoid to talk about the language itself to them, all I talking is the web-framework/server...which they could understand easier

<mark_weaver>Lisp is one of the oldest languages, and Scheme a nice cleanup of it. They are adaptable enough to have remained relevant even as the ways that we program have changed so much.

<mark_weaver>the less flexible languages have to be thrown away and replaced with something totally new every decade or so.

<mark_weaver>C has also survived much longer than the others, but not so much because it's a good language to write stuff in today, but because it's the lowest-level portable language.

<nalaginrut>I learn web-framework since I think maybe web-dev attracts more people, well, there's some, but as I said, people are hardly to change/learn new languages

<nalaginrut>I don't blame C though it has many bad things too, since I'm an OSdev too, I don't think there's better system-language other than C at present, and I have to live with C

<nalaginrut>people are hardly to change, except the language has good selling point

<mark_weaver>I think C is very nicely designed for what it is, basically a portable assembly code.

<nalaginrut>they'll give it a try, as I know many guys tried erlang for special purpose

<mark_weaver>and when that's where I need to work, it's my language of choice.

<nalaginrut>I can't blame C because I can't get rid of it ;-D

<mark_weaver>but most of the time I want to work at a much higher level.

<nalaginrut>me too, that's why I choose Guile, though I can't explain why I choose Scheme in reasonable way, but for Guile, there's reasonable reason

<nalaginrut>IMO, C+Scheme is nice way

<mark_weaver>yes, I wholehearted agree!

<mark_weaver>*wholeheartedly

<nalaginrut>but as I wrote more Scheme code, I realize I'm not willing to write C part

<nalaginrut>Artanis has no C part, and I don't want to insert them

<mark_weaver>most of the time, no C at all should be needed.

<mark_weaver>but it's nice to have the option of writing some small parts in C.

<nalaginrut>yes

<nalaginrut>but I still could *blame Guile* (don't let wingo know) for the performance, that's why I always ask for AOT ;-P

<mark_weaver>nalaginrut: have you read SICP? and did you do the exercises as you went?

<nalaginrut>yes I've read SICP

<nalaginrut>but lack of practice, I forgot many things

<mark_weaver>it occurs to me that EOPL (Essentials of Programming Languages) might be a good book for you to read and work through, if you want to learn more about writing compilers in scheme.

<mark_weaver>I've found that if I don't do the exercises, my understanding of the material becomes increasingly superficial as I go.

<mark_weaver>have you found that also?

<nalaginrut>yes I did exercises, or I don't think it could be called 'read'

<nalaginrut>for textbook

<mark_weaver>ah, good!

<nalaginrut>mark_weaver: one of my friend come to visit me, I have to go out for him, so I have to stop talking now ;-)

<mark_weaver>I have my copy of EOPL here. one of the few books that I keep nearby.

<mark_weaver>okay, enjoy!

<nalaginrut>OK, I'll read EOPL

<nalaginrut>see you

<mark_weaver>have fun :)

<mark_weaver>sneek: later tell nalaginrut https://en.wikipedia.org/wiki/Essentials_of_Programming_Languages

<sneek>Got it.

<mark_weaver>morning wingo!

<mark_weaver>I just noticed that ((assemble-program (compile '(define foo 1) #:env env #:to 'rtl))) defines foo in the current module, regardless of what 'env' is.

<mark_weaver>is that expected?

<wingo>good morning!

<wingo>good question

<wingo>what does that do for tree-il?

<wingo>er

<wingo>the stack vm, i mean i guess

*wingo going to try to get contification done today

<mark_weaver>exciting! :)

<mark_weaver>(compile '(define foo 1) #:env env) seems to do the right thing.

<wingo>probably because that last -> 'value step is done with `env'

*mark_weaver looks

<mark_weaver>you're right. it sets current-module before running the code.

<wingo>i think the reason is to allow for a file that is loaded to be compiled, and then loaded from different modules

<wingo>depending on the module it's loaded from, it defines its bindings here or there

<wingo>we can think of changing that in the future but i think we should avoid doing so now -- we should aim to reproduce the same behavior

<wingo>if possible, anyway

<mark_weaver>okay, fair enough. I tend to agree. Though I dislike the 'current-module' fluid idea for anything outside of REPL-like things, but we can deal with that in the future sometime.

<wingo>agreed

<mark_weaver>fyi, I'm currently working on reworking the patches from my branch, along the lines we agreed on before. (rename the 'apply' instructoin to 'tail-apply', and change 'return-values' to assume that 'reset-frame' has been called).

<mark_weaver>will that conflict badly with what you're doing now?

<wingo>nope, that sounds excellent

<wingo>i have local patches to fix the dfg to be able to create a global (interprocedural) dfg

<mark_weaver>cool! I'd like to get continued-fractions.scm working on wip-cps-bis.

<wingo>and from that i'm working on contification, just another pass

<mark_weaver>ooooh, nice!

<wingo>that's all my pending work

<wingo>i was thinking that .dir-locals.el might be a better way to fix indentation

<mark_weaver>ah yes, makes sense. I forgot about that option.

<mark_weaver>is that file read by default, or do I have to configure emacs?

<mark_weaver>oh, I was also going to move the 'list' -> 'cons' transformation to tree-il/primitives.scm

<mark_weaver>to expand-primitives, that is.

<mark_weaver>does that sound reasonable?

<wingo>sounds reasonable, yes

<wingo>.dir-locals.el is read by default, yes

<wingo>there is an example in the toplevel dir

<mark_weaver>okay, I agree wholeheartedly that's a better option. I was cringing at the redundancy as I was doing it.

<mark_weaver>wingo: I'd be glad to do the dir-locals thing, but before I do: you haven't already done so, right?

<wingo>no i haven't, please go ahead

<mark_weaver>okay

<mark_weaver>wingo: where do you think I should put it? in module/language/ ? seems overly broad for the cps stuff, but both cps.scm and tree-il/compile-cps.scm need it.

<mark_weaver>(I just pushed the other changes, btw, so wip-cps-bis now computes 1000 digits of pi :)

<wingo>excellent!!

<wingo>module/language sounds fine to me

<mark_weaver>okay :)

<mark_weaver>wingo: I wonder if we shouldn't just put these into the top-level .dir-locals.el

<wingo>also fine with me, whatever you think is best

<mark_weaver>okay. I think I'll also arrange for it to get into the tarballs.

<mark_weaver>make sense?

<mark_weaver>well, I guess it's not clear.

<mark_weaver>I'll hold off on that.

<wingo>doesn't matter to me, again whatever you think is best :)

<mark_weaver>all pushed now.

<mark_weaver>and now time for sleep :)

<mark_weaver>happy hacking!

<wingo>happy zzz :)

<ArneBab_>mark_weaver: the paper on Memory Barriers was a great read - thank you again!

<ArneBab_>Can I read yaml with guile? searching for yaml scheme has been unsurprisingly unsuccessful…

<taylanub>ArneBab_: Chicken implementation, if that helps: https://github.com/tenderlove/chicken-yaml

<ArneBab_>taylanub: libyaml bindings

<ArneBab_>taylanub: thanks! (I hope it works in guile without too much effort…)

<ArneBab_>I think I’m not yet versed enough in guile to get that running… but thanks anyway. I planned to share an existing yaml data structure between python and guile. I’ll have to find another way…

<mark_weaver>ArneBab_: the chicken implementation of yaml seems to call out to a C library, so it uses chicken's FFI, which is very different from Guile's. Anyway, IMO it would be much better to write something like that entirely in Scheme.

<mark_weaver>but either way...

<mark_weaver>JSON is simple enough that it's very easy to implement in Scheme, fwiw. There are several implementations around.

<wingo>didn't aleix have a json lib?

*wingo doesn't recall

<tupi> https://github.com/aconchillo/guile-json

<mark_weaver>hi wingo! how goes the hack?

<wingo>tupi: yep, that

<tupi>it's on guildhall as well i think ...

<mark_weaver>time for me to move 'list'->'cons' to expand-primitives...

<wingo>mark_weaver: going ok :) implemented contification first for let, only to find out that fixing letrec transforms let-bound functions to fix-bound functions, so now i have to do part of the general case

<wingo>hopefully done soon

<mark_weaver>hehe

<mark_weaver>I suppose you could have disabled the fixing-letrec pass temporarily, but this way is even better :)

<mark_weaver>after list->cons, I'm thinking of trying to debug prompts in RTL.

<tupi>mark_weaver: heya, it's gong well thanks! i have succeeded to move the entire department of the fac i'm working for to use almost stricktly free S/W [i am working on this since 5 years now] and for the first time, VALE do Rio Doce [a hudge mineral extraction company] will use a GNU linux based solution ... I am using guile mainly to control thousands of processes spread over several servers... it's great to see that with faith [if i may

<tupi>say so] and dedication, you may actually suceed no so to convince but rather invite even industrials to defend the free S/W 'cause' ...

<mark_weaver>tupi: that's great news! :)

<mark_weaver>that reminds me, I still need to get those thread-safety fixes for (ice-9 popen) committed.

<tupi>mark_weaver: that would be nice yes

<mark_weaver>I'll try to get to that later today.

<tupi>and i still [will] need gnome3, clutter-gtk ... let's talk about that and see how nuch time it would take, i'll write an email to you and wingo soon!

<wingo>tupi: congrats, that is great stuff!

<mark_weaver>yeah, need to move on that soon too. so much to do...

<wingo>so much to do indeed :)

<wingo>the good hack.

<tupi>wingo: many thanks!

<mark_weaver>wingo: btw, I noticed that 'expand-primitives' already expands 'cons*' into nested 'cons'.

<wingo>mark_weaver: probably because there is no cons* vm op

<mark_weaver>*nod*

<mark_weaver>wingo: btw, thanks for fixing up my (quite bad) 'convert-to-indices'. I'm embarrassed about how sloppy that was. I didn't really understand the representation yet at that point.

<wingo>not a problem at all!

<mark_weaver>too impatient I guess

<wingo>i also didn't understand the format when i first started with it

<wingo>the notational clarity just wasn't there, and it could still be better

<mark_weaver>btw, I really like what you did with $ktail. when you first mentioned it here, I didn't really understand what you meant, but I think your new solution is perfect.

<mark_weaver>and the builder macros make a world of difference as well.

<tupi>it is just too bad that we don't have a good digital image processing toolbox in guile. and the more i look at it the more i think the world is moving toward java [in that field] and C based toolbox are now late against imagej/fiji, notably]. otherwise i would also consider FFI work ... the design of imagej is teriible [terribly bad], in my [not so humble :)] opinion

<mark_weaver>I wonder if it would be worthwhile to improve 'unparse-cps'.

<tupi>anyway, off topic thoughts ...

<mark_weaver>to produce more readable output. I'm on the fence a bit about that. on the one hand, it's good to see the raw data structure, but on the other hand, it's so verbose that even simple cases end up with huge output.

<mark_weaver>what do you think?

<mark_weaver>actually, I don't want to distract you from contification. we'll talk later.

<mark_weaver>tupi: iirc, cky is working on a JNI interface for Racket. Maybe that could be adapted to Guile when it's ready.

<wingo>mark_weaver: glad you like the builder stuff! i agree that we should improve unparse-cps

<wingo>principally to be more like the builder notation

<mark_weaver>*nod*

<wingo>it would also be nice to improve the pretty-printer so that it can know about other indentations

<mark_weaver>Indeed, and I'm unhappy with the pretty-printer in other ways too. It seems to do a suboptimal job a lot of the time.

<wingo>as a hack we could add special cases to it for lists whose head start in $let or $k

<mark_weaver>I might work on that at some point soon.

<wingo>heh, indeed

<wingo>yes our pretty-printer should be less terrible :)

<mark_weaver>I've been pretty-printing cps quite a bit lately, and I invariably have to manually fix it up before I find it comprehensible.

<wingo>alternately we could make the "unparse" output more like scheme, so the stock pretty-printer does a better job...

<wingo>dunno

<mark_weaver>I think the pretty printer should accept the same indentation data as we have in dir-locals

<mark_weaver>well, maybe it needs a bit more help than that.

<mark_weaver>but yeah, I think you should be able to give it hints about the constructs being printed.

<mark_weaver>and I think it needs some kind of solver algorithm that copes better with deeply-nested constructs.

<mark_weaver>e.g. it shouldn't just use the same indentation rules until it gets to the right edge and then everything down there is vertical. it should spread out that badness in a better way.

<mark_weaver>anyway, I'll think on it later.

<mark_weaver>wingo: peval is turning the nested 'cons'es back into 'list'.

<wingo>exciting!

<mark_weaver>I guess I should remove that rule now.

<wingo>yep, makes sense to me

<mark_weaver>will do

<wingo> (($ $values (arg))

<wingo> (or (maybe-load-constant dst arg)

<wingo> (maybe-mov dst (slot arg))))

<mark_weaver>hmm, there are a lot of rules and patterns in peval involving 'list'. looks like some optimizations might be missed if they're nested 'cons' instead.

<wingo>that in compile-rtl.scm, maybe-load-constant dst not maybe-load-constant (slot dst)

<mark_weaver>huh? I'm confused.

<mark_weaver>oh, the (slot dst) should be changed to dst?

<mark_weaver>but why are you telling me? it's your code :)

<mark_weaver>the first formal argument to 'maybe-load-constant' is named 'slot'.

<mark_weaver>though I haven't looked very carefully at this code.

<wingo>dunno, couldn't recall who owned that

<wingo>anyway :)

<mark_weaver>oh I see. dst is already a slot.

<wingo>dst is a slot in that context

<wingo>yes

<wingo>nice, nonrecursive contification is working

<wingo>will clean up & push

<mark_weaver>yes! :)

<mark_weaver>that's great news!

<mark_weaver>wingo: so, changing 'list' to 'cons' before peval has a potential problem. there are pattern matches in peval that will be more of a pain that way. for example: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/language/tree-il/peval.scm;h=3d350392e2829371b255c80046c9831e6b00abbc;hb=8499f0a37dbdf3d8f2eb7526fc2bb9fd4eab9098#l892

<mark_weaver>and that's not the only one. search for "'list" in that file.

<mark_weaver>certainly it could be done with (? <proc> ...) patterns and such, but it will be more of a pain.

<mark_weaver>after you've pushed, I'd be curious to hear your thoughts on that.

<mark_weaver>hmm, well, looking closer, maybe it's not so bad. maybe of those rules could simply be removed.

<mark_weaver>s/maybe/many/

<mark_weaver>I'll look into it.

<davexunit>wingo: I have a figl issue. On one of my computers, I can get the figl examples to run, but my own code that does not use glut and only imports (figl gl) crashes.

<davexunit>I should write to guile-user about this, but maybe you have some sort of idea?

<wingo>davexunit: i don't have time atm unfortunately

<wingo>prolly write to guile-user and copy daniel hartwig

<mark_weaver>davexunit: I saw your message here about that earlier. does 'dynamic-link' fail?

<davexunit>it seems to, yes.

<davexunit>dynamic-pointer "glViewport" #<dynamic-object #f>

<mark_weaver>so it might be a library load path issue.

<davexunit>ERROR: In procedure dynamic-pointer: Symbol not found: glViewport

<davexunit>but the figl examples work on the same machine.

<mark_weaver>focus on why dynamic link fails. any failures later are just the cascade.

<davexunit>and my guile-2d examples work on at least 2 other debian machine.

<davexunit>I'm trying to figure out the best way to debug.

<mark_weaver>I'd start by running 'strace' on a figl example that works (on the machine where guile-2d fails)

<wingo>do you have the -dev packages installed for the gl things?

<mark_weaver>and look for where it's searching for the figl library.

<mark_weaver>wingo: the figl examples work.

<mark_weaver>wingo: just not his own code.

<wingo>humm

<mark_weaver>and then try your example, and see where it's searching for the library.

<davexunit>okay

<davexunit>thanks

<mark_weaver>search for the name of the dynamic library in the strace output.

<mark_weaver>good luck!

<mark_weaver>the probes for the file in various places will probably be "stat" system calls.

<davexunit>okay. first time really using strace.

<mark_weaver>you'll probably want something like: strace -f -o trace.out guile <args>

<mark_weaver>then search in trace.out. it will be a big file. it's a dump of all the system calls that were made during execution.

<mark_weaver>well, it doesn't have to guile <args> at the end. just put whatever command you would have run from the shell, after the 'trace.out'.

<mark_weaver>you can also attach strace to a process that's already running, if you can manage to attach it before the 'dynamic-link' is done.

<mark_weaver>(with the -p <pid> option)

<davexunit>okay, so my guile-2d program never loads libGL

<davexunit>whereas the figl example yields "10098 open("/usr/lib/i386-linux-gnu/libGL.so.1", O_RDONLY|O_CLOEXEC) = 7"

<mark_weaver>davexunit: in the strace output from guile-2d, can you see where it is attempting to open libGL in various locations, but failing?

<wingo>mark_weaver: the vm changes look good btw

<mark_weaver>(search for "libGL")

<wingo>just rebased to see them

<davexunit>mark_weaver: I searched for that and get nothing.

<mark_weaver>wingo: glad to hear it! thanks :)

<davexunit>I don't think dynamic-link ever gets called

<davexunit>in figl, it's wrapped in a delay form.

<mark_weaver>if you change (dynamic-link ...) to (pk 'dynamic-link (dynamic-link ...)), then it will print something when/if it gets called.

<mark_weaver>you know about 'pk', right?

<mark_weaver>very useful for debugging.

<wingo>mark_weaver: pushed the initial contification pass; it doesn't contify recursive functions yet

<mark_weaver>wingo: excellent! :)

<davexunit>mark_weaver: I know of pk, but not much about it

<wingo>at least it gets (let ((1+ (lambda (n) (+ n 1)))) (1+ 2))

<mark_weaver>can it run continued fractions?

<davexunit>can I just edit the installed figl source or do I have to reinstall the library when I make changes?

<mark_weaver>well, you could, but maybe that's not the best way.

<davexunit>I don't think it's the best way, either.

<wingo>mark_weaver: haven't tested :)

<davexunit>I think I tried just hacking the source I had in /usr/share/guile but that file was not recompiled after

*wingo -> afk, ciao1

<wingo>!

<mark_weaver>wingo: okay, thanks for the hacking. ttyl!

<mark_weaver>davexunit: it didn't print a message about recompiling it?

<mark_weaver>it would have put the new .go file in your home directory until .cache

<ArneBab_>mark_weaver: I agree: I think yaml in scheme would be much nicer.

<mark_weaver>davexunit: so the other way of doing it is to run guile within gdb, and put a breakpoint in the dynamic load procedure.

<ArneBab_>mark_weaver: but writing a yaml parser is not trivial…

<mark_weaver>true.

<mark_weaver>but it also doesn't seem too huge.

<mark_weaver>davexunit: so do this:

<mark_weaver>davexunit: gdb guile

<davexunit>okay

<mark_weaver>then at the gdb prompt: break dynl.c:89

<mark_weaver>it'll ask a question, say: y

<ArneBab_>mark_weaver: I just saw that the haskell parser is generated directly from the specification - that might be the best way to do it for scheme, too.

<mark_weaver>then: run <args>

<mark_weaver>where <args> are the arguments you would have put after "guile" on the command line, if any.

<mark_weaver>then it'll run and hit the breakpoint anytime 'dynamic-link' is called.

<mark_weaver>when it hits the breakpoint, type: display file

<mark_weaver>and it'll show you the name of the library it's trying to load, and also arrange to show that every time the breakpoint is hit in the future.

<davexunit>cool

<mark_weaver>from within the breakpoint, type 'c' to continue execution, e.g. if it's a different library.

<mark_weaver>this should show definitively whether dynamic-link is getting run.

<davexunit>seems to go right through the breakpoint, even with the figl example

<mark_weaver>hmm

<mark_weaver>you typed "break dynl.c:89" ?

<mark_weaver>and said yes to the question?

<davexunit>lyes

<davexunit>yes*

<mark_weaver>ArneBab_: I dunno. I know almost nothing about yaml or the language its spec is written in.

<mark_weaver>davexunit: hmm.

<davexunit>am I missing something else to be able to do this?

<mark_weaver>davexunit: what happens if you do this same thing, but with no arguments to "run". and then type (dynamic-link "foo") at the guile prompt?

<davexunit>let's try

<mark_weaver>ArneBab_: but that can certainly be a very nice approach, in general.

<davexunit>nothing.

<mark_weaver>hmm. works for me. what system are you on? what version of guile?

<davexunit>debian testing. guile 2.0.9

<mark_weaver>hmm, it might be because I'm running a guile that I compiled myself (and the source tree is still around), and you're running the debian package.

<mark_weaver>the debian package might not have been compiled with debugging support.

<davexunit>that's likely the issue.

<davexunit>I'm still wondering why the pks aren't working.

<davexunit>there is only dynamic-link call for "libGL" in figl

<mark_weaver>where is the source code for the file you edited?

<mark_weaver>what pathname?

<davexunit>from the figl directory: figl/glx/runtime.scm

<mark_weaver>what's the full pathname?

<davexunit>/home/dave/Code/guile-figl/figl/glx/runtime.scm

<mark_weaver>is /home/dave/Code/guile-figl/ in %load-path?

<davexunit>I just re-ran make, sudo make uninstall, sudo make install

<mark_weaver>which example works for you?

<davexunit>null-program.scm

<davexunit>all of the examples work, but that's the easiest to run.

<mark_weaver>how are you running the example, exactly? and how are you running guile-2d?

<davexunit>guile null-program.scm

<davexunit>and for guile-2d, I've been specifiying a -L flag, so like: guile -L .. simple.scm

<mark_weaver>well, the reason it didn't pick up your 'pk' change is likely because /home/dave/Code/guile-figl wasn't in the load path. it was looking only in the installed paths.

<mark_weaver>do you have any GUILE_* environment variables set? any relevant pathnames in there?

<mark_weaver>s/relevant/relative/

<mark_weaver>e.g. do you have '.' in there?

<davexunit>mark_weaver: didn't pick it up even though I re-installed the library?

<davexunit>I don't think I have any environment variables set, no.

*davexunit checks .bashrc

<mark_weaver>well, if you ran 'make' it should have compiled the 'pk' into the .go file.

<mark_weaver>just type 'export' to see all your environment variables.

<davexunit>no GUILE_* variables set

<mark_weaver>better yet, run guile and type %load-path

<mark_weaver>(that's really the ultimate thing that matters)

<davexunit> ("/usr/share/guile/2.0" "/usr/share/guile/site/2.0" "/usr/share/guile/site" "/usr/share/guile")

<mark_weaver>so the 'pk' is still not outputting anything, even for the figl examples, after running 'make' and 'make install' ?

<davexunit>yes

<davexunit>which leads me to believe I am looking in the wrong place

<mark_weaver>it looks like this now: (define libGL (delay (pk 'dynamic-link (dynamic-link "libGL"))))

<mark_weaver>?

<davexunit>yes

*mark_weaver tries on his.

<mark_weaver>interesting. it doesn't work for me either.

<mark_weaver>hmm.

<davexunit>there's something else going on here, but I can't quite figure it out.

<davexunit>*somehow* there's a dynamic link to libGL

<mark_weaver>there are also dynamic-links in glx/runtime.scm and glu/runtime.scm and glut/runtime.scm

<davexunit>glu and glut are extras.

<davexunit>I expected the dynamic-link to libGL to be in gl/runtime.scm

<mark_weaver>null-program seems to use only glut

<davexunit>guile-2d uses on (figl gl)

<davexunit>s/on/only/

<mark_weaver>I added pk's to all three of them (libGL libGLU libglut), and in the examples libGL never gets loaded.

<mark_weaver>even though vbo.scm uses (figl gl) and uses a lot of calls that start with gl-*

<mark_weaver>so I guess you should put the pk's in the other places too, 'make' and 'make install', and try again.

<davexunit>okay. will do.

<davexunit>thank you for help, mark_weaver

<mark_weaver>no problem :)

<mark_weaver>guile-2d would be a good thing; I'd like to help make that happen :)

<davexunit>I only have my laptop right now and I really wanted to work on font rendering for guile-2d.

<davexunit>instead, I just wrote a C program last night that uses libpango and libcairo to render fonts.

<davexunit>but now I just heard about FTGL that might be a *lot* easier for me to use, but I might have to sacrifice internationalization stuff.

<mark_weaver>this is an area of ignorance for me, I'm afraid.

<davexunit>yeah, me too.

<davexunit>well, I wrote a blog post about it at least. http://dthompson.us/font-rendering-in-opengl-with-pango-and-cairo.html

<davexunit>I had to dig around a lot to put a basic example program together, so I figured I'd share.

<mark_weaver>nice!

<davexunit>maybe it'll help someone else even if I abandon this approach

<davexunit>anyway, debugging...

<mark_weaver>so guile-2d also has C code that links directly to libGL?

<davexunit>no C code yet.

<davexunit>I will probably have a little bit of C eventually.

<davexunit>particularly for particle systems.

<davexunit>but it will be mostly pure guile.

<mark_weaver>okay. mainly I asked because, if so, it might be a relevant difference between the examples and guile-2d, for purposes of debugging this issue.

<davexunit>yeah. that would complicate things.

<mark_weaver>it might not make any difference at all, but I'm at the point of grasping at straws here.

<davexunit>yeah...

<davexunit>calling dynamic-link with glut somehow links gl, I guess?

<davexunit>I see the one pk output for glut and that's it

<mark_weaver>yeah, when you load glut, it will (I guess) load gl as well, as a dependency, but that happens below the level of the Guile code.

<mark_weaver>presumably you only need that "libGL" dynamic link if you use one of the procedures in figl that needs to call a function in libGL directly.

<davexunit>another weird thing: adding (figl glut) to my imports allows the gl* symbols to be found... but nothing is rendered in the window and the program needs a kill -9 to stop

<davexunit>for my guile-2d example, that is

<mark_weaver>okay, time to shift gears. let me think a moment.

<mark_weaver>so the glViewport foreign call is trying to do so via an #f dynamic library.

<davexunit>yes.

<mark_weaver>that might be a bug in figl.

<mark_weaver>lets see.

<davexunit>quite possibly.

<davexunit>but I'm having a hard time figuring out how figl does its magic.

<davexunit>because the magic *works* on many machines

<mark_weaver>well, the glViewport wrapper seems to be in low-level.scm, defined using 'define-gl-procedures'

<mark_weaver>and that's a macro defined in gl/runtime.scm

<davexunit>yes

<mark_weaver>and I can see something fishy about this define-gl-procedure macro. the second rule will never match.

<davexunit>now into define-foreign-procedure in runtime.scm

<mark_weaver>oh, nevermind, that's wrong.

<mark_weaver>I was confused.

<mark_weaver>indeed.

<mark_weaver>my head hurts :)

<davexunit>you're not alone.

<mark_weaver>okay, I see. so (resolve <name>), in gl/runtime.scm is what's responsible for getting the dynamic library object. in this case it's returning #f, which is no doubt wrong.

<mark_weaver>well, I thought so anyway. let me look at this again.

<davexunit>I hacked in (define libgl (dynamic-link "libGL"))

<davexunit>and replaced ((current-gl-get-dynamic-object)) in resolve with libgl

<mark_weaver>ah!

<davexunit>now my program runs, but...

<davexunit>it does the render nothing and needs to be killed kill -9 thing

<mark_weaver>it looks like you're supposed to set the 'current-gl-get-dynamic-object' parameter during initialization.

<mark_weaver>I'm not sure why it wouldn't just link directly.

<davexunit>what do they mean "parameterize"?

<mark_weaver>what it's doing there, just a plain (dynamic-link), looks in the libraries that have already been loaded, or maybe just the ones loaded as part of the C code link.

<davexunit>ah

<mark_weaver>davexunit: do you know about dynamically-scoped parameters? they're like fluids. (not procedure arguments)

<davexunit>no

<mark_weaver> https://www.gnu.org/software/guile/manual/html_node/Parameters.html

*davexunit is reading

<mark_weaver>regarding why this is a mess, there's a big comment near the top of gl/runtime.scm about it.

<mark_weaver>but basically, the cleaner solution to the hack you just did is this:

<davexunit>yeah I read that

<davexunit>I wonder why my code is running at all on other machines...

<mark_weaver>use the (figl gl runtime) module. and then do as part of initialization: (current-gl-get-dynamic-object (lambda () (dynamic-link "libGL")))

<mark_weaver>what are the other machines that this works on? what systems are they running?

<davexunit>I tested on an ubuntu 12.04 laptop last night.

<davexunit>and my main dev machine running debian testing works as well

<mark_weaver>are they both 64-bit systems?

<davexunit>yes!

<mark_weaver>both of the debian testing systems, that is.

<davexunit>wait, no.

<mark_weaver>(the one that works, and the one that doesn't work)

<davexunit>this laptop is 32 bit.

<davexunit>possible source of an issue.

<mark_weaver>hmm.

<davexunit>the ubuntu machine I used was 64 bit.

<mark_weaver>possibly. figl may not have seen much testing on 32 bit.

<davexunit>2 isn't much of a sample size but...

<davexunit>so, parameterizing got the program running. I see output every second of the program's frames-per-second

<davexunit>but again, window is black

<davexunit>doesn't respond to key events.

<mark_weaver>oh, interesting. glx/runtime.scm and glut/runtime.scm both set the 'current-gl-get-dynamic-object' parameter.

<davexunit>oh, that would explain why the program starts working when I include one of them.

<mark_weaver>the glx runtime sets it to use get-libGL, and the glut one sets it to use get-libglut.

<mark_weaver>so I guess that's what's really happening with the libGL thing. if you load glut, then it knows that libGL will be loaded as a dependency of glut, and thus it can simply use the result of (dynamic-link "libglut") to lookup the libGL functions, I guess?

<davexunit>yeah

<mark_weaver>I think you should undo all the hacks you've made to the figl source. make and make install again.

<davexunit>yes

<mark_weaver>you might try loading (figl glut runtime) before anything else, in your program.

<mark_weaver>I think that might help.

<mark_weaver>because it seems that you're trying to run glViewport before this glut module has been loaded.

<mark_weaver>so 'current-gl-get-dynamic-object' hasn't yet been reset at that point, and that's causing problems.

<mark_weaver>and of course remove your hacks.

<mark_weaver>worth a try anyway.

<davexunit>trying it out

<mark_weaver>but maybe it's a just a bug having to do with 32-bit.

<mark_weaver>and you shouldn't do that (current-gl-get-dynamic-object (lambda ...)) hack I suggested either.

<mark_weaver>or maybe just import (figl glut) instead.

<davexunit>I'll try with figl glx

<mark_weaver>sure.

<davexunit>since I don't really want the glut module.

<mark_weaver>*nod*

<davexunit>same issue.

<mark_weaver>it runs but the window is black?

<davexunit>game loop runs but is unresponsive

<davexunit>yes

<davexunit>I tried stripping down the example program too

<davexunit>to only include the bare minimum needed to run

<mark_weaver>I strongly suspect that figl has a bug relating to 32-bit systems.

<davexunit>I also tried to go back in the commit history for guile-2d in case I introduced a bug.

<davexunit>but no luck.

<mark_weaver>I suggest that you make the smallest example you can, demonstrating the problem. something that works on 64-bit jessie but fails on 32-bit jessie. and send it to the mailing list, cc'ing daniel hartwig.

<davexunit>yeah

<davexunit>I can try that.

<davexunit>perhaps it's an issue with the SDL bindings too...

<davexunit>not sure

<mark_weaver>ah, I forgot you were using that too. yeah, the bug could be there as well.

<mark_weaver>ideally, see if you can eliminate either sdl or figl from the minimal example entirely.

<mark_weaver>if the bug is in guile-sdl, it would be a shame to trouble hartwig with it needlessly.

<davexunit>yes.

<davexunit>well, I think based on the fact that the glut examples work... there is an issue with sdl or something.

<mark_weaver>it's also possible that the 32-bit bug is in your own code.

<davexunit>yes that too.

<mark_weaver>well, I get the impression that the examples use only a tiny fraction of the code.

<mark_weaver>so the fact that they work doesn't mean much.

<mark_weaver>but we found one issue at least: you need to load the glx or glut module before the others.

<davexunit>well... things work now. that was weird.

<mark_weaver>really? well, all's well that ends well, eh? :)

<davexunit>I forgot to upgrade this laptop to guile-sdl 0.5.0

<mark_weaver>ah!

<mark_weaver>excellent! :)

<mark_weaver>now I can go back to hacking the RTL compiler :)

<davexunit>I think I know what happened (roughly)

<davexunit>sorry for pulling you away from that for so long

<mark_weaver>do tell (am curious)

<mark_weaver>no worries.

<davexunit>actually, my theory wouldn't work.

<davexunit>I just don't know how my code didn't break with sdl related functions.

<davexunit>the API changed...

<davexunit>not enough I guess?

<mark_weaver>so upgrading to guile-sdl 0.5.0 is what made it start working?

<davexunit>ohhhh, I know. SDL:set-video-made takes some flags, and the format for that changed.

<davexunit>yes

<mark_weaver>good! mystery solved :)

<davexunit>so the new format fails silently with an older version of guile-sdl

<davexunit>one of those flags is to tell SDL to make an OpenGL context.

<davexunit>so I didn't have an opengl context.

<davexunit>and thus nothing worked.

<mark_weaver>*nod*

<davexunit>okay. case closed. thank you.

<davexunit>going outside now.

<mark_weaver>you're welcome. enjoy!

IRC channel logs

2013-08-17.log