IRC channel logs


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>hi guilers
<zacts>mark_weaver: hum.. I wonder about the possibility of the guile interpreter also interpreting clojure? :-)
<zacts>namely, would it be possible?
<mark_weaver>yes, it's possible. it would be a lot of work.
<zacts>indeed, cool
<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)
<mark_weaver>that would be extremely slow
<zacts>oh really
<zacts>you mean slow development cycle, or slow runtimes?
<zacts>ah ok
<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.
<sneek>Got it.
<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'
<mark_weaver>sneek: botsnack
<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.
<rekado>Should I resubmit it to devel?
<daviid>wingo: hello! did you try make distcheck: guile-gnome [devel branch], using guile-2.0?
<sneek>wingo, you have 1 message.
<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 ?
<wingo>what? :)
<daviid>by the way i did chance 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>all of them?
<wingo>i think so yeah
<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 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'
<wingo>dunno tho
<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?
<wingo>i ran make check, yes
<daviid>it tells me ../../dev-environ: 43: exec: ./api.scm: Permission denied
<daviid>and ../../dev-environ: 43: exec: ./wrapset.scm: Permission denied
<daviid>2 of 3 tests failed
<daviid>here is the full trace just in case:
<wingo>sounds like there's a guile environment variable missing
<wingo>in the dev-environ script
<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>i don't understand how you could run make check :) on master, because in order to be able to, i had to apply all thses changes [all suggested by civodul at that time, not that he is responsible :), but it would not run with guile-2.o otherwise
<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
<wingo>no time for that, sorry
<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 numeric value of SCM_UNSPECIFIED ?
<nmontecc>what do you mean?
<mark_weaver>what is the value of ((scm_t_bits) SCM_UNSPECIFIED) ?
<mark_weaver>scm_t_bits is an unsigned integer type.
<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 :)
<mark_weaver>no worries, all of us were there once :)
<mark_weaver>or just look at it in GDB
<mark_weaver>(currently, scm_t_bits is uintptr_t)
<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));
<nmontecc> ^
<mark_weaver>scm_t_bits is a type, not a function.
<mark_weaver>printf("%d\\n", (scm_t_bits) SCM_UNSPECIFIED);
<nmontecc>ok i'm facepalming - it says 2052
<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>oh, i see the problem
<mark_weaver>scm_list_p returns a boolean as a SCM value, not a C boolean (0 or 1)
<mark_weaver>so you need scm_is_true (scm_list_p (x))
<nmontecc>that explains a lot
<nmontecc>thanks! i'll try that
<nmontecc>yes that was it
<nmontecc>huge thanks!!
<mark_weaver>glad to help
<vimmonkey>Anyone use guile emacs here?
<wingo>daviid: fixed the accessor bug on stable-2.0 and master, i think
<daviid>wingo: great, will check
<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
<paroneayea>I'm still not sure why it failed to install
<paroneayea>some sort of weird infinite compilation issue
<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]
<daviid>same here:
<wingo>daviid: please minimize the test case to be reproducible just with goops -- no guile-gnome
<daviid>i think i did that let me check
<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>wingo mark_weaver: I have a stack trace for the madvise call, here:
<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> 9: ??:0 GC_mark_from()
<linas> 10: ??:0 GC_mark_some()
<linas> 11: ??:0 GC_stopped_mark()
<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.
<daviid>wingo: here is a minimal test case:
<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 about this, along with the strace trace?
<mark_weaver>it's not really my area. wingo should look at it.
<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.
<mark_weaver>does that make sense?
<wingo>mark_weaver: that was my thought too
<linas>Yes, makes sense
<mark_weaver>wingo: could you take a quick look at <> ? I suspect it will take you less than a minute to judge whether it is correct or not.
<mark_weaver>'visit-entry' is definitely being called with too few arguments there
<mark_weaver>(I noticed the same warning)
<wingo>mark_weaver: it should be (visit-entry entry '() v-env) i think
<wingo>i can fix tomorrow or so
<mark_weaver>okay, thanks!
<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.
<mark_weaver>however, it's only an issue on the first build.
<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>they are dependent on word size and endianness.
<mark_weaver>but also, if you put .go files in there, you must make sure they correspond exactly to the .scm files.
<vimmonkey>hm ok
<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>(not safely, anyway)
<vimmonkey>hm i see
<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...
<paroneayea>vimmonkey: if you get it compiled let me know
<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
<paroneayea>but maybe it was my own fault
<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.
<vimmonkey>well, not talking to emacs within threads
<vimmonkey>yeah =)
<mark_weaver>if they are done in elisp, well, I don't know.
<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
<vimmonkey>well the way it's currently implemented
<boxofrox>thanks, mark_weaver. call-with-new-thread is what i was looking for.
<mark_weaver>boxofrox: you're welcome!
*davexunit attempts to replace hash tables with alists in guile-json
<mark_weaver>davexunit: yes! :)
<davexunit>I actually already did it, but...
<davexunit>there's a bit of a complication. how to represent JSON arrays?
<davexunit>lists, vectors, both?
<paroneayea>davexunit: see how emacs does it
<paroneayea>since it supports it
<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>mark_weaver: yes, I was thinking that.
<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.
<davexunit>I thought that would have thrown an error.
<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.
<davexunit>yes, exactly.
<mark_weaver>davexunit: I have confidence in you to find a good solution :) I don't have enough experience working with JSON to judge.
<vimmonkey>\\o/ done with the go files.
<davexunit>mark_weaver: :)
*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.
<davexunit>later mark_weaver
<taylanub>lists would indeed be desirable, but the tagging/untagging might end up no better than vector/vector conversion?..
<davexunit>taylanub: yes, that's a fair point.
<davexunit>json.el uses vectors as well.
<davexunit>but they also do something I don't like: they convert object keys to symbols instead of leaving them as strings
<davexunit>I don't like that.
<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>backed up all my go files just in case ;)
<vimmonkey>and scm
<vimmonkey>\\o/ make finished and no errors
<vimmonkey>some stuff scares me, got a bunch of * has no symboles