freeride-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [FR-devel] Nishio's Source Browser


From: Bob Calco
Subject: RE: [FR-devel] Nishio's Source Browser
Date: Mon, 9 Sep 2002 19:48:18 -0400

Hal et al.:

%% -----Original Message-----
%% From: address@hidden
%% [mailto:address@hidden Behalf Of Hal
%% E. Fulton
%% Sent: Monday, September 09, 2002 7:29 PM
%% To: address@hidden
%% Subject: Re: [FR-devel] Nishio's Source Browser

%%
%% (snippage)
%%
%% Bob,
%%
%% That's interesting and exciting. Comments below.
%%
%% I guess my most important question, though, is this:
%% How mature is it and how functional at present? We'd
%% like to be able to distribute an early version of
%% FR at the RubyConf.

In a week or two it may be. But I gotta hussle to make that happen.

%%
%% Is your parser stable enough to be used in Nishio Mizuho's
%% class browser? Or maybe that's too much work to integrate
%% the two anyhow. What do you think?

I have to look at his class browser. That will help me develop the interface
to ensure that snapping it in, so to speak, will be easier rather than
harder.

%%
%% > My goals are to create a lexer/parser DLL for Ruby that:
%% >
%% > 1. is decoupled from the Object Runtime but 100% compatible with it
%% >    (in other words, Matz could decide to use it in the core distro
%% >    instead of the current highly coupled parser and everything
%% >    would work)
%%
%% That's a wonderful idea, and I hope it's adopted.
%%
%% One reason this is great is that it would be nice to have
%% a "canonical" Ruby parser usable by *any* piece of software
%% and have faith that it parses the same way Ruby does.

Right, that's the idea.

%%
%% Backends could be: IDEs, debuggers, editors, irb-like tools,
%% RDoc-like tools, prettyprinters, lint-like tools, and more.
%%
%% > 2. exposes an API for traversing the symbol table that is simple,
%% >    event-driven, and that follows the POLS.
%%
%% That's great also. Have you considered a non-event-driven
%% model also? I.e., just a traversable tree? Just a thought.

Yeah, and my first pass probably won't be event driven, because that will
take longer to do well (in a way that is 100% portable). ANd if the
non-event driven version works "good 'nuff" and in diverse applications, I
might not even implement an event-driven API. I just had various XML parsers
in mind when I said that.

%%
%% > 3. compiles with each of the target compilers that can be used to
%% >    compile Ruby itself.
%%
%% Yes, that's essential.

Agree.

%%
%% Good work, keep it coming.

Trying. Full time jobs, families, hobbies, and what not, all compete for an
unfortunately finite quantity of time during which both mind and body are
functional. (Don't we all know that!)

Thanks for the feedback, Hal. :)

- Bob

%%
%% Hal
%%
%%
%%
%%
%%
%%
%% _______________________________________________
%% Freeride-devel mailing list
%% address@hidden
%% http://mail.freesoftware.fsf.org/mailman/listinfo/freeride-devel
%%






reply via email to

[Prev in Thread] Current Thread [Next in Thread]