Re: [imp-dev] Bootstrapping IMP.runtime?

[Jurgen Vinju <jurgen@xxxxxxxxx>]

Let's do it! I'm eternally grateful.

On Wed, Feb 4, 2009 at 3:40 PM, Stan Sutton <suttons@xxxxxxxxxx> wrote:
>
> I think this is a good idea.  The need to run LPG manually on the
> checked-out projects has been an obstacle and a hindrance for a long time.
>  Let's at least try this as an interim solution.
>
> Regards,
>
> Stan
>
>
>
> "Robert M. Fuhrer" <rfuhrer@xxxxxxxxxxxxxx>
> Sent by: imp-dev-bounces@xxxxxxxxxxx
>
> 02/04/2009 09:21 AM
>
> Please respond to
> IMP Developers List <imp-dev@xxxxxxxxxxx>
> To
> IMP Developers List <imp-dev@xxxxxxxxxxx>
> cc
> Subject
> Re: [imp-dev] Bootstrapping IMP.runtime?
>
>
>
>
> We've been seeing some requests to check the generated files for
> the various parsers in IMP (both runtime and meta-tooling) into the
> source repo.
>
> I'm seriously considering this, since, at least until we get the LPG
> builder building parsers on checkout of the grammar file, having
> the generated files already in place definitely simplifies the
> workspace prep process.
>
> Perhaps this is also a solution to the bootstrapping issue you've
> been describing (even though I still think there is no cycle).
>
> Any other thoughts, or should we just go ahead and start checking
> in the generated parser/lexer implementations?
>
> [Perhaps when we do get the LPG builder performing as we wish
> on all fronts, we *might* remove the generated files. On the other
> hand, that means that our source users will have to *install* IMP
> into their Eclipse before trying to check things out, or they'll have
> to run LPG on the cmd line manually.]
>
> On Jan 22, 2009, at 2:02 PM, Jurgen Vinju wrote:
>
> In the interest of termination, my reply should be shorter than yours.
> That leaves me just the next sentence, which should be short.
> I agree, but still. :-)
>
> On Thu, Jan 22, 2009 at 5:01 PM, Robert M. Fuhrer <rfuhrer@xxxxxxxxxxxxxx>
> wrote:
> But there isn't really a cyclic dependency. You don't need the
> LPG IDE to build the parser, just the parser generator executable
> and the template library.
>
> On Jan 22, 2009, at 3:44 AM, Jurgen Vinju wrote:
>
> Hi!
>
> The bootstrapping is indirect, to use LPG you would use the LPG meta
> tooling, which
> depends on imp.runtime... You need the LPG meta tooling to compile the IMP
> run-time.
>
> Anyways, beer and/or an onion pizza and the time to discuss this... heaven.
>
> As a possible "solution", pdb.values *will* contain several small parsers
> for simple data exchange
> formats. ATerms is already in there, but I reckon we would add support for
> RSF, YAML and S-Expressions too.
> Those are easy-to-type formats that are suitable for configuration
> languages....
>
> The actual reason for these parsers is to be able to easily absorb data that
> is produced by existing
> software analysis tools, but hey, who am I to not use a parser for something
> it was not intended for?
>
> Cheers,
>
> Jurgen
>
> P.S. you could commit the generated code to break the cyclic dependency at
> build time (o no, I actually wrote this, and it will be archived...)
>
> On Thu, Jan 22, 2009 at 12:17 AM, Robert M. Fuhrer <rfuhrer@xxxxxxxxxxxxxx>
> wrote:
> Hi Jurgen,
>
> Although the only thing I like better than onions are onion analogies, there
> are two flaws in your argument. :-)
>
> It certainly makes sense to differentiate between meta-tools (used at
> compile
> or build time), and runtime tools/software (only used at IDE runtime). That
> distinction still places the generated parser in question in the IMP
> runtime,
> however: it's not part of any meta-tooling - it parses preference values
> that
> are used at IDE runtime by the tooling for any language.
>
> Second, I don't think the bootstrapping notion applies: the component in
> question is not the result of using IMP. It's the result of using another
> tool
> (LPG).
>
> Mind you, I'd like to avoid even the appearance that we're giving
> preferential
> treatment to LPG over any other parser generator. The way to do that,
> though, is to make sure that the meta-tooling and the runtime components
> make it equally easy to build languages using any parser generator. I
> just don't think including the results of one particular parser generator in
> the runtime contradicts that.
>
> Wish we could continue this over a beer... ;-)
>
> On Jan 21, 2009, at 4:56 PM, Jurgen Vinju wrote:
>
> Hi Bob,
>
> I think I would go for the onion solution ;-) A kernel layer, i.e. IMP
> run-time that does
> not require bootstrapping and has no 'meta tooling' in it.
> This is where most of the "heavy lifting" is done, i.e. the
> matching of the family of Eclipse API's to "programming language" concepts
> (API's in
> terms of programming language attributes).
>
> A second layers that adds micro-DSL's (like prefspecs) to more
> effectively/speedily  program
> with the kernel layer. This layer depends on the kernel layer, and may be
> generated by the
> next one. It also depends on additional libraries, such as the run-times of
> the next layer.
>
> A third layer that adds specification languages, such as LPG files and such,
> for generating
> the previous layer. This is the high-level meta-tooling layer. This layer
> depends on the previous
> layer and is obviously bootstrapped on it.
>
> I see the kernel layer to be something that is largely a responsibility of
> the IMP team, although
> it is highly flexible, programmable and extensible by the IDE developer.
> The second layer is an more open collection of meta tools that hook into the
> kernel layer, but
> still closely related to the features offered by the IMP run-time kernel.
> The final layer is completely open, but contains at least the IMP teams most
> favorite tools.
>
> That's just my thoughts on the subject. Maybe it is just a crude description
> of what IMP already is?
>
> Groetjes,
>
> Jurgen
>
> On Wed, Jan 21, 2009 at 8:20 PM, Robert M. Fuhrer <rfuhrer@xxxxxxxxxxxxxx>
> wrote:
> Hi Jurgen,
>
> I'm not sure what to do about this. On the face of it, your comment about
> avoiding
> LPG dependencies seems entirely reasonable. On the other hand, this
> basically
> implies that no part of IMP can depend on *any* parsing technology. That
> seems
> too restrictive.
>
> I can see where requiring a particular parsing technology for the language-
> specific stuff would be *real bad*, and against IMP's basic design goals. I
> don't
> think that runtime dependencies on LPG (or SDF, or ANTLR, or whatever)
> aren't
> a problem.
>
> That said, please remember that we now have the necessary IP approvals for
> our dependencies on LPG, and can now distribute the LPG runtime from the
> IMP update site. So our users won't have to go to multiple update sites any
> more.
>
> In fact, in general, eclipse.org requires that we distribute all non-Eclipse
> dependents from the eclipse.org-hosted IMP update site, so this isn't just
> the result of our wish for simplicity.
>
>
> On Jan 21, 2009, at 10:12 AM, Jurgen Vinju wrote:
>
> Hi guys,
>
> I noticed that a .g file is now part of org.eclipse.imp.runtime, which
> implies that one needs
> LPG meta-tooling to be able to compile the IMP run-time and that the IMP
> run-time now depends on the LPG run-time.
> (import org.eclipse.imp.parser.IParse)
>
> I propose to factor out this dependency in a separate package. Because
> currently the IMP run-time depends on LPG,
> both build-time and run-time, we've introduced a bootstrapping dependency
> that can be avoided.
> Furthermore we burden users of IMP-runtime with an extra dependency. I.e.
> everybody that uses a
> different parsing technology will also have to deploy LPG to their users.
>
> Also, for my development team at CWI, who currently check out IMP run-time
> without having to install
> LPG or LPG meta tooling, this added dependency is an unwanted feature.
>
> --
> Cheers,
>   - Bob
> -------------------------------------------------
> Robert M. Fuhrer
> Research Staff Member
> Programming Technologies Dept.
> IBM T.J. Watson Research Center
>
> IMP Project Lead (http://www.eclipse.org/imp)
> X10: Productivity for High-Performance Parallel Programming
> (http://x10.sf.net)
> _______________________________________________
> imp-dev mailing list
> imp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/imp-dev
>
>
> _______________________________________________
> imp-dev mailing list
> imp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/imp-dev
>
>