<apteryx>is there anything like in Python to construct strings like 3 * " " == " " in Guile? ***jao is now known as Guest18840
<rlb>guile-3.0 3.0.0+1-1 uploaded to debian NEW -- won't be in unstable until it's evaluated by the ftp-masters. <rlb>I suspect it might end up being somewhat longer before it makes it into testing -- anticipate arguing with some of the buildds (i.e. arch-specific build/test issues), but we'll see. <rlb>So I'm back to wondering if this might be a bug in "promotion to generic", or expected behavior. It works if the first define is changed to a define-method: <rlb> (use-modules (oop goops)) <rlb> (define-method (foo x) 1) <rlb> (display (foo)) (newline) <rlb> (display (foo 1)) (newline) <wingo>besides the class redefinition thing, there was no intended change to goops or generics in 3.0 <wingo>relatedly, it would still be a great thing if someone wanted to implement the generic function dispatch MOP :) ***jao is now known as Guest70236
<lloda>guile-readline/readline.c uses rl_get_keymap_name and on OS X libreadline is an alias to libedit and that function isn't provided <spk121>wingo: if in Guile 3.0 you are requiring C99, I wonder if it could be a good opportunity to shrink configure.ac by presuming headers/functions required by C99 <lloda>is it enough to add rl_get_keymap_name to AC_CHECK_FUNCS([rl_get_keymap]) in acinclude.m4? I don't understand the comment above. <wingo>lloda: dunno, give it a go :) <wingo>spk121: could be a good idea! i am not sure what exactly might need to change tho fwiw <wingo>some of those tests might be brought in by gnulib fwiw <spk121>wingo: what made me think of it was when I saw a tests for complex.h and fenv.h scroll by <spk121>lloda: you'll probably need to stub out the call to rl_get_keymap_name in init_bouncing_parens in guile-readline/readline.c <lloda>I could just replace the check for rl_get_keymap for rl_get_keymap_name and then use HAVE_RL_GET_KEYMAP_NAME in readline.c <lloda>it's weird that libedit provides ...keymap and not ...keymap_name ***ng0_ is now known as ng0
<dsmith-work>apteryx_: re python 3 * " "; (make-string 3 #\space) <dsmith-work>sneek: later tell apteryx Re python 3 * " "; see (make-string 3 #\space) or (xsubstring " " 0 3) <rlb>wingo: I'm not sure it's a regression -- i.e. I think 2.2 might do the same thing (not positive yet). I was mostly interested in what was intended there. i.e. the docs do describe define-method automatically promoting an existing procedure to the generic default, and that's worked I think, so the question is, should it work in this case? ***apteryx_ is now known as apteryx
<stis>Darn, found an annoying bug in guile 3.0 <str1ngs>sneek: later tell daviid . Hello daviid when you have time can you take a look at why this is not working? http://paste.debian.net/1127946. I suspect Warning: Unimplemented type - array;: (c -1 #f 1 uint8) might be a hint? also can you confirm when passing SCM strings to functions/methods that take say const *char they are NULL terminated? <lloda>fixes the libreadline thing on os x for me on 10.14 <lloda>if someone can test on 10.15 that would be sweet <lloda>I tested by removing libreadline from my macports install and building without --with-libreadline-prefix <lloda>readline still works and all <lloda>not sure about the missing feature tho (paren bouncing? vi?) I don't think I've ever used it <civodul>lloda: the comment says "Check for rl_get_keymap and rl_get_keymap_name." but it only checks for the latter, right? <lloda>I'm assuming that one implies the other <lloda>it seems a waste to check two functions cause configure is already very slow <lloda>I can make that clearer in the comment <lloda>I'll fix & push tomorrow :-)