On Wednesday, 7 March 2012 at 21:15:46 UTC, dnewbie wrote:
> Zach the Mystic - I can't compile it.

Still not working?

It's working..

Pretty cool :)



On Thu, Mar 8, 2012, at 12:07 AM, Zach the Mystic wrote:
> On Wednesday, 7 March 2012 at 21:15:46 UTC, dnewbie wrote:
> > Zach the Mystic - I can't compile it.
> 
> Still not working?
> 
> 
> 
> 

On Wednesday, 7 March 2012 at 23:35:48 UTC, dnewbie wrote:
> It's working..
>
> Pretty cool :)

I think you're starting new threads each time you respond. You should find a way to respond to only the posts you want and not start a new thread each time. Not that I don't like the free advertising, but yeah.

Thanks for trying out ddmd-clean!

Zach the Mystic wrote:

> Check it out:

Done. Congrats!

-manfred

"Zach the Mystic" <reachMINUSTHISzachgmail@dot.com> wrote in message news:cibxxwrywnorlxwthent@forum.dlang.org...
> On Wednesday, 7 March 2012 at 20:46:40 UTC, Andrej Mitrovic wrote:
>> Hi,
>>
>> which version of the compiler can this be built with?
>>
>> I get this with 2.058:
>> dmd\binExp.d(324): Error: function dmd.binExp.EqualExp.isBit of type
>> bool() overrides but is not covariant with
>> dmd.expression.Expression.isBit of type int()
>> dmd\binExp.d(324): Error: function dmd.binExp.EqualExp.isBit does not
>> override any function
>
> Well, I was using 2.057
>
> But obviously you've found a bug I can fix rather quickly!
>
>

You should check, but I think isBit is dead code anyway.

"Zach the Mystic" <reachMINUSTHISzachgmail@dot.com> wrote in message news:afqmbmvuvizvgfooefqj@forum.dlang.org...

> I'll gladly put a license on it if the leaders of the community tell me which one to use ( Artistic, libpng, Boost ).
>
> Zach

It will need to be the same license as the frontend (GPL/Artistic).  It should be at the top of each c++ source file.

On Thursday, 8 March 2012 at 01:38:43 UTC, Daniel Murphy wrote:
>
> You should check, but I think isBit is dead code anyway.

I think it is. I've left a number of dead codes because it helped me understand the whole system better. There's a lot of isXXX() functions which come in handy, so maybe isBit will too. I have no reason to cut it until I fully understand that it's not going to be useful.

On Thursday, 8 March 2012 at 01:43:26 UTC, Daniel Murphy wrote:
> "Zach the Mystic" <reachMINUSTHISzachgmail@dot.com> wrote in message
> news:afqmbmvuvizvgfooefqj@forum.dlang.org...
>
>> I'll gladly put a license on it if the leaders of the community tell me which one to use ( Artistic, libpng, Boost ).
>>
>> Zach
>
> It will need to be the same license as the frontend (GPL/Artistic).  It
> should be at the top of each c++ source file.

It looks like the license is going to have to be GPL because it says so strictly in dmd's readme.txt. Somehow that license scares me, though. The "Free Software Foundation" seems like a very Orwellian institution to me. I hope it doesn't scare users away.

So be it.

On 3/7/12 5:02 PM, Zach the Mystic wrote:
> Check it out:
> https://github.com/zachthemystic/ddmd-clean/
>
> This program is an adaptation of the work done by the ddmd team:
> http://www.dsource.org/projects/ddmd
>
> I described most of it in the README. I hope it runs smoothly for you. I
> only ran it on MAC OSX, and I don't know much about github or about how
> to get things running smoothly for others.
>
> Don't expect miracles. The parser is NOT up to date, e.g. => with the
> lastest lambda syntax.
>
> I'll gladly put a license on it if the leaders of the community tell me
> which one to use ( Artistic, libpng, Boost ).
>
> Onward and upward to IDE functionality!
>
> Zach

Very nice!

I wonder, how did you port it?

And also, how are you going to maintain it synchronized to the lasted dmd version?

I ask, because I ported dmd to Java and it was really hard to maintain. I almost had to do it manually.

Of course, it will be much easier to diff, copy to the D code and then clean the code a bit. But since the files are different (the names, the extensions, where things are located), I guess it will be a PITA and you'll eventually quit.

On Thursday, 8 March 2012 at 02:32:11 UTC, Ary Manzana wrote:
>
> Very nice!
>
> I wonder, how did you port it?

Manually!
It was hard, but I'm new enough to programming in general that it was just as much of a learning process as a tedious grind or something.

> And also, how are you going to maintain it synchronized to the lasted dmd version?

I'm under the impression that the syntax of the language changes much more rarely than the semantic and backend. While I don't have much experience with software maintenance, it will definitely be easier to maintain a mere parser than an entire semantic and backend.

I have two more things to say here, actually. One, you know, in a perfect world there would not even _be_ a D compiler written in C++ (i.e. only one written in D!), so I don't see why additions to this compiler have to be precisely like they are in dmd. They just need to be consistent with the language specification.

But two, I have a prospective use for this program which I am going to explore further. The idea is that the closer any given part of a compiler is to the human-readable code structure - i.e. the lexer is very close, the parser is a little further away, semantic even further, etc. - the more useful it will be as a development tool. As long as you can reverse any given compilation process - e.g. a parser is reversed by a code generator, a lexer by a "token generator", etc. - you can go backward and show the current state of the program to the user on the screen.

So instead of focusing on getting ddmd to work as a full-fledged compiler, I ( we? ) could focus on adding features which are useful for the development process. For example, say we are able to implement templates, which happen pretty soon after parsing, I believe, and also a reverser which allows us to put their current state to screen. Now we could look at the structure which WOULD be generated when compiled. CTFE may also be within reach, but I'm not at all sure because I know very little about it.

My immediate goal is to make an editor which doesn't work so much with text files as with fully parsed syntax trees, and merely converts them to code for displaying on the screen, and for writing to file to be sent to the actual D compiler.

Continuing with this theme, I've thought about some of the problems I might encounter ahead. But I'm rather excited about the solutions too. One obvious problem is that a parsed program is likely to be much more memory intensive than a text file. The solution I imagine to this problem is to literally convert chunks of a program BACK into text when they go offscreen. In other words, you're storing it as text, but editing it as a program tree. Not only would this text take up less memory, but it would also be easy to search through as text if that were the preferred editing style for the moment. It would also make writing the whole thing to file much faster, which will be extremely necessary because the whole process hinges on being able to quickly convert your tree to file so that it can be picked up by dmd, for example. Also, you could easily use any text editing capabilities you'd already implemented on non-D files.

Another thing I enjoy fantasizing about in this regard, is a program which duplicates its already parsed objects, hands them directly to its built-in compiler, and waits for the result without even needing to write to a file.

Anyway, the first thing I need is a gui, and a code generator capable of coloring its output appropriately, so I'm working on that, but it's not (even close to) ready for show yet!