<dsmith>Anyone cross-compile guile lately? ***fangism is now known as fangism-ctrl-Z
<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>2.1.0.800-3cde gives: ERROR: don't know how to intern #<hash-table c24400 3/31> <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>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>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 goes to read about that <nalaginrut>I've written json->scm and scm->json, but never released <janneke>i hacked guile-json a bit to convert all (most) symbols to strings and vice versa <dsmith>wingo, Currently attempting to cross-compile guile <wingo>did your 32-bit compile succeed? ***Shozan is now known as SHODAN
<wingo>how long did it take, do you know? <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 <dsmith>I'm attemting to get around it by setting an env with -lm fo ./configure <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>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. <civodul>the LT_LIB_M change should be just cosmetic, though <dsmith>civodul, Your recent changes do not have arm be <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>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>Still building other things though. <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>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 **' *civodul is oblivious to gtk+ *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 <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?