On Fri 11 Aug, Manuel M. T. Chakravarty wrote:
> Erlang applications are characterised as being soft-realtime
> applications:
>
> http://www.erlang.org/faq/x847.html#SOFT-REALTIME
>
> In one sentence, I would characterise this as ``it is fast
> enough most of the time.'' This seems to be good
On Fri 11 Aug, Byron Hale wrote:
> I don't mean that threads are non-deterministic, but that the execution
> time of a GC thread seems to be non-deterministic. Large collections need
> more time than small ones and the time required is some function of the
> store to be collected, is it not?
S
On Fri 11 Aug, Sengan wrote:
> I don't buy this: for a long time the embedded hard realtime people
> refused to use CPUs with cache because they would be
> "non-deterministic".
(I assume "non-deterministic" in this context means we can't determine the
execution time of a bit of code, even knowing
On Fri 11 Aug, George Russell wrote:
> However REALLY worst-time-bounded garbage collection is very expensive in
> CPU time. (Is there anything better than Baker's train algorithm?)
> In any case even if you do have garbage-collection, you will still need to
> demonstrate that you won't run out o
On 13-Aug-2000, Sylvan Ravinet <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > > will be coming from C and C++ where it is perfectly normal to do all sorts
> > > of things that the compiler cannot guarantee to be safe. This leads to all
> > > sorts of bugs such as buffer overflows, stack corruption, pa
HOpenGL, a Haskell binding for OpenGL and GLUT
version 1.00
I am pleased to announce the eleventh release of the Haskell binding
for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the*
industrial strength 3D graphics API and a GUI toolkit. More
On Fri, 11 Aug 2000 12:53:39 +0800
Lyndon While <[EMAIL PROTECTED]> wrote:
> At 6:46 pm -0400 10/8/2000, Benjamin Leon Russell wrote:
> >Somebody once wrote that a clearly written,
> well-documented program
> >that doesn't work is usually more valuable than a badly
> written,
> >poorly-document
Hello,
On Sun, 13 Aug 2000, Tyson Dowd wrote:
> > will be coming from C and C++ where it is perfectly normal to do all sorts
> > of things that the compiler cannot guarantee to be safe. This leads to all
> > sorts of bugs such as buffer overflows, stack corruption, page faults
> > accessing unmap
On 11-Aug-2000, Craig Dickson <[EMAIL PROTECTED]> wrote:
> Antony Courtney wrote:
>
> > But Java also has a way to do "rampant pointer-level
> > optimization": You declare a method as "native" and
> > then implement it in C.
>
> That's hardly the same thing, though. Of course an FFI allows you
