Re: In Detail: Native C Calls
Hi Henrik, Worked, thanks! So I'm now using this line: gcc -o main.so -m64 -std=gnu99 -fPIC -shared -export-dynamic main.c -lm -lpcre OK, thanks. I haven't scrutinized it in detail, just a minor hint: (while (let? R (line T) (link R)) ) ) ) ) The 'let?' is not really needed, you could write (while (line T) (link @) ) I noted that ^ needs to be escaped otherwise the regex string won't be OK on the C side. Are there any other characters which needs the same treatment? The backslash (\), the hat (^), and the double quote () need to be escaped. And all characters smaller than a blank (ASCII 1 through 31) should be written as ^X (that's why the hat needs to be escaped). BTW, if I'm not sure if a string is really what it looks like, I always do something like : (mapcar char (chop a^B\c)) - (97 2 34 99) to show the individual ASCII characters. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In Detail: Native C Calls
Worked, thanks! So I'm now using this line: gcc -o main.so -m64 -std=gnu99 -fPIC -shared -export-dynamic main.c -lm -lpcre It seems the version 3 number was not needed after all. I've attached the C code for reference and this is what I use in PL: (println (pipe (native pcre/main.so pcre_match_all NIL From:([\^@]+)@([\^\\.]+)\\.([\^ ]+) From:regular.exÄpressi...@example.com From:ex...@43434.com From:7853...@exgem.com) (make (while (let? R (line T) (link R)) ) ) ) ) I noted that ^ needs to be escaped otherwise the regex string won't be OK on the C side. Are there any other characters which needs the same treatment? Result: (From:regular.exÄpressi...@example.com regular.exÄpressions example com From:ex...@43434.com exddd 43434 com From:7853...@exgem.com 7853456 exgem com) On Sun, May 13, 2012 at 12:06 AM, Alexander Burger a...@software-lab.de wrote: Hi Henrik, Thanks a lot but it seems I can't try it out because apparently I'm not able to create a shared library. I get symbol lookup error: pcre/main.so: undefined symbol: pcre_compile even though my compile lines look like this: gcc main.c -c -std=gnu99 -fPIC -I/usr/local/include -I/usr/include -L/usr/local/lib -L/usr/lib -lpcre3 gcc -shared -rdynamic -o main.so main.o In the first line I've also tried -lpcre, -llibpcre and -llibpcre3 to no avail. I'm always using a line like: gcc -o file.so -m64 -fPIC -shared -export-dynamic file.c -lm so does this work if you append -lpcre3? Note (in general, not your problem here, I think) that file.so should either contain a slash (e.g. like pcre/main.so in your previous example), or it must be passed as ./file.so to 'native', because otherwise it is searched for in the system libraries (e.g. via LD_LIBRARY_PATH). Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe #include string.h #include stdio.h #include pcre.h /* gcc main.c -std=gnu99 -lpcre -o main gcc -o main.so -m64 -std=gnu99 -fPIC -shared -export-dynamic main.c -lm -lpcre ./main From:([^@]+)@([^\\.]+)\\.([^ ]+) From:regular.exÄpressi...@example.com From:ex...@43434.com From:7853...@exgem.com ./main [0-9]+ hello777world99yew 8 I8909do23 ./main From:([^ ]+) From:hej From:svejs From:apa ./main From:([a-z]+) From:hej From:svejs From:apa */ void pcre_match_all (char *regex, char *str) { const char *error; int erroffset; pcre *re; int rc; int i; int ovector[100]; re = pcre_compile (regex, PCRE_MULTILINE, error, erroffset, 0); if (!re) { printf(pcre_compile failed (offset: %d), %s\n, erroffset, error); } unsigned int offset = 0; unsigned int len= strlen(str); while (offset len (rc = pcre_exec(re, 0, str, len, offset, 0, ovector, sizeof(ovector))) = 0) { for(int i = 0; i rc; ++i) { printf(%.*s\n, ovector[2*i+1] - ovector[2*i], str + ovector[2*i]); } offset = ovector[1]; } } void main (int argc, char *argv[]) { pcre_match_all(argv[1], argv[2]); }
Re: In Detail: Native C Calls
I've been looking into using this in conjunction with the pcre library. However I have problems with both returning results and capturing them in PL. The result should be an array of strings or if it's more convenient stored by reference in a variable. ATM I'm trying with the following: void tst(char *strs[2]){ strs[0] = foo; strs[1] = bar; } (native pcre/main.so tst NIL '(X (8 . S))) X contains foo but I can't seem to get at bar. Maybe it's just easier to print the results and capture that? If so then maybe it's even easier/more efficient to skip this completely and simply call an executable or does native have lower overhead? On Wed, May 9, 2012 at 8:33 PM, Alexander Burger a...@software-lab.de wrote: Hi all, at last, I have found the time to write an in-detail description of the 'native' function: http://software-lab.de/doc/native.html Any comments welcome! It became quite long, not because 'native' is so complicated, but because there are so many ways of passing information to and from C functions. I hope it clears some of the smoke. Does anybody know of a programming language with an equally powerful -- yet as simple -- C function interface? Except C/C++ of course ;-) Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In Detail: Native C Calls
Hi Henrik, ATM I'm trying with the following: void tst(char *strs[2]){ strs[0] = foo; strs[1] = bar; } (native pcre/main.so tst NIL '(X (8 . S))) X contains foo but I can't seem to get at bar. Right. (8 . S) is a structure of size 8, consisting of a single string pointer. You should use (native pcre/main.so tst NIL '(X (16 S S))) i.e. a size of 16 (two pointers) with two string pointers. Alternatively (especially when more strings are involved) you can pass an element count (here 2): (native pcre/main.so tst NIL '(X (16 S . 2))) BTW, if you want to call a regexp library (though I don't think using regexps in general is a good idea ;), why not use the standard 'regexec' functions? From http://rosettacode.org/wiki/Regular_expressions#PicoLisp (let (Pat a[0-9]z String a7z) (use Preg (native @ regcomp 'I '(Preg (64 B . 64)) Pat 1) # Compile regex (when (=0 (native @ regexec 'I (cons NIL (64) Preg) String 0 0 0)) (prinl String \ String \ matches regex \ Pat \) ) ) ) Output: String a7z matches pattern a[0-9]z Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In Detail: Native C Calls
Oops, forgot one answer. On Fri, May 11, 2012 at 08:48:15PM +0700, Henrik Sarvell wrote: Maybe it's just easier to print the results and capture that? If so then maybe it's even easier/more efficient to skip this completely and simply call an executable or does native have lower overhead? I would estimate that calling an executable has at least a 1000-fold overhead: : (bench (do 1000 (call /bin/true))) 0.616 sec - T : (bench (do 100 (native pcre/main.so tst NIL '(X (16 S S) 0.157 sec - NIL Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In Detail: Native C Calls
On May 9, 2012 at 3:33 PM Alexander Burger a...@software-lab.de wrote: Does anybody know of a programming language with an equally powerful -- yet as simple -- C function interface? Except C/C++ of course ;-) I think D has it. (D is pretty nice, it looks like C++ except the evil.) best regards, Jakob -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In Detail: Native C Calls
Alex, That looks great! I'm very impressed with native and now he doc! Cheers! Rand On May 9, 2012, at 3:33 PM, Alexander Burger a...@software-lab.de wrote: Hi all, at last, I have found the time to write an in-detail description of the 'native' function: http://software-lab.de/doc/native.html Any comments welcome! It became quite long, not because 'native' is so complicated, but because there are so many ways of passing information to and from C functions. I hope it clears some of the smoke. Does anybody know of a programming language with an equally powerful -- yet as simple -- C function interface? Except C/C++ of course ;-) Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In Detail: Native C Calls
Alexander Burger a...@software-lab.de writes: Hi Alex, at last, I have found the time to write an in-detail description of the 'native' function: http://software-lab.de/doc/native.html Any comments welcome! It became quite long, not because 'native' is so complicated, but because there are so many ways of passing information to and from C functions. I hope it clears some of the smoke. can't wait to try this out with the R statistics package. Since the package can be built as shared library, it might be possible to call all of R directly from PicoLisp - without the need for the typical intermediary packages (like RPy for R/Python communication). -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: In Detail: Native C Calls
Hi Jakob, Does anybody know of a programming language with an equally powerful -- yet as simple -- C function interface? Except C/C++ of course ;-) I think D has it. (D is pretty nice, it looks like C++ except the evil.) OK, but, well, if I understand it right, D is an extension of C (a re-engineering of C++ as Wikipedia puts it). As such, it directly supports the C ABI, and thus doesn't really count. More important: - Though it may indeed be _simple_, it is probably not as _powerful_ as the PicoLisp native function. For example, can we call a C function interactively (from the REPL or command line) in D? - Don't we need declarations and include files (like we need them in C), as D is also a compiled language? In PicoLisp you can refer to a C function in your code even before that library is installed or built. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe