Re: Segfault with huge list...?
I think I'll start keeping a list =) of picolisp's pleasant surprises. /Lindsay On Fri, Feb 10, 2017 at 11:06 AM, Joh-Tob Schäg wrote: > Linsday when you want to prevent values from neing printed take a look at > the 'nil function. > >
Re: Segfault with huge list...?
Linsday when you want to prevent values from neing printed take a look at the 'nil function. Am 10.02.2017 19:44 schrieb "Lindsay John Lawrence" < lawrence.lindsayj...@gmail.com>: > If it even matters, the overhead of recurse is slowest here. > So impressive that picolisp can iterate/recurse over a 10M element list in > these times. > (VirtualBox VM, 4GB, 1Core, with 64bit Debian). > > ... and 'make' is a lot more useful that I first realized. > > /Lindsay > > # Iterative > (de sumi (L) >(let (Sum (car L)) > (while (setq L (cdr L)) > (setq Sum (+ Sum (car L))) ) ) ) > > # Recurse > (de sumr (N) >(cond > ((not N) 0) > (T (+ (car N) (sumr (cdr N ) ) > > # This may take a moment... > : (setq bigly (range 1 1000) D NIL) -> NIL > : (bench (apply '+ bigly)) 0.097 sec -> 500500 > : (bench (sum '+ bigly))0.139 sec -> 500500 > : (bench (sumi bigly)) 0.275 sec -> 500500 > : (bench (sumr bigly)) 0.639 sec -> 500500 > > : (setq bigly (need 1000 1) D NIL) -> NIL > : (bench (apply '+ bigly)) 0.099 sec -> 1000 > : (bench (sum '+ bigly))0.139 sec -> 1000 > : (bench (sumi bigly)) 0.272 sec -> 1000 > : (bench (sumr bigly)) 0.643 sec -> 1000 > > : (bench (setq bigly (make (for X 1000 (link (+ (- 1000 X) 1) > (length bigly))0.437 sec -> 1000 > : (bench (sumr bigly)) 0.630 sec -> 500500 > : (bench (sumi bigly)) 0.279 sec -> 500500 > > > Am 10.02.2017 15:28 schrieb "Mike Pechkin" : >>> hi, On Fri, Feb 10, 2017 at 3:07 PM, Christopher Howard < christopher.how...@qlfiles.net> wrote: > Hi list. When I try to do > > (apply '+ (range 1 100) > List of millions of items is not a problem. Problem how you use it. (apply) is not for free, It *creates* a function call with a million of arguments. Stack size make sense. > I get segfault. I thought maybe this was some kind of internal > limitation of the apply function, so I defined a foldl: > > (de foldl (Fn Acc Lst) > (if (== () Lst) Acc > (let Acc2 (Fn Acc (car Lst)) > (foldl Fn Acc2 (cdr Lst)) ) ) ) > > : (foldl '+ 0 (range 1 1000)) > (foldl '+ 0 (range 1 1000)) > -> 500500 > : (foldl '+ 0 (range 1 100)) > (foldl '+ 0 (range 1 100)) > > Stack size makes sense too. I like recursions this way: (de rec1 (F A L) (if L (rec1 F (inc 'A (++ L)) L) A ) ) recursion with hidden accumulator from outer call and car-cdr: (de rec2 (F L A) (default A 0) (if L (rec2 F (cdr L) (inc 'A (car L))) A ) ) The call will be: (rec2 '+ (range 1 100))) As recursion just loop you can implement it without big stack too: (de sum1 (L) (let N 0 (for I L (inc 'N I) ) ) ) even without list creation: (de sum2 (X) (let N 0 (for I X (inc 'N I) ) ) ) And finally, that's why (sum) was implemented: (sum prog (range 1 100))) Bonus: for practice write recursion function to sum numbers without (range) >>> >>> >> >
Re: Segfault with huge list...?
If it even matters, the overhead of recurse is slowest here. So impressive that picolisp can iterate/recurse over a 10M element list in these times. (VirtualBox VM, 4GB, 1Core, with 64bit Debian). .. and 'make' is a lot more useful that I first realized. /Lindsay # Iterative (de sumi (L) (let (Sum (car L)) (while (setq L (cdr L)) (setq Sum (+ Sum (car L))) ) ) ) # Recurse (de sumr (N) (cond ((not N) 0) (T (+ (car N) (sumr (cdr N ) ) # This may take a moment... : (setq bigly (range 1 1000) D NIL) -> NIL : (bench (apply '+ bigly)) 0.097 sec -> 500500 : (bench (sum '+ bigly))0.139 sec -> 500500 : (bench (sumi bigly)) 0.275 sec -> 500500 : (bench (sumr bigly)) 0.639 sec -> 500500 : (setq bigly (need 1000 1) D NIL) -> NIL : (bench (apply '+ bigly)) 0.099 sec -> 1000 : (bench (sum '+ bigly))0.139 sec -> 1000 : (bench (sumi bigly)) 0.272 sec -> 1000 : (bench (sumr bigly)) 0.643 sec -> 1000 : (bench (setq bigly (make (for X 1000 (link (+ (- 1000 X) 1) (length bigly))0.437 sec -> 1000 : (bench (sumr bigly)) 0.630 sec -> 500500 : (bench (sumi bigly)) 0.279 sec -> 500500 Am 10.02.2017 15:28 schrieb "Mike Pechkin" : >> >>> hi, >>> >>> On Fri, Feb 10, 2017 at 3:07 PM, Christopher Howard < >>> christopher.how...@qlfiles.net> wrote: >>> >>> > Hi list. When I try to do >>> > >>> > (apply '+ (range 1 100) >>> > >>> >>> >>> List of millions of items is not a problem. >>> Problem how you use it. >>> (apply) is not for free, It *creates* a function call with a million of >>> arguments. >>> Stack size make sense. >>> >>> >>> > I get segfault. I thought maybe this was some kind of internal >>> > limitation of the apply function, so I defined a foldl: >>> > >>> > (de foldl (Fn Acc Lst) >>> > (if (== () Lst) Acc >>> > (let Acc2 (Fn Acc (car Lst)) >>> > (foldl Fn Acc2 (cdr Lst)) ) ) ) >>> > >>> > : (foldl '+ 0 (range 1 1000)) >>> > (foldl '+ 0 (range 1 1000)) >>> > -> 500500 >>> > : (foldl '+ 0 (range 1 100)) >>> > (foldl '+ 0 (range 1 100)) >>> > >>> > >>> >>> Stack size makes sense too. >>> I like recursions this way: >>> >>> (de rec1 (F A L) >>>(if L >>> (rec1 F (inc 'A (++ L)) L) >>> A ) ) >>> >>> recursion with hidden accumulator from outer call and car-cdr: >>> (de rec2 (F L A) >>>(default A 0) >>>(if L >>> (rec2 F (cdr L) (inc 'A (car L))) >>> A ) ) >>> The call will be: (rec2 '+ (range 1 100))) >>> >>> >>> As recursion just loop you can implement it without big stack too: >>> (de sum1 (L) >>>(let N 0 >>> (for I L >>> (inc 'N I) ) ) ) >>> >>> even without list creation: >>> (de sum2 (X) >>>(let N 0 >>> (for I X >>> (inc 'N I) ) ) ) >>> >>> >>> And finally, that's why (sum) was implemented: >>> (sum prog (range 1 100))) >>> >>> >>> Bonus: for practice write recursion function to sum numbers without >>> (range) >> >> >
Re: Segfault with huge list...?
yea On Fri, Feb 10, 2017 at 5:21 PM, Joh-Tob Schäg wrote: > (de natsum (N) > (if (=0 N) > 0 > ( + N > ( natsum ( dec N) > > Like that? > Am 10.02.2017 15:28 schrieb "Mike Pechkin" : > >> hi, >> >> On Fri, Feb 10, 2017 at 3:07 PM, Christopher Howard < >> christopher.how...@qlfiles.net> wrote: >> >> > Hi list. When I try to do >> > >> > (apply '+ (range 1 100) >> > >> >> >> List of millions of items is not a problem. >> Problem how you use it. >> (apply) is not for free, It *creates* a function call with a million of >> arguments. >> Stack size make sense. >> >> >> > I get segfault. I thought maybe this was some kind of internal >> > limitation of the apply function, so I defined a foldl: >> > >> > (de foldl (Fn Acc Lst) >> > (if (== () Lst) Acc >> > (let Acc2 (Fn Acc (car Lst)) >> > (foldl Fn Acc2 (cdr Lst)) ) ) ) >> > >> > : (foldl '+ 0 (range 1 1000)) >> > (foldl '+ 0 (range 1 1000)) >> > -> 500500 >> > : (foldl '+ 0 (range 1 100)) >> > (foldl '+ 0 (range 1 100)) >> > >> > >> >> Stack size makes sense too. >> I like recursions this way: >> >> (de rec1 (F A L) >>(if L >> (rec1 F (inc 'A (++ L)) L) >> A ) ) >> >> recursion with hidden accumulator from outer call and car-cdr: >> (de rec2 (F L A) >>(default A 0) >>(if L >> (rec2 F (cdr L) (inc 'A (car L))) >> A ) ) >> The call will be: (rec2 '+ (range 1 100))) >> >> >> As recursion just loop you can implement it without big stack too: >> (de sum1 (L) >>(let N 0 >> (for I L >> (inc 'N I) ) ) ) >> >> even without list creation: >> (de sum2 (X) >>(let N 0 >> (for I X >> (inc 'N I) ) ) ) >> >> >> And finally, that's why (sum) was implemented: >> (sum prog (range 1 100))) >> >> >> Bonus: for practice write recursion function to sum numbers without >> (range) > >
Re: Segfault with huge list...?
(de natsum (N) (if (=0 N) 0 ( + N ( natsum ( dec N) Like that? Am 10.02.2017 15:28 schrieb "Mike Pechkin" : > hi, > > On Fri, Feb 10, 2017 at 3:07 PM, Christopher Howard < > christopher.how...@qlfiles.net> wrote: > > > Hi list. When I try to do > > > > (apply '+ (range 1 100) > > > > > List of millions of items is not a problem. > Problem how you use it. > (apply) is not for free, It *creates* a function call with a million of > arguments. > Stack size make sense. > > > > I get segfault. I thought maybe this was some kind of internal > > limitation of the apply function, so I defined a foldl: > > > > (de foldl (Fn Acc Lst) > > (if (== () Lst) Acc > > (let Acc2 (Fn Acc (car Lst)) > > (foldl Fn Acc2 (cdr Lst)) ) ) ) > > > > : (foldl '+ 0 (range 1 1000)) > > (foldl '+ 0 (range 1 1000)) > > -> 500500 > > : (foldl '+ 0 (range 1 100)) > > (foldl '+ 0 (range 1 100)) > > > > > > Stack size makes sense too. > I like recursions this way: > > (de rec1 (F A L) >(if L > (rec1 F (inc 'A (++ L)) L) > A ) ) > > recursion with hidden accumulator from outer call and car-cdr: > (de rec2 (F L A) >(default A 0) >(if L > (rec2 F (cdr L) (inc 'A (car L))) > A ) ) > The call will be: (rec2 '+ (range 1 100))) > > > As recursion just loop you can implement it without big stack too: > (de sum1 (L) >(let N 0 > (for I L > (inc 'N I) ) ) ) > > even without list creation: > (de sum2 (X) >(let N 0 > (for I X > (inc 'N I) ) ) ) > > > And finally, that's why (sum) was implemented: > (sum prog (range 1 100))) > > > Bonus: for practice write recursion function to sum numbers without (range)
Re: Segfault with huge list...?
hi, On Fri, Feb 10, 2017 at 3:07 PM, Christopher Howard < christopher.how...@qlfiles.net> wrote: > Hi list. When I try to do > > (apply '+ (range 1 100) > List of millions of items is not a problem. Problem how you use it. (apply) is not for free, It *creates* a function call with a million of arguments. Stack size make sense. > I get segfault. I thought maybe this was some kind of internal > limitation of the apply function, so I defined a foldl: > > (de foldl (Fn Acc Lst) > (if (== () Lst) Acc > (let Acc2 (Fn Acc (car Lst)) > (foldl Fn Acc2 (cdr Lst)) ) ) ) > > : (foldl '+ 0 (range 1 1000)) > (foldl '+ 0 (range 1 1000)) > -> 500500 > : (foldl '+ 0 (range 1 100)) > (foldl '+ 0 (range 1 100)) > > Stack size makes sense too. I like recursions this way: (de rec1 (F A L) (if L (rec1 F (inc 'A (++ L)) L) A ) ) recursion with hidden accumulator from outer call and car-cdr: (de rec2 (F L A) (default A 0) (if L (rec2 F (cdr L) (inc 'A (car L))) A ) ) The call will be: (rec2 '+ (range 1 100))) As recursion just loop you can implement it without big stack too: (de sum1 (L) (let N 0 (for I L (inc 'N I) ) ) ) even without list creation: (de sum2 (X) (let N 0 (for I X (inc 'N I) ) ) ) And finally, that's why (sum) was implemented: (sum prog (range 1 100))) Bonus: for practice write recursion function to sum numbers without (range)
Re: Segfault with huge list...?
That sounds very plausible. Am 10.02.2017 14:35 schrieb "Joe Bogner" : > It sounds like it's exceeding the stack size. Have you tried setting it to > unlimited? ulimit -s unlimited > > http://www.mail-archive.com/picolisp@software-lab.de/msg01203.html > > On Fri, Feb 10, 2017 at 8:07 AM, Christopher Howard < > christopher.how...@qlfiles.net> wrote: > >> Hi list. When I try to do >> >> (apply '+ (range 1 100) >> >> I get segfault. I thought maybe this was some kind of internal >> limitation of the apply function, so I defined a foldl: >> >> (de foldl (Fn Acc Lst) >> (if (== () Lst) Acc >> (let Acc2 (Fn Acc (car Lst)) >> (foldl Fn Acc2 (cdr Lst)) ) ) ) >> >> : (foldl '+ 0 (range 1 1000)) >> (foldl '+ 0 (range 1 1000)) >> -> 500500 >> : (foldl '+ 0 (range 1 100)) >> (foldl '+ 0 (range 1 100)) >> >> .and again, a segfault. >> >> Am I doing something wrong? >> >> -- >> https://qlfiles.net >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> > >
Re: Segfault with huge list...?
It sounds like it's exceeding the stack size. Have you tried setting it to unlimited? ulimit -s unlimited http://www.mail-archive.com/picolisp@software-lab.de/msg01203.html On Fri, Feb 10, 2017 at 8:07 AM, Christopher Howard < christopher.how...@qlfiles.net> wrote: > Hi list. When I try to do > > (apply '+ (range 1 100) > > I get segfault. I thought maybe this was some kind of internal > limitation of the apply function, so I defined a foldl: > > (de foldl (Fn Acc Lst) > (if (== () Lst) Acc > (let Acc2 (Fn Acc (car Lst)) > (foldl Fn Acc2 (cdr Lst)) ) ) ) > > : (foldl '+ 0 (range 1 1000)) > (foldl '+ 0 (range 1 1000)) > -> 500500 > : (foldl '+ 0 (range 1 100)) > (foldl '+ 0 (range 1 100)) > > ..and again, a segfault. > > Am I doing something wrong? > > -- > https://qlfiles.net > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Segfault with huge list...?
Maybe you want to try (nil (range 1 100)) and see if the problem is there. Am 10.02.2017 14:24 schrieb "Joh-Tob Schäg" : > I had a similar experience. It tends to happen if you allocate to much at > once. Should be around 16 Megabyte in this case which normally is no > problem. > > If you have such a long list and want to apply functions to it I would use > generators instead. > They are less ram intensive. > > You do things wrong. > For example you still forget to close you parathesis. This will leave us > in a unresolved tension all day. Obligatory XKCD: https://xkcd.com/859/ > Am 10.02.2017 14:15 schrieb "Christopher Howard" < > christopher.how...@qlfiles.net>: > >> Hi list. When I try to do >> >> (apply '+ (range 1 100) >> >> I get segfault. I thought maybe this was some kind of internal >> limitation of the apply function, so I defined a foldl: >> >> (de foldl (Fn Acc Lst) >> (if (== () Lst) Acc >> (let Acc2 (Fn Acc (car Lst)) >> (foldl Fn Acc2 (cdr Lst)) ) ) ) >> >> : (foldl '+ 0 (range 1 1000)) >> (foldl '+ 0 (range 1 1000)) >> -> 500500 >> : (foldl '+ 0 (range 1 100)) >> (foldl '+ 0 (range 1 100)) >> >> ..and again, a segfault. >> >> Am I doing something wrong? >> >> -- >> https://qlfiles.net >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >
Re: Segfault with huge list...?
I had a similar experience. It tends to happen if you allocate to much at once. Should be around 16 Megabyte in this case which normally is no problem. If you have such a long list and want to apply functions to it I would use generators instead. They are less ram intensive. You do things wrong. For example you still forget to close you parathesis. This will leave us in a unresolved tension all day. Obligatory XKCD: https://xkcd.com/859/ Am 10.02.2017 14:15 schrieb "Christopher Howard" < christopher.how...@qlfiles.net>: > Hi list. When I try to do > > (apply '+ (range 1 100) > > I get segfault. I thought maybe this was some kind of internal > limitation of the apply function, so I defined a foldl: > > (de foldl (Fn Acc Lst) > (if (== () Lst) Acc > (let Acc2 (Fn Acc (car Lst)) > (foldl Fn Acc2 (cdr Lst)) ) ) ) > > : (foldl '+ 0 (range 1 1000)) > (foldl '+ 0 (range 1 1000)) > -> 500500 > : (foldl '+ 0 (range 1 100)) > (foldl '+ 0 (range 1 100)) > > ..and again, a segfault. > > Am I doing something wrong? > > -- > https://qlfiles.net > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Segfault
Hi all,
I wrote some nonsense yesterday:
On Thu, Dec 26, 2013 at 09:23:40AM +0100, Alexander Burger wrote:
> > (de in_range (A X B)
> > (and (>= X A) (<= X B)))
> >
> >
> > (de is_alphanumeric_letter (L)
> > (or (in_range "a" L "z") #<=
> > (in_range "A" L "Z")
> > (in_range "0" L "9")))
> >
> >
> > (de is_alphanumeric_string (S)
> > (not (find '((C) (not (is_alphanumeric_letter C))) (chop S
> >
> >
> > (de test_is_alphanumeric_string ()
> > (mapcar
> > '((P)
> > (let (X (car P) Y (cdar P))
> > (println X Y (is_alphanumeric_string X))
> > (or
> > (== Y (is_alphanumeric_string X))
> > (println "FUCK")
> > )
> > )
> > )
> > '(("1" T) ("arst2" T) ("Ssts3" T) ("=s1=" F) (4 T) (banana F))
> > )
> > )
> >
> >
> >
> > (test_is_alphanumeric_string)
>
> Sorry, I can't reproduce it. If I run this, I get immediately
>
>!? (cdar P)
>"1" -- List expected
>
> This is, of course, because 'P' is bound to ("1" T) in
>
>(let (X (car P) Y (cdar P))
>
> so the CAR of 'P' is "1", and taking the CDR of that is an error.
>
>
> The above code doesn't make sense also in other regards:
>
> * 'test_is_alphanumeric_string' takes no arguments but is recursed on. I
> presume you planned that it takes an argument which would then be
> passed to 'mapcar'.
>
> * The recursion would not bottom-out in this example
In fact, the above code doesn't involve any recursion at all! Seems I
was confused by the long and similar function names.
But it is correct that the problem is the CDAR. What is also interesting
to note is that pil64 does more thorough runtime checks here and gives
an error, while pil32 crashes because it only checks the initial
argument (before taking the CAR) but not whether the result of that is a
cons pair.
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Segfault
Hi,
On Thu, Dec 26, 2013 at 04:34:12AM +0100, nejaka osoba wrote:
>
> (de in_range (A X B)
> (and (>= X A) (<= X B)))
>
>
> (de is_alphanumeric_letter (L)
> (or (in_range "a" L "z") #<=
> (in_range "A" L "Z")
> (in_range "0" L "9")))
>
>
> (de is_alphanumeric_string (S)
> (not (find '((C) (not (is_alphanumeric_letter C))) (chop S
>
>
> (de test_is_alphanumeric_string ()
> (mapcar
> '((P)
> (let (X (car P) Y (cdar P))
> (println X Y (is_alphanumeric_string X))
> (or
> (== Y (is_alphanumeric_string X))
> (println "FUCK")
> )
> )
> )
> '(("1" T) ("arst2" T) ("Ssts3" T) ("=s1=" F) (4 T) (banana F))
> )
> )
>
>
>
> (test_is_alphanumeric_string)
Sorry, I can't reproduce it. If I run this, I get immediately
!? (cdar P)
"1" -- List expected
This is, of course, because 'P' is bound to ("1" T) in
(let (X (car P) Y (cdar P))
so the CAR of 'P' is "1", and taking the CDR of that is an error.
The above code doesn't make sense also in other regards:
* 'test_is_alphanumeric_string' takes no arguments but is recursed on. I
presume you planned that it takes an argument which would then be
passed to 'mapcar'.
* The recursion would not bottom-out in this example
BTW, 'in_range' is not needed. Instead of
(in_range "a" L "z")
you can directly call
(<= "a" L "z")
In general, I think that valgrind is not helpful here. You could better
(debug 'test_is_alphanumeric_string)
and then single-step through the function, to see what it does.
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Segfault on Linux Mint 12 x64
Hi Mansur, > I have Linux Mint 12 x64 (based on Ubuntu) on my laptop + picoLisp > x64 ver. 3.0.9.4 (testing release) > gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) > > I get segfault when I run ./dbg, then enter (traceAll) or (ht:Prin "&") I think I know. I saw the same on Ubuntun 11.10, and I think Mint is based on that. The Ubuntu package maintainers somehow messed up the linking, so that dynamic libraries are not correctly loaded. I debugged it with 'gdb' back then, and saw it crashed in dlopen() IIRC. The Debian versions (on which Unbuntu is based) always worked correctly. Please try Ubuntu 12.4 (preliminary version), or Debian testing, if possile. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Segfault on Linux Mint 12 x64
Did you compile everything?
Sometimes I've had problems with other binaries than PL itself (which
I always compile on the given system) when I've just copied them.
On Tue, Mar 6, 2012 at 5:26 PM, Mansur Mamkin wrote:
> Hi Alex!
>
> I have Linux Mint 12 x64 (based on Ubuntu) on my laptop + picoLisp x64 ver.
> 3.0.9.4 (testing release)
> gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
>
> I get segfault when I run ./dbg, then enter (traceAll) or (ht:Prin "&")
>
> I tried strace:
> --- (traceAll) ---
> .. skipped ...
> write(1, "\n", 1) = 1
> open("lib/ext", O_RDONLY) = 3
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\0\0\0\0\0\0"..,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0775, st_size=6304, ...}) = 0
> getcwd("/home/mtm/picoLisp", 128) = 19
> mmap(NULL, 2101624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0x7f46b011b000
> mprotect(0x7f46b011c000, 2093056, PROT_NONE) = 0
> mmap(0x7f46b031b000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7f46b031b000
> close(3) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> Process 2893 detached
> -
> --- (ht:Prin "&") ---
> .. skipped ...
> open("lib/ht", O_RDONLY) = 3
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\21\0\0\0\0\0\0"..., 832)
> = 832
> fstat(3, {st_mode=S_IFREG|0775, st_size=18608, ...}) = 0
> getcwd("/home/mtm/picoLisp", 128) = 19
> mmap(NULL, 2113920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0x7fab3867
> mprotect(0x7fab38672000, 2097152, PROT_NONE) = 0
> mmap(0x7fab38872000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fab38872000
> close(3) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> Process 2884 detached
> -
>
> The same version of PL works fine on CentOS 6.2 x64,
> so maybe that's not PL issue.
> If you have no idea about it at the moment, there is no big trouble, I can
> just migrate to CentOS.
>
> Regards,
> Mansur
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Segfault
On Thu, Jul 10, 2008 at 02:06:33PM +0300, Andrei Ivushkin wrote: > (setq X ((1 . 2) (3 . 4))) > > It crashes with segmentation fault... Sadly ... yes ;-) I must say, though, that it was never a major goal in PicoLisp to protect the programmer from all possible kinds of errors. Whenever there is a tradeoff between runtime checks and execution speed, speed is given favor. The above case is especially difficult, as the interpreter cannot distinguish legal from illegal pointers (here '1') to executable C-code. In retrospect, I think this strategy is good, as such errors happen rather seldom in typical development work. And if they happen, they are usually quickly located and fixed. It would would be a huge waste of computing resources to check such things over and over again. > but the system should warn about incorrect syntax, isn't it? One problem is perhaps that there is virtually no syntax at all in Lisp. Almost every expression might be legal code given a suitable context. BTW, there are may ways to shoot into your foot with PicoLisp. How about this one: : (de foo (R S) (let T (and R S) (bar R (mumble S) T) ) ) You see the glitch? The system symbol 'T' is bound to some value (possibly even 'NIL') during the execution of 'bar' and 'mumble'. One slight remedy is to use the 'lint' function as often as possible: : (lint 'foo) -> ((var T) (def mumble bar)) It tells you that 'T' is a bad variable, and that 'mumble' and 'bar' need to be defined. Usually you don't call 'lint' for each function separately, but let 'lintAll' do the work: : (lintAll) -> ((foo (var T) (def mumble bar))) But don't rely on runtime checks or 'lint' diagnoses! It cannot be a substitute for thorough testing. A strong recommendation is to write a set of unit tests for each application. You can see an example for the PicoLisp kernel in "lib/test.l". Cheers, - Alex -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
