IRC channel logs
2015-01-24.log
back to list of logs
<nmontecc>what type does a (display "...") call return? I'm embedding guile and my C code is crashing because scm_list_p(return_value) is true, and scm_length(ret_val) results in "guile: uncaught throw to wrong-type-arg: (length Wrong type argument in position ~A: ~S (1 #<unspecified>) (#<unspecified>))" <nmontecc>ok I think i fixed the problem by first checking whether ret_val == SCM_UNSPECIFIED; it still feels weird to me though that scm_list_p of SCM_UNSPECIFIED should return true <mark_weaver>nmontecc: scm_list_p of SCM_UNSPECIFIED should definitely return false, and it does for me. what version of guile are you using? <mark_weaver>also, you can't safely compare SCM values using ==. there is no guarantee that SCM will be a scalar type. you must use 'scm_is_eq' <mark_weaver>nmontecc: is it possible you are linking to the guile-1.8 library but using 2.0 headers, or vice versa? that might explain this. <zacts>mark_weaver: hum.. I wonder about the possibility of the guile interpreter also interpreting clojure? :-) <zacts>namely, would it be possible? <zacts>oh, but doesn't guile interpret javascript too? <zacts>if so I think clojurescript can compile down to javascript somehow <zacts>so perhaps that would be a realistic way to do something like this <mark_weaver>we implement ecmascript, but it needs a lot of work. <zacts>(improve the guile JS support) <zacts>you mean slow development cycle, or slow runtimes? <mark_weaver>sneek: later tell nmontecc: scm_list_p of SCM_UNSPECIFIED should definitely return false, and it does for me. what version of guile are you using? <mark_weaver>sneek: later tell nmontecc: is it possible you are linking to the guile-1.8 library but using 2.0 headers, or vice versa? that might explain this. <mark_weaver>sneek: later tell nmontecc: also, you can't safely compare SCM values using ==. there is no guarantee that SCM will be a scalar type. you must use 'scm_is_eq' <rekado>on Dec 31 I submitted a bug/patch to the bug-guile ML to update the SXPath docs. <rekado>I wonder if it was a mistake to send it to the bug-guile ML instead of the devel list. <rekado>I consider the sparseness of the docs in the area of sxml to be a bug, so I posted there, but I feel that my patch would be better discussed on the guile-devel list. <daviid>wingo: hello! did you try make distcheck: guile-gnome [devel branch], using guile-2.0? <sneek>wingo, daviid says: it is all fine and perfect, stable-2.0 and g-wrap pass their tests-suite, guile-gnome and guile-clutter compile fine with the latest stable-2.0 and kisê (guile-gnome) and my guile-clutter examples work fine as well, thank you! now the accessor would be a must, let me know... <daviid>... because then i could release a guile-gnome 2.16.3 version [and guile-clutter 1.12.2] <daviid>wingo: i am a bit git lost here: yesterday i compiled the devel branch but from the 5 patches in master, 4 seems they could be applied valid for guile-2.0 ? <daviid>by the way i did chance configure.ac in devel as well [i'm talking about guile-gnome <wingo>daviid: the patches on guile-gnome master are valid for guile 2.0 and guile 2.2 <daviid>wingo: as you know, a while ago, i created a devel branch, as a fork of master [at that time last patch was ec16517e from mark_weaver], to prepare 2.16.3 [and for that matter i changed configure.ac as well, see 681b47b7 in devel]. anyway, i wonder what would be the appropriate git work now ? <daviid>i'm not completely ignorant but not an a git expert either. how can i apply these 5 patches to my devel branch? <wingo>daviid: git merge master and then fixup any conflicts? <wingo>i.e. when you are on `devel' do a `git merge master' <daviid>wingo: auto merging with master did work - i see there is a git cherry-pick <commit id>, for info - now it compiled fine, but i have a make check- probably nothing serious - problem, did you run make check? <daviid>it tells me ../../dev-environ: 43: exec: ./api.scm: Permission denied <daviid>and ../../dev-environ: 43: exec: ./wrapset.scm: Permission denied <wingo>sounds like there's a guile environment variable missing <wingo>i.e. it's execcing $foo bar.scm but $foo is empty <daviid>i'm prettry sure i ran make check before and never touched dev-environ <daviid>wingo: anyway, i've pushed to devel [the auto merge with master], if you could checkout the devel branch and see why make check [which used to work till 'now' and make distcheck [which never worked on the devel branch] do not work, it would be cool <nmontecc>sneek: hi, i only have 2.0.11 installed on my computer <sneek>nmontecc, you have 3 messages. <sneek>nmontecc, mark_weaver says: scm_list_p of SCM_UNSPECIFIED should definitely return false, and it does for me. what version of guile are you using? <sneek>nmontecc, mark_weaver says: is it possible you are linking to the guile-1.8 library but using 2.0 headers, or vice versa? that might explain this. <sneek>nmontecc, mark_weaver says: also, you can't safely compare SCM values using ==. there is no guarantee that SCM will be a scalar type. you must use 'scm_is_eq' <nmontecc>mark_weaver: hi, i only have 2.0.11 installed on my computer <nmontecc>i tried a simple if(scm_list_p(SCM_UNSPECIFIED)) { printf("wtf\\n"); } and it does indeed print <mark_weaver>what is the value of ((scm_t_bits) SCM_UNSPECIFIED) ? <mark_weaver>well, SCM_UNPACK (SCM_UNSPECIFIED) is the proper way to do that, but on 2.0 they are the same thing. <nmontecc>sorry still i'm trying to print it out - as you can see i'm not exactly a guile expert :) <nmontecc>WOW i just realized i don't have gdb installed :O ok this is kind of embarassing ... <mark_weaver>it's just a C unsigned integer. you know how to print integers with printf, right? <nmontecc>yes, i tried printffing it but wasn't compiling <nmontecc>unexpected type name 'scm_t_bits': expected expression <nmontecc> printf("%d\\n", scm_t_bits(SCM_UNSPECIFIED)); <mark_weaver>okay, good, so you're using 2.0 headers. now, how are you linking this program? <nmontecc>cc -g `pkg-config guile-2.0 --libs` `pkg-config guile-2.0 --cflags` -o test minitest.c <nmontecc>libs: -L/usr/local/Cellar/guile/2.0.11_1/lib -L/usr/local/Cellar/bdw-gc/7.4.2/lib -lguile-2.0 -lgc <nmontecc>cflags: -D_THREAD_SAFE -I/usr/local/Cellar/guile/2.0.11_1/include/guile/2.0 -I/usr/local/Cellar/gmp/6.0.0a/include -I/usr/local/Cellar/readline/6.3.6/include -I/usr/local/Cellar/bdw-gc/7.4.2/include <mark_weaver>scm_list_p returns a boolean as a SCM value, not a C boolean (0 or 1) <wingo>daviid: fixed the accessor bug on stable-2.0 and master, i think <wingo>interestingly guile 1.8 illustrates a different behavior, now that i see it :/ <wingo>the accessor doesn't apply to the subclass, because it sees that field as different. <wingo>dunno, at least it's not reading a slot of a different name :/ *daviid is recompling guile stable-2.0 now <daviid>let's invite 1.8 to orbit a black hole, just a tiny too close :) <paroneayea>I really ought to try installing guilemacs again <boxofrox>i'm curious how fluids work in a multithreading environment. if i'm inside a (with-fluid*) call, and my thunk is about to spawn a thread, does the fluid automatically copy across to the new thread, or do I have to manage that? <daviid>wingo: i'm afraid that did not solve the problem i'm facing: unless, for each subclass(es), i (define-method ((setter <the inherited accessor name>) (self <subclass name>) arg) (next-method)), then it does not bug/crash, but it does not work. so, unless i do the above, the applicable method that [unless redefined for the subclass] comes from the super class is no called <daviid>wingo: just for you to understand better, here is a concrete example where if I do not uncomment the last lines from the paste, it won't work [as it should] http://paste.lisp.org/+345W <wingo>daviid: please minimize the test case to be reproducible just with goops -- no guile-gnome <mark_weaver>boxofrox: if you use 'call-with-new-thread', then the new thread should inherit the fluid values from the current thread. <mark_weaver>if you create the thread outside of guile, then that won't work. <mark_weaver>'scm_spawn_thread' should also propagate the current fluid values to the newly-created thread. <linas>Its not particularly informative (to me) <linas> 7: vm.c:926 return_unused_stack_to_os() <linas> 8: vm.c:1024 scm_i_vm_mark_stack() <linas> 12: ??:0 GC_try_to_collect_inner() <linas>its trying to return a 4K page <linas>at address 7f8653535000 --- this is on linux mint, a variant of ubuntu, <linas>with glibc 2.19 and kernel 3.13 <linas>Its proabably a glibc bug or possibly a kernel bug. <vimmonkey>Huh, any clue while *.go files compile slow? can't find an answer on google other then "just because" <mark_weaver>linas: thanks for that. could you email bug-guile@gnu.org about this, along with the strace trace? <mark_weaver>but yeah, it might be a bug somewhere else. I don't understand how it could be correct for the kernel/libc to report "Cannot allocate memory" when you're trying to say "I don't need this anymore". <mark_weaver>unless maybe that page is not currently allocated. that's the one possibility I can think of that could make this a bug in guile. <wingo>mark_weaver: that was my thought too <mark_weaver>'visit-entry' is definitely being called with too few arguments there <wingo>mark_weaver: it should be (visit-entry entry '() v-env) i think <vimmonkey>Is there any way to speed up guile compilation? <mark_weaver>vimmonkey: it takes a long time to bootstrap initially, because the compiler itself has not yet been compiled. <mark_weaver>so there's an interpreter that's running the compiler to compile the compiler. <vimmonkey>mark_weaver: hm, are the go files systems dependent? if i compile them can i just share them with someone else after? <mark_weaver>but also, if you put .go files in there, you must make sure they correspond exactly to the .scm files. <mark_weaver>i.e. you could use precompiled .go files from 2.0.11 to speed up compiling 2.0.11 on another box with the same word size and endianness. <mark_weaver>but you couldn't use it to speed up the compile of any other version of guile, or from git. <mark_weaver>(i.e. the .go files from an i686 box should work on armel) <mark_weaver>disclaimer: in the future, it's possible that .go files might depend on more than just word size and endianness <vimmonkey>ah alright. I want to try and set up gnuile-emacs on a few different computers, so I was hoping I can pre-package some things to speed things up <mark_weaver>we have discussed the possibility of distributing pre-compiled .go files for common platforms. <vimmonkey>mark_weaver: just curious, you ever set up guile-emacs? Was going to see how threaded scheme code works <mark_weaver>I'm embarrassed to admit that I've not yet done so. too busy with other things. but I'm very excited about the future potential of guile-emacs. <vimmonkey>yeah…honestly i'm looking for a lisp based editor that's a bit more current… light table is cool, wish it had a terminal interface though... <mark_weaver>but I should note that the code in emacs cannot be safely run from multiple threads. <paroneayea>and even better, if you can get it packaged for debian or guix, let me knoww <paroneayea>if you get it packaged for guix, I'd be extra motivated to run guix ;) <mark_weaver>you could create other threads, but those other threads could not run emacs code safely, because elisp code isn't thread safe. <vimmonkey>paroneayea: alright, i hate to admit it but i am running on osx 10.8 <_<, writing a brew script though <paroneayea>vimmonkey: oh well, if you get it running, great! <paroneayea>I need to try again to compile it. I ran into troubles the last time I tried <vimmonkey>mark_weaver: yeah, i wouldn't be modifying buffers within threads, just doing the calculations and signaling back to emacs the results <mark_weaver>that should be fine as long as the calculations are done in scheme code. <paroneayea>sorry, I realized after the fact "could you package it for me" is super rude towards someone asking about it themselves ;) <mark_weaver>I don't know enough about the guile-elisp implementation to know how much elisp you could do safely from another thread. <vimmonkey>paroneayea: not rude, honestly i think elisp is flawed and want to see people use scheme instead heh <boxofrox>thanks, mark_weaver. call-with-new-thread is what i was looking for. *davexunit attempts to replace hash tables with alists in guile-json <davexunit>there's a bit of a complication. how to represent JSON arrays? <paroneayea>I think the popular library for json in common lisp does too <vimmonkey>i read an interesting paper though, talked about how the fact emacs dosen't support multi threaded it forces you to write external applications usually (unless you want to spin up another emacs instance just for some elisp heavy code). <davexunit>paroneayea: good idea. I was looking at a chicken scheme library that uses vectors. <davexunit>for some reason I shy away from vectors most of the time and would prefer lists for this. <vimmonkey>Honestly though the bigger issue is not re-use elisp in other projects, and i think thats what's the guile project is solving which is awesome <taylanub>the Elisp JSON library is configurable in various ways and can use alists, plists, and hash tables for JSON objects <davexunit>I guess I can't choose both, because then (write-json (read-json stuff)) would not be equal to 'stuff'. <mark_weaver>generally I think lists make sense for this, but we need a convenient and reliable way to distinguish arrays from maps. so maybe we need a tag in the 'car' of both. <davexunit>at least a tag for one of them, but a tag for both may be the best thing <davexunit>whoa, just realized that assoc-ref works fine on something like '(object (foo . 1)) <mark_weaver>I'll leave it to your best judgment, especially since my knowledge of JSON is extremely weak. <taylanub>wouldn't it be fine to use Scheme vectors for JSON arrays? their external representation is pretty much as clean as lists, and it would solve ambiguity <davexunit>that's my current solution, but I think it hurts the usability of it. <mark_weaver>are there any other compound structures in json besides arrays and maps? <vimmonkey>ah ok there we go, flying through these go files now… heh <taylanub>JSON is *very* simplistic. it's an advantage and a disadvantage. (if they at least just added comment syntax...) <davexunit>taylanub: I frequently have lists of data, and it would be a pain to use vector->list all over my serialization code. <mark_weaver>using vectors for arrays is tempting, since it would avoid the tagging problem, but vectors are more awkward to work with in scheme. <mark_weaver>davexunit: I have confidence in you to find a good solution :) I don't have enough experience working with JSON to judge. *mark_weaver goes afk for a bit <davexunit>using plain sexps will also remove the need for macros in guile-json, another pain point for me. <taylanub>lists would indeed be desirable, but the tagging/untagging might end up no better than vector/vector conversion?.. <davexunit>but they also do something I don't like: they convert object keys to symbols instead of leaving them as strings <taylanub>well json.el is configurable in many ways. e.g. I preferred using it with plists for objects for my json-sexp-mode.el because plists look nicer for human editing than alists <taylanub>(occasionally object keys would turn into weird keyword symbols with backslash-escaped whitespace in them... in any case it was configurable) <davexunit>yeah, I'm not going to make guile-json configurable. <davexunit>unless the maintainer rejects my changes, I guess. <vimmonkey>hm, getting an error about _rl_get_keymap_name is a undefined symbol in readline.o <vimmonkey>i just did a install of gnu's readline, trying to override where to link to w/ LDFLAGS but it's not working <_< <vimmonkey>hm, reconfigured with a —with-libreadline-prefix , lets see if that works heh <vimmonkey>some stuff scares me, got a bunch of * has no symboles