On Thu, 11 Dec 2014 12:02:43 +0000
Tobias Pankrath via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Thursday, 11 December 2014 at 11:46:50 UTC, ketmar via Digitalmars-d wrote:
> >
> > you can't see how this can help 'cause we don't have such
> > AST-companions yet. i can see how this will help 'cause i have
> > alot of
> > expirience with turbo/borland pascal and BlackBox Component
> > Builder.
> > think a-la BCB can be a killer app for D, but it's very hard to
> > build
> > it without good AST-companions.
> 
> And we're back to parsing speed.
nope. at least not more than in my "we don't need to generate native binaries" example. it's not about "code suggestions" at all.

> So, using an preparsed ast yields me nothing today, but might brake all the tools that work with object files.
how can it break any tool? and what tool is going to break? it's incredibly easy to convert "precompiled module file" to ".o" file which ld wants, but not vice versa.

> Giving the amount of manpower available, I'd say we have better things to do. But I guess no one would mind if you just make it happen.
i'm slowly working on it. as i really want my component system to work into, i *have* to write all the things i need for it. yet i'm a lone developer with alot of other things to do, and any slight change in D frontend means that i have to change my code too. with "AST-companions" integrated into frontend it's much easier to keep such system alive, 'cause the one who changes frontend will fix the "companion generator" too. it's not that hard (we have to fix .di generators now, for example), but almost impossible for lone independend developer who have to do payed work for living.

as i'm pretty sure that such work will never be integrated into mainline code, i'm just hacking it sometimes, but never tried to keep it up with DMD developement.

On Thu, 11 Dec 2014 12:06:39 +0000
Paulo  Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > with "AST-companions" D is in position to occupy that niche. D
> > is
> > c-like, D has great metaprogramming abilities, D is
> > open-source. it's
> > doomed to win.
> 
> To be honest, with .NET Native and OpenJDK getting an AOT compiler around the corner (Java 9 or 10 not yet decided) this opportunity is already lost.
nope, it's not lost. java was in position to do such thing for more than ten years, yet there is no real component system in java. the same for .net. they just not working in that direction, they still have IDEs, debuggers, compilers, libraries and all that separated crap. nothing will change in following twenty years, i can bet on it.

On Thu, 11 Dec 2014 12:11:35 +0000
Tobias Pankrath via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> If what you have in mind is indeed impossible with current object
> files, it may
> be worthwhile to create our own. But as I see it, the only
> benefit of storing an AST is compilation speed, which currently
> is not dominated by parsing.
it is possible, but it's like today's JIT compilers: first they compile the source to bytecode loosing alot of the info by the way, and then they "decompiling" bytecode to restore the info they throw away on the first step. i was laughing at java since i've seen "juice" project (don't try to google that, you'll find nothing).

> How would your precompiled modules differ from ELF except that they'd contain an AST for things that didn't emit the machine code yet?
how did one object file format differs from another object file format? they just targeted at different applications. i can emulate one with another, but it's a klugdery.

11-Dec-2014 04:17, Walter Bright пишет:
> On 12/10/2014 10:28 AM, H. S. Teoh via Digitalmars-d wrote:
>> Yeah, the compiler cannot instantiate the template without access to the
>> full body. It *could*, though, if we were to store template body IR in
>> object files, perhaps under specially-dedicated object file sections. It
>> wouldn't prevent reverse-engineering (which is moot anyway when
>> templates are involved), but it *would* work as an "opaque" library
>> interface file.
>
> Storing it as body IR accomplishes nothing practical over storing it as
> source file, i.e. .di files.
>

Even if we just bundle .di with .obj in one file, or better the whole library there are operational advantages. Consider that if a compiled library is trivially redistributable as a single file.

Importantly _always_ up to date "headers", a curse that follows C/C++ is out of sync header files or using wrong header files.

Futher options may include pre-tokenized .di files potentially with generated ddocs in one bundle. All in all looks like Java JAR files ;)

-- 
Dmitry Olshansky

On 2014-12-11 09:05, ketmar via Digitalmars-d wrote:

> except that there's no need to parse source code over and over again,
> which is good for other tools (like completion suggesting, intelligent
> code browsing and so on).

Wouldn't you need to parse the IR?

-- 
/Jacob Carlborg

On Fri, 12 Dec 2014 08:32:39 +0100
Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 2014-12-11 09:05, ketmar via Digitalmars-d wrote:
> 
> > except that there's no need to parse source code over and over again, which is good for other tools (like completion suggesting, intelligent code browsing and so on).
> 
> Wouldn't you need to parse the IR?
with good IR it's way easier than parsing the source. to the extent that it is possible to just mmap() compiled module and use it as ready data structure.

On 12/4/14 6:39 PM, deadalnix wrote:
> On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
> Digitalmars-d wrote:
>> It's an argument for Java over Python specifically but a bit more
>> general in reality. This stood out for me:
>>
>>
>> !…other languages like D and Go are too new to bet my work on."
>>
>>
>> http://www.teamten.com/lawrence/writings/java-for-everything.html
>
> Also relevant:
> http://wiki.jetbrains.net/intellij/Developing_and_running_a_Java_EE_Hello_World_application

Very interesting. Even after all IDE details are factored out, the code is quite convoluted. No wonder Ruby on Rails and friends are so attractive by comparison. -- Andrei

On Wed, 2014-12-17 at 09:09 -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> 
[…]
> Very interesting. Even after all IDE details are factored out, the code is quite convoluted. No wonder Ruby on Rails and friends are so attractive by comparison. -- Andrei

For the record, the right tools for lightweight web applications on the JVM are Grails, Ratpack, or Vert.x. JavaEE is for "enterprise size sites" (which is why it has enterprise in the title I guess :-). Spring as was is still there but Spring Boot is making a lot of people very happy.

I do not do any Web application, but I know a lot of people who do.

BSkyB for example do some JavaEE, quite a lot of Spring, and a great deal of Grails.

cf. http://grails.org/doc/2.4.x/guide/gettingStarted.html, http://www.ratpack.io/manual/current/, http://vertx.io/

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 12/11/2014 2:05 AM, Araq wrote:
> On Wednesday, 10 December 2014 at 23:23:50 UTC, Walter Bright
> wrote:
>> On 12/10/2014 4:15 AM, Paulo Pinto wrote:
>>> I prefer the model used by the referred languages, where binary libraries and
>>> metadata is used, instead of the C toolchain model.
>>>
>>> For example, just shipping the .TPU/.DCU libraries in the Object Pascal world.
>>
>> If the metadata had enough info in it to do inlining, it might as well be the
>> source code.
>
> Er ... but you're the guy who stresses that lexers cannot be fast
> enough because they need to look at every input char. (And you're
> right.) You can at least cache the lexing step. Not that D's
> compiler is not fast enough anyway, I'm just saying that your
> statement is really weird.

You're right that a binary version of the token stream would be faster. But not enough to justify the implementation complexity and other issues with a binary format. A text format also has the major advantage of being able to look at it and edit it as necessary without special tools.

On 12/11/2014 12:05 AM, ketmar via Digitalmars-d wrote:
> On Wed, 10 Dec 2014 17:17:11 -0800
> Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> On 12/10/2014 10:28 AM, H. S. Teoh via Digitalmars-d wrote:
>>> Yeah, the compiler cannot instantiate the template without access to the
>>> full body. It *could*, though, if we were to store template body IR in
>>> object files, perhaps under specially-dedicated object file sections. It
>>> wouldn't prevent reverse-engineering (which is moot anyway when
>>> templates are involved), but it *would* work as an "opaque" library
>>> interface file.
>>
>> Storing it as body IR accomplishes nothing practical over storing it as source
>> file, i.e. .di files.
> except that there's no need to parse source code over and over again,
> which is good for other tools (like completion suggesting, intelligent
> code browsing and so on).
>

Yeah, you just need to write another parser for the binary format, rather than reuse a canned D parser. :-)