Carlos Santander wrote:
> Jim Hewes escribió:
>>
>> Thanks, I'll check out the plug-in when dsource is back.
>> I was able to debug the sample hello.exe app in VS2005 by doing the following:
>>
>> 1. Load hello.exe into VS2005 as a project. Also, open the hello.d source file.
>> 2. Press F11 to take one step into the code. Source is not available, so show disassembly.
>> 3. In the disassembly window, enter the address as "_Dmain" and hit return. The window will show the mixed source/assembly at _Dmain.
>> 4. In the disassembly window, set a breakpoint at the first line of _Dmain and hit Go.
>> 5. In the source window, you should now see execution stop at the first line and you can single step from there.
>>
>> However, I wasn't able to set breakpoints from the source window. But I haven't had much time to play with it yet. Hopefuly I can spend more time next weekend. (Hey! I have a day job.)
>>
>> Jim
>>
>>
>>
> 
> You have to compile with -g to do so.
> 

Nope.  Setting breakpoints on source file lines still doesn't work even with -g.

But something's odd.  I'm pretty sure it _did_ work before I installed the VSPluginD.  I could set breakpoints, but I couldn't see variables before.  Now I can see variables, but I can't set breakpoints (except from dissasembly).  Or maybe it was only VS.NET 7.1 that was able to set source-level breakpoints?

I wonder if it's possible to tweak something in AutoExp.dat or in an EEAddIn plugin to make D strings and such show up properly, without the need for the "(char*)*((int*)(&str)+1)" trick.

The debugger seems to think all D arrays are of type unsigned__int64, though, which will probably be problematic.

--bb

"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:ejman4$10b1$1@digitaldaemon.com...
>
> Nope.  Setting breakpoints on source file lines still doesn't work even with -g.
>
> But something's odd.  I'm pretty sure it _did_ work before I installed the VSPluginD.  I could set breakpoints, but I couldn't see variables before. Now I can see variables, but I can't set breakpoints (except from dissasembly).  Or maybe it was only VS.NET 7.1 that was able to set source-level breakpoints?
>
> I wonder if it's possible to tweak something in AutoExp.dat or in an EEAddIn plugin to make D strings and such show up properly, without the need for the "(char*)*((int*)(&str)+1)" trick.
>
> The debugger seems to think all D arrays are of type unsigned__int64, though, which will probably be problematic.
>
> --bb
>

I think you're correct. My memory is a bit foggy, but I think I did try out a D sample program briefly a while back using VS2003 (v 7.1)  and I was able to set breakpoints in the source window.  With CS2005, I can see variables but can't set breakpoints in the source window. So perhaps Microsoft changed the format of their debug info or something.

Jim

"Jim Hewes" <jhewesNOSPAM@ix.netcom.com> wrote in message news:ejqgf0$2nol$1@digitaldaemon.com...
>
>   With CS2005, I can see variables ...

Oops, typo. I meant VS2005.

On Sat, 11 Nov 2006 17:36:26 -0800, "Jim Hewes" <jhewesNOSPAM@ix.netcom.com> wrote:

>I don't mean to sound like an advertisement for VS2005 and C#. My point is that by comparison, even though the D language is productive, some of that is negated by the whole development experience.

D has issues, its true, but it depends what you're doing. And the interoperability with C can help - for instance, build the UI in C#, add a simple C interface using VC++, and you're ready to use that UI from D. Not ideal, of course, but it's an option.

However my real view is that, depending on what development tools you have available, D may simply be more for a possible future than for the present. Perl, Python, PHP, Ruby etc have shown that there are people out there who will develop the needed tools given a compelling reason. I wouldn't be surprised if topics like this trigger 'just download these Eclipse plugins' responses some time in the near future.

>it's not cross-platform (is MONO a serious option?)

Good question. The windows GUI tends to get heavy use in .NET, for instance, yet MONO simply cannot provide it because Microsoft hasn't included it in the open part of .NET. There are alternatives (I forget which, but there is support for either GTK or KDE widget sets) but the apps that use them seem to be for Linux only. You can certainly get GTK for windows, but I'm not so sure about KDE, so maybe that has something to do with it.

My view is that MONO is a good solid platform, on the whole, but that Windows .NET and Linux .NET are separate platforms. The user interface is too important to most apps to dismiss as some kind of minor detail. After all, the UI is often the bulk of the code.

-- 
Remove 'wants' and 'nospam' from e-mail.

On Sat, 11 Nov 2006 23:36:08 -0300, Ary Manzana <ary@esperanto.org.ar> wrote:

>I plan to support refactoring.

In that case, I hope you don't mind me throwing some general ramblings your way.

I've been thinking about parsing recently. Not parsing for compilers, but parsing for documentation/refactoring/whatever where you need to make sense of incomplete and broken code.

And I've also been thinking about Google-style text searches.

To be specific, I was thinking that you could build an index based on the tokenized source code, and then search for all points in the code that match a certain grammar in much the same way that you would search the index for a regular expression match in a search engine that supported it.

The index might be a ternary tree, for instance, containing substrings of the tokenised source from each possible start token. You could limit those substrings to some small number of tokens to avoid needing polynomial time to build the index, and to make incremental changes practical. Anything that matches the first 8 (or whatever) tokens that are kept in the index, you just refer back to the full tokenised source to find out how far the matching continues.

Add some Tomita/backtracking/whatever trickery to get past ambiguities and this sounds to me like a workable method for doing things like spotting all functions or all variable declarations or whatever in an incomplete/broken source file with limited context (library headers etc) available.

It seems to me somehow closer to the way people read code than to traditional parsing, in that it can basically spot landmark patterns anywhere in the code without needing to understand the whole of the source file.

Is this sense, or nonsense?

-- 
Remove 'wants' and 'nospam' from e-mail.