<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>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, 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) <ArneBab>waxysubs`: could you (later) tell me why I should not use with-fluids? (I have a backlog, so it’s not urgent) <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>I’m pretty happy that I can actually program quite conveniently in wisp, now. <davexunit>cool to see other languages running on guile <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. <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. <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? <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? <mark_weaver>you said there is a field for each type of hook. what structure are these fields in? <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. <mark_weaver>well, creating these C functions is probably not particularly cheap. <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. <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? <davexunit>mark_weaver: no, because it's not my library. <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! <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 ☺) <ArneBab>And I’m actively using it for programming stuff I want to test *happy* ***Lajjla is now known as SmurfettePrincip