My current priorities

[Jeffrey Kegler]

These days my #1 priority is bug and misfeature fixes to Marpa::R2 and
Libmarpa. Outright bugs are rare at this point, and usually quick to
fix. But I've spent the last couple of weeks on a rewrite of
Marpa::R2's documentation on events, which I realized was poor enough
that it could be called a misfeature. It has taken a lot of time, but
adequate reference documentation is essential for software like Marpa,
so whatever time it takes has to be made available.

My #2 priority is Marpa's new direction, which I loosely call Kollos.
I've done nothing on it recently, alas, because of priority #1. But I
think Kollos is something those of you who are C-fluent can join in on
the ground floor, as equal contributors with me, or close to it. I will
be saying more in the near future.

A mistake other projects make IMHO is not seeking a user/application
community early and/or not making providing it stability a priority over
new features. New features always seem more glorious than the N+1st
rewrite of a reference doc, but a project should remember those who have
brought it this far.

-- jeffrey

[Ron Savage]

Sounds good, and I for one deeply appreciate putting quality above new features when it comes to priorities.

[Ruslan Shvedov]

On Tue, Sep 30, 2014 at 3:44 AM, Jeffrey Kegler <jeffre...@jeffreykegler.com> wrote:

These days my #1 priority is bug and misfeature fixes to Marpa::R2 and Libmarpa.  Outright bugs are rare at this point, and usually quick to fix.  But I've spent the last couple of weeks on a rewrite of Marpa::R2's documentation on events, which I realized was poor enough that it could be called a misfeature.  It has taken a lot of time, but adequate reference documentation is essential for software like Marpa, so whatever time it takes has to be made available.

My #2 priority is Marpa's new direction, which I loosely call Kollos.  I've done nothing on it recently, alas, because of priority #1.  But I think Kollos is something those of you who are C-fluent can join in on the ground floor, as equal contributors with me, or close to it.  I will be saying more in the near future.

I think #1 helps #2 in the sense that it makes SLIF more rewriteable and by 'rewriteable' I mean something you can understand relatively easily by reading the docs and connecting them to the code and the tests. Easier to understand, easier to translate and thus rewrite. Higher rewriteability would help creating new interfaces, Kollos of course included.

 

A mistake other projects make IMHO is not seeking a user/application community early and/or not making providing it stability a priority over new features.  New features always seem more glorious than the N+1st rewrite of a reference doc, but a project should remember those who have brought it this far.

Very true!

 

-- jeffrey

--
You received this message because you are subscribed to the Google Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email to marpa-parser+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.