<daviid>[ sorry but to try the above paste, you'll have to comment the #:use-module (dimfi) ] <daviid>have to run again :) bbl [ but please sneek me the solution :) ] <mark_weaver>daviid: I'm sorry, there's not nearly enough context in that paste for me to understand what you're doing. <mark_weaver>for one thing, you're not showing where you are using that 'eval-when' form. <daviid>mark_weaver: hello! really? i thought i pasted the module as a all, let me check <daviid>the top of the paste is the module definition, you may copy/paste/save it <mark_weaver>daviid: well, for starters, if you want any hope for this to work, you need to move the 'eval-when' to the end of the module. <daviid>is that true? sorry for my ignorance, but i thought it was not necessary, let me try <mark_weaver>but I'm not sure what you hope to achieve here that a simple #:re-export wouldn't acheive. <daviid>[ ithought so because in the define-module form, we export re-export things that are obviously not defined yet <mark_weaver>and why do you want to export things that aren't defined? <daviid>mark_weaver: becausae you don't know and don't wantr to impose a particular module import 'chain' <mark_weaver>it works to unconditionally export or re-export something before it is defined, but if you ask if it's 'defined?' before it has been, then the answer will be #f <daviid>mark_weaver: !colour [as a example] could be defined by many modules <daviid>you don't know which one and in which order a user will import them <mark_weaver>that doesn't help me understand why you want to export !colour from a module that doesn't define it. <mark_weaver>in that case, you _are_ defining it, via the (define-class ...) <mark_weaver>but your 'eval-when' has (if (defined? acc) (re-export acc) (export acc)) <daviid>if it has been defined, there is a generic, you want the system to add a methods <mark_weaver>if you want to unconditionally export with no warnings of duplicates, just use #:re-export (!colour ...) <daviid>mark_weaver: this is an accessor, nbopt a procedure <daviid>we, clos 'experts' do _not_ want the module system to interact with methods, accessors, setters and getters, as i said already many times] <mark_weaver>I confess that I might be overlooking something here, I haven't studied guile's module system very deeply. <daviid>mark_weaver: right now, it does not matter ytou don'1t understand why, i mhave a million lines of clos code behind me, i trying to overcome this terrible module system limitation [for clos expert, it isd terrible] <mark_weaver>well, we've been over that before, but I don't see how it relates to my recent comments here. <daviid>i don't undertand you don't understand :) <mark_weaver>how does this hack to choose between 'export' and 're-export' help you achieve your goal? <mark_weaver>why not just always re-export? does it interfere with the merge generics stuff somehow? <daviid>i just want the module system, if the symbol is defined, to 'run' re-epxport <daviid>because it hides my generic(s) and methodf(s) <daviid>i tried re-export does not work if the symbol does not exists <mark_weaver>look, I understand that you want all generic functions to have global scope, not per-module. <mark_weaver>if you're going to do ugly hacks to achieve that, let me tell you the best way I know: <daviid>that's ok with the merge generic option <mark_weaver>just make a single module that defines all the generics, and import that from everywhere. <daviid>mark_weaver: this , i'm sorry to say so, impossible in practice <daviid>let's concentrate on how to over come the liitation <daviid>you don't know and don't want to which module a user will import first <daviid>therefore, the system must just add methods when the generic exists <daviid>there is no practicle way to manually do that <daviid>that is why clos has a specific name space for generics <daviid>and that is why we have he merge generics option <daviid>but it's not sufficient [with guile] because of this accessors/getters/stters export re-export problem <mark_weaver>as I've said countless times, merge generics is not sufficient, because it means that each module's generics will only have methods from the modules it imported. <mark_weaver>and in many cases, you need to write code that calls generics and expects to use methods that it knows nothing about. <daviid>mark_weaver: if i know the order in which modules are imported, i can impose, by 'hand' or the #;export or the #:re-export ... <mark_weaver>the next evolution of my suggested hack would be, again, to define all generics in a single module, but to modify the part of guile that automatically defines generics to add those generics to this single global module of generics that everyone imports. <mark_weaver>so that way, you wouldn't have to enumerate the set of generics yourself. <daviid>mark_weaver: that's not what we wanbt <daviid>no clos 'expert' would want that <daviid>you want the system to add methods, that's all <mark_weaver>I may not be a clos expert, but I can clearly see the fatal flaw in the merge generics approach, as I just outlined above. <daviid>this is wrong mark_weaver , soory <daviid>but anyway, why does the code i wrote does not work? <daviid>i thought i missed, maybe, something like <daviid>(if (defined? acc) (re-export `(,acc)) (export `(,acc))) <daviid>mark_weaver: you should read a clos tutorial really: it is _not_ about protection, neither about encapsulation. clos is also not 'respecting' the cl package system, of course not ... but anyway, i don't want to 'convince you', just want a series of options that give me clos, not goops <daviid>for a clos user, the responsibility is to uniquyely name his classes, as for a guile user uniqyuely name his procedures. from there, i'm the expert, not the guile mnodule system <mark_weaver>daviid: I can understand why you'd want generics to have global scope, but merge generics doesn't give you that. <mark_weaver>merge generics results in every module having it's own variant of each generic function: one that only knows methods that its imported module added. <mark_weaver>and I'm telling you the only way I know of to achieve what CLOS gives you. <daviid>mark_weaver: i know that, but as the system has been implemented, it will work if i can or export or re-export <mark_weaver>merge-generics is just a fatally flawed approach, and that judgment stands even if I want global scope for generics (which I think is not unreasonable to wish for) <daviid>it does actually if i use the #:export or #:re-export clause of our module system <daviid>mark_weaver: can you helkp me make this code i pasted work? <daviid>the conversationb is useless afaic <daviid>you just don't understand clos, that's fine <mark_weaver>this discussion is really irritating me, so I'd better drop out soon, but if you insist that you know better than me, then look at the definitions of 'export' and 're-export' in boot-9.scm, see how they use 'module-export!' and 'module-re-export!' and try hacking your own variant. <nalaginrut>how can I remove ";;; newer than compiled" while compiling? I've already disabled auto-compile <ArneBab>2>&1 | sed "s/^;;;.*//" 2>&1 | grep . 1>&2 ; test ! $$? -eq 0 # grep did not find anything <nalaginrut>ArneBab: why not just $(GUILEC) -o $@ $< 2>/dev/null ? <ArneBab>nalaginrut: that part runs a build script (bootstrap.sh) which can also create some relevant error output, so I have to only kill the unimportant parts. <nalaginrut>one more question, I want precompiled all *.scm, then ,use (artanis artanis) won't compile it in the first time, or it's too slow. But I've tried precompile and install it to /usr/local/lib64/guile/2.0/ccache/artanis, but seems not work <nalaginrut>as we know, Guile is precompiled, so it won't compile eval.scm when we use Guile first time <artyom-poptsov>nalaginrut: Hi. It seems that .go-files should be installed into `<prefix>/lib/guile/2.0/site-ccache/' <nalaginrut>artyom-poptsov: nice, thanks! Seems the manual has been updated so much <nalaginrut>hmm...I did according to the manual, but it seems don't use the path (%site-ccache-dir) specified, maybe a bug <nalaginrut>and I realized that other packages suffer from the same thing, like guile-irc <nalaginrut>even these packages were precompiled, it compiles when I use it first time <nalaginrut>seems it always use ~/.cache/guile/ccache/2.0-LE-8-2.0/usr/local/share/guile/2.0/ for me <artyom-poptsov>nalaginrut: Just checked one of my projects, and it looks like site-ccache works fine. <artyom-poptsov>BTW, invoking of "guile -c '(display (%site-ccache-dir))'" returns `/usr/lib/guile/2.0/site-ccache' for me. <nalaginrut>well, it seems my %load-path always added ~/.local/share/guile/site/2.0 <nalaginrut>I've removed GUILE_LOAD_PATH setting in ~/.bashrc, but seems it's still there <ft>The compiled load path is controlled by: $GUILE_LOAD_COMPILED_PATH <nalaginrut>Compiled files will be stored in the directory $XDG_CACHE_HOME/guile/ccache, where XDG_CACHE_HOME defaults to the directory $HOME/.cache <ft>it uses that xdg path if it couldn't find the .go file in %site-cache-dir <ft>%compile-fallback-path <ft>I'm pretty sure, this is working on my end, too. <nalaginrut>but %compile-fallback-path will add $HOME anyway <nalaginrut>does it mean I have to set XDG_CACHE_HOME first? <ft>Here's a .go file that loaded from the site-ccache path on my system: open("/usr/local/lib/guile/2.0/site-ccache/termios.go", O_RDONLY|O_CLOEXEC) <nalaginrut>%compile-fallback-path is "/home/nalaginrut/.cache/guile/ccache/2.0-LE-8-2.0" on my machine, but I don't think users should 'make install' with sudo to put the *.go here <ft>No they shouldn't. But your installation procedure can install to (%site-ccache-dir) when it has root priviledges. <nalaginrut>yes, I installed it to (%site-ccache-dir), but seems doesn't work when I test <ft>Wrong permissions on the directory? <ft>or the installed files? <ft>It should work and it does for me, FWIW. <ft>Maybe use ‘strace’ to see what's up? <nalaginrut>ft: do you just put the compiled file to (%site-ccache-dir) without any suffix? <ft>strace -e open guile -c 'whatever code here' <ft>nalaginrut: nope, including the .go suffix. See the output from strace I pasted earlier. <ft>nalaginrut: that's for (use-modules (termios)) <nalaginrut>ft: it auto compile directly, so I don't know which file it tries to open <ft>Auto-compile always compiles to the fallback path, AFAIK. <ft>Because that's in $HOME, what means that the user will have write permissions. <nalaginrut>ft: what I want is avoid auto-compile, since I've already precompiled <ft>it shouldn't auto-compile if there's a .go file that's *newer* than the corresponding .scm file in the site-ccache directory structure. <ft>What's the exact situation, including full path names, configuration parameters and time stamps? <nalaginrut>the *.scm will be put in (%site-dir), /usr/local/share/guile/site/2.0 here <ft>Hm... I guess I'm out of ideas then. :-/ <nalaginrut>with strace output, when it load the first *.scm in (%site-dir) , it tried to find .go in /home/nalaginrut/.cache/guile/ccache/2.0-LE-8-2.0/usr/local/share/guile/site/2.0/ <nalaginrut>seems it never try to load .go in (%site-ccache-dir) <ft>It does work as expected for me, as I said before and my strace output confirms. *ft is going to be AFK for a while now. <nalaginrut>ft: oh! The problem is that I use -p in cp command, which will keep timestemp when compiling, I removed it, now it works fine! Terrible *davexunit sees the GNU Glean release announcement <zdavis>I all. I am having a hell of a time with guile and unicode/bytevectors/strings/etc. <sneek>Welcome back zdavis, you have 1 message. <sneek>zdavis, tadni_ says: Hey, any news on *.iso generation? :^) <zdavis>I have a bytevector that I want to convert to a string <zdavis>and I dont want any unicode conversion to happen, I need it one-to-one: #vu(255) -> "ÿ" <zdavis>i tried utf8->string and it threw an error trying to generate unicode <zdavis>am I missing some function somewhere? <zdavis>ijp: where would I specify latin-1? <ijp>I'm trying to remember <ijp>I am of the "utf8 or gtfo" generation <ijp>the ugly way would be to iterate over the bytevector, using integer->char, and collecing the output in a string (which should work for latin-1 because of how unicode codepoints were allocated) <ijp>or to write to a string port <ijp>zdavis: try bytevector->string from (ice-9 iconv) <ijp>with encoding string "latin-1" <ijp>or maybe the string is "ISO-8859-1" ***dsmith-w` is now known as dsmith-work
<cky>ijp++ re "utf8 or gtfo"