Lars Ivar Igesund escribió:
> Yigal Chripun wrote:
> 
>> Denis Koroskin wrote:
>>> On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100@gmail.com>
>>> wrote:
>>>
>>>> Denis Koroskin wrote:
>>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> For me, V1.038 compiles my code but takes a really really really long
>>>>>> time to do so.
>>>>>>
>>>>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>>>>> in 13 seconds.
>>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>>
>>>>>> (building with DSSS and tango)
>>>>>>
>>>>>> --bb
>>>>>>
>>>>> I generally make all my imports private and run a command line tool
>>>>> that strips unnecessary imports once in a while to minimize
>>>>> intermodular dependencies. Maybe it could help in your case, too?
>>>> When programming in Java, Eclipse knows to handle all of this for you.
>>>> it will suggest adding missing imports, it can remove unused imports
>>>> and it can convert a foo.bar.* into a list of the specific modules you
>>>> actually used in the code.
>>>> I wish that kind of tool would be available for D. Is this
>>>> functionality implemented in descent? if not, is it planned?
>>>>
>>>> I do realize that it's more difficult to do this for D than it is for
>>>> Java, because of Conditional compilation and other issues already
>>>> mentioned in this thread. But it would be awesome if I could just write:
>>>>
>>>> Stdout("whatever").newline;
>>>>
>>>> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
>>>> of imports.
>>>>
>>>> --Yigal
>>> You should watch Descent videos on youtube, it is *much* smarter that
>>> that!
>>>
>>> http://www.youtube.com/user/asterite
>> I watched the video.
>> the functionality is that if you write: new Foo; it added automatically
>> an import for Foo. that's very cool and all but I was asking for
>> something more than that.
>>
>> for Java, Eclipse can add and manage imports for you not only when you
>> do new Somthing() but also for functions - like recognizing that
>> Stdout("string") needs to import tango.io.Stdout. More over, if you
>> wrote some of the imports yourself, or edited some code and removed the
>> only call to some function, you can ask eclipse to orginize your imports
>> and it'll remove unneeded imports and expand Java's Foo.* kind of import
>> to a list of the actual modules the code needs.
>>
>> Descent is a great project and I want to thank all the developers
>> involved in this great undertaking. All I'm saying is that it would be
>> nice to also have an "organize imports" function in Descent.
> 
> And you know for certain that it doesn't have this?
> 

Yigal is right, Descent doesn't have that kind of functionality.

As I mentioned before, you'd need to try every possible conditional-compilation setup combination to see which are the unused imports.

Also, when I first implemented it, I thought about adding selective imports in autocompletion, so that:

---
void foo() {
  writefln| <-- autocomplete!
}
---

results in:

---
import std.stdio : writefln;

void foo() {
  writefln(...)
}
---

and successive uses of symbols in std.stdio would add to the selective import, but many people told me that selective imports have some problems (I can't remember which were them right now).

Lars Ivar Igesund wrote:
> Yigal Chripun wrote:
>
>> Denis Koroskin wrote:
>>> On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun<yigal100@gmail.com>
>>> wrote:
>>>
>>>> Denis Koroskin wrote:
>>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter<wbaxter@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> For me, V1.038 compiles my code but takes a really really really long
>>>>>> time to do so.
>>>>>>
>>>>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>>>>> in 13 seconds.
>>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>>
>>>>>> (building with DSSS and tango)
>>>>>>
>>>>>> --bb
>>>>>>
>>>>> I generally make all my imports private and run a command line tool
>>>>> that strips unnecessary imports once in a while to minimize
>>>>> intermodular dependencies. Maybe it could help in your case, too?
>>>> When programming in Java, Eclipse knows to handle all of this for you.
>>>> it will suggest adding missing imports, it can remove unused imports
>>>> and it can convert a foo.bar.* into a list of the specific modules you
>>>> actually used in the code.
>>>> I wish that kind of tool would be available for D. Is this
>>>> functionality implemented in descent? if not, is it planned?
>>>>
>>>> I do realize that it's more difficult to do this for D than it is for
>>>> Java, because of Conditional compilation and other issues already
>>>> mentioned in this thread. But it would be awesome if I could just write:
>>>>
>>>> Stdout("whatever").newline;
>>>>
>>>> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
>>>> of imports.
>>>>
>>>> --Yigal
>>> You should watch Descent videos on youtube, it is *much* smarter that
>>> that!
>>>
>>> http://www.youtube.com/user/asterite
>> I watched the video.
>> the functionality is that if you write: new Foo; it added automatically
>> an import for Foo. that's very cool and all but I was asking for
>> something more than that.
>>
>> for Java, Eclipse can add and manage imports for you not only when you
>> do new Somthing() but also for functions - like recognizing that
>> Stdout("string") needs to import tango.io.Stdout. More over, if you
>> wrote some of the imports yourself, or edited some code and removed the
>> only call to some function, you can ask eclipse to orginize your imports
>> and it'll remove unneeded imports and expand Java's Foo.* kind of import
>> to a list of the actual modules the code needs.
>>
>> Descent is a great project and I want to thank all the developers
>> involved in this great undertaking. All I'm saying is that it would be
>> nice to also have an "organize imports" function in Descent.
>
> And you know for certain that it doesn't have this?
>

yeap. this is one of the basic refactorings, I guess. Descent isn't implementing any refactorings yet, right? I think they are still working on finishing some other internal systems - The semantic parsing is still experimental IIRC.

once the semantic parsing works fully refactorings on the AST can be implemented, but I don't think Descent reached that stage of development yet. correct me if I'm wrong.

I read the InteliJ IDEA changelog for the latest version 8 today. they added 10 refactorings, one of which is doing a dataflow analysis on the pointed to symbol and shows in the call heirarchy where that symbol's value comes from. Sounds extremly useful to me.

-- Yigal

Ary Borenszweig escribió:
> Lars Ivar Igesund escribió:
>> Yigal Chripun wrote:
>>
>>> Denis Koroskin wrote:
>>>> On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100@gmail.com>
>>>> wrote:
>>>>
>>>>> Denis Koroskin wrote:
>>>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> For me, V1.038 compiles my code but takes a really really really long
>>>>>>> time to do so.
>>>>>>>
>>>>>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>>>>>> in 13 seconds.
>>>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>>>
>>>>>>> (building with DSSS and tango)
>>>>>>>
>>>>>>> --bb
>>>>>>>
>>>>>> I generally make all my imports private and run a command line tool
>>>>>> that strips unnecessary imports once in a while to minimize
>>>>>> intermodular dependencies. Maybe it could help in your case, too?
>>>>> When programming in Java, Eclipse knows to handle all of this for you.
>>>>> it will suggest adding missing imports, it can remove unused imports
>>>>> and it can convert a foo.bar.* into a list of the specific modules you
>>>>> actually used in the code.
>>>>> I wish that kind of tool would be available for D. Is this
>>>>> functionality implemented in descent? if not, is it planned?
>>>>>
>>>>> I do realize that it's more difficult to do this for D than it is for
>>>>> Java, because of Conditional compilation and other issues already
>>>>> mentioned in this thread. But it would be awesome if I could just write:
>>>>>
>>>>> Stdout("whatever").newline;
>>>>>
>>>>> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
>>>>> of imports.
>>>>>
>>>>> --Yigal
>>>> You should watch Descent videos on youtube, it is *much* smarter that
>>>> that!
>>>>
>>>> http://www.youtube.com/user/asterite
>>> I watched the video.
>>> the functionality is that if you write: new Foo; it added automatically
>>> an import for Foo. that's very cool and all but I was asking for
>>> something more than that.
>>>
>>> for Java, Eclipse can add and manage imports for you not only when you
>>> do new Somthing() but also for functions - like recognizing that
>>> Stdout("string") needs to import tango.io.Stdout. More over, if you
>>> wrote some of the imports yourself, or edited some code and removed the
>>> only call to some function, you can ask eclipse to orginize your imports
>>> and it'll remove unneeded imports and expand Java's Foo.* kind of import
>>> to a list of the actual modules the code needs.
>>>
>>> Descent is a great project and I want to thank all the developers
>>> involved in this great undertaking. All I'm saying is that it would be
>>> nice to also have an "organize imports" function in Descent.
>>
>> And you know for certain that it doesn't have this?
>>
> 
> Yigal is right, Descent doesn't have that kind of functionality.
> 
> As I mentioned before, you'd need to try every possible conditional-compilation setup combination to see which are the unused imports.

Also: templates are not resolved until their instantiation, so that's a harder problem.

Yigal Chripun escribió:
> Denis Koroskin wrote:
>> On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100@gmail.com>
>> wrote:
>>
>>> Denis Koroskin wrote:
>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com>
>>>> wrote:
>>>>
>>>>> For me, V1.038 compiles my code but takes a really really really long
>>>>> time to do so.
>>>>>
>>>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>>>> in 13 seconds.
>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>
>>>>> (building with DSSS and tango)
>>>>>
>>>>> --bb
>>>>>
>>>>
>>>> I generally make all my imports private and run a command line tool that
>>>> strips unnecessary imports once in a while to minimize intermodular
>>>> dependencies. Maybe it could help in your case, too?
>>>
>>> When programming in Java, Eclipse knows to handle all of this for you.
>>> it will suggest adding missing imports, it can remove unused imports
>>> and it can convert a foo.bar.* into a list of the specific modules you
>>> actually used in the code.
>>> I wish that kind of tool would be available for D. Is this
>>> functionality implemented in descent? if not, is it planned?
>>>
>>> I do realize that it's more difficult to do this for D than it is for
>>> Java, because of Conditional compilation and other issues already
>>> mentioned in this thread. But it would be awesome if I could just write:
>>>
>>> Stdout("whatever").newline;
>>>
>>> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
>>> of imports.
>>>
>>> --Yigal
>>
>> You should watch Descent videos on youtube, it is *much* smarter that that!
>>
>> http://www.youtube.com/user/asterite
> 
> I watched the video.
> the functionality is that if you write: new Foo; it added automatically an import for Foo. that's very cool and all but I was asking for something more than that.
> 
> for Java, Eclipse can add and manage imports for you not only when you do new Somthing() but also for functions - like recognizing that Stdout("string") needs to import tango.io.Stdout.

If you put the cursor right after Stdout, you get the autocompletion. But I understand what you say, you want ctrl+shift+o (organize imports). I need to add some hooks into the port of the compiler so when a "symbol undefined" is reported, show a popup suggesting an import.

Aww... so many features I'd like to add. I wish more people would join the project. Many people say "thanks to all the developers involved in this project", and it's really just me, Robert Fraser, Bruno Medeiros, Frank Benoit helped a little in the beginning, and I can't remember if someone else helped... Of course, its testing, its usage, comments and suggestions by part of the community helped a lot also, but if more people would join the project, it would be much more powerful than now...

Ary Borenszweig wrote:
> Lars Ivar Igesund escribió:
>> Yigal Chripun wrote:
>>
>>> Denis Koroskin wrote:
>>>> On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100@gmail.com>
>>>> wrote:
>>>>
>>>>> Denis Koroskin wrote:
>>>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> For me, V1.038 compiles my code but takes a really really really
>>>>>>> long
>>>>>>> time to do so.
>>>>>>>
>>>>>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>>>>>> in 13 seconds.
>>>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>>>
>>>>>>> (building with DSSS and tango)
>>>>>>>
>>>>>>> --bb
>>>>>>>
>>>>>> I generally make all my imports private and run a command line tool
>>>>>> that strips unnecessary imports once in a while to minimize
>>>>>> intermodular dependencies. Maybe it could help in your case, too?
>>>>> When programming in Java, Eclipse knows to handle all of this for you.
>>>>> it will suggest adding missing imports, it can remove unused imports
>>>>> and it can convert a foo.bar.* into a list of the specific modules you
>>>>> actually used in the code.
>>>>> I wish that kind of tool would be available for D. Is this
>>>>> functionality implemented in descent? if not, is it planned?
>>>>>
>>>>> I do realize that it's more difficult to do this for D than it is for
>>>>> Java, because of Conditional compilation and other issues already
>>>>> mentioned in this thread. But it would be awesome if I could just
>>>>> write:
>>>>>
>>>>> Stdout("whatever").newline;
>>>>>
>>>>> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
>>>>> of imports.
>>>>>
>>>>> --Yigal
>>>> You should watch Descent videos on youtube, it is *much* smarter that
>>>> that!
>>>>
>>>> http://www.youtube.com/user/asterite
>>> I watched the video.
>>> the functionality is that if you write: new Foo; it added automatically
>>> an import for Foo. that's very cool and all but I was asking for
>>> something more than that.
>>>
>>> for Java, Eclipse can add and manage imports for you not only when you
>>> do new Somthing() but also for functions - like recognizing that
>>> Stdout("string") needs to import tango.io.Stdout. More over, if you
>>> wrote some of the imports yourself, or edited some code and removed the
>>> only call to some function, you can ask eclipse to orginize your imports
>>> and it'll remove unneeded imports and expand Java's Foo.* kind of import
>>> to a list of the actual modules the code needs.
>>>
>>> Descent is a great project and I want to thank all the developers
>>> involved in this great undertaking. All I'm saying is that it would be
>>> nice to also have an "organize imports" function in Descent.
>>
>> And you know for certain that it doesn't have this?
>>
>
> Yigal is right, Descent doesn't have that kind of functionality.
>
> As I mentioned before, you'd need to try every possible
> conditional-compilation setup combination to see which are the unused
> imports.
>
> Also, when I first implemented it, I thought about adding selective
> imports in autocompletion, so that:
>
> ---
> void foo() {
> writefln| <-- autocomplete!
> }
> ---
>
> results in:
>
> ---
> import std.stdio : writefln;
>
> void foo() {
> writefln(...)
> }
> ---
>
> and successive uses of symbols in std.stdio would add to the selective
> import, but many people told me that selective imports have some
> problems (I can't remember which were them right now).

Sounds awesome. if those problems (DMD bugs?) can be overcome, this would be one of my favorite features in descent.
what about a compromise? for the sake of unused import elimination assume that all possible versions are used. it's not that far off..
suppose I have:

import Foo;
import Bar;

version (foo) {
 // use symbols from Foo here
}

version (bar) {
 // use symbols from Bar here
}

removing either of the imports will be bad.
more advanced functionality would be to move the imports to inside of the version blocks.
I haven' t thought this through yet, but even some of this would be extremely useful. even if you just implement adding missing imports (and requiring me to remove redundant imports myself manually).

Keep on the good work, and thanks for an awsome and very useful project!

-- Yigal

Ary Borenszweig wrote:
> Yigal Chripun escribió:
>> Denis Koroskin wrote:
>>> On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <yigal100@gmail.com>
>>> wrote:
>>>
>>>> Denis Koroskin wrote:
>>>>> On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <wbaxter@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> For me, V1.038 compiles my code but takes a really really really long
>>>>>> time to do so.
>>>>>>
>>>>>> It now takes 1 min 20 secs for a full build, when it used to compile
>>>>>> in 13 seconds.
>>>>>> Forget the 60% slowdown from LDC -- this is 515% slower!
>>>>>>
>>>>>> (building with DSSS and tango)
>>>>>>
>>>>>> --bb
>>>>>>
>>>>>
>>>>> I generally make all my imports private and run a command line tool
>>>>> that
>>>>> strips unnecessary imports once in a while to minimize intermodular
>>>>> dependencies. Maybe it could help in your case, too?
>>>>
>>>> When programming in Java, Eclipse knows to handle all of this for you.
>>>> it will suggest adding missing imports, it can remove unused imports
>>>> and it can convert a foo.bar.* into a list of the specific modules you
>>>> actually used in the code.
>>>> I wish that kind of tool would be available for D. Is this
>>>> functionality implemented in descent? if not, is it planned?
>>>>
>>>> I do realize that it's more difficult to do this for D than it is for
>>>> Java, because of Conditional compilation and other issues already
>>>> mentioned in this thread. But it would be awesome if I could just
>>>> write:
>>>>
>>>> Stdout("whatever").newline;
>>>>
>>>> and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
>>>> of imports.
>>>>
>>>> --Yigal
>>>
>>> You should watch Descent videos on youtube, it is *much* smarter that
>>> that!
>>>
>>> http://www.youtube.com/user/asterite
>>
>> I watched the video.
>> the functionality is that if you write: new Foo; it added
>> automatically an import for Foo. that's very cool and all but I was
>> asking for something more than that.
>>
>> for Java, Eclipse can add and manage imports for you not only when you
>> do new Somthing() but also for functions - like recognizing that
>> Stdout("string") needs to import tango.io.Stdout.
>
> If you put the cursor right after Stdout, you get the autocompletion.
> But I understand what you say, you want ctrl+shift+o (organize imports).
> I need to add some hooks into the port of the compiler so when a "symbol
> undefined" is reported, show a popup suggesting an import.
>
> Aww... so many features I'd like to add. I wish more people would join
> the project. Many people say "thanks to all the developers involved in
> this project", and it's really just me, Robert Fraser, Bruno Medeiros,
> Frank Benoit helped a little in the beginning, and I can't remember if
> someone else helped... Of course, its testing, its usage, comments and
> suggestions by part of the community helped a lot also, but if more
> people would join the project, it would be much more powerful than now...

You read my mind :)
I hear you. It's not easy to take such a huge undertaking on yourself.

Well, I know Java, I don't know the sourcecode of eclipse and how to work with it. I have very little spare time.
I'll be happy to help as much as I can, even if it's just testing and such. I can help test for 64bit (windows/linux)...

Is it possible to close the bugzilla bugs that were fixed?

More generally, bug owners get e-mails when bugs are closed, but don't receive e-mails when new releases are made.  Here I was sitting around waiting for one of my bugs to get fixed, and here it's been fixed a week and a half :(

Walter Bright wrote:

> 
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.038.zip
> 
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.022.zip

Jason House wrote:
> Is it possible to close the bugzilla bugs that were fixed?
> 
> More generally, bug owners get e-mails when bugs are closed, but
> don't receive e-mails when new releases are made.  Here I was sitting
> around waiting for one of my bugs to get fixed, and here it's been
> fixed a week and a half :(

Yes, I just haven't gotten around to it yet!