IRC channel logs


back to list of logs

<ArneBab>I have a problem with define-language: When I run it interactively, the reader can read unicode as plain unicode symbols, but when I run it on a file, I get unicode escape symbols instead.
<ArneBab>when run interactively the (display port) gives #<input: soft 677270>
<ArneBab>when run on a file, I get #<input: examples/d20world.w 5>
<ArneBab>and running it on a file containing only “define φ 1” raises the error `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'
<ArneBab>could it be that I have to use some SRFI which is loaded in interactive use and which changes the encoding of the port?
<ArneBab>,d set-port-encoding! → New ports are created with the encoding appropriate for the
<ArneBab> current locale if `setlocale' has been called or ISO-8859-1
<ArneBab>I think that answers that…
<ArneBab>somehow solved: When I use (with-fluids ((%default-port-encoding "UTF-8"))), it works flawlessly.
<ArneBab>I don’t know whether that’s the clean way to do it, though.
<ArneBab>I guess that (set-fluid! %default-port-encoding "UTF-8") could negatively affect other parts of the code (which relies on ISO-8859-1 encoding)
<ArneBab>Is there a reason not to use with-fluids?
***mario-go` is now known as mario-goulart
<jmd>In which directory should dynamically loadeded libraries go?
<sneek>jmd, you have 1 message.
<sneek>jmd, civodul says: "failed to produce output path" means that the package's build system did not actually create and populate $prefix
<waxysubs`>ArneBab: do (setlocale LC_ALL "") early in your program's execution. that's done automatically when running guile interactively, but not when running a script.
<waxysubs`>(this is mark_weaver, typing at his logging bot)
<waxysubs`>anyway, gotta go...
<ArneBab>waxysubs`: ah - thanks!
<ArneBab>waxysubs`: could you (later) tell me why I should not use with-fluids? (I have a backlog, so it’s not urgent)
<ArneBab>also it works pretty well, now
<davexunit>ArneBab: is there a reason you are using fluids instead of parameters?
<ArneBab>davexunit: apart from “it was the only solution I found”, no.
<davexunit>I know that Mark has told me before to avoid fluids/parameters wherever I can because they do not play nice with things like lazy evaluation.
<ArneBab>then I think I should just setlocale
***nalaginrut_ is now known as nalaginrut
<ArneBab>waxysubs`: but don’t I destroy localization with that?
<davexunit>ArneBab: since I missed all the context of this discussion, I have no idea if the reason I gave is the reason why mark recommended against using with-fluids. Could very well not be.
<ArneBab>davexunit: I think he first of all wanted to help me get the system running.
<ArneBab>in a not-too-horrible way ☺
<ArneBab>I’m pretty happy that I can actually program quite conveniently in wisp, now.
<ArneBab>davexunit: I can now do stuff like this:
<davexunit>boy does that look different
<davexunit>cool to see other languages running on guile
<dsmith-work>Morning Greetings, Guilers
<davexunit>good morning
<davexunit>I've been experiencing some bizzare crashes which I think are a result of using procedure->pointer
<davexunit>I give pointer->procedure a lambda, but I think that lambda gets GCd at some point and all hell breaks loose.
<ArneBab>davexunit: ☺
<mark_weaver>davexunit: pointer->procedure takes a pointer object, not a scheme procedure. did you mean to write procedure->pointer?
<mark_weaver>I believe that when you use procedure->pointer, you need to keep a reference to the SCM pointer object as long as it's needed.
<mark_weaver>ArneBab: destroy localization with 'setlocale'? I don't understand. 'setlocale' is all about supporting localization.
<ArneBab>mark_weaver: I mean that when I set LC_ALL to "", users who only set LC_ALL will get unlocalized strings, right?
<mark_weaver>ArneBab: I should also mention that Guile 2.2 will call (setlocale LC_ALL "") automatically, even in scripts.
<ArneBab>so I need not worry about surprising people
<mark_weaver>ArneBab: no, the "" means that it sets the locale according to the relevant environment variables such as LC_ALL, LANG, etc.
<davexunit>mark_weaver: yes I meant to write procedure->pointer. I need to find somewhere to stash the pointers.
<ArneBab>mark_weaver: ah, nice!
<davexunit>because the pointers are created in a constructor procedure for a record type, so I guess I'll add a field to keep a list of all the pointer.
<mark_weaver>davexunit: unless you expect to create large numbers of these record types, where some of them will become obsolete and can be GC'd, you could just store them in a global table.
<davexunit>mark_weaver: yeah, that's true. this is a library intended for others to use, though, so maybe I should worry about that case.
<mark_weaver>regarding the field you suggested, with a list of the pointer objects, where would that field go?
<davexunit>into the record type.
<davexunit>for lack of a better place.
<davexunit>I don't really like that solution, though.
<mark_weaver>the record type descriptor? (not the instances, I assume)
<mark_weaver>I guess ideally they would go in the same place where the C pointers go.
<mark_weaver>i.e. a sibling field to whatever stores the associated C function pointers.
<mark_weaver>I wonder if we could somehow make this situation less awkward...
<davexunit>maybe I should explain a bit further. I'm wrapping up a C struct. there are some functions that modify an instance of that struct to register callback functions for when certain events happen.
<davexunit>so, I thought that I would register callbacks that triggered Guile hooks, so users of the library won't have to worry about the ugly details of the FFI.
<davexunit>the record type I made has a field for each type of hook.
<davexunit>perhaps that field could store a pair with the hook and the pointer that needs to stay alive.
<davexunit>sorry if this is confusing. not doing the best job at explaining. thanks for trying to help.
<mark_weaver>are these C function pointer fields in the instances, or in the type descriptor?
<davexunit>they aren't in either place right now.
<mark_weaver>you said there is a field for each type of hook. what structure are these fields in?
<davexunit>they are fields of a record type.
<mark_weaver>fields of the record instances, or of the record type descriptor?
<davexunit>(define-record-type <foo> (make-foo bar-hook) foo? (bar-hook foo-bar-hook))
<davexunit>I'm not sure what the difference is, I guess. apologies if this is like pulling teeth.
<mark_weaver>well, if you have 1000 objects of type <foo>, will there will 1000 copies of these fields, or just one?
<davexunit>because I create a new hook for each instance.
<davexunit>the callback functions are associated with an instance of the C struct.
<davexunit>here's a thought: use a global weak-key hash table to store the pointers.
<mark_weaver>davexunit: hmm, that seems suboptimal, unless there will not be very many of these instances.
<mark_weaver>seems better to have these functions take the record instance as an argument.
<mark_weaver>and then you'd only need to create the hooks once for each record type.
<davexunit>hmm, I don't think that will work for me.
<mark_weaver>well, creating these C functions is probably not particularly cheap.
<mark_weaver>though I confess I don't know for sure.
<davexunit>so, those C callbacks do pass along the instance of the struct. the complication for me is when the scheme procedure is applied, I need to take the pointer and retrieve the corresponding instance of the record type.
<davexunit>I guess this too could be solved by a global hash table.
<davexunit>in this case I could indeed have only 1 pointer per callback, for all instances of the record type.
<mark_weaver>In Scheme, creating many procedures that differ only by the values of some free variables is cheap and memory efficient. but the same cannot be said of creating C functions using procedure->pointer.
<davexunit>yeah, good point.
<mark_weaver>davexunit: could you add a field to the C struct of type SCM, that contains a pointer to the associated Scheme record object?
<mark_weaver>(or whatever the Scheme callbacks need)
<davexunit>mark_weaver: no, because it's not my library.
<davexunit>I think I can make this work, though.
<davexunit>I will just need something like a hash table to convert from foreign pointer to instance of the record type.
<davexunit>but maybe there's a better solution for that part.
<mark_weaver>davexunit: I suppose another option would be to use the SCM pointer object as the record type, and use the bytevector procedures to access the fields. not sure what's best. I mostly use pure scheme these days...
<davexunit>the API has functions to access all of the fields I need. which would be fine if I didn't want to store additional information, like those hook objects.
<davexunit>so I currently have a record type that stores the pointer and the hooks, and I have an unwrap-foo procedure to get access to the pointer.
<mark_weaver>if you avoided the per-instance hooks, would you still need additional per-instance information attached to these records?
<davexunit>I'm unsure if I want to avoid per-instance hooks, just per-instance C pointers.
<davexunit>I guess the trade off here is making it the user's responsibility to check that the instance passed when the hook is run is the one that they were expecting.
<davexunit>that could be fine, certainly a lot simpler for me to write.
<davexunit>mark_weaver: that's for your patience in discussing this with me. now I have some things to try when I get home from work.
<ArneBab>mark_weaver: also thank from me for all your help on wisp!
<mark_weaver>glad to help!
<ArneBab>mark_weaver: it’s pretty far now, by the way. The parser and REPL works and the SRFI is almost in a state where I dare to submit it (though I plan to delay for 7 more weeks, so the SRFI process only starts after I come back from vacation ☺)
<mark_weaver>sounds great!
<ArneBab>And I’m actively using it for programming stuff I want to test *happy*
<mark_weaver>going offline for a while. ttyl!
<ArneBab>mark_weaver: I showed the example to davexunit today: (sadly that is missing syntax highlighting)
***Lajjla is now known as SmurfettePrincip