From: "Aurélien Aptel" <aurelien.aptel@gmail.com>
To: Martyn Jago <martyn.jago@btinternet.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: GSoC 2012 -- Elisp backend for Ragel
Date: Tue, 27 Mar 2012 22:34:58 +0200 [thread overview]
Message-ID: <CA+5B0FOJVxDbbff9s2vT4BfJETj_4BP1_fdb0bUv+wPfFgs2SQ@mail.gmail.com> (raw)
In-Reply-To: <m2ty1cx2q5.fsf@btinternet.com>
On Sun, Mar 25, 2012 at 2:52 PM, Martyn Jago <martyn.jago@btinternet.com> wrote:
> For the design process I currently use the excellent plantuml library
> from within Org-mode (Aurélien, see lisp/ob-plantuml.el for the
> Org-babel interface), although have previously used a bespoke
> Ruby/Graphviz library of my design, and previous to that Ragel.
I didn't know about plantuml. Nice tool!
> For that reason I think it would be great to see an `Org-Babel'
> implementation of Ragel. I think it could be a very useful tool.
I'm discovering org-mode little by little. The whole org-babel thing
is really nice too. So what you want is an org-babel interface that
will convert a source block input for ragel to an image of the
automata/generated code once you export e.g. to html?
> 1) It complicates the build process
Yes, it adds complexity for the developers. Users won't notice.
> 2) It adds yet more SOUP (software of unknown provenance) to the build
> process which may then need mitigating against (this is relevant to me,
> although possibly not to Org-mode).
You mean it complicates the build process? I'm not sure I understand.
> 3) FSM implementation into code is inherently very simple anyway
Well I've never done it for big language but I did not find it that
easy. Mistakes are easily made e.g. you end up accepting more thing
that the language does in order to simplify the code, etc.
> What I do instead is validate the FSM code against the formal state
> representation as an integration test (which is fairly easy to arrange).
I'm not familiar with this. Does this mean you test random valid and
invalid input against the parser (aka fuzzing)?
> So my point is, I personally don't see the use of FSM code generators as
> a panacea to perfect super-fast code. To me their usefulness is in the
> visual representation of the state interaction (during development, and
> subsequent code documentation), and the resulting code quality.
I'm not very experienced (just a student :) but for me their
usefulness is in the robustness and the abstraction it brings. It also
happens to be faster. But I see what you're saying.
next prev parent reply other threads:[~2012-03-27 20:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-22 13:43 GSoC 2012 -- Elisp backend for Ragel Rustom Mody
2012-03-23 11:12 ` Aurélien Aptel
2012-03-23 11:36 ` Rustom Mody
[not found] ` <CAJ+TeoebkVTLs9nrDTH_6xvzvkk1vTEZDL2iHmEAkTUfZRjpjQ@mail.gmail.com>
[not found] ` <CAJ+TeoebkVTLs9nrDTH_6xvzvkk1vTEZDL2iHmEAkTUfZRjpjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-03-25 4:17 ` Rustom Mody
2012-03-25 6:55 ` Rustom Mody
2012-03-25 10:06 ` Aurélien Aptel
2012-03-25 11:40 ` Nicolas Goaziou
2012-03-25 12:52 ` Martyn Jago
2012-03-27 20:34 ` Aurélien Aptel [this message]
2012-03-27 21:22 ` Achim Gratz
2012-03-27 22:11 ` Aurélien Aptel
2012-03-28 6:34 ` Achim Gratz
2012-03-29 17:50 ` Aurélien Aptel
2012-03-29 17:52 ` Samuel Wales
2012-03-29 19:04 ` Achim Gratz
[not found] ` <87vclsykl6.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-03-27 20:03 ` Aurélien Aptel
2012-03-26 16:01 ` Bastien
[not found] ` <87wr674aii.fsf-mXXj517/zsQ@public.gmane.org>
2012-03-27 20:49 ` Aurélien Aptel
2012-03-27 22:10 ` Bastien
2012-03-26 15:53 ` Bastien
-- strict thread matches above, loose matches on Subject: below --
2012-03-21 18:51 Aurélien Aptel
2012-03-21 19:32 ` Aurélien Aptel
2012-03-21 19:34 ` Samuel Wales
2012-03-22 12:22 ` Thorsten
2012-03-24 8:16 ` Nicolas Goaziou
2012-03-26 16:03 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+5B0FOJVxDbbff9s2vT4BfJETj_4BP1_fdb0bUv+wPfFgs2SQ@mail.gmail.com \
--to=aurelien.aptel@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=martyn.jago@btinternet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).