www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Taunting

reply Ary Borenszweig <ary esperanto.org.ar> writes:
http://www.youtube.com/watch?v=rtYCFVPfx4M
May 21 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Ary,

 http://www.youtube.com/watch?v=rtYCFVPfx4M
 
The clunk you just heard is my jaw bouncing on the floor <G> NICE!!!!!
May 21 2009
parent reply grauzone <none example.net> writes:
BCS wrote:
 Reply to Ary,
 
 http://www.youtube.com/watch?v=rtYCFVPfx4M
The clunk you just heard is my jaw bouncing on the floor <G> NICE!!!!!
It would be very nice to have such a debugging feature. Too bad it's hardcoded into a very bug GUI system. Even if I spent hours configuring Eclipse for my needs, there's still the speed issue. Even after I purchased a new PC, using Eclipse felt like stirring lava. (Sure, it was better than before, but I'll just stay with my light-speed fast syntax highlighting text editor.) But for someone who does use Eclipse/Descent, this is great, of course.
May 22 2009
next sibling parent grauzone <none example.net> writes:
 It would be very nice to have such a debugging feature. Too bad it's 
 hardcoded into a very bug GUI system.
I meant to write "big", not "bug". Talk about Freudian Slips!
May 22 2009
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
grauzone wrote:
 BCS wrote:
 Reply to Ary,

 http://www.youtube.com/watch?v=rtYCFVPfx4M
The clunk you just heard is my jaw bouncing on the floor <G> NICE!!!!!
It would be very nice to have such a debugging feature. Too bad it's hardcoded into a very bug GUI system.
Yes, heaven forbid Ary spends his time adding and improving features when he should be building a new editor from the ground up. In all seriousness, I hate IDEs because they are big, slow, and waste vast tracts of prime monitor space. But I'm willing to put up with that for Descent's compile-time view and (hopefully soon) compile-time debugging. If I could get that in a super fast, light programming editor, I'd use that instead. But I can't. Although it is annoying when I'm out and about on my little netbook and can't use Eclipse. C'est la vie.
May 22 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Daniel Keep wrote:
 
 grauzone wrote:
 BCS wrote:
 Reply to Ary,

 http://www.youtube.com/watch?v=rtYCFVPfx4M
The clunk you just heard is my jaw bouncing on the floor <G> NICE!!!!!
It would be very nice to have such a debugging feature. Too bad it's hardcoded into a very bug GUI system.
Yes, heaven forbid Ary spends his time adding and improving features when he should be building a new editor from the ground up. In all seriousness, I hate IDEs because they are big, slow, and waste vast tracts of prime monitor space. But I'm willing to put up with that for Descent's compile-time view and (hopefully soon) compile-time debugging. If I could get that in a super fast, light programming editor, I'd use that instead. But I can't. Although it is annoying when I'm out and about on my little netbook and can't use Eclipse. C'est la vie.
Another problem with Descent is that it's kind of buggy (yes, I know it). But most of the bugs are because of errors in the semantic analysis ported from DMD's front end. So, for example, some template instantiations fail when they shouldn't. What's good about being able to debug these template instantiations is that we'll be able to understand why a template instantiation fails when it shouldn't, that is, there's a bug in Descent, and it'll help us make it more robust (it'll help me find faster where's the bug). Thus, this feature will help you debug templates and compile-time functions, and also make Descent better. :-)
May 22 2009
parent dennis luehring <dl.soluz gmx.net> writes:
Ary Borenszweig schrieb:
 Daniel Keep wrote:
 
 grauzone wrote:
 BCS wrote:
 Reply to Ary,

 http://www.youtube.com/watch?v=rtYCFVPfx4M
The clunk you just heard is my jaw bouncing on the floor <G> NICE!!!!!
It would be very nice to have such a debugging feature. Too bad it's hardcoded into a very bug GUI system.
Yes, heaven forbid Ary spends his time adding and improving features when he should be building a new editor from the ground up. In all seriousness, I hate IDEs because they are big, slow, and waste vast tracts of prime monitor space. But I'm willing to put up with that for Descent's compile-time view and (hopefully soon) compile-time debugging. If I could get that in a super fast, light programming editor, I'd use that instead. But I can't. Although it is annoying when I'm out and about on my little netbook and can't use Eclipse. C'est la vie.
Another problem with Descent is that it's kind of buggy (yes, I know it). But most of the bugs are because of errors in the semantic analysis ported from DMD's front end. So, for example, some template instantiations fail when they shouldn't.
maybe we should think about extending dmd itselfe to give you and runtime interface to the compile which can be used for features like that - any ideas?
May 22 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Daniel,

 In all seriousness, I hate IDEs because they are big, slow, and waste
 vast tracts of prime monitor space.  But I'm willing to put up with
 that for Descent's compile-time view and (hopefully soon) compile-time
 debugging.
 
 If I could get that in a super fast, light programming editor, I'd use
 that instead.  But I can't.
 
 Although it is annoying when I'm out and about on my little netbook
 and can't use Eclipse.  C'est la vie.
I've used Eclipse in a netbook. It works fine aside from the screen being a little small. But then again, the screen being a little small would be a problem no mater what editor I used until I can afford this: http://www.codinghorror.com/blog/archives/000959.html
May 22 2009
prev sibling next sibling parent grauzone <none example.net> writes:
 Yes, heaven forbid Ary spends his time adding and improving features
 when he should be building a new editor from the ground up.
That's not what I'm saying. First, he's free to do with his time whatever he chooses to. Second, I think it'd be better to decouple debugger and editor. For example, I'd like to use this feature without having to use an entire IDE. Wouldn't it be great to have a free choice what components to use? Of course, that's only theory. In practice, it's simpler to built on an existing framework, GUI, and so on. And Ary is actually in favor of the fat-IDE-approach. I mean, that's fine, I don't expect him to change anything about this and I respect his opinion.
 In all seriousness, I hate IDEs because they are big, slow, and waste
 vast tracts of prime monitor space.  But I'm willing to put up with that
 for Descent's compile-time view and (hopefully soon) compile-time debugging.
 
 If I could get that in a super fast, light programming editor, I'd use
 that instead.  But I can't.
As I said, I don't like all-in-one components. Except if it's really a holy grail of an IDE (by definition, everything would be perfect). But yeah, you can't have that. Thus it'd be better to split functionality and features across different pieces of software.
 Although it is annoying when I'm out and about on my little netbook and
 can't use Eclipse.  C'est la vie.
May 22 2009
prev sibling parent reply "Saaa" <empty needmail.com> writes:
 If I could get that in a super fast, light programming editor, I'd use
 that instead.  But I can't.
Wasn't there an effort somewhere to port eclipse to D ?
May 22 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Saaa" <empty needmail.com> wrote in message 
news:gv6qcj$2ckd$1 digitalmars.com...
 If I could get that in a super fast, light programming editor, I'd use
 that instead.  But I can't.
Wasn't there an effort somewhere to port eclipse to D ?
I have no idea, but that does raise an interesting question (maybe one of our resident Eclipse experts can answer it?): If it were ported to D, would that really improve the speed/resource-usage? From various things I've heard, I fear the answer may be "only a little bit" and that it would still need a bunch of extra optimizations (Although despite claims of Java being fast, I would think it still has a big limit in that there's a lot of optimizations that just simply can't be done without a systems language like D).
May 22 2009
parent Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky wrote:
 "Saaa" <empty needmail.com> wrote in message 
 news:gv6qcj$2ckd$1 digitalmars.com...
 If I could get that in a super fast, light programming editor, I'd use
 that instead.  But I can't.
Wasn't there an effort somewhere to port eclipse to D ?
I have no idea, but that does raise an interesting question (maybe one of our resident Eclipse experts can answer it?): If it were ported to D, would that really improve the speed/resource-usage? From various things I've heard, I fear the answer may be "only a little bit" and that it would still need a bunch of extra optimizations (Although despite claims of Java being fast, I would think it still has a big limit in that there's a lot of optimizations that just simply can't be done without a systems language like D).
A direct port of Eclipse to D I would guess to be much SLOWER. Eclipse relies *heavily* on inheritance (Java can inline virtual calls; D can't) and allocating many small objects (something D tests badly in, and Java is particularly well-suited for). There's also a lot of static initialization that would need to be converted to static this() in D. However, in Java, the static stuff is initialized lazily at the first time it's used, while in D, it's all run at startup, even if only 1/5th of it is going to be used. If the codebase were D-ized, it's possible that native code optimizations make it slightly faster (though the shootout shows Java performing nearly as well as C/C++/D for many tasks).
May 22 2009
prev sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Fri, 22 May 2009 20:26:32 +0200, Saaa wrote:

 If I could get that in a super fast, light programming editor, I'd use
 that instead.  But I can't.
Wasn't there an effort somewhere to port eclipse to D ?
Frank has an interest in having Eclipse ported, but nothing has been started that I know of.
May 22 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Ary Borenszweig wrote:

 http://www.youtube.com/watch?v=rtYCFVPfx4M
when is the next release, pretty please? :)
May 21 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig escribió:
 http://www.youtube.com/watch?v=rtYCFVPfx4M
Bah... I just realized debugging that kind of things might be really hart to do. Imagine this: --- char[] something() { return "x *= 3; x += 4;"; } mixin("int bla(int x) { x *= 2; " ~ something ~ " return 4; }"); void main() { const something = bla(2); } --- Now I want to debug the invocation of bla: how the variable x is being modified. But there's no such place in the source code for that definition (well, there is, but it's split in pieces, and obviously you'll get lost when debugging). So I'm starting to think that the compile-time debugger should work on the (formatted) compile-time view of the modules. So you'll end up debugging code like this: --- char[] something() { return "x *= 3; x += 4;"; } int bla(int x) { x *= 2; x *= 3; x += 4; return x; } void main() { const something = bla(2); } --- But that's way more hard to do than what I'm doing right now. Finally, you might want to have both worlds together, like: --- char[] someOtherFunc() { return "char[] x = \"whatever\";"; } char[] someFunc() { mixin(someOtherFunc()); return x; } mixin(someFunc()); --- Now I want to debug someFunc(). But I also want to see that someOtherFunc() is expanded well, so I can't just show the compile-time view of the module, because doing this might have an error already (the error I want to debug, for example!). (and also the compile-time view dependens on the function I'm trying to debug) Aaah... I give up. (I came to this conclusion when trying to debug the scrappes:units project).
May 29 2009
parent BCS <ao pathlink.com> writes:
Reply to Ary,

 (I came to this conclusion when trying to debug the scrapple:units
 project).
 
I'm sorry <g> OTOH that is a rater pathological cases. One option that might be doable (I don't know how the inside works so I'm guessing here) is to have the debug more highlight expression that can undergo CTFE and constant folding. The user would work by selecting an expression and it would be replace with it's value. to make things manageable, long string expressions could be truncated and accessed via pop up and as for string mixins, run the result thought the general code formatter.
Jun 01 2009