date:20091012

Re: dmd support for IDEs

2009-10-12 Thread Don


Nick Sabalausky wrote:
Jeremie Pelletier"  wrote in message 
news:hats2b$as...@digitalmars.com...

Lutger wrote:

Jacob Carlborg wrote:
...

As far as I know neither Qt(d) or gtkD uses native controls on platforms
other than linux, which to me is unacceptable. The look especially on 
mac.
Qt used to try and look like native controls, but now it uses them 
directly.
It has pros and cons, Firefox too has the native look and feel without 
using the native controls, so it saves on the overhead of tons of GDI 
handles and can render the entire GUI in cairo.


I use FF a lot and umm...no it doesn't. Not remotely. It's always stood out 
as every bit of a blatant GTK app as GAIM, GIMP, or Thunderbird. As soon as 
I can find a browser with equivilents too all my essential hacks (*cough* 
extensions) and *real* controls (which rules out IE and Opera. And 
Chrome/Safari... AH HA HA HA!), then I'm ditching this garbage. 


Are you talking about FF 3.5? It's a really poor product. Crashes all 
the time, has some terrible UI misfeatures. I'm really amazed they 
shipped it in that condition.

A safer switch?

2009-10-12 Thread bearophile

This is a pruned method from a command-line Java program:

private static void parseCmdLine(String args[]) {
  int i = 0;
  String arg;
  while (i < args.length && args[i].startsWith("-")) {
arg = args[i++];
if (arg.equals("-s")) {
  if (i < args.length)
size = new Integer(args[i++]).intValue();
  else
throw new Error("-l ...");
} else if (arg.equals("-m")) {
  printMsgs = true;
} else if (arg.equals("-p")) {
  printResults = true;
} else if (arg.equals("-h")) {
  usage();
}
  }
  if (size == 0) usage();
}


I may translate part of that to D like this:

switch (arg) {
case "-s":
if (idx < args.length)
size = toInt(args[idx++]);
else
throw new Exception("...");
break;
case "-m":
printMessages = true;
break;
case "-p":
printResults = true;
break;
case "-h":
showUsage();
default:
showUsage();
throw new Exception("...");
}

But the "-h" case misses a break. Languages like C# have found a way to avoid 
(in most cases) that common bug. D may use some like this:

switch (arg) {
case("-s") {
try {
  next_arg = iargs.next();
  size = toInt(args[idx++]);
} catch (...) {
throw new Exception("...");
}
}
case("-m") {
printMessages = true;
}
case("-p") // just 1 istruction, no {} needed
printResults = true;
case("-h"); // semicolon isn't allowed here
showUsage();
default { // default case may need some care
throw new Exception("...");
}
}

Mixing "case:" and "case()" in the same switch is not allowed, to keep things 
tidy.

"break" is implicit. You can add "continue" if you want to step to the 
following case. If you put the switch inside a loop, the continue is relative 
to the switch and not the loop. So if you want to continue the loop you need a 
"continue LABEL;" where the LABEL if before the loop.

Bye,
bearophile

Re: A safer switch? + abbreviation of member names in enum switches

2009-10-12 Thread Justin Johansson

bearophile Wrote:

> This is a pruned method from a command-line Java program:
> 
> private static void parseCmdLine(String args[]) {
>...
> }
> 
> 
> I may translate part of that to D like this:
> 
> switch (arg) {
>...
> }
> 
> But the "-h" case misses a break. Languages like C# have found a way to avoid 
> (in most cases) that common bug. D may use some like this:
> ...


(Sorry bearophile, don't mean to steal your thunder but since I'm writing some 
D1 switch code right now, I may as well strike while the iron is still hot ...)

Speaking of switch statements, when switching on an enum type, e.g.

enum Color {
   RED,
   GREEN,
   BLUE
}

void foo( Color color) {
   switch (color) {
   case Color.RED:
  break;
   case Color.GREEN:
  break;
   case Color.BLUE:
  break;
   }
}

Would it be possible for the compiler to infer the declared enum type, in this 
case Color, making for abbreviation of the enum member names in the case 
clauses as per the following?

void bar( Color color) {
   switch (color) {
   case RED:
  break;
   case GREEN:
  break;
   case BLUE:
  break;
   }
}


Koala hugs,

-- Justin Johansson

Re: dmd support for IDEs

2009-10-12 Thread language_fan

Sun, 11 Oct 2009 09:39:32 -0500, Ellery Newcomer thusly wrote:

> Denis Koroskin wrote:
>> On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright
>>  wrote:
>> 
>> If anyone is interested and is willing to test and/or help, I will
>> gladly share my code.
> 
> Oooo.. You should put that on dsource or somewhere. Hacking D sounds
> like a lot more fun than hacking C++. I wouldn't mind helping out on
> this one.

Wow, I am pretty sure I have already seen a D port of dmd on dsource. Was 
there a good reason to start yet another port of it?

Re: dmd support for IDEs

2009-10-12 Thread language_fan

Sun, 11 Oct 2009 12:44:08 -0400, Jeremie Pelletier thusly wrote:

> language_fan wrote:
>> Well since there is already a project working on an Eclipse plugin, I
>> see little use for other IDEs at the moment. The D community is rather
>> small and only a small amount of people are capable of developing and
>> willing to donate their free time on free IDE development (commercial
>> IDEs have small potential now that
>> Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio dominate the market).
>> So why not concentrate on fixing the spec and fixing compiler bugs
>> instead of building a modest IDE support no one will use?
> 
> Eclipse is heavy, slow and often unresponsive. I use poseidon myself
> because it is light and fast and I don't require much more from an IDE
> at the moment.

If you turn off all the advanced features of Eclipse (spell checking, 
interactive parsing & type checking etc), it will become a lot more 
responsive. You can even uninstall many of the plugins if you really do 
not need them. I recommend firing up the latest development build with 
the latest 1.6 jvm. It will take couple of seconds for the JIT to spot 
the hot spots after starting up. Of course Poseidon is faster *now* that 
it lacks all the advanced features, but once you start adding more, it 
will eventually grind to a halt.

Re: A safer switch? + abbreviation of member names in enum switches

2009-10-12 Thread bearophile

Justin Johansson:

> Would it be possible for the compiler to infer the declared enum type, in 
> this case Color, making for abbreviation of the enum member names in the case 
> clauses as per the following?
> 
> void bar( Color color) {
>switch (color) {
>case RED:
>   break;
>case GREEN:
>   break;
>case BLUE:
>   break;
>}
> }

That's a special case, with the purpose of shortening code a little. So while 
writing Color.something isn't handy, it safe and it has no special casing. So I 
don't like your idea a lot.

Related: I have compiled your code with D1 with warnings (-w):

enum Color {
RED,
GREEN,
BLUE
}

void foo(Color color) {
switch (color) {
case Color.RED:
break;
case Color.GREEN:
break;
case Color.BLUE:
break;
}
}

void main() {}

It prints:
warning - test.d(8): Error: switch statement has no default
warning - test.d(8): Error: statement is not reachable

But there's no need for default there because all enum cases are covered. So 
that warning test has to be improved.

Bye,
bearophile

Re: A safer switch?

2009-10-12 Thread Vladimir Panteleev

On Mon, 12 Oct 2009 11:03:13 +0300, bearophile   
wrote:



This is a pruned method from a command-line Java program:


(snip)

This was discussed before. IIRC, someone suggested to force using a  
control-flow keyword (break/continue/goto) at the end of a case. Using  
"continue" to fall through was rejected because it changes its meaning  
when there's a switch in a loop. You'd use goto  to jump to the  
particular (next) switch case.


--
Best regards,
 Vladimir  mailto:thecybersha...@gmail.com

Re: dmd support for IDEs

2009-10-12 Thread Michal Minich




Eclipse is heavy, slow and often unresponsive. I use poseidon myself
because it is light and fast and I don't require much more from an
IDE at the moment.


You can try to download just bare Eclipse platform (which is just text editor) 
and install descent into it using Eclipse software updates. It starts up 
faster than C or Java version Eclipse and there is only D related stuff in 
the UI.


http://download.eclipse.org/eclipse/downloads/drops/R-3.5.1-200909170800/index.php
Under "Platform runtime binary"

Re: dmd support for IDEs

2009-10-12 Thread breezes

Ary Borenszweig Wrote:

> Walter Bright wrote:
> > In my discussions with companies about adopting D, the major barrier 
> > that comes up over and over isn't Tango vs Phobos, dmd being GPL, 
> > debugger support, libraries, bugs, etc., although those are important.
> > 
> > It's the IDE.
> > 
> > So, while I'm not going to be writing an IDE, I figure that dmd can 
> > help. dmd already puts out .doc and .di files. How about putting out an 
> > xml file giving all the information needed for an IDE to implement 
> > autocompletion? There'd be one .xml file generated per .d source file.
> > 
> > What do you think?
> 
> What I think is that even with an xml representing the parse tree (maybe 
> with some semantic stuff resolved) it'll be still incomplete for a real 
> IDE (the kind of thing users expect from an IDE). You can see this 
> video, for example:
> 
> http://www.youtube.com/watch?v=KQbTT605ags
> 
> So you have:
> 
> ---
> module one;
> 
> class Foo(T) {
>static if (is(T == class)) {
>  T property;
>} else {
>  T someMethod() { return T.init; }
>}
>mixin(guessWhat!(T)());
> }
> ---
> 
> You want to define an xml for that module that'll help IDEs. Can you 
> think what it'll look like?
> 
> Now the user writes in another module:
> 
> class Bar {
> }
> 
> void x() {
>auto foo = new Foo!(Bar)();
>foo. <-- what does the IDE do here?
> }
> 
> Now, the correct thing for the IDE to do is to suggest the field "Bar 
> property". How can the IDE do that just with an xml? It can't. It need 
> to perform some kind of semantic anlysis to Foo's argument to see if 
> it's a class, match the static if in the template, replace template 
> parameters, etc. It also needs to evaluate the string mixin.
> 
> Of course you could say "Bah, just show all the declarations inside the 
> template in the autocomplete", but that's wrong. That'll lead to files 
> that don't compile. You could ommit supporting autocompletion or other 
> nice features, but that's exactly the big features of D. If you don't 
> support that then it's like using Java or C# from within the IDE: you 
> could use the advanced features but the IDE won't help you. And in your 
> discussions with companies adopting D, I'm sure they were talking about 
> great IDEs like JDT Eclipse or Visual Studio, not just some tool that 
> helps you a little but not anymore when things get interesting.
> 
> Oh, and you need to have some kind of semantic analysis to know the type 
> of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new 
> Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:
> 
> auto b = foo.property;
> b. <-- and here?
> // remember "property" is templated and depends on static analysis
> // or the IDE could need to resolve alias this or other things
> 
> So... my opinion (like some others, I see) is to either ask things to 
> the compiler directly (but here the compiler lacks some info, like exact 
> source range positions), or to have a compiler (not a full-blown one, 
> just the front-end) built into the IDE, and that's what Descent is. 
> Unfortunately Descent is sometimes slow, sometimes buggy, but that's 
> normal: just a few people develop and maintain it (so I can see a 
> similarity with dmd here, where each day I see two or three new bugs 
> reported). If more people were into it, more unit tests were written 
> into it and, most of all, more people would use it, it'll get better.
> 
> Another problem that people see in Descent (maybe also JDT Eclipse and 
> Visual Studio0 is that it's huge, it consumes a lot of memory and they 
> don't want to open a huge tool just to hack some lines. My answer is: 
> memory performance can be improved (but not a lot), but since an IDE is 
> a huge tool it requires a lof from the computer. And an IDE is not meant 
> to be used to hack some lines, it's meant to help you write big project, 
> huge projects without getting lost in the amount of code.
> 
> So my bet would be to start supporting an existing IDE that integrates a 
> compiler into it. Updating it is easy: just port the diffs between DMD 
> versions. It's a huge job for one or two people, but if a lot of people 
> were involved it's not that much. Of course I'd recommend you to try 
> Descent since I'm one of it's creators and I do believe it can get 
> pretty good. :-)

A lot of people like me have been waiting for a good IDE for D for a long time. 
In the field of IDE of D, Descent has already have a good baseline. So I think 
the community should put more effort in make Descent better, other than create 
another IDE. 

For this reason, I think Ary Borenszweig's opinion on in which way can dmd help 
in building a better IDE may be more valuable than Water's, for he is the 
author of the currently most advanced IDE of D.

Sorry for my poor English.

Re: CTFE vs. traditional metaprogramming

2009-10-12 Thread Don


language_fan wrote:

Sat, 10 Oct 2009 10:30:31 +0200, Don thusly wrote:


The more fundamental problem is that you can't
instantiate a template from inside CTFE. IE, you can cross from the
"compile-time world" to the "runtime world" only once -- you can never
get back.


That's not exactly true. Also both templates and CTFE are compile time 
features. You can compute a value with CTFE in the "value world" and lift 
the result to the "type world" with a template.


Yes, but the problem is that variables inside a CTFE function, even 
though they are known at compile-time, are not permitted to be used as 
template value parameters. For example:


template A(int X) { enum int A = B(X)+1; } // OK, template can call CTFE

int B(int X) { return A!(X) + 1; }
// Not OK, CTFE cannot call template.

Re: dmd support for IDEs

2009-10-12 Thread language_fan

Sun, 11 Oct 2009 16:07:44 -0300, Leandro Lucarella thusly wrote:

> Walter Bright, el 10 de octubre a las 18:19 me escribiste:
>> In my discussions with companies about adopting D, the major barrier
>> that comes up over and over isn't Tango vs Phobos, dmd being GPL,
>> debugger support, libraries, bugs, etc., although those are important.
>> 
>> It's the IDE.
>> 
>> They say that the productivity gains of D's improvements are
>> overbalanced by the loss of productivity by moving away from an IDE.
>> And what is it about an IDE that is so productive? Intellisense
>> (Microsoft's word for autocompletion).
> 
> I think you've got that answer because they are not using D alread. When
> they start using D, they will start complaining about Phobos vs. Tango,
> debugger support, librararies, bugs, etc. ;) (maybe not DMD being GPL
> though, even when I think it's important).

What can I say, the larger the enterprise, the larger the expectations 
and need for stability. You can try it yourself, any Java 1.4 code from 
2003 can be compiled, debugged, profiled etc. nicely with the most recent 
version of jdk and 3rd party tools. It's also nicely compatible with new 
code. OTOH take some D 1.0 code from 2003 (e.g. the free dool/dui or aba 
games code available online) and try to do *something* with it. Basically 
nothing works. You even have problems with new code as some project 
depends on a specific svn version of tango trunk. There is a lot to be 
done before D is ready for large scale enterprise use.

Re: dmd support for IDEs

2009-10-12 Thread language_fan

Sun, 11 Oct 2009 17:01:03 -0400, Nick Sabalausky thusly wrote:

> "language_fan"  wrote in message
> news:hasd5u$1fg...@digitalmars.com...
>>
>> Well since there is already a project working on an Eclipse plugin, I
>> see little use for other IDEs at the moment. The D community is rather
>> small and only a small amount of people are capable of developing and
>> willing to donate their free time on free IDE development (commercial
>> IDEs have small potential now that
>> Netbeans/Eclipse/IntelliJ/KDevelop/Visual Studio dominate the market).
>> So why not concentrate on fixing the spec and fixing compiler bugs
>> instead of building a modest IDE support no one will use?
> 
> Any editor that is less responsive than notepad is useless to me, and
> I'm far from alone on that. Thus, we don't go anywhere near Eclipse,
> VS.NET, or anything along those lines (bunch of bloated garbage...and
> probably designed to get developers to buy fancier hardware and thus end
> up develop apps that require their users to buy fancier hardware).

Fine, if you are happy with your productivity. For me it was a natural 
choice. I started with notepad like editors, then moved to "programmer's 
editors" like crimson editor and jedit, soon discovered vim and emacs, 
and finally have settled down on Eclipse, Netbeans, Visual Studio, and 
IntelliJ IDEA. The productivity boost is enormous. "Practical" languages 
have lots of boiler-plate, and I can easily generate hundreds of lines of 
code with a couple of key combinations or mouse clicks. Another killer 
feature is the "intellisense" stuff. Having the ability to see a) 
inferred type b) integrated html rendered javadoc c) type correct class 
members etc. saves me hours of work time per day. YMMV

Re: Geek of the week

2009-10-12 Thread Tim Matthews

bearophile wrote:

Just a note:

What are the application areas that D targets? WB: In short, any application that
would otherwise use C or C++ would be suitable for D.<

That may become true in future, but it can't be true now. If I buy an Arduino,
or a little 16 bit CPU that has to go inside a cheap microwave oven, I usually
have to program it in C, Forth (or worse). I can't use D for that. Currently D
is not fit for the world of small real-time CPUs. And embedded CPUs are very
common, for every desktop (and handheld) CPU produced, 10 or 100 small CPUs for
embedded purposes are produced.

But there are possible ways to make D fitter for those purposes. For example it may be designed a "lightD", a subset of D (that has no built-in AAs, that uses no GC, etc), and adds several tricks/constructs useful when your available RAM is 1200 bytes long and your available ROM (well, flash, or a different slower kind of RAM) is 3 bytes. In such situations a compiler is even asked to produce not just the faster or shorter binary, but sometimes even the less energy consuming one! (think about a -Oe compilation flag, beside the -O and the -Os). Or maybe D will never fit for such purposes.

I wouldn't want the language to be too different though. Maybe a subset
runtime (with gc off by default) + std lib though (subset of existing
and not really a third choice of library). Call just about anything in
tango and you get an allocation, no explicit delete and an assumption
that the GC will take care of it eventually.

Aswell as the embedded, regular operating systems are a big area of
C/C++. This should be an easier fit for D but all D kernel/os projects
have probably been abandoned.

1 2 3 >

1 - 100 of 212 matches

Mail list logo