Re: dmd json file output
On 21.01.2013 08:27, Walter Bright wrote:
The current version is pretty verbose. For:
int ***x;
it will emit as the type:
"type" : {
"kind" : "pointer",
"pretty" : "int***",
"targetType" : {
"kind" : "pointer",
"pretty" : "int**",
"targetType" : {
"kind" : "pointer",
"pretty" : "int*",
"targetType" : {
"kind" : "int",
"pretty" : "int"
}
}
}
}
I find this to be excessive, and it helps to produce truly gigantic
.json files. I think it's better to just put out the deco for the type:
"type" : "PPPi"
But, you might say, that is not user friendly! Nope, it isn't. But the
.json output is for a machine to read, not humans, and the deco types
are very space efficient, and are trivial to convert to whatever data
structure the reader needs. Much easier than the verbose thing.
What do you think?
I agree the verbose output is overkill.
Considering that the demangling in druntime still has a number of open
issues (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=3034,
http://d.puremagic.com/issues/show_bug.cgi?id=6045) and that there are
ambiguities in the name mangling (e.g.
http://d.puremagic.com/issues/show_bug.cgi?id=5957,
http://d.puremagic.com/issues/show_bug.cgi?id=4268), my first reaction
was that it might be better to provide a function to parse the pretty
type. It is not too difficult and would be a nice start for the
lexer/parser topic, but might be burdened with new bugs.
Considering function types, the deco does not contain any function
argument identifiers anymore, but these are very useful for tooltips in
an IDE like Visual D.
As a compromise, the type chould just contain the mangled and the pretty
name:
> "type" : {
> "mangled" : "PPPi",
> "pretty" : "int***",
> }
Re: Internal and external iteration, fibers
On 01/21/2013 08:00 PM, Nick Sabalausky wrote: On Mon, 21 Jan 2013 11:48:58 +0100 "deadalnix" wrote: ... Why can't this be done in D ? What are the major problems ? I don't know whether or not it can be done in D. ... Why not? I have essentially done it and posted it here. Also, there is nothing feasible that 'cannot be done' in D, because D can host arbitrarily complex embedded languages.
Re: dmd json file output
Am 22.01.2013 09:02, schrieb Rainer Schuetze: > > Considering function types, the deco does not contain any function argument > identifiers anymore, but > these are very useful for tooltips in an IDE like Visual D. > I thought so, too. But considering that types are always subject to this problem: --- alias StateCallback = void function(int state); static assert(StateCallback.stringof == "void function(int state)"); alias IndexCallback = void function(int index); static assert(IndexCallback.stringof == "void function(int state)"); // still "state" --- ... it may be better to not even make it possible to fall into this trap by excluding them. Except if I'm wrong and the JSON output happens at an earlier stage where the parameter name information is still tagged to the declaration, of course.
Trust about D programming.
Hello Folks. How are you? Excuse me, I need a trust about D programming and C, In your opinion D can be a replace for C? Why a user should use D? Please let me know your opinion. Thank you. Cheers.
Re: D popularity
On 2013-01-22 04:57, Andrei Alexandrescu wrote: LaTeX. Isn't that a failure of ddoc. Wasn't ddoc supposed to be independent of the output format. If we're only using ddoc to generate the HTML documentation it seems it's not good enough. This is not a big issue. I mostly care about the HTML docs. -- /Jacob Carlborg
Why D is created?
Why D programming language is created and what is the most features?
Re: D popularity
On 01/22/2013 10:46 AM, Jacob Carlborg wrote: On 2013-01-22 04:57, Andrei Alexandrescu wrote: LaTeX. Isn't that a failure of ddoc. Wasn't ddoc supposed to be independent of the output format. If we're only using ddoc to generate the HTML documentation it seems it's not good enough. This is not a big issue. I mostly care about the HTML docs. It is ddoc -> LaTeX -> pdf.
Re: Why D is created?
Am 22.01.2013 10:53, schrieb MMj: Why D programming language is created and what is the most features? what is your background - C/C++? read the language specs on dlang.org to get a feeling about reasons for creation and features
Re: Why D is created?
On Tuesday, 22 January 2013 at 10:14:52 UTC, dennis luehring wrote: Am 22.01.2013 10:53, schrieb MMj: Why D programming language is created and what is the most features? what is your background - C/C++? read the language specs on dlang.org to get a feeling about reasons for creation and features Hello Dennis. Thanks very much for your guidance. Yes I'm a C\C++ programmer. Are you an expert in D? Why you thought C\C++ not good?
Re: Why D is created?
On Tuesday, 22 January 2013 at 10:20:57 UTC, MMj wrote: Hello Dennis. Thanks very much for your guidance. Yes I'm a C\C++ programmer. Are you an expert in D? Why you thought C\C++ not good? Wow, are we looking at C++ programmer who considers C++ good? :)
Re: Why D is created?
Am 22.01.2013 11:27, schrieb mist: > On Tuesday, 22 January 2013 at 10:20:57 UTC, MMj wrote: >> >> Hello Dennis. >> Thanks very much for your guidance. >> Yes I'm a C\C++ programmer. Are you an expert in D? Why you thought >> C\C++ not good? > > Wow, are we looking at C++ programmer who considers C++ good? :) There are a few incorrigible C++ programmers out there :P
Re: Why D is created?
On Tuesday, 22 January 2013 at 09:53:50 UTC, MMj wrote: Why D programming language is created and what is the most features? Please, read this: http://www.amazon.com/exec/obidos/ASIN/0321635361/classicempire It will change the way you see programming.
randomSample does not accept char[]
Hi everyone,
can you explain me why this code DOES compile:
/*---*/
import std.range, std.random;
void main()
{
int[] vowels = ['A', 'E', 'I', 'O', 'U'];
static assert(isInputRange!(typeof(vowels)));
auto x = randomSample(vowels, 1);
}
/*---*/
but this DOES NOT:
/*---*/
import std.range, std.random;
void main()
{
char[] vowels = ['A', 'E', 'I', 'O', 'U'];
static assert(isInputRange!(typeof(vowels))); //pass
auto x = randomSample(vowels, 1); //fail
}
/*---*/
main.d(6): Error: template std.random.randomSample(R) if
(isInputRange!(R)) does not match any function template
declaration
main.d(6): Error: template std.random.randomSample(R) if
(isInputRange!(R)) cannot deduce template function from argument
types !()(char[],int)
Re: D popularity
On 2013-01-22 11:04, Timon Gehr wrote: It is ddoc -> LaTeX -> pdf. Ok, I guess it's easier to go through LaTeX than directly to PDF. -- /Jacob Carlborg
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote: Hello Folks. How are you? Excuse me, I need a trust about D programming and C, In your opinion D can be a replace for C? Why a user should use D? Please let me know your opinion. Thank you. Cheers. It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out.
Re: randomSample does not accept char[]
Short answer: unicode Long answer is here: http://dlang.org/phobos/std_range.html#.hasLength , please pay attention to narrow string paragraph. (failed constraint is hasLength!char[]) int is >= dchar so no issues for int.
Re: randomSample does not accept char[]
On 01/22/2013 11:42 AM, andrea9940 wrote:
Hi everyone,
can you explain me why this code DOES compile:
/*---*/
import std.range, std.random;
void main()
{
int[] vowels = ['A', 'E', 'I', 'O', 'U'];
static assert(isInputRange!(typeof(vowels)));
auto x = randomSample(vowels, 1);
}
/*---*/
but this DOES NOT:
/*---*/
import std.range, std.random;
void main()
{
char[] vowels = ['A', 'E', 'I', 'O', 'U'];
static assert(isInputRange!(typeof(vowels))); //pass
auto x = randomSample(vowels, 1); //fail
}
/*---*/
main.d(6): Error: template std.random.randomSample(R) if
(isInputRange!(R)) does not match any function template declaration
main.d(6): Error: template std.random.randomSample(R) if
(isInputRange!(R)) cannot deduce template function from argument types
!()(char[],int)
Use randomSample(vowels, 1, vowels.length); to make it work.
The error message is bad.
You are trying to call the following overload:
auto randomSample(R)(R r, size_t n)
if(isInputRange!R && hasLength!R)
{
return RandomSample!(R, void)(r, n, r.length);
}
hasLength!(char[]) is false. This is because Phobos considers char[],
const(char)[] and immutable(char)[] ranges of dchar.
Re: randomSample does not accept char[]
On Tuesday, 22 January 2013 at 10:53:16 UTC, mist wrote: Short answer: unicode Long answer is here: http://dlang.org/phobos/std_range.html#.hasLength , please pay attention to narrow string paragraph. (failed constraint is hasLength!char[]) int is >= dchar so no issues for int. Thanks !
Re: randomSample does not accept char[]
This is a good hint, by the way, that something needs to be done about constraint error messages or we are risk to fallback to C++ world of pretty template library errors. I usually just go straight to template sources to save some time but that is hardly expected from a newcomer.
Re: Internal and external iteration, fibers
"Jacob Carlborg" wrote in message news:kdlfhr$1676$1...@digitalmars.com... > Would that be so bad idea, to have a fixed AST representation? The AST > presented for the user doesn't need to be the same as the compiler uses > internally. > > It's the same as any library function. You can easily change the > implementation as long as the signature and behavior is the same. > > -- > /Jacob Carlborg It depends how much information is in the AST you give the user. Just syntax? Types? Full semantic information? Of course you can transform the internal AST to the user AST, but the more information the closer this gets to forcing the compiler to use the user AST, or support two ASTs internally.
Some dynamic dispatch to reduce template bloat
This "Dynamic dispatch" section of the Clay language documentation shows a way to avoid some template bloat (that is common in Clay): https://github.com/jckarter/clay/wiki/Avoiding-generic-programming-pitfalls Maybe it's possible to make that syntax&code shorter and lighter. Bye, bearophile
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote: On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote: Hello Folks. How are you? Excuse me, I need a trust about D programming and C, In your opinion D can be a replace for C? Why a user should use D? Please let me know your opinion. Thank you. Cheers. It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out. I saw D wiki and understand some goals about but Can you tell me why you choose D and not C?
Re: Some dynamic dispatch to reduce template bloat
On Tuesday, 22 January 2013 at 11:09:05 UTC, bearophile wrote: This "Dynamic dispatch" section of the Clay language documentation shows a way to avoid some template bloat (that is common in Clay): https://github.com/jckarter/clay/wiki/Avoiding-generic-programming-pitfalls Maybe it's possible to make that syntax&code shorter and lighter. Bye, bearophile May be I do not get it, but this can already be done in D. There is always a trade-off between template binary bloat and performance penalty of dynamic typing and suggested approach (make a templated light interface and code most function using dynamic typing) is not that uncommon one even in C++ world.
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 11:17:32 UTC, MMj wrote: On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote: On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote: Hello Folks. How are you? Excuse me, I need a trust about D programming and C, In your opinion D can be a replace for C? Why a user should use D? Please let me know your opinion. Thank you. Cheers. It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out. I saw D wiki and understand some goals about but Can you tell me why you choose D and not C? From my perspective, D cannot replace C in sense "you can throw C away". Well, maybe it could theoretically, but not practically. But the trend is C is becoming more and more a high-level assembler. Things like mapping to a register, no hidden costs, "you can basically see the assembler when programming in C". So programming OS kernels and stuff is very practical in C. I guess C++ could replace C in a sense "you can throw C away" in foreseeable future. Because, essentially C++ is a better C than C. It might go this way or not, but the potential is good enough. Things in D are kind of upside down. It places itself close to C++, but if C++ looks towards C from that position, D looks towards Java/C#. It makes it very appealing for "productive" (in Java sense) and "efficient" (in C sense) systems programming. E.g. right know, I think D is very compelling for writing a server (vibe.d would be a good example). But for embedded programming I don't think D is a good practical choice. C and C++ shines there and I don't think things are changing soon.
Re: Trust about D programming.
Well I could name slicing and meta programming (templates, traits, mixins). But in reality it is more the feel of the language. It is easy to read, (in D I even understand programs written by other people!), it is powerful. Due to its meta programming techniques it has much of the power typically only found in dynamically typed languages, but with the safety and speed of compiled, statically typed language. Typically when a language becomes powerful, it also becomes complex and hard to learn, I think D did a really good job in being one of the most powerful languages out there but still being "easy" to learn and understand, in particular easy to read. The concepts are sound and well thought of. It is fun to use it. The down side is, that it is far less mature than C or C++. One of the things that convinced me, was slices and the way the GC is put to good use. Things that make me stick to it, are the meta programming capabilities, its power and its design. Best regards, Robert On Tue, 2013-01-22 at 12:17 +0100, MMj wrote: > On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote: > > On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote: > >> Hello Folks. > >> How are you? > >> Excuse me, I need a trust about D programming and C, In your > >> opinion D can be a replace for C? > >> Why a user should use D? > >> Please let me know your opinion. > >> > >> Thank you. > >> Cheers. > > > > It really depend on what you try to achieve. But in many case > > it is a viable alternative. In other, things need to be ironed > > out. > > I saw D wiki and understand some goals about but Can you tell me > why you choose D and not C?
Re: Why D is created?
Am 22.01.2013 11:20, schrieb MMj: On Tuesday, 22 January 2013 at 10:14:52 UTC, dennis luehring wrote: Am 22.01.2013 10:53, schrieb MMj: Why D programming language is created and what is the most features? what is your background - C/C++? read the language specs on dlang.org to get a feeling about reasons for creation and features Hello Dennis. Thanks very much for your guidance. Yes I'm a C\C++ programmer. Are you an expert in D? Why you thought C\C++ not good? you know its weakness if you're an experienced C/C++ developer - D is just more expressive in template,generic programming, combining procedural,oop,and functional programming etc. in short a very clean C++ (nearly) without its weakness-es but beware D isn't better than C++ just because of its standard librarie - its not like Java or C# were you got a hell of helper classes around why are you looking at D? did you reach the end of your C++ journey - used STL, Boost to the end and want to see whats beat that in quality :)
Re: Memory corruption bug in struct dtor
On Friday, 18 January 2013 at 20:14:23 UTC, H. S. Teoh wrote: http://d.puremagic.com/issues/show_bug.cgi?id=9352 Seems like dtors are a minefield of hidden and dangerous bugs, Yes. It's one of the worst areas. Postblit as well. due to them not being used (and therefore tested) very often. :-/ Not really. It's because it's an intrinsically difficult concept. The destructor is called at end-of-life of the struct. This means that in every possible part of the language, you have to know what the end-of-life is. So interaction with other parts of the language is inevitable, there's an explosion of special cases. (By contrast, something like 'pure' is a very simple language feature: you just need to iterate over all the code that's marked pure, and generate an error if you find anything that isn't pure).
Re: Trust about D programming.
On 22 January 2013 11:17, MMj wrote: > On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote: > >> On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote: >> >>> Hello Folks. >>> How are you? >>> Excuse me, I need a trust about D programming and C, In your opinion D >>> can be a replace for C? >>> Why a user should use D? >>> Please let me know your opinion. >>> >>> Thank you. >>> Cheers. >>> >> >> It really depend on what you try to achieve. But in many case it is a >> viable alternative. In other, things need to be ironed out. >> > > I saw D wiki and understand some goals about but Can you tell me why you > choose D and not C? > I choose D for safety and speed. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: D popularity
Wow! :-) Thanks for this link. This is so much better! :-) Best regards, Robert > > Check out the new experimental on-line documentation. > http://vibed.org/temp/d-programming-language.org/phobos/std/range.html > > You can put in user comments too. > > Still not as good as it can be, but it's a big improvement over > the existing documentation. > > The important thing is that D seems to always be improving, and > the community is very active. > > --rt
Re: Some dynamic dispatch to reduce template bloat
mist: this can already be done in D. Of course. But that link is a starting point to invent a possible syntax sugar. Sometimes some sugar makes the difference from nearly never using a feature, and using it when it's useful. There is always a trade-off between template binary bloat and performance penalty of dynamic typing Right. A flexible language allows you to chose case by case (with a default, when you don't care). Bye, bearophile
Re: Memory corruption bug in struct dtor
Don: (By contrast, something like 'pure' is a very simple language feature: you just need to iterate over all the code that's marked pure, and generate an error if you find anything that isn't pure). D "pure" has required several iterations, and the design of its details is not finished yet (see Bugzilla)... Bye, bearophile
Re: Internal and external iteration, fibers
On 2013-01-22 12:00, Daniel Murphy wrote: It depends how much information is in the AST you give the user. Just syntax? Types? Full semantic information? Of course you can transform the internal AST to the user AST, but the more information the closer this gets to forcing the compiler to use the user AST, or support two ASTs internally. I watched a talk about AST macros in Scala. He said it was a fairly small change to the compiler to implement. Around 1k lines of code. The AST introspection was already there in the form of runtime reflection. I don't expect it to be as easy to do in DMD. Although Don has said it would be pretty easy to expose the internal AST to the user. -- /Jacob Carlborg
Re: Internal and external iteration, fibers
On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote: On Tue, Jan 22, 2013 at 2:55 AM, deadalnix wrote: On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote: I know people don't like it but I have to say, this seems it could be a job for AST macros. I was thinking the same thing, but don't wanted to bug people. Indeed, it is the perfect job for AST macro. I can concur now that you mentioned it xD Would any of you be so kind as to propose another definition for AST macros here ? http://wiki.dlang.org/Commonly-Used_Acronyms AST macros is CTFE done right :)
Re: Some dynamic dispatch to reduce template bloat
What syntax sugar do you propose? There is hardly anything in the link that can't be done with current std.variant.Algebraic at first glance. Only stuff I can think of is some convenient way to retrieve strongly typed value from Algebraic back, but that is library update, nothing to do about language syntax.
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote: On Tuesday, 22 January 2013 at 11:17:32 UTC, MMj wrote: On Tuesday, 22 January 2013 at 10:45:27 UTC, deadalnix wrote: On Tuesday, 22 January 2013 at 09:27:22 UTC, MMj wrote: Hello Folks. How are you? Excuse me, I need a trust about D programming and C, In your opinion D can be a replace for C? Why a user should use D? Please let me know your opinion. Thank you. Cheers. It really depend on what you try to achieve. But in many case it is a viable alternative. In other, things need to be ironed out. I saw D wiki and understand some goals about but Can you tell me why you choose D and not C? From my perspective, D cannot replace C in sense "you can throw C away". Well, maybe it could theoretically, but not practically. But the trend is C is becoming more and more a high-level assembler. Things like mapping to a register, no hidden costs, "you can basically see the assembler when programming in C". This is only true in very simple processor architectures. In modern optimizing C compilers targeting modern CPUs, C no longer maps to the hardware as much as many C coders still think it does. -- Paulo
Re: Internal and external iteration, fibers
On Tuesday, 22 January 2013 at 12:14:26 UTC, Max Samukha wrote: On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote: On Tue, Jan 22, 2013 at 2:55 AM, deadalnix wrote: On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote: I know people don't like it but I have to say, this seems it could be a job for AST macros. I was thinking the same thing, but don't wanted to bug people. Indeed, it is the perfect job for AST macro. I can concur now that you mentioned it xD Would any of you be so kind as to propose another definition for AST macros here ? http://wiki.dlang.org/Commonly-Used_Acronyms AST macros is CTFE done right :) That is completely nonsensial.
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote: But for embedded programming I don't think D is a good practical choice. C and C++ shines there and I don't think things are changing soon. It would be a shame if D would be PC-only... Maybe when GDC will be ready things will change - who knows... Apart from the garbage collector, which really is not embedded-friendly (I'm talking about kilobytes of RAM, not megabytes) everything sounds quite OK in the specs (; 4\/3!!
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 13:36:15 UTC, Freddie Chopin wrote: On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote: But for embedded programming I don't think D is a good practical choice. C and C++ shines there and I don't think things are changing soon. It would be a shame if D would be PC-only... Maybe when GDC will be ready things will change - who knows... Apart from the garbage collector, which really is not embedded-friendly (I'm talking about kilobytes of RAM, not megabytes) everything sounds quite OK in the specs (; 4\/3!! What is the problem with gdc ? I used to use it for ages.
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 13:37:38 UTC, deadalnix wrote: What is the problem with gdc ? I used to use it for ages. Have you tried compiling it for something like bare-metal ARM (arm-none-eabi target)? Check the thread about embedded D in the GDC (D.GNU) forum to see what problems exist when you want to compile that for an OS-less target that doesn't provide hundreds of POSIX functions. Do note that embedded does not mean "smartphone with Android". When GDC will be part of GCC a proper support for other platforms will probably appear, not only for PC with Windows/Linux/MacOS. 4\/3!!
Re: Trust about D programming.
On 22 January 2013 13:43, Freddie Chopin wrote: > On Tuesday, 22 January 2013 at 13:37:38 UTC, deadalnix wrote: > >> What is the problem with gdc ? I used to use it for ages. >> > > Have you tried compiling it for something like bare-metal ARM > (arm-none-eabi target)? Check the thread about embedded D in the GDC > (D.GNU) forum to see what problems exist when you want to compile that for > an OS-less target that doesn't provide hundreds of POSIX functions. > > Do note that embedded does not mean "smartphone with Android". > > When GDC will be part of GCC a proper support for other platforms will > probably appear, not only for PC with Windows/Linux/MacOS. > > 4\/3!! > That's a common misconception. Other platform support are already appearing (ARM, MIPS, PPC), it just requires users who have the hardware and knowledge to port the D runtime over. Regards, -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
[OT] Walter about compilers
Hi everybody, I was just reading this: http://www.laputan.org/metamorphosis/metamorphosis.html#SoftwareTectonics (a thing about software architectures). The text opens with...: "We like it when people always want more! Otherwise, we'd be out of the upgrade business. Sometimes, people ask me what I will do when the compiler is done. Done? No software program that is selling is ever done! -- Walter Bright, C++ compiler architect" So... the question is: does that quote also applies for dmd? :)
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 13:50:51 UTC, Iain Buclaw wrote: That's a common misconception. Other platform support are already appearing (ARM, MIPS, PPC), it just requires users who have the hardware and knowledge to port the D runtime over. That's what I meant (; A small misunderstanding [; 4\/3!!
Re: Trust about D programming.
Well, "porting druntime" is not exactly the thing I can call "support from GDC", it is somewhat orthogonal from compiler. On Tuesday, 22 January 2013 at 13:55:05 UTC, Freddie Chopin wrote: On Tuesday, 22 January 2013 at 13:50:51 UTC, Iain Buclaw wrote: That's a common misconception. Other platform support are already appearing (ARM, MIPS, PPC), it just requires users who have the hardware and knowledge to port the D runtime over. That's what I meant (; A small misunderstanding [; 4\/3!!
Re: Trust about D programming.
On 22 January 2013 14:02, mist wrote: > Well, "porting druntime" is not exactly the thing I can call "support from > GDC", it is somewhat orthogonal from compiler. > > > I could argue the toss, but I'm instead going to have talk about why you are wrong... in May perhaps... :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: D popularity
On Tuesday, 22 January 2013 at 06:38:01 UTC, Rob T wrote: Check out the new experimental on-line documentation. http://vibed.org/temp/d-programming-language.org/phobos/std/range.html You can put in user comments too. Still not as good as it can be, but it's a big improvement over the existing documentation. The important thing is that D seems to always be improving, and the community is very active. A little different; feels more like a table of contents and a brief overview of each feature/function unless you want more detail. Two minor dislikes, and both are the menu half on the left side. First, it's listing core, etc and then std; Obviously that's not horrible but std is likely the more used and should be at the top, etc and core I am not sure about, so reversing the order I would think is preferred. Second, the first level is automatically expanded, that's not a bad thing but with the core on the top skimming more what I want takes a little more time and navigation. I would say only have std expanded by default, or the tree you are currently in.
Re: Some dynamic dispatch to reduce template bloat
mist: What syntax sugar do you propose? Maybe some tagging to denote what template arguments should be autoboxed? The last piece of code in that page shows two saveClient() functions. Maybe only one of them is needed, and the other can be auto-generated. Bye, bearophile
Re: Trust about D programming.
Please do, looking forward to watching video about how I am wrong :) On Tuesday, 22 January 2013 at 14:29:11 UTC, Iain Buclaw wrote: On 22 January 2013 14:02, mist wrote: Well, "porting druntime" is not exactly the thing I can call "support from GDC", it is somewhat orthogonal from compiler. I could argue the toss, but I'm instead going to have talk about why you are wrong... in May perhaps... :o)
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 13:54:08 UTC, eles wrote:
The text opens with...:
"We like it when people always want more! Otherwise, we'd be
out of the upgrade business. Sometimes, people ask me what I
will do when the compiler is done. Done? No software program
that is selling is ever done!
-- Walter Bright, C++ compiler architect"
So... the question is: does that quote also applies for dmd? :)
It's been quoted that for every 10 lines of code there's a bug.
There are programs with tens of thousands of lines of code, so
finding every bug is probably impossible for large programs
(above 1000 lines). But that doesn't mean they can't run very
very well. A number of the bugs for unchecked work is addition
for example, perhaps simplest of operations; Are you going to
check after every little + that you didn't have an overflow?
Without a lot of extra work are you going to include checks that
ensure they can't break?
C example:
//code looks okay
void* getMemory(int a, int b) {
return malloc(a + b);
}
//becomes negative due to overflow. it can happen
//probably returns NULL. I don't know..
void* ptr = getMemory(0x7fff, 0x7fff);
//overflow free version?
void* getMemory(unsigned int a, unsigned int b) {
//max name may be wrong, but you get the idea.
//don't remember, need third cast?
assert(((long long) a) + ((long long) b) <= UNSIGNED_INT_MAX);
return malloc(a + b);
}
//should assert now
void* ptr = getMemory(UNSIGNED_INT_MAX, UNSIGNED_INT_MAX);
Since part of the process is not only fixing bugs and improving
the compiler, but there's also new features that may be requested
that you find necessary yet never needed before you thought about
it.
Consider: A recent project of mine that I hadn't updated in over
a year and a half seemed to have a bug with how it handled a
certain feature and was just brought up, needed to add about 10
lines of code to handle it; Then I found a bug within those 10
lines (after it was working).
With that in mind, it's likely no program will be 'done', but if
they do the job well enough then it's probably good enough. So to
answer it, the answer is probably yes it applies to dmd.
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote: It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines). I love how >1kloc is "large" :D I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large.
Re: [OT] Walter about compilers
Era Scarecrow: Are you going to check after every little + that you didn't have an overflow? In debug mode that's the job of a modern well designed language, just like checking an index is inside the bounds of an array every time you perform an array access. Bye, bearophile
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 14:59:48 UTC, Peter Alexander wrote: On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote: It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines). I love how >1kloc is "large" :D I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large. It really depends if we are talking about java or not.
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 14:59:48 UTC, Peter Alexander wrote: On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote: I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large. That means (at least) 100k bugs. Happy fixing!
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 13:36:15 UTC, Freddie Chopin wrote: On Tuesday, 22 January 2013 at 11:41:14 UTC, Sergei Nosov wrote: But for embedded programming I don't think D is a good practical choice. C and C++ shines there and I don't think things are changing soon. It would be a shame if D would be PC-only... Maybe when GDC will be ready things will change - who knows... Apart from the garbage collector, which really is not embedded-friendly (I'm talking about kilobytes of RAM, not megabytes) everything sounds quite OK in the specs (; 4\/3!! Ah, you mean something like Astrobe, an Oberon compiler for the ARM Cortex-M3 and NXP LPC2000 micro-controlers? http://www.astrobe.com/default.htm Presentation from the 2011 Oberon days, http://www.oberonday2011.ethz.ch/talks/armembedded.pdf It is possible to do C free development in embedded systems, using system programming languages with GC. There are of course embedded systems, where the only way to program is either Assembly or a crippled down version of C due to hardware constraints. However, if the hardware is able to execute full ANSI C code, then there are other options becoming available. It is just a matter to get a more widespread acceptance. -- Paulo
Re: [OT] Walter about compilers
On 2013-01-22, 15:59, Peter Alexander wrote: On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote: It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines). I love how >1kloc is "large" :D I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large. It's context dependent, of course. Finding all the bugs in 1kloc is doable, but lots of work. Finding all the bugs in 10kloc, conceivably doable, but unlikely to be worth it. >= 100kloc? ouch. -- Simen
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 15:26:28 UTC, deadalnix wrote: On Tuesday, 22 January 2013 at 14:59:48 UTC, Peter Alexander wrote: On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote: It's been quoted that for every 10 lines of code there's a bug. There are programs with tens of thousands of lines of code, so finding every bug is probably impossible for large programs (above 1000 lines). I love how >1kloc is "large" :D I'd say anything under 100kloc is a small program. 100kloc-1mloc medium, and >1mloc large. It really depends if we are talking about java or not. Not just Java. According to Wikipedia Debian 5 has over 300 million lines of code. http://en.wikipedia.org/wiki/Source_lines_of_code Last time I counted, Phobos has ~200kloc.
Re: Some dynamic dispatch to reduce template bloat
On Tuesday, 22 January 2013 at 14:39:58 UTC, bearophile wrote: mist: What syntax sugar do you propose? Maybe some tagging to denote what template arguments should be autoboxed? The last piece of code in that page shows two saveClient() functions. Maybe only one of them is needed, and the other can be auto-generated. Bye, bearophile So far not convincing, do not see a lot of added value for new syntax :) Thanks for your explanations anyway.
Re: D popularity
On 1/22/13 12:19 AM, H. S. Teoh wrote: On Mon, Jan 21, 2013 at 10:57:39PM -0500, Andrei Alexandrescu wrote: On 1/21/13 10:32 PM, Nick Sabalausky wrote: On Mon, 21 Jan 2013 21:03:55 -0500 Andrei Alexandrescu wrote: On 1/21/13 3:06 PM, H. S. Teoh wrote: I have to admit that ddoc hasn't really done it for me (yet). I think the impediment is that the default output needs some work (mainly in CSS and indexing) before it is useful as actual documentation. We should make a few macro batteries (HTML, mobi, pdf) readily available in e.g. tools/ or examples/. Is that possible? PDF is binary, but I thought DDoc only did text output? Come to think of it, how *do* the non-html versions of the docs currently get generated? LaTeX. [...] Speaking of which, did you manage to polish up the LaTeX macros to produce decent output? I'd love to take a look if you did -- I'm a LaTeX fan. Yah, a start is already on github, run make VERSION=2.061 `pwd`/web/dlangspec.pdf from the d-programming-language.org repo. Andrei
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 15:42:04 UTC, Paulo Pinto wrote: It is possible to do C free development in embedded systems, using system programming languages with GC. Instead of just ditching C or C++ for something related to Delphi, it would be nicer to use D, as it's multithreading options look quite nice (; There are of course embedded systems, where the only way to program is either Assembly or a crippled down version of C due to hardware constraints. Well, a typical ARM Cortex-M3 is not THAT crippled, it just does not have that much RAM to waste - rarely there's more than 64kB, usually less than 32kB... However, if the hardware is able to execute full ANSI C code, then there are other options becoming available. Well, it's not about "full ANSI C", because you could do that on 8051 30 years ago... it just the matter of: a. RAM usage b. heap usage c. real-time constraints For a typical ARM bare-metal microcontroller C++ exceptions are a-bit-too-much (taking ~60kB of flash code when almost not used, and 60kB quite often would be 95% of available code memory, but in more common cases 25-50%), in D these are probably inevitable and I could live with that (; But I just cannot imagine a GC on a microcontroller that has so little RAM and which has to do something in real-time - you probably will just get annoyed if an app on PC freezes for a second, but if a 100-tonne crane controller freezes for that time it can end really bad (; Yes, GC and dynamic memory is really cool, but it costs just a lot of RAM... You can sometimes live with mallocs() (but modestly used), yet I cannot imaging GC in so small memory. It can be easily assumed that such applications don't do a lot of memory allocation at run-time (usually none), so the GC would just waste time and memory... It is just a matter to get a more widespread acceptance. I think it's just a matter of realistic expectations (; A LOT (and I really mean that) people think that ARM based microcontrollers are an overkill for most of the tasks, so you'll just not convince them to use an even more expensive chip, which has 4x the amount of RAM just to use "a fancy language". And do remember we're not talking about routers and smartphones that have 128MB of RAM, but rather about home automation systems, some industrial controllers (but not HMI with a fancy GUI, but the devices that really do the monitoring and control), maybe some electronics embedded in toys (RC models etc.). 4\/3!!
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 15:11:41 UTC, bearophile wrote: Era Scarecrow: Are you going to check after every little + that you didn't have an overflow? In debug mode that's the job of a modern well designed language, just like checking an index is inside the bounds of an array every time you perform an array access. Agreed. However D (compilers) doesn't have an option to check those, I think it was requested but walter said no (due to slower speed I think); Therefore if the compiler won't do it for you, you have to do it yourself. I really wouldn't want to have to use BigInt for everything that can't overflow and then check to make sure I can fit it in my smaller variables afterwards along with the extra move. I wouldn't want to use BigInts everywhere, and long's aren't needed everywhere either. Of course if an attribute was added that checked just those functions for important overflows then it could help, but in truth it kinda clutters the signatures with something that isn't an important attribute. Guess 'CheckedInt' could work in those cases, but that's more during runtime and release rather than debugging.
Re: [OT] Walter about compilers
Not just Java. According to Wikipedia Debian 5 has over 300 million lines of code. It also consists of over 2 packages. It is not one program.
Re: dmd json file output
On Tuesday, 22 January 2013 at 08:02:26 UTC, Rainer Schuetze
wrote:
> "type" : {
> "mangled" : "PPPi",
> "pretty" : "int***",
> }
I would favour plain "type" : "int***".
Consider it will be parsed from many different languages, C#,
Java... etc and the generic tools may be able to handle json from
multiple languages, and in this context have no reason to use
differently mangled types for different languages.
"int***" is both compact and easy enough to parse anyway.
Even for pure D-based tools, for unit-test reasons it could be
useful to have the pretty name to compare against, thus Rainer's
proposal is a reasonable compromise.
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 16:31:20 UTC, Era Scarecrow wrote: I really wouldn't want to have to use BigInt for everything that can't overflow and then check to make sure I can fit it in my smaller variables afterwards along with the extra move. I wouldn't want to use BigInts everywhere, and long's aren't needed everywhere either. Since D aims to emulate C in this aspect, overflow with uints is probably defined as a wrap-around (like C). In this case it seems to me the check for overflow would simply be '(a+b)to cast to longs and BigInts and all that. Of course this may not apply to signed ints...
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 17:10:35 UTC, Thiez wrote:
On Tuesday, 22 January 2013 at 16:31:20 UTC, Era Scarecrow
wrote:
I really wouldn't want to have to use BigInt for everything
that can't overflow and then check to make sure I can fit it
in my smaller variables afterwards along with the extra move.
I wouldn't want to use BigInts everywhere, and long's aren't
needed everywhere either.
Since D aims to emulate C in this aspect, overflow with uints
is probably defined as a wrap-around (like C). In this case it
seems to me the check for overflow would simply be '(a+b)no need to cast to longs and BigInts and all that. Of course
this may not apply to signed ints...
That merely shortens the size of the check, not where you need
to place the checks or how often. Truthfully, in almost all cases
the wrap-around or overflow/underflow is an error, usually
unchecked. If 1 million were the max, then 1,000,000 + 1 should
equal 1,000,001 and not <=0, and if 0 is the minimum, 0 - 1
should not equal >=0.
The only real time I can find overflow wanted is while making
something that watches for it explicitly to make use of it. Say
we emulate or write the 'ucent' types. That could be done as:
//addition example obviously
void add(const uint[4] lhs, const uint[4] rhs) {
uint[4] val;
bool carry = false;
foreach(i, ref v; val) {
uint tmp = lhs[i];
v = lhs[i] + rhs[i] + (carry ? 1 : 0);
carry = v < tmp;
}
assert(!carry); //could fail. How to handle this? Ignore?
}
Now let's say there's a for loop which someone decides they
would be clever and use a ubyte (unsigned char) as an index or
counter.
for(ubyte i = 0; i < 1000; i++) {
writeln(i);
}
The overflow is an error because the wrong type was selected but
doesn't change the obvious logic behind it. You can hide the type
behind an alias or similar but that doesn't change the fact it's
a bug, and can be easier to detect if we are aware the overflow
is happening at all rather than it getting stuck and having to
manually kill the process or step through it in a debugger. If it
wasn't outputting in some way you could identify it's much harder
to find.
Encryption may make use of the overflow/wrap around, but far
more likely they use xor or binary operations which don't have
those problems.
Re: Trust about D programming.
Am 22.01.2013 17:19, schrieb Freddie Chopin: On Tuesday, 22 January 2013 at 15:42:04 UTC, Paulo Pinto wrote: It is possible to do C free development in embedded systems, using system programming languages with GC. Instead of just ditching C or C++ for something related to Delphi, it would be nicer to use D, as it's multithreading options look quite nice (; Sure, I was actually trying to point out the existence of strong type languages for (some type) of embedded development. It would be surely nice to use something like D. There are of course embedded systems, where the only way to program is either Assembly or a crippled down version of C due to hardware constraints. Well, a typical ARM Cortex-M3 is not THAT crippled, it just does not have that much RAM to waste - rarely there's more than 64kB, usually less than 32kB... However, if the hardware is able to execute full ANSI C code, then there are other options becoming available. Well, it's not about "full ANSI C", because you could do that on 8051 30 years ago... it just the matter of: a. RAM usage b. heap usage c. real-time constraints I had PIC micro-controlers with memory in the order of bytes, when I wrote that. If I am not mistaken, many of the C compilers for such environments are limited on what is actually possible to use from ANSI C. There was an assembler from TI which looked like C control flow with intrinsics, but I am no longer able to find the information. For a typical ARM bare-metal microcontroller C++ exceptions are a-bit-too-much (taking ~60kB of flash code when almost not used, and 60kB quite often would be 95% of available code memory, but in more common cases 25-50%), in D these are probably inevitable and I could live with that (; But I just cannot imagine a GC on a microcontroller that has so little RAM and which has to do something in real-time - you probably will just get annoyed if an app on PC freezes for a second, but if a 100-tonne crane controller freezes for that time it can end really bad (; Agreed. Yes, GC and dynamic memory is really cool, but it costs just a lot of RAM... You can sometimes live with mallocs() (but modestly used), yet I cannot imaging GC in so small memory. It can be easily assumed that such applications don't do a lot of memory allocation at run-time (usually none), so the GC would just waste time and memory... True, although in my naïve opinion, I would expect such systems to still be developed in Assembly. It is just a matter to get a more widespread acceptance. I think it's just a matter of realistic expectations (; A LOT (and I really mean that) people think that ARM based microcontrollers are an overkill for most of the tasks, so you'll just not convince them to use an even more expensive chip, which has 4x the amount of RAM just to use "a fancy language". Yes, I know the issues of a few cents per unit might imply. And do remember we're not talking about routers and smartphones that have 128MB of RAM, but rather about home automation systems, some industrial controllers (but not HMI with a fancy GUI, but the devices that really do the monitoring and control), maybe some electronics embedded in toys (RC models etc.). 4\/3!! Faire enough, I guess even C has issues on those systems right? Thanks for the comprehensive post, Paulo
Segfault with DMD optimization switch
Hi,
I just spent the last 5 hours trying to find the cause of a
segmentation fault. It was clearly my mistake that I did all
those tests with dmd's optimization switch on ("-O").
When I disabled optimization, i.e. removed the "-O" flag, the
code runs perfectly.
I can't exclude an actual bug in my code with 100 percent
certainty. But given various segmentation faults that I have seen
with dmd previous to version 2.061, and given the fact that I am
not using any pointers or other memory-unsafe constructs, I am
inclined to believe that this segfault is actually caused by dmd
itself, or at least dmd's optimization. Please correct me if you
think that is extremely unlikely.
Has anyone experienced those kind of problems which only occur
with the "-O" flag, but not without it? Or can anyone point me to
a related bug that has already been reported on bugzilla?
Unfortunately, in my case the code crashed in a position late in
some iteration loop, so I can't easily reproduce it in a simple
program to file a bug report.
Stephan
Re: Segfault with DMD optimization switch
On Tuesday, January 22, 2013 19:21:33 Stephan wrote: > Unfortunately, in my case the code crashed in a position late in > some iteration loop, so I can't easily reproduce it in a simple > program to file a bug report. DustMite might be able to help you reduce your code to a simpler program which also has the failure: https://github.com/CyberShadow/DustMite - Jonathan M davis
Re: D popularity
On Tuesday, 22 January 2013 at 00:32:03 UTC, John Colvin wrote: On Tuesday, 22 January 2013 at 00:24:04 UTC, John Colvin wrote: P.S. dmd 32bit on linux produces functional shared libraries, which can be happily called by IDL to clarify: extern(C) is required, there's nothing clever going on. Another correction: dmd can't make the runtime work. Ldc does work however.
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 18:14:30 UTC, Paulo Pinto wrote: If I am not mistaken, many of the C compilers for such environments are limited on what is actually possible to use from ANSI C. From what I've heard D is 32- and 64-bits only, so that actually leaves things like ARM, MIPS, AVR32 and such cores, these usually have really good GCC support, so I guess there are no "special" limits... It also depends on what you mean by "ANSI C" - for example for ARM, GCC and newlib's libc you basically have everything [; Things that are "OS-dependent" - like malloc(), stdio functions (printf(), ...) and stuff like that require you to provide "re-targeting syscalls" (like sbrk(), write(), read(), ...) but that's not a big issue [; You basically have whole libstdc++ too (from GCC), with all the templates, containers, iterators and stuff, plus typical C++ stuff - exceptions, RTTI, new, delete etc. - some of these things depend on the syscalls I mentioned above, some of these features take just too much memory [; So I guess that 32-bit microcontrollers are really standards-compliant! (; True, although in my naïve opinion, I would expect such systems to still be developed in Assembly. Do you mean controllers for 100-tonne crane of maybe just "general embedded microcontroller"? I guess that no one would go so low for things that can be done in C with a cheap chip like Cortex-M0 [; Faire enough, I guess even C has issues on those systems right? If we stick to ARM (like Cortex-M3) there are no issues other than memory limitations, and it generally concerns mostly RAM, as code memory is usually big enough (hundreds of kB usually, up to 512kB, sometimes 1MB). That's why you cannot get too fancy with your code, and - unfortunately - most of nice programming "tricks" are dynamic-memory-only... On the other hand, maybe I should ask what do you consider "an issue"? There's definitely nothing "non-standard" in the C/C++ that you use here - there's just no OS (but you can have an RTOS - scheduler), no POSIX (but there are POSIX-like RTOSes) and not-a-lot of RAM (there's no library for fixing that [; ). 4\/3!!
Re: Segfault with DMD optimization switch
Stephan: Has anyone experienced those kind of problems which only occur with the "-O" flag, but not without it? Compiler crashes caused by -O happen. But I think in your case looking at bugzilla isn't a big help, because the possible causes are too many. Unfortunately, in my case the code crashed in a position late in some iteration loop, so I can't easily reproduce it in a simple program to file a bug report. If you want the bug to be fixed, you will probably have to localize and submit it. Bye, bearophile
Error about @disabled constructor when there is a custom one
I have this structure:
struct Scene
{
Array!Surface objects; // objects in the scene
Array!Light lights; // lights in the scene
/*private*/ BVHNode root; // root node of the BVH
tree
@disable this(); // disable the default constructor because
space needs to be reserved for objects and lights
this(size_t objectReserveSpace = 20, size_t lightReserveSpace =
3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
}
auto scene = Scene(); // error about @disabled constructor
Yes, the default constructor is @disabled BUT I am not using that
one. I want to use the other one - the custom constructor. I
guess it signals an error because it has those defaults
parameters. But shouldn't the compiler choose that one?
Re: Error about @disabled constructor when there is a custom one
22-Jan-2013 22:45, Minas Mina пишет:
I have this structure:
struct Scene
{
Array!Surface objects;// objects in the scene
Array!Light lights;// lights in the scene
/*private*/ BVHNode root;// root node of the BVH tree
@disable this(); // disable the default constructor because space
needs to be reserved for objects and lights
this(size_t objectReserveSpace = 20, size_t lightReserveSpace = 3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
}
auto scene = Scene(); // error about @disabled constructor
That is the reason I dislike D's struct constructors as they currently
stand. Behold as the above is always rewritten to:
auto scene = Scene.init;
that is the same as
Scene scene;
And for Scene.init to work it has to have T.init for all of its members.
You've hit what I think is the design bug w.r.t. conflating 0-argument
constructor (including one with all default args) and T.init.
Short answer is: use static opCall instead. In the meantime let us all
pray some supreme gods so that 0-arg constructor support is introduced
later on. (because opCall doesn't have some powers of constructors such
as constructing const object)
Yes, the default constructor is @disabled BUT I am not using that one. I
want to use the other one - the custom constructor. I guess it signals
an error because it has those defaults parameters. But shouldn't the
compiler choose that one?
The official stance seems to be that the code shouldn't compile i.e.
accepts-invalid.
http://d.puremagic.com/issues/show_bug.cgi?id=3438
--
Dmitry Olshansky
Re: D popularity
On Monday, 21 January 2013 at 21:27:54 UTC, Nick Sabalausky wrote: If text editors written in JavaScript have become commonplace (Thanks, Google!), I'm sure JS-based interpreters, JS-based codecs and "F"FTs (rather SFTs), and other such nonsense aren't far behind. You probably already saw these, but an x86 emulator that runs linux, written in javascript: http://www.geek.com/articles/chips/javascript-emulator-lets-linux-run-in-a-browser-tab-20110517/ Forge, a Transport Layer Security implementation written in javascript: http://digitalbazaar.com/2010/07/20/javascript-tls-1/ Not quite FFTs or codecs, but not far off. :) I think these are horribly dumb ideas, just pointing out that they exist. A roundabout way to say it, but I guess the point I started out trying to make is this: The popularity of dynamic/interpreted/sandboxed/etc languages *is* IMO one of the more significant roadblocks in the way of D popularity. Silent fire alarms are what's hip, and here we are peddling an old-fashioned sounds-and-lights fire alarm. We're pragmatic instead of cool. I agree with this generally, but I'll note that those dynamic languages really aren't that popular. Using TIOBE data, (yes, yes, I know it's not good data, but I'm going to keep looking under the streetlight, dammit ;) ) http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Three out of the top four languages are now native compiled, with C even beating back Java for the top spot recently. D is probably in the top 7 for compiled languages and the only one to be designed in the last decade or so (I don't think Pascal and Ada are coming back ;) ). So I think D is well-positioned to hit that top spot, or at least that's what I told a friend recently when I explained why I'm trying to use D. :)
Re: Error about @disabled constructor when there is a custom one
On 2013-01-22, 19:45, Minas Mina wrote:
I have this structure:
struct Scene
{
Array!Surface objects; // objects in the scene
Array!Light lights; // lights in the scene
/*private*/ BVHNode root; // root node of the BVH
tree
@disable this(); // disable the default constructor because space needs
to be reserved for objects and lights
this(size_t objectReserveSpace = 20, size_t lightReserveSpace = 3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
}
auto scene = Scene(); // error about @disabled constructor
Yes, the default constructor is @disabled BUT I am not using that one. I
want to use the other one - the custom constructor. I guess it signals
an error because it has those defaults parameters. But shouldn't the
compiler choose that one?
You *are* using the default one. The one without parameters *is* the
default constructor, and you are calling the constructor without
parameters.
One could argue that the compiler should choose the other constructor, and
even that having default constructors is reasonable. However, D has gone
the route of not having default constructors for structs. Instead,
structs are defined to be trivially constructible from T.init.
The workaround is to use static opCall:
struct Scene
{
Array!Surface objects;
Array!Light lights;
/*private*/ BVHNode root;
@disable this();
this(size_t objectReserveSpace = 20, size_t lightReserveSpace = 3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
static Scene opCall(size_t objectReserveSpace = 20, size_t
lightReserveSpace = 3)
{
return Scene(objectReserveSpace, lightReserveSpace);
}
}
--
Simen
Misconceptions, and views on D
I keep hearing a lot of people saying that they think that D is a "niche" language. Did I completely miss something, or are they just misinformed? I've never thought of D as a niche language. I consider (and use) it as what Cpp should have been. Like a love child from C, C++, and Python. I'd be very interested to hear others thoughts on the subject, as well as other common misconceptions.
Re: Error about @disabled constructor when there is a custom one
On 01/22/2013 11:07 AM, Simen Kjaeraas wrote:
> The workaround is to use static opCall:
>
> struct Scene
> {
> Array!Surface objects;
> Array!Light lights;
>
> /*private*/ BVHNode root;
>
> @disable this();
That line must still be removed.
> this(size_t objectReserveSpace = 20, size_t lightReserveSpace = 3)
The default parameter values are not useful (or don't make sense) anymore:
this(size_t objectReserveSpace, size_t lightReserveSpace)
> {
> objects.reserve(objectReserveSpace);
> lights.reserve(lightReserveSpace);
> }
>
> static Scene opCall(size_t objectReserveSpace = 20, size_t
> lightReserveSpace = 3)
> {
> return Scene(objectReserveSpace, lightReserveSpace);
Luckily that line calls the constructor, not itself and avoids an
infinite loop. :)
Ali
Re: dmd json file output
On 1/22/13 2:48 AM, Walter Bright wrote: On 1/21/2013 10:56 PM, ric wrote: Would it be reasonable to put an option whether to produce the (too) verbose json output or the minimal one? I'd rather we make a decision. Verbose should probably be it. Andrei
Re: D popularity
On 1/22/13 4:46 AM, Jacob Carlborg wrote: On 2013-01-22 04:57, Andrei Alexandrescu wrote: LaTeX. Isn't that a failure of ddoc. Wasn't ddoc supposed to be independent of the output format. If we're only using ddoc to generate the HTML documentation it seems it's not good enough. This is not a big issue. I mostly care about the HTML docs. Not sure I understand. We have working templates that produce passable PDF via LaTeX. Andrei
Re: Internal and external iteration, fibers
On 1/22/13 7:14 AM, Max Samukha wrote: On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote: On Tue, Jan 22, 2013 at 2:55 AM, deadalnix wrote: On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote: I know people don't like it but I have to say, this seems it could be a job for AST macros. I was thinking the same thing, but don't wanted to bug people. Indeed, it is the perfect job for AST macro. I can concur now that you mentioned it xD Would any of you be so kind as to propose another definition for AST macros here ? http://wiki.dlang.org/Commonly-Used_Acronyms AST macros is CTFE done right :) Not at all, I'd say. CTFE has a much lower cost of learning - you only need to know which subset of D is allowed. Maybe you meant code mixins? Andrei
Re: dmd json file output
Am 22.01.2013 18:05, schrieb Tove: > (...) > > "int***" is both compact and easy enough to parse anyway. > Consider "int[4u] delegate(scope float*[void function(scope int)] p1, Rebindable!(const(C))*[]* b)" There are actually quite some things to parse in human readable type strings, I even remember some expressions. And parsing this is at least as language specific as the mangled name. But I agree that having both should be a good compromise.
Re: Misconceptions, and views on D
You could always ask, "What niche ?". You know, like web-programming is a niche, even though pretty large one. I think "general public" does not know about even existence of D, or most of other modern languages.
More struct woes
Fun, fun: http://d.puremagic.com/issues/show_bug.cgi?id=9372 Now I have to use a dummy argument to my class ctor, just because it happens to have a member that has a @disabled ctor. :-/ T -- If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Re: Trust about D programming.
C requirements are extremely low. With only a couple of standard library functions (I think memcpy() and memcmp()) gcc starts to generate viable code. You can code on bare metal out of the box. D 'flyes' much higher - it uses a whole runtime, and requires OS services. Of course there are ways to adapt D to bare metal, but C was born adapted. But, for coding on top of fully fledged OS, looks like D is a good choice.
Re: Update #1 on new std.uni
17-Jan-2013 22:48, H. S. Teoh пишет:
On Wed, Jan 16, 2013 at 02:48:30PM +0400, Dmitry Olshansky wrote:
11-Jan-2013 23:31, Dmitry Olshansky пишет:
The code, including extra tests and a benchmark is here:
https://github.com/blackwhale/gsoc-bench-2012
And documentation:
http://blackwhale.github.com/phobos/uni.html
[snip]
- Why are the isX() functions @system? I would have expected they should
be at least @trusted? (Or are there technical problems / compiler bugs
preventing this?)
M-hm I'm seeing this in my sources:
bool isAlpha(dchar c) @safe pure nothrow
{...}
The DDoc however shows @system.
A compiler bug?
It's indeed a bug in the compiler, looks funny:
http://d.puremagic.com/issues/show_bug.cgi?id=9371
Makes me think that the compiler treats @safe after
the function prototype differently then the one placed before it.
The trailing-@safe camp must be jealous.
That's all for now. I hope you don't mind me allowing the grammar nazi
to take over for a bit. I want Phobos documentation to be professional
quality. :)
All of these were incorporated, thanks.
Among other new stuff I've added some cross-links throughout.
Now on to the normalization forms description, etc.
--
Dmitry Olshansky
Re: Error about @disabled constructor when there is a custom one
From Jonathan M Davis: "...At this point, I don't think that the situation with default constructors and structs is going to change. It's a result of requiring init properties for all types, and is thus a "forced fault" in the language..." Why does requiring init properties for all types results in this? What does that even mean?
Re: dmd json file output
On 1/22/2013 11:46 AM, Andrei Alexandrescu wrote: On 1/22/13 2:48 AM, Walter Bright wrote: On 1/21/2013 10:56 PM, ric wrote: Would it be reasonable to put an option whether to produce the (too) verbose json output or the minimal one? I'd rather we make a decision. Verbose should probably be it. Rationale?
Re: Trust about D programming.
Am 22.01.2013 19:33, schrieb Freddie Chopin: On Tuesday, 22 January 2013 at 18:14:30 UTC, Paulo Pinto wrote: ... [cutted] Faire enough, I guess even C has issues on those systems right? If we stick to ARM (like Cortex-M3) there are no issues other than memory limitations, and it generally concerns mostly RAM, as code memory is usually big enough (hundreds of kB usually, up to 512kB, sometimes 1MB). That's why you cannot get too fancy with your code, and - unfortunately - most of nice programming "tricks" are dynamic-memory-only... On the other hand, maybe I should ask what do you consider "an issue"? There's definitely nothing "non-standard" in the C/C++ that you use here - there's just no OS (but you can have an RTOS - scheduler), no POSIX (but there are POSIX-like RTOSes) and not-a-lot of RAM (there's no library for fixing that [; ). 4\/3!! I don't really have much embedded experience besides assembly programming in the old days (Z80, M68000, x86, MIPS, self build processor for digital circuits class). My understanding is that the processors the micro-controler class, the ones with memory in the order of bytes or kilobytes, usually C compilers that only implement part of the ANSI standard, given the hardware constraints. Meaning just a very small subset of data types is supported, limited library support and lots of compiler extensions to make use of the processor and on die ports. I used to follow PIC articles for a while in the Elektor magazine, hence my fuzzy knowledge about this. -- Paulo
Re: Trust about D programming.
On Tuesday, 22 January 2013 at 21:02:32 UTC, Paulo Pinto wrote: I don't really have much embedded experience besides assembly programming in the old days (Z80, M68000, x86, MIPS, self build processor for digital circuits class). My understanding is that the processors the micro-controler class, the ones with memory in the order of bytes or kilobytes, usually C compilers that only implement part of the ANSI standard, given the hardware constraints. Meaning just a very small subset of data types is supported, limited library support and lots of compiler extensions to make use of the processor and on die ports. Nothing like this here - you have all types, you have complete libm, libc and stdlibc++ with everything you need. There are no compiler extensions other than a typical GCC __attribute__ used to declare interrupts, which is not really necessary on most Cortex-M3 chips. These are really powerful chips with 1.25DMIPS/MHz and clocks around 70MHz (ranging from 24MHz to 204MHz)... There's even a dual-core chip - LPC43xx which has Cortex-M4F (with single precision hardware FPU and some SIMD instructions) and a Cortex-M0, both running at 204MHz <: So these are not very much like 8-bit microcontrollers (AVR, PIC, ...) That's why I think D would fit such chips quite nice (; Sans the GC of course... Maybe without exceptions too, but I don't think that would be possible (it's pretty hard in C++)... 4\/3!!
Re: Error about @disabled constructor when there is a custom one
23-Jan-2013 00:28, Minas Mina пишет: From Jonathan M Davis: "...At this point, I don't think that the situation with default constructors and structs is going to change. It's a result of requiring init properties for all types, and is thus a "forced fault" in the language..." Why does requiring init properties for all types results in this? What does that even mean? I don't buy it either. 0-argument constructor have nothing to do with requiring .init. -- Dmitry Olshansky
Re: Misconceptions, and views on D
On Tue, 22 Jan 2013 20:38:29 +0100 "IanWizard" <1.am.w1z...@gmail.com> wrote: > I keep hearing a lot of people saying that they think that D is a > "niche" language. Did I completely miss something, or are they > just misinformed? I've never thought of D as a niche language. > I consider (and use) it as what Cpp should have been. Like a > love child from C, C++, and Python. I'd be very interested to > hear others thoughts on the subject, as well as other common > misconceptions. D is a general-purpose language, so when people call it "niche" I suspect they're simply referring to D's user base currently being much smaller than C/C++/Java/Python/etc. The "niche" of D users. OTOH, D can be (and often is) very accurately described as a reimagined, cleaned-up C++, so maybe their line of thinking is "Ok, so it's for C++ users that are unhappy with C++", which might a niche *if* that were *all* D was well suited for.
Re: Update #1 on new std.uni
On Wednesday, January 23, 2013 00:20:19 Dmitry Olshansky wrote: > It's indeed a bug in the compiler, looks funny: > http://d.puremagic.com/issues/show_bug.cgi?id=9371 > > Makes me think that the compiler treats @safe after > the function prototype differently then the one placed before it. > The trailing-@safe camp must be jealous. Prepending @safe is evil. ;) That's definitely a weird bug though. I'd say that it pretty much has to be a bug in the parser given that the AST should be identical regardless of which side of the function signature an attribute is on. - Jonathan m Davis
Re: Misconceptions, and views on D
On Tuesday, January 22, 2013 16:16:33 Nick Sabalausky wrote: > D is a general-purpose language, so when people call it "niche" I > suspect they're simply referring to D's user base currently being much > smaller than C/C++/Java/Python/etc. The "niche" of D users. Exactly. Regardless of how good D is, its user base is still relatively small - especially in industry. I'd fully expect that anyone specifically looking for a job programming in D would have a very hard time of it. They exist, but they're not common. But the user base is growing, so D may yet become a mainstream programming language like we'd like it to. Plenty of other programming languages have taken a while to really catch on (e.g. Python). - Jonathan M Davis
Re: Error about @disabled constructor when there is a custom one
On Tuesday, 22 January 2013 at 21:12:50 UTC, Dmitry Olshansky wrote: 23-Jan-2013 00:28, Minas Mina пишет: From Jonathan M Davis: "...At this point, I don't think that the situation with default constructors and structs is going to change. It's a result of requiring init properties for all types, and is thus a "forced fault" in the language..." Why does requiring init properties for all types results in this? What does that even mean? I don't buy it either. 0-argument constructor have nothing to do with requiring .init. What he said.
Re: Error about @disabled constructor when there is a custom one
On Wednesday, January 23, 2013 01:12:45 Dmitry Olshansky wrote: > 23-Jan-2013 00:28, Minas Mina пишет: > > From Jonathan M Davis: > > "...At this point, I don't think that the situation with default > > constructors and > > structs is going to change. It's a result of requiring init properties > > for all > > types, and is thus a "forced fault" in the language..." > > > > Why does requiring init properties for all types results in this? What > > does that even mean? > > I don't buy it either. 0-argument constructor have nothing to do with > requiring .init. init prevents us from having _default_ constructors. As much as no-arg constructors are normally default constructors, they're technically separate concepts. static opCall shows us that it's perfectly possible to have no-arg constructors. However, there's a certain danger in simply making a no-arg constructor for structs not be a default constructor, as pretty much anyone coming from another OO language will expect it to be a default constructor. For the most part, static opCall solves the problem. - Jonathan M Davis
Re: Segfault with DMD optimization switch
Thanks for that hint. DustMite looks promising. I will try to file a report. Stephan On Tuesday, 22 January 2013 at 18:28:08 UTC, Jonathan M Davis wrote: On Tuesday, January 22, 2013 19:21:33 Stephan wrote: Unfortunately, in my case the code crashed in a position late in some iteration loop, so I can't easily reproduce it in a simple program to file a bug report. DustMite might be able to help you reduce your code to a simpler program which also has the failure: https://github.com/CyberShadow/DustMite - Jonathan M davis
Re: Segfault with DMD optimization switch
On Tuesday, 22 January 2013 at 18:28:08 UTC, Jonathan M Davis
wrote:
On Tuesday, January 22, 2013 19:21:33 Stephan wrote:
Unfortunately, in my case the code crashed in a position late
in
some iteration loop, so I can't easily reproduce it in a simple
program to file a bug report.
DustMite might be able to help you reduce your code to a
simpler program which
also has the failure:
https://github.com/CyberShadow/DustMite
- Jonathan M davis
Using DMD 2.061 on Windows XP with VisualD and turning on
optimization in debug mode, this will throw an exception:
import std.datetime;
void main() {
StopWatch sw;
sw.start;
}
What seems to cause it is adding a break point on the last line.
It exits successfully with code 0 without the break point. This
just happens to be the minimal case the first program I could
think of reduces to and still has the issue, I have no idea if
it's anything to do with std.datetime nor if I am demonstrating
the same issue, apologies if this is irrelevant.
Re: Error about @disabled constructor when there is a custom one
On Tuesday, 22 January 2013 at 19:07:56 UTC, Simen Kjaeraas wrote:
On 2013-01-22, 19:45, Minas Mina wrote:
I have this structure:
struct Scene
{
Array!Surface objects; // objects in the scene
Array!Light lights; // lights in the scene
/*private*/ BVHNode root; // root node of the BVH
tree
@disable this(); // disable the default constructor because
space needs to be reserved for objects and lights
this(size_t objectReserveSpace = 20, size_t lightReserveSpace
= 3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
}
auto scene = Scene(); // error about @disabled constructor
Yes, the default constructor is @disabled BUT I am not using
that one. I want to use the other one - the custom
constructor. I guess it signals an error because it has those
defaults parameters. But shouldn't the compiler choose that
one?
You *are* using the default one. The one without parameters
*is* the
default constructor, and you are calling the constructor
without parameters.
One could argue that the compiler should choose the other
constructor, and
even that having default constructors is reasonable. However, D
has gone
the route of not having default constructors for structs.
Instead,
structs are defined to be trivially constructible from T.init.
Which incompatible with the desire of a NonNull construct.
The workaround is to use static opCall:
struct Scene
{
Array!Surface objects;
Array!Light lights;
/*private*/ BVHNode root;
@disable this();
this(size_t objectReserveSpace = 20, size_t lightReserveSpace
= 3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
static Scene opCall(size_t objectReserveSpace = 20, size_t
lightReserveSpace = 3)
{
return Scene(objectReserveSpace, lightReserveSpace);
}
}
Cheap workaround as you cannot new.
Re: [OT] Walter about compilers
On 1/22/2013 6:44 AM, Era Scarecrow wrote: It's been quoted that for every 10 lines of code there's a bug. I've been doing some refactoring in dmd now and then. Every time I do, the process exposes latent bugs. On the one hand, that's discouraging, on the other hand, I think it shows the value in refactoring into a better design.
Re: [OT] Walter about compilers
On Tuesday, 22 January 2013 at 14:44:26 UTC, Era Scarecrow wrote: It's been quoted that for every 10 lines of code there's a bug. It is said a lot. I'd like to see hard data on that one. I'd bet that it greatly vary from one programmer to another, and probably from one language to another.
Re: Segfault with DMD optimization switch
I encountered a segfault once after compiling with -O -release. It was the -release that caused an assert to be removed from a function that did not return due to an error condition. When the error was encountered there was no longer an assert to catch it, resulting in a segfault. -rt
Re: dmd json file output
On 1/22/13 3:36 PM, Walter Bright wrote: On 1/22/2013 11:46 AM, Andrei Alexandrescu wrote: On 1/22/13 2:48 AM, Walter Bright wrote: On 1/21/2013 10:56 PM, ric wrote: Would it be reasonable to put an option whether to produce the (too) verbose json output or the minimal one? I'd rather we make a decision. Verbose should probably be it. Rationale? You can always filter out the verboseness with a simple program, but you can't add missing information. If the efficiency of generating json ever comes up, _then_ it's worth looking into an option that produces less verbose output directly. For now be verbose and let downstream tools filter it out. Andrei
