View mode: basic / threaded / horizontal-split · Log in · Help
May 22, 2012
DCT use cases - draft
http://d-coding.com/2012/05/22/dct-use-cases.html
May 22, 2012
Re: DCT use cases - draft
On Tue, May 22, 2012 at 6:04 PM, Roman D. Boiko <rb@d-coding.com> wrote:

> http://d-coding.com/2012/05/**22/dct-use-cases.html<http://d-coding.com/2012/05/22/dct-use-cases.html>
>

Oh, boy! IMO, that's gonna be THE most useful thing related to D so far.

-- 
Bye,
Gor Gyolchanyan.
May 22, 2012
Re: DCT use cases - draft
On 22.05.2012 18:04, Roman D. Boiko wrote:
> http://d-coding.com/2012/05/22/dct-use-cases.html

>>Find parts of code model by a query (this single point will be 
>>expanded into its own series of posts)

Love this idea. Some sort of cool hierarchical pattern syntax would save 
megatons of boilerplate. Efficiency may suffer a bit but we have this 
CTFE stuff for hardcoded queries ;).

I can easily envision a code transformation of the whole project 
represented as a bunch of regex-like expressions.

-- 
Dmitry Olshansky
May 22, 2012
Re: DCT use cases - draft
On Tuesday, 22 May 2012 at 14:42:28 UTC, Dmitry Olshansky wrote:
> On 22.05.2012 18:04, Roman D. Boiko wrote:
>> http://d-coding.com/2012/05/22/dct-use-cases.html
>
> >>Find parts of code model by a query (this single point will
> be >>expanded into its own series of posts)
>
> Love this idea. Some sort of cool hierarchical pattern syntax 
> would save megatons of boilerplate. Efficiency may suffer a bit 
> but we have this CTFE stuff for hardcoded queries ;).
>
> I can easily envision a code transformation of the whole 
> project represented as a bunch of regex-like expressions.

The complicated part is conceptual, efficiency is feasible to 
achieve.
May 22, 2012
Re: DCT use cases - draft
22.05.2012 18:04, Roman D. Boiko написал:
> http://d-coding.com/2012/05/22/dct-use-cases.html

Please, please, try to rape dmd to do what you want first because 
otherwise you (like every other existing parsers in IDE) will fail with 
templates which are used everywhere in D (I mean std.algorithm).

A suggestion:
  Step 1 (bad performance): pass whole UTF-8 encoded source to dmd for 
recompilation every time (through memory mapped file, e.g.) and force 
dmd to write everything you want (yes, to mmfile because there will be a 
lot of information).
  Step 2 (better performance): stop dmd at some compilation stage (in a 
function context) and on user input fork dmd, give it new data, execute 
it, kill it. Pass whole source only when e.g. user start editing of 
another function.

It looks like we can't do anything better without good compiler-as-library.


By the way, it was really easy to change dmd to produce token 
information for token colonizing and it worked faster that Eclipse's 
Descent IIRC.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
May 22, 2012
Re: DCT use cases - draft
On 22.05.2012 18:45, Roman D. Boiko wrote:
> On Tuesday, 22 May 2012 at 14:42:28 UTC, Dmitry Olshansky wrote:
>> On 22.05.2012 18:04, Roman D. Boiko wrote:
>>> http://d-coding.com/2012/05/22/dct-use-cases.html
>>
>> >>Find parts of code model by a query (this single point will
>> be >>expanded into its own series of posts)
>>
>> Love this idea. Some sort of cool hierarchical pattern syntax would
>> save megatons of boilerplate. Efficiency may suffer a bit but we have
>> this CTFE stuff for hardcoded queries ;).
>>
>> I can easily envision a code transformation of the whole project
>> represented as a bunch of regex-like expressions.
>
> The complicated part is conceptual, efficiency is feasible to achieve.

Well for starters:

Abuse regex syntax, ban '/' w/o escape & use '/' for scopes/level, 
introduce a bunch of better wildcards/character sets like "identifier" 
etc. Throw in annotations that work like a list of tags the symbol 
should(n't) have: constant, template, function, class, struct, ... see 
traits. Same goes for protection & other annotations.

Then it goes like:

demo/{function, pure}f.*/i
->
j
(e.g. simple rename, refactoring looks similarly)

To fetch all of local symbols named i inside of pure functions that 
begin with 'f' inside entity demo  (entity = struct, class, template, 
module depending on where you apply it) and rename them to j.

I suggest to go with such kind of improvised notation with more examples 
until you fell that semantics are crystal clear.


-- 
Dmitry Olshansky
May 22, 2012
Re: DCT use cases - draft
On Tuesday, 22 May 2012 at 14:48:49 UTC, Denis Shelomovskij wrote:
> 22.05.2012 18:04, Roman D. Boiko написал:
>> http://d-coding.com/2012/05/22/dct-use-cases.html
>
> Please, please, try to rape dmd to do what you want first 
> because otherwise you (like every other existing parsers in 
> IDE) will fail with templates which are used everywhere in D (I 
> mean std.algorithm).
>
> A suggestion:
>   Step 1 (bad performance): pass whole UTF-8 encoded source to 
> dmd for recompilation every time (through memory mapped file, 
> e.g.) and force dmd to write everything you want (yes, to 
> mmfile because there will be a lot of information).
>   Step 2 (better performance): stop dmd at some compilation 
> stage (in a function context) and on user input fork dmd, give 
> it new data, execute it, kill it. Pass whole source only when 
> e.g. user start editing of another function.
>
> It looks like we can't do anything better without good 
> compiler-as-library.
>
>
> By the way, it was really easy to change dmd to produce token 
> information for token colonizing and it worked faster that 
> Eclipse's Descent IIRC.

Thanks, but what you described is outside DCT scope and goals.
May 22, 2012
Re: DCT use cases - draft
On Tuesday, 22 May 2012 at 14:48:49 UTC, Denis Shelomovskij wrote:
> 22.05.2012 18:04, Roman D. Boiko написал:
>> http://d-coding.com/2012/05/22/dct-use-cases.html
>
> Please, please, try to rape dmd to do what you want first 
> because otherwise you (like every other existing parsers in 
> IDE) will fail with templates which are used everywhere in D (I 
> mean std.algorithm).
>
> A suggestion:
>   Step 1 (bad performance): pass whole UTF-8 encoded source to 
> dmd for recompilation every time (through memory mapped file, 
> e.g.) and force dmd to write everything you want (yes, to 
> mmfile because there will be a lot of information).
>   Step 2 (better performance): stop dmd at some compilation 
> stage (in a function context) and on user input fork dmd, give 
> it new data, execute it, kill it. Pass whole source only when 
> e.g. user start editing of another function.
>
> It looks like we can't do anything better without good 
> compiler-as-library.
>
>
> By the way, it was really easy to change dmd to produce token 
> information for token colonizing and it worked faster that 
> Eclipse's Descent IIRC.

Thanks, but what you described is outside DCT scope and goals.
May 22, 2012
Re: DCT use cases - draft
On Tuesday, 22 May 2012 at 14:56:42 UTC, Dmitry Olshansky wrote:
> On 22.05.2012 18:45, Roman D. Boiko wrote:
>> On Tuesday, 22 May 2012 at 14:42:28 UTC, Dmitry Olshansky 
>> wrote:
>>> On 22.05.2012 18:04, Roman D. Boiko wrote:
>>>> http://d-coding.com/2012/05/22/dct-use-cases.html
>>>
>>> >>Find parts of code model by a query (this single point will
>>> be >>expanded into its own series of posts)
>>>
>>> Love this idea. Some sort of cool hierarchical pattern syntax 
>>> would
>>> save megatons of boilerplate. Efficiency may suffer a bit but 
>>> we have
>>> this CTFE stuff for hardcoded queries ;).
>>>
>>> I can easily envision a code transformation of the whole 
>>> project
>>> represented as a bunch of regex-like expressions.
>>
>> The complicated part is conceptual, efficiency is feasible to 
>> achieve.
>
> Well for starters:
>
> Abuse regex syntax, ban '/' w/o escape & use '/' for 
> scopes/level, introduce a bunch of better wildcards/character 
> sets like "identifier" etc. Throw in annotations that work like 
> a list of tags the symbol should(n't) have: constant, template, 
> function, class, struct, ... see traits. Same goes for 
> protection & other annotations.
>
> Then it goes like:
>
> demo/{function, pure}f.*/i
> ->
> j
> (e.g. simple rename, refactoring looks similarly)
>
> To fetch all of local symbols named i inside of pure functions 
> that begin with 'f' inside entity demo  (entity = struct, 
> class, template, module depending on where you apply it) and 
> rename them to j.
>
> I suggest to go with such kind of improvised notation with more 
> examples until you fell that semantics are crystal clear.

This is a possible, although not the only, option. Anyway I'm not
ready for designing the details yet. There is a lot to do before
that.
May 22, 2012
Re: DCT use cases - draft
On Tuesday, 22 May 2012 at 15:15:49 UTC, Roman D. Boiko wrote:
> On Tuesday, 22 May 2012 at 14:56:42 UTC, Dmitry Olshansky wrote:
>> I suggest to go with such kind of improvised notation with 
>> more examples until you fell that semantics are crystal clear.
>
> This is a possible, although not the only, option. Anyway I'm 
> not
> ready for designing the details yet. There is a lot to do before
> that.

After thinking a bit more, I decided to investigate the topic
early, although not immediately :) It should help deciding which
indices are needed, where are rough edges of API, etc.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home