April 16, 2012
Le 16/04/2012 09:00, Jakob Ovrum a écrit :
> On Monday, 16 April 2012 at 06:37:00 UTC, Jacob Carlborg wrote:
>> On 2012-04-16 04:35, Ary Manzana wrote:
>>> On 4/13/12 9:10 PM, deadalnix wrote:
>>>> SDC have a lot of theses, and I proposed a similar stuff for its
>>>> evolution. I think it is easier for SDC than it is for dmd considering
>>>> the codebase of both.
>>>
>>> Cool! SDC is the way to go. Let's focus our efforts on that project. :-)
>>
>> I noticed that SDC is licensed under the GPL license :( That is not
>> compatible with, for example, EPL used by Eclipse.
>
> We are changing the license soon, with BSD/MIT in mind. I am really just
> waiting for Bernard to make the change, we've gotten permission from all
> contributors as far as I know.

You didn't asked me, but now you have mine. (Anyway, I'm not a big contributor, and only have submitted some small patches).
April 16, 2012
On Monday, 16 April 2012 at 07:00:19 UTC, Jakob Ovrum wrote:
> On Monday, 16 April 2012 at 06:37:00 UTC, Jacob Carlborg wrote:
>> On 2012-04-16 04:35, Ary Manzana wrote:
>>> On 4/13/12 9:10 PM, deadalnix wrote:
>>>> SDC have a lot of theses, and I proposed a similar stuff for its
>>>> evolution. I think it is easier for SDC than it is for dmd considering
>>>> the codebase of both.
>>>
>>> Cool! SDC is the way to go. Let's focus our efforts on that project. :-)
>>
>> I noticed that SDC is licensed under the GPL license :( That is not compatible with, for example, EPL used by Eclipse.
>
> We are changing the license soon, with BSD/MIT in mind. I am really just waiting for Bernard to make the change, we've gotten permission from all contributors as far as I know.

Oh god, what did we decide on? Boost?
April 16, 2012
On Monday, 16 April 2012 at 11:34:14 UTC, deadalnix wrote:
> Le 16/04/2012 09:00, Jakob Ovrum a écrit :
>> On Monday, 16 April 2012 at 06:37:00 UTC, Jacob Carlborg wrote:
>>> On 2012-04-16 04:35, Ary Manzana wrote:
>>>> On 4/13/12 9:10 PM, deadalnix wrote:
>>>>> SDC have a lot of theses, and I proposed a similar stuff for its
>>>>> evolution. I think it is easier for SDC than it is for dmd considering
>>>>> the codebase of both.
>>>>
>>>> Cool! SDC is the way to go. Let's focus our efforts on that project. :-)
>>>
>>> I noticed that SDC is licensed under the GPL license :( That is not
>>> compatible with, for example, EPL used by Eclipse.
>>
>> We are changing the license soon, with BSD/MIT in mind. I am really just
>> waiting for Bernard to make the change, we've gotten permission from all
>> contributors as far as I know.
>
> You didn't asked me, but now you have mine. (Anyway, I'm not a big contributor, and only have submitted some small patches).

I recall mentioning it via IRC. Which is hardly going to stand up
in a court. :V

April 16, 2012
On Monday, 16 April 2012 at 06:37:00 UTC, Jacob Carlborg wrote:
> On 2012-04-16 04:35, Ary Manzana wrote:
>> On 4/13/12 9:10 PM, deadalnix wrote:
>>> SDC have a lot of theses, and I proposed a similar stuff for its
>>> evolution. I think it is easier for SDC than it is for dmd considering
>>> the codebase of both.
>>
>> Cool! SDC is the way to go. Let's focus our efforts on that project. :-)
>
> I noticed that SDC is licensed under the GPL license :( That is not compatible with, for example, EPL used by Eclipse.

https://github.com/bhelyer/SDC/commit/2002ec27e8df9144f0d1051032abbfe24d2ad4d2

Go nuts.
April 16, 2012
On Monday, 16 April 2012 at 02:34:29 UTC, Ary Manzana wrote:
> On 4/13/12 9:10 PM, deadalnix wrote:
>> Le 13/04/2012 11:58, Ary Manzana a écrit :
>>> Having a D compiler available as a library will (at least) give these
>>> benefits:
>>>
>>> 1. Can be used by an IDE: D is statically typed and so an IDE can
>>> benefit a lot from this. The features Descent had, as far as I remember,
>>> were:
>>> 1.1. Outline
>>> 1.2. Autocompletion
>>> 1.3. Type Hierarchy
>>> 1.4. Syntax and semantic errors, showing not only the line number but
>>> also column numbers if it makes sense
>>> 1.5. Automatic import inclusion (say, typing writefln and getting a list
>>> of modules that provide that symbol)
>>> 1.6. Compile-time view: replace auto with the inferred type, insert
>>> mixins into scope, rewrite operator overloads and other lowerings (but
>>> I'm not sure this point is really useful)
>>> 1.7. Determine, given a set of versions and flags, which branches of
>>> static ifs are used/unused
>>> 1.8. Open declaration
>>> 1.9. Show implementations (of an interface, of interface's method or,
>>> abstract methods, or method overrides).
>>> 1.10. Propose to override a method (you type some letters and then hit
>>> some key combination and get a list of methods to override)
>>> 1.11. Get the code of a template when instantiated.
>>> 2. Can be used to build better doc generators: one that shows known
>>> subclasses or interface implementation, shows inherited methods, type
>>> hierarchy.
>>> 3. Can be used for lints and other such tools.
>>>
>>> As you can see, a simple lexer/parser built into an IDE, doc generator
>>> or lint will just give basic features but will never achieve something
>>> exceptionally good if it lacks the full semantic knowledge of the code.
>>>
>>> I'll write a list of things I'd like this compiler-as-library to have,
>>> but please help me make it bigger :-)
>>>
>>> * Don't use global variables (DMD is just thought to be run once, so
>>> when used as a library it can just be used, well, once)
>>> * Provide a lexer which gives line numbers and column numbers
>>> (beginning, end)
>>> * Provide a parser with the same features
>>> * The semantic phase should not discard any information found while
>>> parsing. For example when DMD resolves a type it recursively resolves
>>> aliasing and keeps the last one. An example:
>>>
>>> alias int foo;
>>> alias foo* bar;
>>>
>>> bar something() { ... }
>>>
>>> It would be nice if "bar", after semantic analysis is done, carries the
>>> information that bar is "foo*" and that "foo" is "int". Also that
>>> something's return type is "bar", not "int*".
>>> * Provide errors and warnings that have line numbers as well as column
>>> numbers.
>>> * Allow to parse the top-level definitions of a module. Whit this I mean
>>> skipping function bodies. At least Descent first built a the outline of
>>> the whole project by doing this. This mode should also allow specifying
>>> a location as a target, and if that location falls inside a function
>>> body then it's contents are returned (useful when editing a file, so you
>>> can get the outline as well as semantic info of the function currently
>>> being edited, which will never affect semantic in other parts of the
>>> module). This will dramatically speed up the editor.
>>> * Don't stop parsing on errors (I think DMD already does this).
>>> * Provide a visitor class. If possible, use visitors to implement
>>> semantic analysis. The visitor will make it super easy to implement
>>> lints and to generate documentation.
>>
>> SDC have a lot of theses, and I proposed a similar stuff for its
>> evolution. I think it is easier for SDC than it is for dmd considering
>> the codebase of both.
>
> Cool! SDC is the way to go. Let's focus our efforts on that project. :-)
>
> One thing I saw in the code is that global variables are used in it (specially in the sdc.aglobal module).
>
> Also, the lexer returns a TokenStream which contains the full array of tokens. This is very slow compared to returning them as they are scanned, when requested. But I guess this is easy to fix as it's hidden behind the TokenStream interface.
>
> I tried to compile a simple file:
>
> void main() {}
>
> > ./bin/sdc main.d
> core.exception.AssertError@sdc.gen.sdcmodule(560): Assertion failure
> ----------------
> 5   sdc                                 0x000000010b87aa2a _d_assertm + 42
> 6   sdc                                 0x000000010b4e2daa void sdc.gen.sdcmodule.__assert(int) + 26
> 7   sdc                                 0x000000010b55d19c void sdc.gen.sdcmodule.Store.addFunction(sdc.gen.sdcfunction.Function) + 92
> 8   sdc                                 0x000000010b55d75b void sdc.gen.sdcmodule.Scope.add(immutable(char)[], sdc.gen.sdcfunction.Function) + 123
> 9   sdc                                 0x000000010b54ee36 void sdc.gen.declaration.declareFunctionDeclaration(sdc.ast.declaration.FunctionDeclaration, sdc.ast.sdcmodule.DeclarationDefinition, sdc.gen.sdcmodule.Module) + 1278
> 10  sdc                                 0x000000010b54e4b2 void sdc.gen.declaration.declareDeclaration(sdc.ast.declaration.Declaration, sdc.ast.sdcmodule.DeclarationDefinition, sdc.gen.sdcmodule.Module) + 146
> 11  sdc                                 0x000000010b54d12e void sdc.gen.base.genDeclarationDefinition(sdc.ast.sdcmodule.DeclarationDefinition, sdc.gen.sdcmodule.Module, ulong) + 374
> 12  sdc                                 0x000000010b54c8d0 void sdc.gen.base.resolveDeclarationDefinitionList(sdc.ast.sdcmodule.DeclarationDefinition[], sdc.gen.sdcmodule.Module, sdc.gen.type.Type) + 564
> 13  sdc                                 0x000000010b54c439 sdc.gen.sdcmodule.Module sdc.gen.base.genModule(sdc.ast.sdcmodule.Module, sdc.aglobal.TranslationUnit) + 157
> 14  sdc                                 0x000000010b53432d int sdc.sdc.realmain(immutable(char)[][]) + 3081
> 15  sdc                                 0x000000010b4e283e _Dmain + 54
> 16  sdc                                 0x000000010b87b415 extern (C) int rt.dmain2.main(int, char**).void runMain() + 29
> 17  sdc                                 0x000000010b87adc5 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 45
> 18  sdc                                 0x000000010b87b467 extern (C) int rt.dmain2.main(int, char**).void runAll() + 63
> 19  sdc                                 0x000000010b87adc5 extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate()) + 45
> 20  sdc                                 0x000000010b87ad48 main + 232
> 21  sdc                                 0x000000010b4e2694 start + 52
> 22  ???                                 0x0000000000000002 0x0 + 2
> ----------------

https://github.com/bhelyer/SDC/issues/30

Rename main.d to something else and it should work. Gotta fix that. >_<



April 16, 2012
On 2012-04-16 14:14, Bernard Helyer wrote:

> https://github.com/bhelyer/SDC/commit/2002ec27e8df9144f0d1051032abbfe24d2ad4d2
>
>
> Go nuts.

Awesome :)

-- 
/Jacob Carlborg
April 18, 2012
Am Sat, 14 Apr 2012 22:44:07 -0400
schrieb "Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com>:

> "Jacob Carlborg" <doob@me.com> wrote in message news:jm9ulg$ui3$1@digitalmars.com...
> >
> > * Refactoring
> >
> 
> * Make DustMite even more awesomer by attempting to factor out functions, etc.

Something internal:

* Keep a view of every opened file in memory.

* Allow to manipulate that file with an interface like insert, delete,
  replace of character ranges.

* Reparse only what has changed through that interface (remember datetime.d?)
  This is to avoid CPU hogging and typing delays.

* Manage multiple open projects. That means sharing of the internal
  representation of druntime/Phobos and libraries.

* We probably want two parser interfaces. Thinking of XML: SAX and DOM.
  One parser iterates over the tokens and calls event handlers (no AST).
    Example: lazy (line-by-line) editor syntax highlighting.
  The other parser builds the whole module as an AST to work on.
    Example: editing code multiple times in an IDE/refactorings

* If necessary, some sort of transaction, so a refactoring that fails in
  the middle of the operation doesn't leave the code in a broken state.

* DDoc awareness. Cross-linked symbols etc. must be included when that
  symbol is renamed.

I want refactoring to be as simple as Foo.renameSymbol("std.path.sep", "std.path.dirSeperator"); if the connection between module- and filename allows "std.path" to be traced back to the original file.

-- 
Marco

April 18, 2012
On 2012-04-18 14:49, Marco Leise wrote:

> I want refactoring to be as simple as Foo.renameSymbol("std.path.sep", "std.path.dirSeperator"); if the connection between module- and filename allows "std.path" to be traced back to the original file.

I'm not sure but I don't think that is enough. In Clang you do something like this:

1. Get cursor of source location
2. Get a unique global ID of the cursor the corresponds to the symbol (unified symbol resolution)
3. Walk the AST to find all matches of this ID
4. Get the source location of the cursors which match
5. Rename the symbol at the source location

-- 
/Jacob Carlborg
April 19, 2012
On Wednesday, 18 April 2012 at 16:48:46 UTC, Jacob Carlborg wrote:
> On 2012-04-18 14:49, Marco Leise wrote:
>
>> I want refactoring to be as simple as Foo.renameSymbol("std.path.sep", "std.path.dirSeperator"); if the connection between module- and filename allows "std.path" to be traced back to the original file.
>
> I'm not sure but I don't think that is enough. In Clang you do something like this:
>
> 1. Get cursor of source location
> 2. Get a unique global ID of the cursor the corresponds to the symbol (unified symbol resolution)
> 3. Walk the AST to find all matches of this ID
> 4. Get the source location of the cursors which match
> 5. Rename the symbol at the source location

Convenience interface on top of low-level core functionality can be provided and would suffice for many typical situations.
April 19, 2012
On Monday, 16 April 2012 at 11:57:29 UTC, Bernard Helyer wrote:
> On Monday, 16 April 2012 at 07:00:19 UTC, Jakob Ovrum wrote:
>> On Monday, 16 April 2012 at 06:37:00 UTC, Jacob Carlborg wrote:
>>> On 2012-04-16 04:35, Ary Manzana wrote:
>>>> On 4/13/12 9:10 PM, deadalnix wrote:
>>>>> SDC have a lot of theses, and I proposed a similar stuff for its
>>>>> evolution. I think it is easier for SDC than it is for dmd considering
>>>>> the codebase of both.
>>>>
>>>> Cool! SDC is the way to go. Let's focus our efforts on that project. :-)
>>>
>>> I noticed that SDC is licensed under the GPL license :( That is not compatible with, for example, EPL used by Eclipse.
>>
>> We are changing the license soon, with BSD/MIT in mind. I am really just waiting for Bernard to make the change, we've gotten permission from all contributors as far as I know.
>
> Oh god, what did we decide on? Boost?

MIT is great, it is a huge step forward with respect to commercial reuse of code.

However, Boost would allow inclusion of sources (e.g., lexer/parser) into D standard library (I saw it has been mentioned somewhere that such functionality is planned, probably by Andrei Alexandrescu). Of course, before inclusion it might be rewritten significantly, but at least it could be based on SDC or whatever other implementation with Boost license.

What was the motivation behind selecting MIT?