Re: [Chicken-users] some questions about easyffi and foreign code
Hey Hugo, Yeah, that example wasn't working for me either. If you put (use easyffi) at the top of the file though, it should work. Note that easyffi is deprecated, use bind http://api.call-cc.org/doc/bind instead: (use bind) (bind* double modf(double x, ___out double *iptr);) (let-values ([(frac int) (modf 33.44)]) (print frac int)) I'm afraid I don't understand what Kon means either... If 64-bit integers are all you need, perhaps you can use the foreign type unsigned-integer64? I'm guessing the C compiler will handle that even if you're on a 32bit system. I'm not sure how Chicken will handle integer64's if you're on a 32bit system though. If you want to continue using your multiword version, you could look into the u32vector foreign type. It will give you a nice array on the C-side, and a nice vector on the Chicken side: (use srfi-4) (define double-uint64 (foreign-lambda* void ((double d) (u32vector _o)) uint32_t* ptr = (uint32_t*)d; _o[0] = ptr[0]; _o[1] = ptr[1]; )) (define (double-byte-blob value) (let ((out (make-u32vector 2))) (double-uint64 value out) out)) (print (double-byte-blob 1.3) \n (double-byte-blob 0) \n (double-byte-blob 1) \n (double-byte-blob 100)) I don't know if this is a good approach, though. Maybe someone knows how uint64_t foreign-types are handled on 32bit systems? K. On Sun, Feb 3, 2013 at 1:52 AM, Hugo Arregui hugo.arre...@gmail.com wrote: Hi again, 1) .. $ csc -X easyffi test.scm -c++; ./test Error: unbound variable: foreign-parse Call history: foreign-parse I have no idea of what's going on. Could this be a problem in my installation? The example in the wiki is not working either: #! #ifndef CHICKEN #include math.h #endif double modf(double x, ___out double *iptr); # (let-values ([(frac int) (modf 33.44)]) (print frac int)) //with the same error: unbound variable: foreign-parse 2) Then I tried another approach: .. Error: bad argument type - not a pointer: 0 I found a way to do this[1]. But, I found another problem: big int32 are promoted to flonums, I know that this is an expected behaviour, but I have a doubt: In a message[2] Kon Lovett writes: Means you want to compile w/ generic-arithmetic usual-integrations when using a foreign call. I suposse this is a compiler setting, but I don't now how to enable it. Also, I don't know what usual-integrations means, could you provide more details please? Thanks again, and sorry for bothering you. Regards, Hugo [1] http://pastebin.com/XH5n3V72 [2] http://lists.nongnu.org/archive/html/chicken-users/2007-05/msg00227.html ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
On Sun, Feb 03, 2013 at 06:42:55PM +1100, richo wrote: 3) expose a new function that raises errors if the directory exists so that an atomic mkdir is available. My thought is to just name it mkdir, but I'm not sure where it belongs. Please don't do that. This sort of design leads to mysql_real_escape_string. It's confusing to the user, and ugly to have several differently named procedures that do almost exactly the same thing but with slight differences in behavior. Better to either keep it the way it is, change the semantics and breaking compat (so be it), or convert to keyword args and make it an optional feature (my least favorite alternative). Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
On 03/02/13 11:42 +0100, Peter Bex wrote: On Sun, Feb 03, 2013 at 06:42:55PM +1100, richo wrote: 3) expose a new function that raises errors if the directory exists so that an atomic mkdir is available. My thought is to just name it mkdir, but I'm not sure where it belongs. Please don't do that. This sort of design leads to mysql_real_escape_string. It's confusing to the user, and ugly to have several differently named procedures that do almost exactly the same thing but with slight differences in behavior. Better to either keep it the way it is, change the semantics and breaking compat (so be it), or convert to keyword args and make it an optional feature (my least favorite alternative). Cheers, Peter Awesome, I guess with that said, I need someone who's more planted in the project to make a call so I know which way to jump. My preference is certainly to change the semantics and have a unified implementation without weird caveats, but I can't speak for how much code it'll break. I have a patch ready, but I can't test it as I can't get the test suite to work (followup post to -hackers incoming) Thanks again Richo -- richo || Today's excuse: The Dilithium Crystals need to be rotated. http://blog.psych0tik.net signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
On Sat, Feb 02, 2013 at 08:06:41PM -0600, Jim Ursetto wrote: (bug found -- tl;dr see end of message) Figured it out: you're exceeding the default maximal heap size, which is 2GB. Speaking of which, I wondered about this before: why do we even _have_ a maximum heap size? This is arbitrary and awkward. For instance, on my trusty old G4 iBook, 2G was way more than I actually had (512 MB), while at work and on my new laptop it's a relatively small fraction of my total memory. So on some machines it won't prevent the machine from crashing hard by going out of memory, while on other machines it'll just get in the way of doing large calculations. If there's no good reason for an upper limit, could we get rid of it? Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
Jim, that's great! Thank you so much! I've read that facebook reached out billions of users. As I'm testing graph implementations to create a graph database, do you believe this code could handle billions nodes or I would need a lot more RAM to run it? I'm not experienced in programming so I don't know if there is a way to handle this problem, like share this graph data structures along many machines, serializing it to disk and handle in memory only a part of it, etc. Do you know any applicable strategy to make it work properly? Thanks again! Arthur Em 03/02/2013 02:54, Jim Ursetto zbignie...@gmail.com escreveu: OK, I patched the core and the program runs to completion. Patch forthcoming. $ ./list-partials -:d -:hm16G [debug] application startup... [debug] heap resized to 1048576 bytes [debug] stack bottom is 0x7fff6f80f4b0. [debug] entering toplevel toplevel... [debug] entering toplevel library_toplevel... [debug] entering toplevel build_2dversion_toplevel... [debug] entering toplevel eval_toplevel... [debug] resizing mutation-stack from 8k to 16k ... [debug] entering toplevel expand_toplevel... [debug] entering toplevel modules_toplevel... [debug] resizing mutation-stack from 16k to 32k ... [debug] entering toplevel chicken_2dsyntax_toplevel... [debug] entering toplevel srfi_2d69_toplevel... Hash-tables - Inserting edges [debug] resizing heap dynamically from 1024k to 2048k ... [debug] resizing heap dynamically from 2048k to 4096k ... [debug] resizing heap dynamically from 4096k to 8192k ... [debug] resizing heap dynamically from 8192k to 16384k ... [debug] resizing heap dynamically from 16384k to 32768k ... [debug] resizing heap dynamically from 32768k to 65536k ... [debug] resizing heap dynamically from 65536k to 131072k ... [debug] resizing heap dynamically from 131072k to 262144k ... 5000 nodes inserted [debug] resizing heap dynamically from 262144k to 524288k ... 1 nodes inserted [debug] resizing heap dynamically from 524288k to 1048576k ... 15000 nodes inserted 2 nodes inserted [debug] resizing heap dynamically from 1048576k to 2097152k ... 25000 nodes inserted 3 nodes inserted 35000 nodes inserted 4 nodes inserted [debug] resizing heap dynamically from 2097152k to 4194304k ... 45000 nodes inserted 5 nodes inserted 55000 nodes inserted 6 nodes inserted 65000 nodes inserted 7 nodes inserted 75000 nodes inserted 8 nodes inserted 85000 nodes inserted [debug] resizing heap dynamically from 4194304k to 8388608k ... 9 nodes inserted 95000 nodes inserted 10 nodes inserted 105000 nodes inserted 11 nodes inserted 115000 nodes inserted 12 nodes inserted 125000 nodes inserted 13 nodes inserted 135000 nodes inserted 14 nodes inserted 145000 nodes inserted 15 nodes inserted 155000 nodes inserted 16 nodes inserted 165000 nodes inserted 17 nodes inserted 175000 nodes inserted [debug] resizing heap dynamically from 8388608k to 16777216k ... 18 nodes inserted 185000 nodes inserted 19 nodes inserted 195000 nodes inserted 20 nodes inserted 205000 nodes inserted 21 nodes inserted 215000 nodes inserted 22 nodes inserted 225000 nodes inserted 23 nodes inserted 235000 nodes inserted 24 nodes inserted 245000 nodes inserted 1042.938s CPU time, 50.714s GC time (major), 250066522 mutations, 44/851838 GCs (major/minor) [debug] forcing finalizers... [debug] application terminated normally On Feb 2, 2013, at 8:06 PM, Jim Ursetto wrote: (bug found -- tl;dr see end of message) Figured it out: you're exceeding the default maximal heap size, which is 2GB. For whatever reason, Chicken doesn't terminate reliably and with an error in this situation, it just tries to continue. Simply run your program with -:d to see: $ ./list-partials -:d Hash-tables - Inserting edges [debug] resizing heap dynamically from 1024k to 2048k ... [debug] resizing heap dynamically from 2048k to 4096k ... [debug] resizing heap dynamically from 4096k to 8192k ... [debug] resizing heap dynamically from 8192k to 16384k ... [debug] resizing heap dynamically from 16384k to 32768k ... [debug] resizing heap dynamically from 32768k to 65536k ... [debug] resizing heap dynamically from 65536k to 131072k ... [debug] resizing heap dynamically from 131072k to 262144k ... 5000 nodes inserted [debug] resizing heap dynamically from 262144k to 524288k ... 1 nodes inserted [debug] resizing heap dynamically from 524288k to 1048576k ... 15000 nodes inserted 2 nodes inserted [debug] resizing heap dynamically from 1048576k to 2097151k ... 25000 nodes inserted 3 nodes inserted 35000 nodes inserted 4 nodes inserted Error: segmentation violation The easy fix to is increase the max heap size, say to 8GB: $ ./list-partials -:d -:hm8192000k [debug] application
Re: [Chicken-users] some questions about easyffi and foreign code
Hey Kristian,
many thanks for you response!
Yeah, that example wasn't working for me either. If you put (use easyffi)
at the top of the file though, it should work. Note that easyffi is
deprecated, use bind instead:
(use bind)
(bind* double modf(double x, ___out double *iptr);)
(let-values ([(frac int) (modf 33.44)])
(print frac int))
Great!, I'm changing it right now.
If 64-bit integers are all you need, perhaps you can use the foreign type
unsigned-integer64? I'm guessing the C compiler will handle that even if
you're on a 32bit system. I'm not sure how Chicken will handle integer64's
if you're on a 32bit system though.
Well, I tried that at first (I have a 32bits machine):
(use numbers)
(use bind)
(define double-uint64
(foreign-lambda* unsigned-integer64 ((double d))
#EOS
union { double d; uint64_t i; } mem;
mem.d = d;
C_return(mem.i);
EOS
))
(print (flonum? (double-uint64 1.3)))
that code prints #t.
If you want to continue using your multiword version, you could look into
the u32vector foreign type. It will give you a nice array on the C-side, and
a nice vector on the Chicken side:
I exactly do that, but found another problem. u32 uses 31bit, so it's
not working either, let me show you:
(use srfi-4)
(import foreign)
(define double-u32vector
(foreign-lambda* void ((double d) (nonnull-u32vector v))
#EOS
union { double d; uint64_t i; } mem;
mem.d = d;
uint32_t* p = (uint32_t*) mem.i;
v[0] = p[0];
v[1] = p[1];
EOS
))
(let ((out (make-u32vector 2)))
(double-u32vector 1.3 out)
(print out))
prints #u32(3435973837.0 1073007820)
(Maybe I'm doing something wrong, i don't know).
So finally i have it working with uint8, and there's no problem. But I
felt curious about all this steps.
Thanks again!
Regards,
Hugo
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
Oh, and just to add info from another language
#include iostream
#include boost/graph/adjacency_list.hpp
using namespace std;
using namespace boost;
typedef adjacency_listvecS, vecS, directedS Graph;
int main()
{
const int VERTEXES = 25;
const int EDGES = 1000;
Graph g(VERTEXES);
cout Boost Graph Library - Inserting edges endl;
for (int i = 0; i VERTEXES; ++i)
for (int j = 1; j EDGES; ++j)
add_edge(i, j, g);
}
$ g++ boost-example.cpp -o boost-example
$ time ./boost-example
Boost Graph Library - Inserting edges
Killed
real2m10.779s
user0m47.279s
sys0m2.548s
---
I don't know if Killed is the same as a segfault.
Best wishes,
Arthur
2013/2/3 Arthur Maciel arthurmac...@gmail.com
Jim, that's great! Thank you so much!
I've read that facebook reached out billions of users. As I'm testing
graph implementations to create a graph database, do you believe this code
could handle billions nodes or I would need a lot more RAM to run it?
I'm not experienced in programming so I don't know if there is a way to
handle this problem, like share this graph data structures along many
machines, serializing it to disk and handle in memory only a part of it,
etc. Do you know any applicable strategy to make it work properly?
Thanks again!
Arthur
Em 03/02/2013 02:54, Jim Ursetto zbignie...@gmail.com escreveu:
OK, I patched the core and the program runs to completion. Patch
forthcoming.
$ ./list-partials -:d -:hm16G
[debug] application startup...
[debug] heap resized to 1048576 bytes
[debug] stack bottom is 0x7fff6f80f4b0.
[debug] entering toplevel toplevel...
[debug] entering toplevel library_toplevel...
[debug] entering toplevel build_2dversion_toplevel...
[debug] entering toplevel eval_toplevel...
[debug] resizing mutation-stack from 8k to 16k ...
[debug] entering toplevel expand_toplevel...
[debug] entering toplevel modules_toplevel...
[debug] resizing mutation-stack from 16k to 32k ...
[debug] entering toplevel chicken_2dsyntax_toplevel...
[debug] entering toplevel srfi_2d69_toplevel...
Hash-tables - Inserting edges
[debug] resizing heap dynamically from 1024k to 2048k ...
[debug] resizing heap dynamically from 2048k to 4096k ...
[debug] resizing heap dynamically from 4096k to 8192k ...
[debug] resizing heap dynamically from 8192k to 16384k ...
[debug] resizing heap dynamically from 16384k to 32768k ...
[debug] resizing heap dynamically from 32768k to 65536k ...
[debug] resizing heap dynamically from 65536k to 131072k ...
[debug] resizing heap dynamically from 131072k to 262144k ...
5000 nodes inserted
[debug] resizing heap dynamically from 262144k to 524288k ...
1 nodes inserted
[debug] resizing heap dynamically from 524288k to 1048576k ...
15000 nodes inserted
2 nodes inserted
[debug] resizing heap dynamically from 1048576k to 2097152k ...
25000 nodes inserted
3 nodes inserted
35000 nodes inserted
4 nodes inserted
[debug] resizing heap dynamically from 2097152k to 4194304k ...
45000 nodes inserted
5 nodes inserted
55000 nodes inserted
6 nodes inserted
65000 nodes inserted
7 nodes inserted
75000 nodes inserted
8 nodes inserted
85000 nodes inserted
[debug] resizing heap dynamically from 4194304k to 8388608k ...
9 nodes inserted
95000 nodes inserted
10 nodes inserted
105000 nodes inserted
11 nodes inserted
115000 nodes inserted
12 nodes inserted
125000 nodes inserted
13 nodes inserted
135000 nodes inserted
14 nodes inserted
145000 nodes inserted
15 nodes inserted
155000 nodes inserted
16 nodes inserted
165000 nodes inserted
17 nodes inserted
175000 nodes inserted
[debug] resizing heap dynamically from 8388608k to 16777216k ...
18 nodes inserted
185000 nodes inserted
19 nodes inserted
195000 nodes inserted
20 nodes inserted
205000 nodes inserted
21 nodes inserted
215000 nodes inserted
22 nodes inserted
225000 nodes inserted
23 nodes inserted
235000 nodes inserted
24 nodes inserted
245000 nodes inserted
1042.938s CPU time, 50.714s GC time (major), 250066522 mutations,
44/851838 GCs (major/minor)
[debug] forcing finalizers...
[debug] application terminated normally
On Feb 2, 2013, at 8:06 PM, Jim Ursetto wrote:
(bug found -- tl;dr see end of message)
Figured it out: you're exceeding the default maximal heap size, which
is 2GB. For whatever reason, Chicken doesn't terminate reliably and with
an error in this situation, it just tries to continue.
Simply run your program with -:d to see:
$ ./list-partials -:d
Hash-tables - Inserting edges
[debug] resizing heap dynamically from 1024k to 2048k ...
[debug] resizing heap dynamically from 2048k to 4096k ...
[debug] resizing heap dynamically from 4096k to 8192k ...
[debug] resizing heap dynamically from 8192k
Re: [Chicken-users] Segfault with large data-structures (bug)
* Arthur Maciel arthurmac...@gmail.com [130203 14:11]:
Oh, and just to add info from another language
#include iostream
#include boost/graph/adjacency_list.hpp
using namespace std;
using namespace boost;
typedef adjacency_listvecS, vecS, directedS Graph;
int main()
{
const int VERTEXES = 25;
const int EDGES = 1000;
Graph g(VERTEXES);
cout Boost Graph Library - Inserting edges endl;
for (int i = 0; i VERTEXES; ++i)
for (int j = 1; j EDGES; ++j)
add_edge(i, j, g);
}
$ g++ boost-example.cpp -o boost-example
$ time ./boost-example
Boost Graph Library - Inserting edges
Killed
real2m10.779s
user0m47.279s
sys0m2.548s
---
I don't know if Killed is the same as a segfault.
This sounds like you are hitting a ulimit there...
Cheers,
Christian
--
In the world, there is nothing more submissive and weak than
water. Yet for attacking that which is hard and strong, nothing can
surpass it. --- Lao Tzu
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
Peter Bex scripsit: Better to either keep it the way it is, change the semantics and breaking compat (so be it), or convert to keyword args and make it an optional feature (my least favorite alternative). I'm not a big fan of keyword args either, but an optional second argument that makes it atomic wouldn't kill anybody. (create-directory pathname [ atomic? ] ) Create the directory specified by pathname. If the atomic? argument is present and is true, do this atomically, raising an error if the directory already exists. Otherwise, do nothing if the directory already exists. Raise an error in all other cases where the directory cannot be created. -- John Cowan http://www.ccil.org/~cowan co...@ccil.org After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat? No, I wouldn't, the beggar replied. Why is that? the Master asked. A Dinar doesn't go very far these days, Master.--Kehlog Albran Besides, the Temple of Toplat is across the street. The Profit ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
On Sun, Feb 03, 2013 at 10:22:45AM -0500, John Cowan wrote: Peter Bex scripsit: Better to either keep it the way it is, change the semantics and breaking compat (so be it), or convert to keyword args and make it an optional feature (my least favorite alternative). I'm not a big fan of keyword args either, but an optional second argument that makes it atomic wouldn't kill anybody. (create-directory pathname [ atomic? ] ) It already takes an optional second arg. The current signature is: (create-directory pathname [ parents? ] ) This optional parameter tells it to create parent directories if they don't exist. Of course we could make it look like: (create-directory pathname [ parents? [ atomic? ] ] ) This is probably the cleanest backwards-compatible solution. Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
Peter Bex scripsit: This optional parameter tells it to create parent directories if they don't exist. Of course we could make it look like: (create-directory pathname [ parents? [ atomic? ] ] ) This is probably the cleanest backwards-compatible solution. +1 -- John Cowanco...@ccil.orghttp://ccil.org/~cowan Sound change operates regularly to produce irregularities; analogy operates irregularly to produce regularities. --E.H. Sturtevant, ca. 1945, probably at Yale ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
Peter Bex scripsit: Speaking of which, I wondered about this before: why do we even _have_ a maximum heap size? This is arbitrary and awkward. For instance, on my trusty old G4 iBook, 2G was way more than I actually had (512 MB), while at work and on my new laptop it's a relatively small fraction of my total memory. On a 32-bit system, you can't by any means get more than a 4G memory for any single process, short of heroic measures in the kernel that allow you to assign the same virtual addresses to different physical addresses at the same time. OS considerations limit this figure to 1G to 3G. On x86_64 architecture, the hard limit is 128T (47 bits), but that's well beyond the practical limit. -- Real FORTRAN programmers can program FORTRANJohn Cowan in any language. --Ed Post co...@ccil.org ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
On Sun, Feb 03, 2013 at 11:15:12AM -0500, John Cowan wrote: Peter Bex scripsit: Speaking of which, I wondered about this before: why do we even _have_ a maximum heap size? This is arbitrary and awkward. For instance, on my trusty old G4 iBook, 2G was way more than I actually had (512 MB), while at work and on my new laptop it's a relatively small fraction of my total memory. On a 32-bit system, you can't by any means get more than a 4G memory for any single process, short of heroic measures in the kernel that allow you to assign the same virtual addresses to different physical addresses at the same time. OS considerations limit this figure to 1G to 3G. Well, sure. But then malloc would just fail, wouldn't it? The Chicken heap doesn't need to be limited from within Chicken; the OS will do that for us more reliably. Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
Blunderingly I wrote: On a 32-bit system, you can't by any means get more than a 4G memory for any single process, short of heroic measures in the kernel that allow you to assign the same virtual addresses to different physical addresses at the same time. I meant, of course, at different times. Some of DEC's PDP-11 operating systems actually provided this kind of support: you could have more than 64K of code, but if you wanted to call a procedure with virtual addresses conflicting with your own, you had to vector it through the kernel. The linker figured out what went where. You were still strictly limited to 64K of data, though. -- Even the best of friends cannot John Cowan attend each others' funeral.co...@ccil.org --Kehlog Albran, The Profit http://www.ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
Well, there is another option, which is to put an atomic implementation in, say, the posix-extras egg, and then the user may import it under a different name or overwrite posix's create-directory with it. On Feb 3, 2013, at 9:26 AM, Peter Bex wrote: On Sun, Feb 03, 2013 at 10:22:45AM -0500, John Cowan wrote: Peter Bex scripsit: Better to either keep it the way it is, change the semantics and breaking compat (so be it), or convert to keyword args and make it an optional feature (my least favorite alternative). I'm not a big fan of keyword args either, but an optional second argument that makes it atomic wouldn't kill anybody. (create-directory pathname [ atomic? ] ) It already takes an optional second arg. The current signature is: (create-directory pathname [ parents? ] ) This optional parameter tells it to create parent directories if they don't exist. Of course we could make it look like: (create-directory pathname [ parents? [ atomic? ] ] ) This is probably the cleanest backwards-compatible solution. Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
From: John Cowan co...@mercury.ccil.org Subject: Re: [Chicken-users] [patch] remove the initial check on directory existance Date: Sun, 3 Feb 2013 10:22:45 -0500 Peter Bex scripsit: Better to either keep it the way it is, change the semantics and breaking compat (so be it), or convert to keyword args and make it an optional feature (my least favorite alternative). I'm not a big fan of keyword args either, but an optional second argument that makes it atomic wouldn't kill anybody. Good point, add1. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-users] [patch] remove the initial check on directory existance Date: Sun, 3 Feb 2013 16:26:28 +0100 On Sun, Feb 03, 2013 at 10:22:45AM -0500, John Cowan wrote: Peter Bex scripsit: Better to either keep it the way it is, change the semantics and breaking compat (so be it), or convert to keyword args and make it an optional feature (my least favorite alternative). I'm not a big fan of keyword args either, but an optional second argument that makes it atomic wouldn't kill anybody. (create-directory pathname [ atomic? ] ) It already takes an optional second arg. The current signature is: (create-directory pathname [ parents? ] ) This optional parameter tells it to create parent directories if they don't exist. Of course we could make it look like: (create-directory pathname [ parents? [ atomic? ] ] ) This is probably the cleanest backwards-compatible solution. Oh damn. I mixed this up with the one in setup-api. So, add1 to *this* solution, instead. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-users] Segfault with large data-structures (bug) Date: Sun, 3 Feb 2013 12:53:16 +0100 On Sat, Feb 02, 2013 at 08:06:41PM -0600, Jim Ursetto wrote: (bug found -- tl;dr see end of message) Figured it out: you're exceeding the default maximal heap size, which is 2GB. Speaking of which, I wondered about this before: why do we even _have_ a maximum heap size? This is arbitrary and awkward. For instance, on my trusty old G4 iBook, 2G was way more than I actually had (512 MB), while at work and on my new laptop it's a relatively small fraction of my total memory. So on some machines it won't prevent the machine from crashing hard by going out of memory, while on other machines it'll just get in the way of doing large calculations. If there's no good reason for an upper limit, could we get rid of it? The intention is to provide some sort of soft ulimit at the application level, in case you want to make sure a certain maximum amount of memory is not exceeded. Or if you want to benchmark memory consumption, or do other whacky things. So let's keep it for a while. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
On Sun, Feb 03, 2013 at 11:37:42PM +0100, Felix wrote: The intention is to provide some sort of soft ulimit at the application level, in case you want to make sure a certain maximum amount of memory is not exceeded. Or if you want to benchmark memory consumption, or do other whacky things. So let's keep it for a while. But why not just use ulimit? It can be set per process, so I don't see the need to have a second ulimit-like limit inside each process. Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
Peter Bex scripsit: But why not just use ulimit? It can be set per process, so I don't see the need to have a second ulimit-like limit inside each process. +1 -- John Cowan co...@ccil.org http://www.ccil.org/~cowan Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-users] Segfault with large data-structures (bug) Date: Sun, 3 Feb 2013 23:47:39 +0100 On Sun, Feb 03, 2013 at 11:37:42PM +0100, Felix wrote: The intention is to provide some sort of soft ulimit at the application level, in case you want to make sure a certain maximum amount of memory is not exceeded. Or if you want to benchmark memory consumption, or do other whacky things. So let's keep it for a while. But why not just use ulimit? It can be set per process, so I don't see the need to have a second ulimit-like limit inside each process. Not everybody uses UNIX, you know. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
On Mon, Feb 04, 2013 at 12:10:16AM +0100, Felix wrote: But why not just use ulimit? It can be set per process, so I don't see the need to have a second ulimit-like limit inside each process. Not everybody uses UNIX, you know. I keep forgetting not everybody is lucky enough to use it. More seriously, do modern OSes not have some sort of sane limiting system? ulimit must be several decades old... Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Missing link flags in SDL egg for Chicken
Hello! I've found the bug in the SDL egg. If the egg is installed via ``chicken-install``, any program segfaults on (ttf-init). However, it works when the SDL egg is installed using the Makefile supplied. My system is Ubuntu 12.04. I've found it is because the arguments to compiler are different. Makefile links to ``SDL_ttf``, ``SDL_image``, ``SDL_gfx``, ``SDL_net``, while ``sdl.setup`` doesn't. Changing the line 18 in ``sdl.setup`` from: (compile -s -O3 -d1 sdl.scm -j sdl -lSDL ,sdl-cflags ,sdl-lflags) to the following: (compile -s -O3 -d1 sdl.scm -j sdl -lSDL_ttf -lSDL_image -lSDL_gfx -lSDL_net -lSDL ,sdl-cflags ,sdl-lflags) fixes the problem when installing via chicken-install. At least if I do ``chicken-install -r sdl``, then do this change and do ``chicken-install``, it works. Could someone please change the egg's sdl.setup file? -- Best regards, Agrest ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault with large data-structures (bug)
Peter Bex scripsit: Not everybody uses UNIX, you know. I keep forgetting not everybody is lucky enough to use it. More seriously, do modern OSes not have some sort of sane limiting system? ulimit must be several decades old... Windows System Resource Manager is our friend here: it allows users to set CPU and memory limits on any process. Granted, it's only available on Windows Server 2003/2008, but servers are where such a feature is really necessary. -- I am expressing my opinion. When myJohn Cowan honorable and gallant friend is called, co...@ccil.org he will express his opinion. This is http://www.ccil.org/~cowan the process which we call Debate. --Winston Churchill ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
