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
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
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
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
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
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);)
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);
* 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
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
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
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 Cowan
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
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
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
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,
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
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
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
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
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
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
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.
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
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
24 matches
Mail list logo
