Subscribe
Hello Oskar Wieland :-) You are now subscribed Hi, bitte melde mich fuer die email liste an. ein kleiner unwichtiger fehler: : (version) 3.1.2.0 C -> (3 1 2 0) : (setq foo 1) -> 1 : (foo) Segmentation fault (core dumped) lg oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Segmentation fault (Was: Subscribe)
Hi Alex, thanks for your answer. It is a great pleasure to see how PicoLisp works... In general, PicoLisp doesn't catch such errors, as this would induce relatively high runtime overhead, in contrast to their extremely rare occurrence in production programs. I agree and I did not expect it. And, after all, "Segmentation fault" *is* an error message, generated by the hardware, isn't it? And you test your program at least once, don't you? It is and I do many times. But this is not the point because you're going to loose unsaved data and the error could also be caught somewhere else. Setting a symbol to a number (like '1' above) is perfectly legal. And "calling" a symbol with a numeric value means to call an internal function (i.e. a function pointer). However, at memory location '1' there is probably no function, but the interpreter cannot know this. But when it comes to classes you are using a different scheme to dereference memory locations: : (load "@doc/shape.l") -> move> : (setq R (new +Rectangle 0 0 30 20)) -> $384486372 : ($384486372) # -> Segmentation fault : (show $384486372) -> ((draw> NIL (NIL (: x) (: y) (: dx) (: dy))) ... : (show ($384486372)) !? (perimeter> NIL (* 2 (+ (: dx) (: dy perimeter> -- Bad message : (show (($384419102))) # ->Segmentation fault Anyhow, not that impotant, as I said before. Perhaps the FAQ http://software-lab.de/doc/faq.html#segfault should elaborate more on that? > PicoLisp is a pragmatic language. Pragmatic to whom? > It doesn't check at runtime for all possible error conditions which won't occur during normal usage. What is normal usage? > Catching the segfault signals is also not a good idea, because the Lisp heap is most probably be damanged afterwards. A fine excuse? all the best oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Small URL problem at Cloud9
Hi Jon,
guessing from your code I'd try:
(when (= '("/" "/") (tail 1 (chop Path)))
instead of
(when (= '("/" "/") (tail 2 (chop Path)))
I can't get your code running, only the following error msg popping up:
? !? (ht:Pack Lst)
ht:Pack -- Undefined
Do I have to modify the 64-bit version, if yes, in what way?
Do you have any idea?
all the best
Oskar
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Small URL problem at Cloud9
On 05/22/2013 06:32 PM, Jon Kleiser wrote: No, you don't have to do any modifications (unless you're going to run it at c9.io), at least it works for me on standard 32-bit. Did you try this with my tiny web server code? That's where the libs are loaded: (load "lib/http.l" "lib/xhtml.l" "lib/form.l") /Jon Yep, and in the 32-bit version everything runs fine. No /doc/doc/ Thx Oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Small URL problem at Cloud9
Hi Alex, This is strange. 'ht:Pack' (in the 'ht' library) is part of the PicoLisp core. How did you install it? Along the lines of the INSTALL file, or from a Debian-Derivate? I build the emu version along the lines of your INSTALL file. With local installation mode on a 32-bit ubuntu 12.04. It worked on first try. oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Small URL problem at Cloud9
Hi Alex, OK. So if 'ht:Pack' is undefined, then either the 'ht' library is not found, or it somehow has the wrong contents. What does $ file /lib/ht say? Is it perhaps incompatible to your 'picolisp' executable (e.g. remained from some other build)? /lib/ht: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x4cea250351b0b49806b2acb120c17435cc342f4a, stripped I builded the 64-bit version again, got a new ht file and 'ht:Pack' is defined. (The timestamp on the files showed me I builded the 32-bit on top of the 64-bit) And now the 32-bit version is showing 'ht:Pack' undefined :) Better not run them in one installation? Oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
REPL and OpenGL
Hi, I'm trying to create an OpenGL window without loosing control to the "glutMainLoop". Thus I added the following definition from glut to OpenGL: : (de glutMainLoopEvent () (native `*GlutLib "glutMainLoopEvent") ) I set up some kind of main loop: : (mouseFunc '((Btn State X Y) (setq _run NIL))) # Exit upon mouse click : (de go () (setq _run T)(while _run (glutMainLoopEvent))) Is there a function to keep the REPL in the console alive, like (de go () (setq _run T)(while _run (glutMainLoopEvent DO_THE_REPL))) or is there another (better) way to create a OpenGL window without loosing control to "glutMainLoop"? Oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: REPL and OpenGL
Hi, thanks for the suggestions but I couldn't find a way to get it worrking together. Maybe I didn't made myself clear enough, the link shows what I'm trying to do: Lisp, Opengl and live editting of code: http://www.youtube.com/watch?v=XLkUI89fgRI Is this possible with picoLisp? Regards Oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: REPL and OpenGL
Hi alex, setting a background task was exactly what I was looking for. (task -10 0 (...)) works fine. I tried it with the socket fd also, by reading it from /proc//fd/ and putting it into (task (glutMainLoopEvent)) but got only segmentation faults. Thanks a lot Oskar -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: the hash function
this behavior may be caused by the fact that your are using only 26 values for letters out of 256 possible numbers. by considering upper and lower case it's 52 letters out of 256, which accounts for about 20%. 52÷256×5 = 10156.25 (10271) regards oskar On 02/27/2015 03:25 AM, Enrique Sánchez wrote: > Hello, > > I found some strange behaviour in the hash function. > > When applied to numbers, it works ok, but when applied > to strings, it leads to a huge number of collisions. > > An example: > # == > > (setq N 5 > Lnumbers (range 1 N) > Lstrings (mapcar format (range 1 N)) ) > > (prinl "uniq hashed values, using " N " different numbers: " >(length (uniq (mapcar hash Lnumbers))) ) > > (prinl "uniq hashed values, using " N " different strings: " >(length (uniq (mapcar hash Lstrings))) ) > > (bye) > > # == > # PRINTED RESULTS: > # > # uniq hashed values, using 5 different numbers: 5 > # uniq hashed values, using 5 different strings: 10271 > # == > > enrique. > > > > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Unclear licensing
don't let yourself (or others) be confused by freedom. same with the term "free trade agreement". it is contradictory in itself. if you think about it for a moment, "free trade" don't need an "agreement". the absence of agreements, rules and disclaimers is enough. regards 05k4r -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
