From wdouglass at carnegierobotics.com Thu Jul 11 13:37:17 2019 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Thu, 11 Jul 2019 20:37:17 +0000 Subject: [CM] s7 loading functions Message-ID: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com> Hello, I'm working on a project which uses s7 scheme for scripting, and I'm finding it incredibly useful. I am interested in the load function; i've written some libraries in C which i'd like to load into the interpreter. I've noticed that g_load and s7_load behave a bit differently; native libraries (with a '.so' extension) can be dlopened using g_load but not s7_load. Also, the *load-path* is searched for scheme files but not for native ones. Finally, the autoloader calls s7_load and not g_load, so no autoloading native libraries. So here are my questions: 1) Is there a way to get the autoloader to load native libraries? 2) is there a reason why the *load-path* functionality doesn't apply to native libraries? 3) if i decide to write a patch to make s7_load and g_load behave more similarly, is this mailing list the right place to put it? is there a process for 'upstreaming' patches? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Thu Jul 11 14:15:11 2019 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 11 Jul 2019 14:15:11 -0700 Subject: [CM] s7 loading functions In-Reply-To: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com> References: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com> Message-ID: <933e5d359547cbfa8b48516683c385a0@ccrma.stanford.edu> Hi! I'm pleased that s7 has been useful. To address your questions, I can't remember any reason for the difference between g_load and s7_load. It is possible to use autoload with native libraries via the file-or-function argument, I think -- it's been a long time since I looked at it. But it would be simpler to give "libc.so" as the file name. I'll also test *load-path* with native libraries -- in the past I don't think this worked (my vague recollection is that you got no error if the file didn't exist until you tried to use something from the library). In any case, this is the right mailing list for these sorts of questions, and I'm usually happy to receive code. Unless there's some problem I've overlooked, I'll make the changes to s7_load and autoload. Thanks for the suggestions! From bil at ccrma.Stanford.EDU Thu Jul 11 14:41:43 2019 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 11 Jul 2019 14:41:43 -0700 Subject: [CM] s7 loading functions In-Reply-To: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com> References: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com> Message-ID: <721b4cd951cff08afaaf677d05b9960c@ccrma.stanford.edu> Now I read the code... the autoloader can't work with just the *.so library name (as opposed to a function) because it can't tell what the init function's name is. You could do this with s7_load_with_environment if it were extended to handle *.so files, because you can pass the init function name in the environment argument, or you could call the init function explicitly after loading, but autoload happens at the point where an undefined name is encountered, so you need to pass a function something like (lambda (e) (load "libc.so" (inlet 'init_func 'init))) From wdouglass at carnegierobotics.com Fri Jul 12 07:25:52 2019 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Fri, 12 Jul 2019 14:25:52 +0000 Subject: [CM] s7 loading functions In-Reply-To: <721b4cd951cff08afaaf677d05b9960c@ccrma.stanford.edu> References: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com>, <721b4cd951cff08afaaf677d05b9960c@ccrma.stanford.edu> Message-ID: Mr Schottstaedt, Thanks for the advice, and for this great interpreter! using a lambda for autoloading native libraries works well, and I'm using the attached patch to search the load path for .so files; i've tested it a bit and it seems to work. The patch also adds the current directory "." as an implicit entry to the load path; this makes things a bit simpler, and it's easy to override in scheme if necessary. Good luck and thanks again, Woody Douglass On 2019-07-11 17:40:43-04:00 bil at ccrma.Stanford.EDU wrote: Now I read the code... the autoloader can't work with just the *.so library name (as opposed to a function) because it can't tell what the init function's name is. You could do this with s7_load_with_environment if it were extended to handle *.so files, because you can pass the init function name in the environment argument, or you could call the init function explicitly after loading, but autoload happens at the point where an undefined name is encountered, so you need to pass a function something like (lambda (e) (load "libc.so" (inlet 'init_func 'init))) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: load-path-native.patch Type: application/octet-stream Size: 3651 bytes Desc: load-path-native.patch URL: From bil at ccrma.Stanford.EDU Fri Jul 12 11:51:26 2019 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 12 Jul 2019 11:51:26 -0700 Subject: [CM] s7 loading functions In-Reply-To: References: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com>, <721b4cd951cff08afaaf677d05b9960c@ccrma.stanford.edu> Message-ID: <6337760e086c09b57bccab93b785fc45@ccrma.stanford.edu> Thanks! I have merged those changes into my versions of s7, and harmonized s7_load and g_load (there are still some differences due to the contexts in which they are called). As always, I need to write more tests. From wdouglass at carnegierobotics.com Thu Jul 25 05:42:51 2019 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Thu, 25 Jul 2019 12:42:51 +0000 Subject: [CM] s7 loading functions In-Reply-To: <6337760e086c09b57bccab93b785fc45@ccrma.stanford.edu> References: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com>, <721b4cd951cff08afaaf677d05b9960c@ccrma.stanford.edu> , <6337760e086c09b57bccab93b785fc45@ccrma.stanford.edu> Message-ID: One more patch -- My earlier patch failed to load .so files if there was an absolute path in `*load-path*` The attached patch fixes that. Thanks, Woody Douglass On 2019-07-12 14:50:25-04:00 bil at ccrma.Stanford.EDU wrote: Thanks! I have merged those changes into my versions of s7, and harmonized s7_load and g_load (there are still some differences due to the contexts in which they are called). As always, I need to write more tests. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_full_filename.patch Type: application/octet-stream Size: 1492 bytes Desc: fix_full_filename.patch URL: From bil at ccrma.Stanford.EDU Thu Jul 25 09:25:01 2019 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 25 Jul 2019 09:25:01 -0700 Subject: [CM] s7 loading functions In-Reply-To: References: <8ffd8c18c78147a5b54f68b198824305@carnegierobotics.com>, <721b4cd951cff08afaaf677d05b9960c@ccrma.stanford.edu> , <6337760e086c09b57bccab93b785fc45@ccrma.stanford.edu> Message-ID: <3644edf93bc6b421a283221ed0b3b3f7@ccrma.stanford.edu> Thanks! I have merged those changes into my s7.c (and removed +8 from long ago), but my s7.c is currently a mess -- it may be a few days before I update the ccrma versions. From bil at ccrma.Stanford.EDU Tue Jul 30 06:10:40 2019 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 30 Jul 2019 06:10:40 -0700 Subject: [CM] Snd 19.6 Message-ID: <6f4fff64748990520a3122b6ff29ca68@ccrma.stanford.edu> Snd 19.6: s7: added tools directory (timing tests etc) moved most-positive|negative-fixnum to *s7* s7_load now parallels scheme load; it returns NULL if file not found (or a directory). added s7_call_with_catch and define-expansion*. checked: sbcl 1.5.4|5 Thanks!: Kjetil Matheussen, Woody Douglas