Re: [anic] Digest for ani-compiler@googlegroups.com - 1 Message in 1 Topic

[Travis Ayres]

Are you high?

On Oct 4, 2010 2:32 AM, <ani-compil...@googlegroups.com> wrote:
> =============================================================================
> Today's Topic Summary
> =============================================================================
>
> Group: ani-co...@googlegroups.com
> Url: http://groups.google.com/group/ani-compiler/topics
>
> - Ringbuffers ? [1 Update]
> http://groups.google.com/group/ani-compiler/t/b79833f22addc6cf
>
>
> =============================================================================
> Topic: Ringbuffers ?
> Url: http://groups.google.com/group/ani-compiler/t/b79833f22addc6cf
> =============================================================================
>
> ---------- 1 of 1 ----------
> From: 3Jane <1...@depikt.net>
> Date: Oct 03 05:56AM -0700
> Url: http://groups.google.com/group/ani-compiler/msg/f75af25707a5330b
>
> Hello,
>
> i've found anic, while trying to get an overview of all existing
> languages searching one to write a GUI-Builder. For those
> dynamism and threading is essential for me: Essential,
> where i want to improve them.
>
> 1. It is ridiculous, that a print preview is modal. It is ridiculous,
> that scrollbars, tab headers and similar navigation elements
> are not usable always, should there run a callback or not.
>
> 2. The execution order in a GUI-program could be compared
> with a torus, the main-Event-loop the main circle, the callbacks
> the smaller ones. The structure of our programs is reflecting
> this torus in no way at all. Especially the exits from the
> main loops are everywhere, sometimes deeply hidden in
> the code.
>
> 3. "Clicked" is a fairly complex event, built from other.
> The GUI-builder should provide tools to synthesize
> Events much more easy. In a language with functions
> this needs at least higher-order and assignable
> functions. I'd like to make matching a regular expression
> in text widgets to Events, among others.
>
> I've begun to create an own language too, Brace. And
> one of the sequence types supported by the syntax
> will be ringbuffers, for entries with heterogenous types
> (of course). These have a fixed "readius", fixed at
> creation, and push() and pop() both using a pointer.
> And when the write-pointer is reaching the read-pointer
> writing blocks (causing the writer to wait til some more
> entries are read), when the read-pointer reaches the
> write-pointer, reading blocks.
>
> That means, that when they are equal, one of them
> is "covered" and only the other usable.
>
> With radius 1 this were just a latch. With larger
> radiusses it can provide a
> flexible coupling of execution in different
> threads. With really large radiusses they could
> used like streams with the advantage, that
> memory need is strictly limited and never
> growing. And their behavior with the
> write-pointer could be changed allowing
> overwriting of "expired" (never read) entries.
>
> Thought at something like this ? For radius 1
> the read- and write-pointers would be huge
> overhead in comparation to latches - but
> that could resolved internally. And radius
> could have the default value 1.
>
> The focus of Brace related to threading will be
> providing easy creation and control of threads.
> Thus it is heading towards quite a different
> direction than anic. Still i'd could share some
> work on standard methods, utf-related for
> example with anic.
>
> Good luck, Joost
>
>
>
>

[3Jane]

That doesn't look like any error of any human writer, but
like an error produced internally by bad compatible email-servers
or -clients. Mine is Sylpheed. In fact it has is special way of
displaying multi-part messages sometimes.

However, before your error report arrived, everything looked normal.
And i had written it not in Sylpheed, but directly in my browser,
which subsequently produced a quite normal view of my post.
Nothing wrong so far. The problem could also stem from your
email client.

Regards, Joost