> From: "Sandro Magi" <[EMAIL PROTECTED]>
> On 7/10/07, Rhythmic Fistman <[EMAIL PROTECTED]> wrote:
> > > > There's some support for async disk file I/O, but really
> > > > Linux can't do this so it's fairly pointless.
> >
> > Win32 felix happily uses TransmitFile. That looks like async file io
>
Rhythmic Fistman wrote:
>> 1.1.3_rc4 - installed perfectly fine (on ppc mac osx 10.4.10).
>> [I already had ocaml, python latest versions]
>
> Really? Are you using the native ocaml binaries? Maybe they
> fixed the stack overflow problem. These days I have to build
> felix with
> ulimit -s 6000
> What do you want?
Basically, I have lots of python scripts
that work with and process files/logs...etc.
However, these are sometimes huge files and
need huge data structures.
A simple example (in python) :
file_input = open('biglog.txt','r')
d = {}
for line in file_input.readlines():
x =
Thanks a lot for the detailed reply.
Yes, I am reading through the tutorial pages and
they are very helpful. Actually page 1 (hello
world page) says that "let's look at what
all these files mean later". And what you had
written in your email is a beautiful *enough*
explanation. My suggestion woul
On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-10 at 12:59 -0400, Sandro Magi wrote:
> > On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
>
> > As long as you can continue useful computation while blocking, and you
> > can do so safely, then you have a good concurrency model.
>
> On
On Tue, 2007-07-10 at 12:59 -0400, Sandro Magi wrote:
> On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
> As long as you can continue useful computation while blocking, and you
> can do so safely, then you have a good concurrency model.
On blocking: it's the other way around. The current fibre
ex
On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-10 at 12:12 -0400, Sandro Magi wrote:
>
> > Convinced of what? The concurrency safety? The security claims? E
> > covers quite a bit of ground.
>
> The basic problem is finding the right primitives to build
> parallel system on top of
On Tue, 2007-07-10 at 12:12 -0400, Sandro Magi wrote:
> On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
> > The thesis is rather long, but I've looked at E and am not
> > particularly convinced.
>
> Convinced of what? The concurrency safety? The security claims? E
> covers quite a bit of ground.
On Tue, 2007-07-10 at 11:25 -0400, Sandro Magi wrote:
> > What do you want?
>
> Consider an I/O model based on promises/futures with continuations.
Argg .. I sent a reply but it went to you, not the list .. my bad :)
At present the I/O model is based on calls which block fthreads:
there are no
On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
> [...]
> Now, with the new parser in place, some more pleasing
> syntax might be invented for this. In particular the above
> is not very nice because 'promise' remains in scope after
> it has been read .. it should evaporate.
>
> So, we have the prim
On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
> So actually we have not got this right yet.
>
> The last version of Felix added typeclasses, and it
> changed the whole way we approached making libraries:
> we start to use typeclasses instead of open overloading,
> but typeclasses make you think mu
On 7/10/07, Rhythmic Fistman <[EMAIL PROTECTED]> wrote:
> > > There's some support for async disk file I/O, but really
> > > Linux can't do this so it's fairly pointless.
>
> Win32 felix happily uses TransmitFile. That looks like async file io
> to me, or at least async file -> socket. I don't see
On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
>
> HOF aren't necessarily slow. Try this program with
I'm not really concerned about speed. And your example is neat by the way. :-)
HOF are really needed when one needs abstraction. I'm just saying that
I suspect that the abstraction won't be neede
> From: skaller <[EMAIL PROTECTED]>
> Felix __can__ be twice as fast as C .. :)
I've never been comfortable with this statement, because seeing
as felix's output IS a C programme it's its own competitor hence
felix can be __exactly__ as fast C. It would be fairer to say that felix's
unorthodox ma
On Tue, 2007-07-10 at 10:31 +0200, Rhythmic Fistman wrote:
> > From: skaller <[EMAIL PROTECTED]>
>
> > Felix __can__ be twice as fast as C .. :)
>
> I've never been comfortable with this statement, because seeing
> as felix's output IS a C programme it's its own competitor hence
> felix can be __
> From: Krishna Srinivasan <[EMAIL PROTECTED]>
> 1.1.1 - make was ok, but 'make install' FAILED.
> So I was not able to run ./bin/flx as well.
I personally wouldn't install it, prefering instead to build
it somewhere, set FLX_INSTALL_DIR and add FLX_INSTALL_DIR/bin
to my path.
> 1.1.3_rc4 - inst
> From: "Sandro Magi" <[EMAIL PROTECTED]>
> > Felix comes with a high performance platform independent
> > asynchronous I/O subsystem: works with sockets mainly,
> > but RF (the author) is playing with Unix pipes and some
> > other stuff.
>
> Excellent! :-)
I think that stuff just works on the un
> From: skaller <[EMAIL PROTECTED]>
> The Felix GC itself is split into an abstract class and
> an implementation, and the allocator likewise is a separate
> abstract class and implementation.
>
> The standard allocator implementation is malloc-free.
That is it uses malloc and malloc's counterpart
18 matches
Mail list logo
