IRC channel logs


back to list of logs

<dsmith>sneek, botsnack
<dsmith>Anyone cross-compile guile lately?
***fangism is now known as fangism-ctrl-Z
<davexunit>hey guilers
<davexunit>what's the best procedure(s) to use to catch exceptions and print a nice backtrace + error message like when an error is unhandled?
<davexunit>there's display-backtrace, but that doesn't print the nice error message part.
<ijp>are you trying to display the "normal" message as part of your program?
<davexunit>yeah, I want to print the normal stuff + do something special
<ijp>I think the normal exception printer is print-exception
<ijp>more than that, I'd need to peek into the repl code
<davexunit>ah, it's not in the manual. I guess I need to dig into the source.
<nalaginrut>I just can't believe Artanis got 50 stars during the time I stopped hacking for my new baby LOL ;-D
*nalaginrut is picking it up these days
***janneke` is now known as janneke_
***george2 is now known as george2_
***george2_ is now known as george2
***petercommand is now known as Guest40998
***petercom1and is now known as petercommand
<janneke>i have trouble using '#,(hash syntax as described in srfi-10 info page
<janneke>with 2.0.9, i get: ERROR: build-constant-store: unrecognized object #<hash-table 1617440 3/31>
<janneke>when defining the animal->family function
<janneke> gives: ERROR: don't know how to intern #<hash-table c24400 3/31>
<civodul>Hello Guilers!
*janneke found a bug
<janneke>the srfi-10 define-reader-ctor 'hash does not work for me
<janneke>i typed the example from the info page
<janneke>(animal->family "lion") works with guile-1.8
<janneke>i'm on fab18c0 Use the right GC version macros.
<janneke>going to build 5ded849 Convert slot allocation to use intsets
<janneke>any ideas?
<janneke>anything i'm missing?
<janneke>i want to interface with json
<janneke>and using hash tables seems natural to json...
<nalaginrut>janneke: you may try guile-json, but I suggestion you try SXML if it's possible for you
<janneke>nalaginrut: i'm usin guile-json!
<janneke>and that's translating hash maps to json nicely
<janneke>i just want a convenient way to create the hash map for export to json
<janneke>sxml,can that help me with json?
*janneke goes to read about that
<nalaginrut>I've written json->scm and scm->json, but never released
<nalaginrut>hmm...maybe not your case
<nalaginrut>janneke: there is hash-for-each you may try
<janneke>yes, thanks
<janneke>i hacked guile-json a bit to convert all (most) symbols to strings and vice versa
<dsmith>Howdy wingo
<dsmith>wingo, Currently attempting to cross-compile guile
<wingo>did your 32-bit compile succeed?
<wingo>cool :)
***Shozan is now known as SHODAN
<wingo>how long did it take, do you know?
<dsmith>No, I didn't log it.
<dsmith>An odd thing with cross compiling. I'm using buildroot, and by default it uses uClibc. Has a separate -lm. Fails finding libunistring, cause it needs frexp for some reason.
<civodul>dsmith: beuc reported something similar when building for Android
<civodul>i have something in my git stash for that
<civodul>lemme see
<dsmith>I'm attemting to get around it by setting an env with -lm fo ./configure
<civodul>yeah, that should work
<civodul>./configure LDFLAGS=-lm
<dsmith>Course, that blows away the configure tests to see if -lm is needed...
<civodul>yes but it shouldn't matter, because it's here
<mario-goulart>dsmith: yocto applies a couple of patches to Guile. Maybe some problems are fixed by those patches already:
<mario-goulart>The patches are those .patch files referenced in the SRC_URI variable. You can find them under the "files" directory in that tree.
<dsmith>mario-goulart, What target is arm big endian?
<mario-goulart>dsmith: I don't know exactly. Doesn't ARM support big and little endianess these days?
<dsmith>Yea arm does, but does anyone actually use be?
<mario-goulart>I don't know. The embedded world is very diverse, so I wouldn't doubt it.
<dsmith>I'm using buildroot. And the sad thing is, need a host-guile, so also need host-gc, host-unistring, etc..
<civodul>dsmith: i just pushed a couple of fixes for what beuc reported a while back
<civodul>wingo: the bit-set* bug was already fixed in stable-2.0 apparently, dunno what happened
<mario-goulart>dsmith: Oh, yeah. I went through similar issues when I ported CHICKEN + eggs to Yocto/OpenEmbedded.
<dsmith>civodul, Ahh. Yeah, I wondered why it ./configure wasn't using -lm when it just previously verified that it needed it.
<dsmith>s/why it/why/
<civodul>the LT_LIB_M change should be just cosmetic, though
<dsmith>civodul, Your recent changes do not have arm be
<dsmith>Hmm. no csqrt
<wingo>civodul: interesting.
<wingo>it was bit-count* btw
<wingo>civodul: i don't see it as fixed fwiw
<wingo>bitvectors.c:716, the first arg should be kv, not v
<civodul>oh, maybe i looked at the wrong commit
<civodul>ok, i've cherry-picked it in stable-2.0 (commit d407525)
<civodul>dsmith: you mean "armbe-*" triplets? does that exist?
<dsmith>civodul, mario-goulart's patch has (string-match "^arm.*eb" cpu)
<civodul>oh, this:
<civodul>looks like they didn't find the bug-report address
<civodul>config.guess does have a case for armeb
<civodul>dsmith: i've pushed a few more patterns
<dsmith>sneek, libgc?
<sneek>Someone once said libgc is
<dsmith>Yey, the cross build happened!
<dsmith>Still building other things though.
<daviid>hello guilers
<daviid>i'd to patch this file which uses twice a deprecated guile procedure, scm_make_vtable_vtable, see line 824 and 833. did read a bit but not much :), so the question is: can I [simply] change that for scm_make_vtable or is there more beind the scene... ?
<daviid>I can not find the doc for scm_make_vtable [else then reading the code], and the manual says [for make-vtable] the seconf arg is optional, but i get a bug if i pass 1 arg only
<daviid>guile-gnome-corba-types.c:824:53: error: too few arguments to function 'scm_make_vtable'
<daviid>scm_corba_struct_vtable = scm_permanent_object (scm_make_vtable (scm_from_locale_string ("srprprprpopopW")));
<daviid>ok, got it right now, sorry for the noise :)
<daviid>source code says ./libguile/deprecated.c: ("`scm_make_gsubr' is deprecated. Use `scm_c_define_gsubr' instead.");, but the manual does not mention that, no warning at compile time either, should i report this?
<civodul>daviid: deprecations are usually documented in the 'NEWS' file
<daviid>ok, but scm_make_vtable_vtable triggers a warning at compile time, not scm_make_gsubr'
<daviid>should it not? it's thanks to these messages that I started to notice 'problems' with corba... I'd never know otherwise...
<civodul>daviid: in ~2.0.11 scm_make_gsubr is declared as SCM_DEPRECATED, so you should get a compile-time or link-time warning for that
<daviid>civodul: for info, i know we don't do that [yet] know, and it would probably represent quite a job :), but while [learning] manipulating hudge libraries [_just_ wrapping gtk generates 32.000 lines of C code] and dozens of these... it helped me tremendously to read in the manuals what is deprecated or not...
<daviid>civodul: I changed the code already, but I am pretty sure it did not print a warning [at compile time] for scm_make_gsubr, but never mind, I'm trying to solve another problem now...
<civodul>ok, np
<civodul>i agree it could help in some cases to document deprecated things
<civodul>so far we've always done differently though
<daviid>still something i don' understand [speaking loudely]: glib-spec.scm defines (add-type-rule! ws "const-gchar**" '(mchars callee-owned out)), gtk.defs properly defines get_application_info,which 3d argument is ... ("const-gchar**" "app_exec") ... _but_ the wrapper generates C code that triggers (add-type-rule! ws "const-gchar**" '(mchars callee-owned out)) ... expected 'const gchar **' but argument is of type 'char **'
<daviid>copy/paste mistake: the wrapper generates C code that triggers: warning: passing argument 3 of 'gtk_recent_info_get_application_info' from incompatible pointer type
<daviid>... expected 'const gchar **' but argument is of type 'char **'
<daviid>anyone ? :) :)
*civodul is oblivious to gtk+
<daviid>the problem is g-wrap
*civodul is allergic to g-wrap :-)
<daviid>fine :), _but_, until we have something fully implemented that wraps gnome as it is right now, which means all gnome libraries wrapped [or what ever you'd like to call that in the future] as goops classes, methods... which is far from being not even designed, we should still maintain guile-gnome and guile-clutter, I think
<civodul>yes of course, just kidding
<daviid>I'd like to understand, this is C code really: why g-wrap does generate char** instead of const-gchar ** if the type is properly defined ?
<civodul>no idea, but lack of 'const' is no big deal, no?
<civodul>anyway, /me -> zZz
<civodul>good night/day!
<daviid>no big deal, you're right
<daviid>bye good night