bug in std.array.insertInPlace ?
Hi, I found some strange behavior of std.array.insertInPlace leading to segfault. The example below works for int, it is failed for reference type with array becoming of length bigger 1024 on windows (x64) and 512 on linux (x64). code: http://cloud.theambient.org/0O360r1d2t1g09171F1m Is it my bug or compiler? -- BR, Ruslan Mullakhmetov
Re: How about a 100% CTFE?
Don Wrote:
On 07.11.2011 14:13, Gor Gyolchanyan wrote:
After reading
http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
I had a thought:
Why not compile and run CTFE code in a separate executable, write it's
output into a file, read that file and include it's contents into the
object file being compiled?
This would cover 100% of D in CTFE, including external function calls
and classes;
String mixins would simply repeat the process of compiling and running
an extra temporary executable.
This would open up immense opportunities for such things as
library-based build systems and tons of unprecedented stuff, that I
can't imagine ATM.
First comment: classes and exceptions now work in dmd git. The remaining
limitations on CTFE are intentional.
With what you propose:
Cross compilation is a _big_ problem. It is not always true that the
source CPU is the same as the target CPU. The most trivial example,
which applies already for DMD 64bit, is size_t.sizeof. Conditional
compilation can magnify these differences. Different CPUs don't just
need different backend code generation; they may be quite different in
the semantic pass. I'm not sure that this is solvable.
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an X86???
}
I think we discussed those issues before.
1. size_t.sizeof:
auto a = mixin(size_t.sizeof); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU
2. version (ARM) example - this needs clarification of the semantics. Two
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today. require
'mixin' to call it on HOST. This should be backwards compatible since we keep
the current CTFE and add support for multi-level compilation.
b. immutable x = ... is run via the new system which requires the function
armSpecificCode to be compiled ahead of time and provided to the compiler in
an object form. No Platform incompatibility is possible.
I don't see any problems with cross-compilation. It is a perfectly sound design
(Universal Turing machine) and it was successfully implemented several times
before: Lisp, scheme, Nemerle, etc.. It just requires to be a bit careful with
the semantic definitions.
Re: Damn - again!
On Wednesday, November 09, 2011 05:25:55 Steve Teale wrote: I use the Pan newsreader. In the mornings when I'm looking at digitalmars.D I regularly make the mistake of editing the panel that displays the individual posts. I'll mark some of the older text and hit delete. At that point you are hosed. The article disappears, and there's no obvious way to get it back. Any recommendations for a different reader? IPersonally, I sign up for the mailing list and use that instead of the newsgroup. That way, I can use my e-mail client to read everything, and the state is synced between machines (since I use IMAP). - Jonathan M Davis
Re: Global immutable AA literals
I think this is a bug and i even recall seeing it in bugzilla, but i
don't have a link to it.
On Wed, Nov 9, 2011 at 10:43 AM, bearophile bearophileh...@lycos.com wrote:
Is it possible to modify DMD to allow a program like:
immutable int[int] aa = [1:15, 2: 7];
void main() {}
With the latest DMD it gives:
test.d(1): Error: non-constant expression [1:15,2:7]
Global immutable associative arrays are handy in script-like programs, I use
them now and then in Python (despite they are not immutable).
This is a workaround for script-like programs, that I sometimes use:
immutable int[int] aa;
static this() {
aa = [1:15, 2: 7];
}
void main() {}
But when possible I try to avoid using static this.
Bye,
bearophile
Re: How about a 100% CTFE?
I knew I'm not crazy :-)
I knew there would be at least somebody, who will see what I meant :-)
On Wed, Nov 9, 2011 at 12:17 PM, foobar f...@bar.com wrote:
Don Wrote:
On 07.11.2011 14:13, Gor Gyolchanyan wrote:
After reading
http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
I had a thought:
Why not compile and run CTFE code in a separate executable, write it's
output into a file, read that file and include it's contents into the
object file being compiled?
This would cover 100% of D in CTFE, including external function calls
and classes;
String mixins would simply repeat the process of compiling and running
an extra temporary executable.
This would open up immense opportunities for such things as
library-based build systems and tons of unprecedented stuff, that I
can't imagine ATM.
First comment: classes and exceptions now work in dmd git. The remaining
limitations on CTFE are intentional.
With what you propose:
Cross compilation is a _big_ problem. It is not always true that the
source CPU is the same as the target CPU. The most trivial example,
which applies already for DMD 64bit, is size_t.sizeof. Conditional
compilation can magnify these differences. Different CPUs don't just
need different backend code generation; they may be quite different in
the semantic pass. I'm not sure that this is solvable.
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an X86???
}
I think we discussed those issues before.
1. size_t.sizeof:
auto a = mixin(size_t.sizeof); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU
2. version (ARM) example - this needs clarification of the semantics. Two
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today.
require 'mixin' to call it on HOST. This should be backwards compatible since
we keep the current CTFE and add support for multi-level compilation.
b. immutable x = ... is run via the new system which requires the function
armSpecificCode to be compiled ahead of time and provided to the compiler
in an object form. No Platform incompatibility is possible.
I don't see any problems with cross-compilation. It is a perfectly sound
design (Universal Turing machine) and it was successfully implemented several
times before: Lisp, scheme, Nemerle, etc.. It just requires to be a bit
careful with the semantic definitions.
Re: Damn - again!
I've signed up for puremagic.D using my gmail acoount and i made a filder in gmail to add the D tag on emails, that come from puremagic.D. The discussion threads are stored as conversations (a neat feature of gmail) and are tagged with a red D label, making them very easy to work with. On Wed, Nov 9, 2011 at 2:36 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: On Wednesday, November 09, 2011 05:25:55 Steve Teale wrote: I use the Pan newsreader. In the mornings when I'm looking at digitalmars.D I regularly make the mistake of editing the panel that displays the individual posts. I'll mark some of the older text and hit delete. At that point you are hosed. The article disappears, and there's no obvious way to get it back. Any recommendations for a different reader? IPersonally, I sign up for the mailing list and use that instead of the newsgroup. That way, I can use my e-mail client to read everything, and the state is synced between machines (since I use IMAP). - Jonathan M Davis
Re: Damn - again!
On 9 November 2011 12:47, Gor Gyolchanyan gor.f.gyolchan...@gmail.comwrote: I've signed up for puremagic.D using my gmail acoount and i made a filder in gmail to add the D tag on emails, that come from puremagic.D. The discussion threads are stored as conversations (a neat feature of gmail) and are tagged with a red D label, making them very easy to work with. Ditto.. win!
Re: Damn - again!
On Wednesday, November 09, 2011 14:47:47 Gor Gyolchanyan wrote: I've signed up for puremagic.D using my gmail acoount and i made a filder in gmail to add the D tag on emails, that come from puremagic.D. The discussion threads are stored as conversations (a neat feature of gmail) and are tagged with a red D label, making them very easy to work with. Though gmail has a nasty habit of not sending your own messages to you (the ones that you send to the list), so it tends to screw up the threading. And since gmail's threads are linear, they don't handle the mesage hierarchy very well. I've always used a client on my machine which _is_ able to handle all of the threading correctly (or at least far better than gmail). And while I used to use gmail for the e-mail address (even if I didn't use it for reading any e-mail), I stopped due to issues like it not sending my own e-mails to me. I switched to gmx.com, which isn't quite a stable, but feature-wise it's much better IMHO. Regardless, having an IMAP account and using the mailing list can work quite well - especially if you're trying to access the newsgroup on multiple computers and therefore have to worry about syncing between them. - Jonathan M Davis
Re: Damn - again!
Steve Teale wrote: Any recommendations for a different reader? Steve Steve, a good alternative is what I use at the moment - KNode. Thunderbird is also a good choice for a newsgroups reader. I think Pan is okay as well.
Re: assert(obj) is an atrocity
Alex, it is a well know bug, I remember it from... ~2006... It has been reported as a bug ages ago... I/we totally agree with you.
Re: Damn - again!
On 2011-11-09 12:39, Dejan Lekic wrote: Steve Teale wrote: Any recommendations for a different reader? Steve Steve, a good alternative is what I use at the moment - KNode. Thunderbird is also a good choice for a newsgroups reader. I think Pan is okay as well. I'm using Thunderbird. I've symlinked the News directory to dropbox to have it automatically synced. -- /Jacob Carlborg
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 03:16:30 -0500, Timon Gehr timon.g...@gmx.ch wrote: On 11/08/2011 02:08 AM, Walter Bright wrote: http://drdobbs.com/blogs/cpp/231902461 Anyone want to do the reddit honors? Nice article! It isn't a template, and inout can only be used on function parameters and the return value. What about local variables? Yes. Local variables cease to exist beyond the scope of the function, so they are allowed. the main principal of inout is that it only exists as inout during the scope of the function, then goes back to its original const flavor (const/immutable/mutable). In fact, my original proposal called inout scoped const. -Steve
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 18:57:19 -0500, Martin Nowak d...@dawgfoto.de wrote: On Wed, 09 Nov 2011 00:01:09 +0100, Walter Bright newshou...@digitalmars.com wrote: On 11/8/2011 11:10 AM, Martin Nowak wrote: I personally find it much more astonishing that inout methods finally work. I literally meant methods as in member functions. Being able to use inout as method qualifier is way more important than achieving the same for free functions as it makes transitive qualifiers almost hassle free in simple cases. To give a bit of trivia, the main motivator for proposing what is now inout was trying to port Tango to D2. In doing this, I realized that in order to be const-correct, I was going to have to triplicate all property accessors on classes (and Tango uses classes + properties much more than Phobos does). The prospect of having three *identical* copies of the same function just so I could have something as simple as an accessor was reason enough to find a better solution before moving forward on Tango for D2. In other words, the astonishment was intentional :) BTW, I want to publicly thank Kenji Hara for his work on making inout a reality. He created the patch that solved all the remaining inout problems, then quickly fixed most of the remaining bugs found with his patch before this last release. Without his work, inout would still be a pipe-dream! -Steve
Re: Damn - again!
Any recommendations for a different reader? Opera :)
Re: How about a 100% CTFE?
On 09.11.2011 09:17, foobar wrote:
Don Wrote:
On 07.11.2011 14:13, Gor Gyolchanyan wrote:
After reading
http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
I had a thought:
Why not compile and run CTFE code in a separate executable, write it's
output into a file, read that file and include it's contents into the
object file being compiled?
This would cover 100% of D in CTFE, including external function calls
and classes;
String mixins would simply repeat the process of compiling and running
an extra temporary executable.
This would open up immense opportunities for such things as
library-based build systems and tons of unprecedented stuff, that I
can't imagine ATM.
First comment: classes and exceptions now work in dmd git. The remaining
limitations on CTFE are intentional.
With what you propose:
Cross compilation is a _big_ problem. It is not always true that the
source CPU is the same as the target CPU. The most trivial example,
which applies already for DMD 64bit, is size_t.sizeof. Conditional
compilation can magnify these differences. Different CPUs don't just
need different backend code generation; they may be quite different in
the semantic pass. I'm not sure that this is solvable.
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an X86???
}
I think we discussed those issues before.
1. size_t.sizeof:
auto a = mixin(size_t.sizeof); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU
That doesn't work. mixin happens _before_ CTFE. CTFE never does any
semantics whatsoever.
2. version (ARM) example - this needs clarification of the semantics. Two
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today. require
'mixin' to call it on HOST. This should be backwards compatible since we keep
the current CTFE and add support for multi-level compilation.
b. immutable x = ... is run via the new system which requires the function
armSpecificCode to be compiled ahead of time and provided to the compiler in
an object form. No Platform incompatibility is possible.
I don't see any problems with cross-compilation. It is a perfectly sound design
(Universal Turing machine) and it was successfully implemented several times
before: Lisp, scheme, Nemerle, etc.. It just requires to be a bit careful with
the semantic definitions.
AFAIK all these languages target a virtual machine.
Re: Type Qualifiers and Wild Cards
On Tue, 08 Nov 2011 08:08:19 -0500, deadalnix deadal...@gmail.com wrote: Le 08/11/2011 02:08, Walter Bright a écrit : http://drdobbs.com/blogs/cpp/231902461 Anyone want to do the reddit honors? Great article. The only point I would raise is the choice of inout as a keyword for this. This make no sens whatsoever. Here is why : - inout did exist in D1 and is different. - in and out qualifier already exists and have nothing to do with inout. - in and out are used for contracts and have nothing to do with inout. - the inout term has nothing to do with const/immutable/mutable. This is in a totally different lexical field. The argument given to use inout is that it was a dead keyword (it's totally superseded by ref). At the time of proposal, an argument against such a feature was that people didn't want to add any more keywords. Reusing inout keyword was a way to cut the legs off that argument, although I would have preferred not to use inout. It is kind of related, as in, the qualifier you pass in becomes the qualifier passed out. Another keyword should be choosen. vconst, as suggested here : http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2 is way more appropriate. On external details, but still important, I face the need of inout few days ago and did knew about it. The documentation on const/immutable ( http://www.d-programming-language.org/const3.html ) doesn't mention it. The page on fucntion mention it, but it would be nice to have at least a link on the const/immutable page. That documentation is not exactly documentation. It's an article on const. I agree it needs to be updated. -Steve
Re: assert(obj) is an atrocity
On 09-11-2011 01:57, Martin Nowak wrote:
On Wed, 09 Nov 2011 01:21:47 +0100, Timon Gehr timon.g...@gmx.ch wrote:
On 11/09/2011 01:18 AM, Martin Nowak wrote:
On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen
xtzgzo...@gmail.com wrote:
Hi,
As the title suggests, I'm going to be rather blunt about this.
assert(obj) testing the invariant *without* doing a null check is
insane for the following reasons:
1) It is not what a user expects. It is *unintuitive*.
2) assert(!obj) does an is-null check. assert(obj) is a completely
broken opposite of this.
3) No AssertError is thrown, which is the entire point of the built-in
assert().
4) The few added instructions for the null check hardly matter in a
*debug* build of all things.
I don't mind assert(obj) testing the invariant of obj. In fact, that
very much makes sense. But please, please, *please* check the object
for null first. This is a random inconsistency in the language with no
other justification than seg faults are convenient in a debugger. By
the same logic, we might as well not have array bounds checks.
However, the state of things is that array bounds checks are emitted
by default and users can disable them for e.g. a release build. I
don't see why this case is any different.
- Alex
It does check for null.
Only it's a runtime support function (_d_invariant) and druntime is
likely
compiled without assertions. Are you really suggesting to add a null
check before
every method call?
martin
No, he is suggesting to add a null check for assert(objref);, a
construct that *looks* as if it was a null check, but does something
almost unrelated.
Then just for reference, apply this patch to druntime and you'll get an
assertion instead.
diff --git a/src/rt/invariant.d b/src/rt/invariant.d
index 71337f1..bc5e53a 100644
--- a/src/rt/invariant.d
+++ b/src/rt/invariant.d
@@ -16,13 +16,16 @@
/**
*
*/
+import core.exception;
+
void _d_invariant(Object o)
{ ClassInfo c;
//printf(__d_invariant(%p)\n, o);
// BUG: needs to be filename/line of caller, not library routine
- assert(o !is null); // just do null check, not invariant check
+ if (o is null)
+ throw new AssertError(_d_invariant called with null reference.);
c = o.classinfo;
do
But as that BUG note states, it still isn't sufficient/consistent. :)
Thanks for the patch though!
- Alex
Re: Type Qualifiers and Wild Cards
On 09.11.2011 00:57, bearophile wrote: Walter: The whole too many keywords issue strikes me as strange. English has over a million words in it. Who cares if a language uses 80 or 100 of them? What difference can it possibly make? How can an extra 20 words pollute the million word namespace (and not including any non-word identifiers (like inout))? I agree. This is also why I have suggested auto_ref instead of auto ref, that I think is a bit confusing. auto ref is something we should *really* get rid of. Because it isn't 'auto'. There should be a symmetry between: auto --- const auto ref --- const ref But there isn't. The correct patten is: auto --- const ref --- const ref auto ref --- const auto ref And note that auto const ref is not the same as const auto ref. I'd be happy with auto_ref or autoref or pretty much any sequence of characters that doesn't contain auto .
Re: Version Identifiers for Platforms / Architectures not supported byDMD
On 09-11-2011 02:29, Daniel Murphy wrote:
There is always one backwards compatible solution:
We could make version identifiers case insensitive.
That's not backwards-compatible. What if someone out there is really
using Foo and fOO for two different things? I know this sounds
far-fetched, but the possibility is there.
It's a change from everywhere else in the language, but...
There is no 'correct' casing for os/architecture etc
windows vs Windows, linux vs Linux, x86 vs X86 are meaningless distinctions.
It's proper spelling of the titles of the architectures/OSs. I don't see
how this is not correct.
Invalid identifiers are _silently_ accepted.
eg.
version(Linux) {}
Would anybody ever _actually_ mean Linux here?
Maybe... they could have:
version (linux) { version (Linux); }
to fix the inconsistency that is in place now. ;)
Because it works on a is/is not defined basis, this is one case where case
sensitivity harms usability. You never get an error for messing up the
casing, unless you explicitly add a static assert in an else clause.
Very true. But you're supposed to do that anyway, as Walter pointed out
in a post to the druntime mailing list, because it aids portability.
Does anybody really define both 'MyVersion' and 'myVersion' and expect them
to do different things?
I think the inconsistency and the small addition to the spec are worth it to
have the compiler silently and automatically do the right thing, and remove
the impact of some incredibly inconsistent and arbirtary casing choices.
In general, I agree, but this would be a breaking change no matter how
you look at it. I'm not sure if that's a good idea.
- Alex
Re: assert(obj) is an atrocity
On 09-11-2011 06:23, Davidson Corry wrote: I don't get it -- why is this even necessary? Please don't answer here. Swing over to D.learn, where I am starting an assert(obj) is a mystery thread... ...because answers that start with because... belong in a learn newsgroup. Thanks in advance. -- Davidson On 11/8/2011 2:35 PM, Alex Rønne Petersen wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than seg faults are convenient in a debugger. By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex This has nothing to do with learning. This entire thread is a language design counter-argument. - Alex
Re: assert(obj) is an atrocity
On 09-11-2011 12:48, Dejan Lekic wrote: Alex, it is a well know bug, I remember it from... ~2006... It has been reported as a bug ages ago... I/we totally agree with you. Yep, I just figured I'd bring some attention to it again, as well as some arguments for why the way it is now is broken. - Alex
Re: Disallow arrays as pointers
On 07.11.2011 10:45, Dejan Lekic wrote: Don wrote: It was a bug. And it's now been fixed. Don, care to explain why? If I want to treat D's array like I would do in C, why not allow me do so? I had no involvement with it at all. Although, when we originally banned implicit conversions from arrays to pointers, it was because it was _the_ most common bug in D code. Especially when you pass a char[] array to an extern(C) function that accepts a char *. It really was a disaster. Just add .ptr if you want to convert it to a pointer. It's beautiful, really.
Re: Phobos examples and auto
On Tue, 08 Nov 2011 17:53:06 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: On Tuesday, November 08, 2011 17:25:57 Marco Leise wrote: After some hacking into the keyboard layout file, I now use the alias ℕ (the mathematical symbol for the non-negative integral number) everywhere instead of the ugly size_t. It is even shorter than 'auto'. ℕ i = 5; ℕ j = i; ℕ k = j; ℕ l = k; ;) LOL. And no one but you will have any idea what your code is doing. It _is_ kind of cool to see unicode like that in D, but that's _really_ bad practice if you intend anyone else to ever read your code. If it's just for you, then you obviously can do whatever you want, but size_t is the correct name and what others are going to expect if they ever read your code. Also, ℕ would more correctly be a BigUInt, as it has no upper bound.
Re: Damn - again!
On Wed, 09 Nov 2011 08:02:21 -0500, Trass3r u...@known.com wrote: Any recommendations for a different reader? Opera :) I use opera too. And it has been somewhat valuable for finding old posts. I set opera to download all headers, and now I have instant search through headers and messages I've viewed. Makes it easy to find bugs and old messages. -Steve
Re: Phobos examples and auto
On 5 November 2011 22:14, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 11/5/11 3:02 PM, bearophile wrote: Andrei Alexandrescu: If we avoid auto in documentation examples but we do use it in everyday code, we effectively foster a style that's foreign and non-idiomatic to newcomers. Sample code should mimic real code. If real code would use auto, sample code should use auto. D programmers are probably able to learn to use auto later, because it's handy, it's an attractor. On the other hand one of the main purposes of the online documentation is to be as clear as possible. D written by newbies is not the same D written by D experts. But documentation must be written for D newbies too, because they are ones that have more need of documentation. The code written in the thousands of examples in the very good Pascal/Delphi docs was written in a clear style that is not the same compact style an expert Delphi programmer writes code. So I'd like D docs to avoid auto when the types are not very clear. The purpose of the docs is not to shows examples of idiomatic D code written by experts. Patronizing one's reader is a common trap. There's nothing patronising about printing the types clearly. As a D new comer myself, I DEFINITELY want to see the types associated with function documentation in such examples. It re-enforces my memory, and also informs me if I don't know without wasting my time looking it up. It might even be nice if that doc also hyperlinked to the type and function references themselves... save me more time looking this stuff up.
Re: Type Qualifiers and Wild Cards
Timon Gehr Wrote: Actually, we don't have the transitive qualifier safety yet: http://d.puremagic.com/issues/show_bug.cgi?id=6912 But it should be a fairly easy fix to do. Yeah, I think a simple fix will be enough here.
Re: Type Qualifiers and Wild Cards
Don Wrote: I'd be happy with auto_ref or autoref or pretty much any sequence of characters that doesn't contain auto . As it's a function attribute, it doesn't have to be a keyword in the first place. @autoref is just fine.
Re: Version Identifiers for Platforms / Architectures not supported byDMD
Alex Rønne Petersen xtzgzo...@gmail.com wrote in message news:j9dviv$1jbd$4...@digitalmars.com... ... In general, I agree, but this would be a breaking change no matter how you look at it. I'm not sure if that's a good idea. - Alex Thanks for the comments. I expect this change would fix many, many more bugs than it causes. But, as it is a breaking change (very slightly), and a special case, I doubt this will ever happen unless Walter loves the idea. Walter?
Re: Type Qualifiers and Wild Cards
The whole too many keywords issue strikes me as strange. English has over a million words in it. Who cares if a language uses 80 or 100 of them? What difference can it possibly make? How can an extra 20 words pollute the million word namespace (and not including any non-word identifiers (like inout))? Another silly aspect of this issue is all keywords could be replaced by a sequence of special characters. For example, we could replace inout with ##. Voila! Less keywords! But is that better? Keywords exist to make the language more readable. That's why we use inout instead of ##, and it's why we use + instead of add. Well, using inout contradict this argument. inout isn't reminding in any way of its functionnality. It is more readable than ##, for sure, but way less than any word from const/immutable lexical field.
Re: How about a 100% CTFE?
Don Wrote:
On 09.11.2011 09:17, foobar wrote:
Don Wrote:
On 07.11.2011 14:13, Gor Gyolchanyan wrote:
After reading
http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
I had a thought:
Why not compile and run CTFE code in a separate executable, write it's
output into a file, read that file and include it's contents into the
object file being compiled?
This would cover 100% of D in CTFE, including external function calls
and classes;
String mixins would simply repeat the process of compiling and running
an extra temporary executable.
This would open up immense opportunities for such things as
library-based build systems and tons of unprecedented stuff, that I
can't imagine ATM.
First comment: classes and exceptions now work in dmd git. The remaining
limitations on CTFE are intentional.
With what you propose:
Cross compilation is a _big_ problem. It is not always true that the
source CPU is the same as the target CPU. The most trivial example,
which applies already for DMD 64bit, is size_t.sizeof. Conditional
compilation can magnify these differences. Different CPUs don't just
need different backend code generation; they may be quite different in
the semantic pass. I'm not sure that this is solvable.
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an X86???
}
I think we discussed those issues before.
1. size_t.sizeof:
auto a = mixin(size_t.sizeof); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU
That doesn't work. mixin happens _before_ CTFE. CTFE never does any
semantics whatsoever.
If I wasn't clear before - the above example is meant to illustrate how
multilevel compilation *should* work.
If you want, we can make it even clearer by replacing 'mixin' above with
'macro'.
2. version (ARM) example - this needs clarification of the semantics. Two
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today.
require 'mixin' to call it on HOST. This should be backwards compatible
since we keep the current CTFE and add support for multi-level compilation.
b. immutable x = ... is run via the new system which requires the function
armSpecificCode to be compiled ahead of time and provided to the compiler
in an object form. No Platform incompatibility is possible.
I don't see any problems with cross-compilation. It is a perfectly sound
design (Universal Turing machine) and it was successfully implemented
several times before: Lisp, scheme, Nemerle, etc.. It just requires to be a
bit careful with the semantic definitions.
AFAIK all these languages target a virtual machine.
Nope. See http://www.cons.org/cmucl/ for a native lisp compiler.
Re: Type Qualifiers and Wild Cards
On 09/11/2011 15:29, deadalnix wrote: inout isn't reminding in any way of its functionnality. It is more readable than ##, for sure, but way less than any word from const/immutable lexical field. inout means transfer the input qualifier to the output, it is descriptive enough.
Re: Damn - again!
KNode. Steve Teale wrote: I use the Pan newsreader. In the mornings when I'm looking at digitalmars.D I regularly make the mistake of editing the panel that displays the individual posts. I'll mark some of the older text and hit delete. At that point you are hosed. The article disappears, and there's no obvious way to get it back. Any recommendations for a different reader? Steve
Re: ScintillaD 0.0.1
Hey zhang, I see you can now run SciteD, but it still crashes of course. Does ScintillaD have more bugs to fix, or just SciteD, or even both?
Linking Error (WS2_32.LIB)
Hey, i wanted to write a basic cli chat to get familiar with d. So i looked up the default library for sockets and found std.socket; There is a note that says compile with ws2_32.lib. When i simply run: dmd main.d it tells me: OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address8toStringMFZAya dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address13addressFamilyMFZE3std6socket1 3AddressFamily dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address7nameLenMFZi dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address4nameMFZPS3std1c7windows7winsoc k8sockaddr --- errorlevel 4 So then i tried this: dmd main.d -Llib ws2_32.lib But i keep getting the exact same error plus OPTLINK : Warning 9: Unknown Option : NOILIB doing this: dmd main.d link client.obj -lib ws2_32.lib Its the same again plus OPTLINK : Warning 9: Unknown Option : LIB Can somone please tell me how to link the compiled code correctly so that i can run it? Or is this a bug? Greets, Tobi
Re: bug in std.array.insertInPlace ?
On Tuesday, November 08, 2011 23:55 Ruslan Mullakhmetov wrote: Hi, I found some strange behavior of std.array.insertInPlace leading to segfault. The example below works for int, it is failed for reference type with array becoming of length bigger 1024 on windows (x64) and 512 on linux (x64). code: http://cloud.theambient.org/0O360r1d2t1g09171F1m Is it my bug or compiler? It might by related to http://d.puremagic.com/issues/show_bug.cgi?id=6874 - Jonathan M Davis
Re: Linking Error (WS2_32.LIB)
Tobse tobia...@onlinehome.de wrote in message news:j9efl3$2igk$1...@digitalmars.com... Hey, i wanted to write a basic cli chat to get familiar with d. So i looked up the default library for sockets and found std.socket; There is a note that says compile with ws2_32.lib. When i simply run: dmd main.d it tells me: OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address8toStringMFZAya dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address13addressFamilyMFZE3std6socket1 3AddressFamily dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address7nameLenMFZi dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address4nameMFZPS3std1c7windows7winsoc k8sockaddr --- errorlevel 4 So then i tried this: dmd main.d -Llib ws2_32.lib But i keep getting the exact same error plus OPTLINK : Warning 9: Unknown Option : NOILIB doing this: dmd main.d link client.obj -lib ws2_32.lib Its the same again plus OPTLINK : Warning 9: Unknown Option : LIB Can somone please tell me how to link the compiled code correctly so that i can run it? Or is this a bug? Greets, Tobi Not sure whether or not there's some other problem, but try this: dmd main.d ws2_32.lib
Re: Type Qualifiers and Wild Cards
On 11/9/11 9:58 AM, Nick Treleaven wrote: On 09/11/2011 15:29, deadalnix wrote: inout isn't reminding in any way of its functionnality. It is more readable than ##, for sure, but way less than any word from const/immutable lexical field. inout means transfer the input qualifier to the output, it is descriptive enough. Thank you. I was itching to write that but was hoping somebody else would. Andrei
Re: Linking Error (WS2_32.LIB)
No, did not work, same result. C:\Users\Tobse\Documents\chatdmd main.d ws2_32.lib -ofdist\client.exe OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address8toStringMFZAya dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address13addressFamilyMFZE3std6socket1 3AddressFamily dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address7nameLenMFZi dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address4nameMFZPS3std1c7windows7winsoc k8sockaddr --- errorlevel 4
Re: Linking Error (WS2_32.LIB)
After compiling the sources dmd will call optlink to do the linking. I don't know why it's failing, but try to pass -v to dmd to see what's happening. Once you're done, you'll see how it calls optlink which is documented here: http://www.digitalmars.com/ctg/optlink.html Command line operation of OPTLINK uses the following syntax: LINK obj[,out[,map[,lib[,def[,res] Please also have a look at the environment variables (See link). Optlink will use them as search pathes. But it's also explanied there. I'm not quite sure, because I'm living in the linux world. But maybe you could also use the mingw tools to link ??? - mta`chrono
Re: Type Qualifiers and Wild Cards
Andrei Alexandrescu wrote: On 11/9/11 9:58 AM, Nick Treleaven wrote: On 09/11/2011 15:29, deadalnix wrote: inout isn't reminding in any way of its functionnality. It is more readable than ##, for sure, but way less than any word from const/immutable lexical field. inout means transfer the input qualifier to the output, it is descriptive enough. Thank you. I was itching to write that but was hoping somebody else would. Andrei it would be a good solution, if in and out didn't exists. I was _very_ confused, when I first saw inout and thougth it would be a combination of in and out. So I think it deserves a prominent place in the documentation next to in and out.
RFC curl
Hi, So after the last review of the etc.curl there were some requests for making it simpler. After some thinking, refactoring and documentation I've come up with a somewhat changed API. Before sending it for official review again I would really like some comments on the new API and if you think it is better or worse etc. http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Thanks, Jonas
Re: ScintillaD 0.0.1
Any features you're planning to add that aren't in C++ Scintilla? (I'd *love* to be able to have support for elastic tabstops.) Never heard of elastic tabstops before. Thx for mentioning that.
Integer overflow bug in windows
http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx
Re: Integer overflow bug in windows
Am 09.11.2011, 22:34 Uhr, schrieb Kagamin s...@here.lot: http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx Solution: upgrade all computers to 64-bit
Re: RFC curl
Am 09.11.2011, 21:53 Uhr, schrieb Jonas Drewsen jdrew...@nospam.com: Hi, So after the last review of the etc.curl there were some requests for making it simpler. After some thinking, refactoring and documentation I've come up with a somewhat changed API. Before sending it for official review again I would really like some comments on the new API and if you think it is better or worse etc. http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Thanks, Jonas Amazing! D docs that look like they were made to be read by a human being! ;) I like the accessibility, that gets you right to the point for any use case. I did not compare it to your previous version though. The external links sometimes have four slashes http: and the text Authentication method equal to looks incomplete and you wrote valie instead of value. Good luck with the next review!
Re: Bartosz about Chapel
On Wed, Nov 9, 2011 at 10:31 AM, Simen Kjærås simen.kja...@gmail.comwrote: On Tue, 08 Nov 2011 05:39:07 +0100, Caligo iteronve...@gmail.com wrote: On Mon, Nov 7, 2011 at 7:51 PM, bearophile bearophileh...@lycos.com wrote: Bartosz talks a bit about the very nicely designed Chapel language: http://bartoszmilewski.**wordpress.com/2011/11/07/** supercomputing-in-seattle/http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/ (But my appreciation for Chapel design is on other things). Bye, bearophile Interesting (maybe useless) facts: Chapel has 59 keywords. D has, I think, 107 keywords. C++11, I think, 81. Python has 33. Interesting, questionably. Useless, indeed. how many keywords in D are needed because the preprocessor is built into the language itself?
Re: Integer overflow bug in windows
Kagamin: http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx I'd like a runtime error when an integral overflows (unsigned numbers too, the C99 Standard is not a religion book for me), unless where asked otherwise. Bye, bearophile
Re: Type Qualifiers and Wild Cards
Walter: http://drdobbs.com/blogs/cpp/231902461 Anyone want to do the reddit honors? On Reddit I see the discussion is a bit about merging of templates that produce the same function code. This is already possible in D, compiling with the LDC1 (and maybe LDC2 too) compiler using the -mergefunc switch. I think according to the C standard all functions must have different function pointers, and I presume D has the same rule (even if I don't remember reading it in the D specs). This problem is solved leaving a tiny stub that just contains a jump instruction for the removed duplicated functions. This jump is probably nearly always correctly predicted by the CPU, because it's hard-coded. As far as I know this -mergefunc is not able to remove partially duplicated functions, this is left to future improvements of the LLVM back-end. Bye, bearophile
Re: How about a 100% CTFE?
On 09.11.2011 16:30, foobar wrote:
Don Wrote:
On 09.11.2011 09:17, foobar wrote:
Don Wrote:
On 07.11.2011 14:13, Gor Gyolchanyan wrote:
After reading
http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
I had a thought:
Why not compile and run CTFE code in a separate executable, write it's
output into a file, read that file and include it's contents into the
object file being compiled?
This would cover 100% of D in CTFE, including external function calls
and classes;
String mixins would simply repeat the process of compiling and running
an extra temporary executable.
This would open up immense opportunities for such things as
library-based build systems and tons of unprecedented stuff, that I
can't imagine ATM.
First comment: classes and exceptions now work in dmd git. The remaining
limitations on CTFE are intentional.
With what you propose:
Cross compilation is a _big_ problem. It is not always true that the
source CPU is the same as the target CPU. The most trivial example,
which applies already for DMD 64bit, is size_t.sizeof. Conditional
compilation can magnify these differences. Different CPUs don't just
need different backend code generation; they may be quite different in
the semantic pass. I'm not sure that this is solvable.
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an X86???
}
I think we discussed those issues before.
1. size_t.sizeof:
auto a = mixin(size_t.sizeof); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU
That doesn't work. mixin happens _before_ CTFE. CTFE never does any
semantics whatsoever.
If I wasn't clear before - the above example is meant to illustrate how
multilevel compilation *should* work.
Sorry, I don't understand what you're suggesting here.
If you want, we can make it even clearer by replacing 'mixin' above with
'macro'.
That doesn't help me. Unless it means that what you're talking about
goes far, far beyond CTFE.
Take std.bigint as an example, and suppose we're generating code for ARM
on an x86 machine. The final executable is going to be using BigInt, and
CTFE uses it as well.
The semantic pass begins. The semantic pass discards all of the
x86-specific code in favour of the ARM-specific stuff. Now CTFE runs.
How can it then run natively on x86? All the x86 code is *gone* by then.
How do you deal with this?
2. version (ARM) example - this needs clarification of the semantics. Two
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today. require
'mixin' to call it on HOST. This should be backwards compatible since we keep
the current CTFE and add support for multi-level compilation.
b. immutable x = ... is run via the new system which requires the function
armSpecificCode to be compiled ahead of time and provided to the compiler in
an object form. No Platform incompatibility is possible.
I don't see any problems with cross-compilation. It is a perfectly sound design
(Universal Turing machine) and it was successfully implemented several times
before: Lisp, scheme, Nemerle, etc.. It just requires to be a bit careful with
the semantic definitions.
AFAIK all these languages target a virtual machine.
Nope. See http://www.cons.org/cmucl/ for a native lisp compiler.
That looks to me, as if it compiles to a virtual machine IR, then
compiles that. The real question is whether the characteristics of the
real machine are allowed to affect front-end semantics. Do any of those
languages do that?
Re: Integer overflow bug in windows
On 09-11-2011 23:49, bearophile wrote: Kagamin: http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx I'd like a runtime error when an integral overflows (unsigned numbers too, the C99 Standard is not a religion book for me), unless where asked otherwise. Bye, bearophile If anything, we should do it like C#: have checked/unchecked arithmetic blocks. - Alex
Re: Bartosz about Chapel
On 11/9/2011 2:45 PM, Danni Coy wrote: how many keywords in D are needed because the preprocessor is built into the language itself? It's true, people forget about the preprocessor keywords when counting C++ keywords.
Re: Version Identifiers for Platforms / Architectures not supported byDMD
On 11/9/2011 6:46 AM, Daniel Murphy wrote:
But, as it is a breaking change (very slightly), and a
special case, I doubt this will ever happen unless Walter loves the idea.
Walter?
Sorry, I don't love the idea. I dislike it for its inconsistency with the rest
of the language. The trend in programming languages and operating systems has,
for a long time, been towards case sensitivity.
BTW, the correct way to write version sensitive code is:
version (linux)
{
...
}
else version (OSX)
{
...
}
else
static assert(0, unsupported OS version);
Otherwise, it's miserable to find and tweak all the version sensitive code in
your codebase. Here's a WRONG WRONG WRONG way:
version (linux)
{
...
}
else /* Windows */
{
...
}
Looks stupid, but I tend to often see stuff like this in C, C++ and D source
code. Even in my own. This is also why there's no ! for versions:
version (!linux)
{
...
}
Aaaaggg. I'm pretty fed up with seeing that crap in C code. And if you see
any of it in dmd or phobos sources, please file a bugzilla report! Show no mercy.
Re: RFC curl
On 11/9/2011 12:53 PM, Jonas Drewsen wrote: Before sending it for official review again I would really like some comments on the new API and if you think it is better or worse etc. http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Thank you so much for doing this. I think it's a nice piece of work. Some nitpicky comments: * libcurl should be a link to where people can read up on what it is. I suggest http://curl.haxx.se/libcurl Point out that the user will need libcurl installed on their system in order to use etc.curl. * Need a brief statement on why a D programmer should prefer using etc.curl rather than directly use libcurl. * ranges should be a link to what a range is * examples should include import etc.curl; and any other needed, like std.stdio. In fact, they should be cut paste complete examples that are compilable and runnable. * Keep comment lines under 40 characters; use multiple lines for longer comments. (This is so things format better for small screens.) Try to format code so it doesn't need more than 40 lines. I tend to indent by only two spaces in documentation which helps. * Remove all instances of the word you. For example, If you need more control than the low high level functions provide, you'll have to use the low level API: rewrite as: For more control than the low high level functions provide, use the low level API: Note how much simpler and direct it is. You is almost always an unnecessary filler word, and frankly has no place in a reference work. * For the same reason, get rid of we: First, we create an instance = First, create an instance We then set = Then set * derivate = derived * Connection type used when the url should be used to auto detect protocol .. I have no idea what this sentence means. * HTTP/FTP upload from local file system. = Upload file from local file system using the HTTP or FTP protocol. And which protocol would be used? * A string with the content of the resource pointer to by the url Missing period. Grammar problems, how about: A string containing the content of the resource pointed to by the url. Most of these apply to the rest of the documentation. Also, need more examples. I tend to like references to things in other modules to be hyperlinks. For example, writeln should be $(LINK2 http://www.d-programming-language.org/phobos/std_stdio.html#writeln, writeln)
Re: RFC curl
On 11/9/2011 4:24 PM, Walter Bright wrote: On 11/9/2011 12:53 PM, Jonas Drewsen wrote: Before sending it for official review again I would really like some comments on the new API and if you think it is better or worse etc. http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Thank you so much for doing this. I think it's a nice piece of work. I forgot to mention: I like the cheat sheet a lot.
Re: RFC curl
Walter: Thank you so much for doing this. I think it's a nice piece of work. I agree. As they say, easy things should be easy and hard things should be possible. * libcurl should be a link to where people can read up on what it is. I suggest http://curl.haxx.se/libcurl Point out that the user will need libcurl installed on their system in order to use etc.curl. Is the (just) Windows compiled version present in the DMD zip? I don't remember what was the decision on this (I'd like it to be present). Bye, bearophile
Reminder: Two days left to review Jesse Phillips' CSV Parser
As a reminder, the review of Jesse Phillips' CSV parser ends at the end of Friday and will be followed by one week of voting. Please speak up now about any remaining issues.
Re: RFC curl
On Thu, 10 Nov 2011 01:25:29 +0100, Walter Bright newshou...@digitalmars.com wrote: On 11/9/2011 4:24 PM, Walter Bright wrote: On 11/9/2011 12:53 PM, Jonas Drewsen wrote: Before sending it for official review again I would really like some comments on the new API and if you think it is better or worse etc. http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Thank you so much for doing this. I think it's a nice piece of work. I forgot to mention: I like the cheat sheet a lot. Indeed. I am tempted to argue all of our docs should have that.
Re: RFC curl
On Wednesday, November 09, 2011 16:58 bearophile wrote: Is the (just) Windows compiled version present in the DMD zip? I don't remember what was the decision on this (I'd like it to be present). Currently, no version of libcurl is included in the zip file. I don't believe that there has been any decision on what to do about it. But if we do end up including it, then that's one more reason to consider splitting up the zip file by OS. - Jonathan M Davis
Re: How about a 100% CTFE?
On 07.11.2011 17:00, Gor Gyolchanyan wrote: Well and somefunction ? It does modify teh value of a too. Is it executed before ? after ? What is the value at the end of all that ? Obviously it will be incremented first. The order is dependent of the rules by which the conditions are evaluated at compile-time. For example, the compiler will build a depth-first list of the import tree and evaluate code sequentially in each module. This is not what it does now. At present, the order of compile-time evaluation is not defined; DMD currently does it vaguely in lexical order but that is planned to change in the near future. 'static if' and 'mixin' will be evaluated in lexical order, before anything else is done. Afterwards, everything else will be evaluated on-demand. Apart from the static if/mixin pass, compilation can proceed in parallel (though the current implementation doesn't yet do this) which means there's no ordering (multiple items may complete compilation simultaneously). Allowing globals to be modified at compile time would destroy this.
Re: RFC curl
On Wednesday, November 09, 2011 17:05 Simen Kjærås wrote: On Thu, 10 Nov 2011 01:25:29 +0100, Walter Bright newshou...@digitalmars.com wrote: On 11/9/2011 4:24 PM, Walter Bright wrote: On 11/9/2011 12:53 PM, Jonas Drewsen wrote: Before sending it for official review again I would really like some comments on the new API and if you think it is better or worse etc. http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Thank you so much for doing this. I think it's a nice piece of work. I forgot to mention: I like the cheat sheet a lot. Indeed. I am tempted to argue all of our docs should have that. It's essentially what std.algorithm does now, and std.container does something similar. I'd love to do something like that with std.datetime, but the fact that the anchors that ddoc generates have no concept of hiearchy (e.g. every year function in the file gets #year for its anchor rather than something like #Date.year, #DateTime.year, etc.). So, I couldn't provide any links in such a cheat sheat. I think that one or two people have said that they'd look into fixing it, but no one has actually fixed it yet. If no one else fixes it any time soon, I may be forced to go dig into ddoc to figure it out myself, which is definitely not where I want to be spending my time if I can avoid it. - Jonathan M Davis
Re: Linking Error (WS2_32.LIB)
On Wed, 09 Nov 2011 20:09:39 +0200, Tobse tobia...@onlinehome.de wrote: Hey, i wanted to write a basic cli chat to get familiar with d. So i looked up the default library for sockets and found std.socket; There is a note that says compile with ws2_32.lib. When i simply run: dmd main.d it tells me: OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address8toStringMFZAya dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address13addressFamilyMFZE3std6socket1 3AddressFamily dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address7nameLenMFZi dist\client.obj(client) Error 42: Symbol Undefined _D3std6socket7Address4nameMFZPS3std1c7windows7winsoc k8sockaddr --- errorlevel 4 These errors don't have anything to do with ws2_32.lib. It looks like you are trying to use the latest version of std.socket sources (from git) with an outdated phobos.lib. Did you download the latest version of std.socket without rebuilding Phobos, or something? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Bartosz about Chapel
On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright newshou...@digitalmars.comwrote: On 11/9/2011 2:45 PM, Danni Coy wrote: how many keywords in D are needed because the preprocessor is built into the language itself? It's true, people forget about the preprocessor keywords when counting C++ keywords. You're right, I did forget about the preprocessor. Besides the usual things in the header files, I always try to avoid macros. There are about 20 directives, so that puts the keywords count for C++ to 101. It's still fewer than D. Does that mean D is more complex than C++? Python with 33, I think most would agree that is has a very consice grammer.
Re: Reminder: Two days left to review Jesse Phillips' CSV Parser
On 11/9/2011 8:02 PM, dsimcha wrote:
As a reminder, the review of Jesse Phillips' CSV parser ends at the end
of Friday and will be followed by one week of voting. Please speak up
now about any remaining issues.
BTW, here's my second round of review now that some changes have been made:
Design-level stuff:
How do I use csvReader to process a CSV file as it's being read in (i.e.
I don't want to ever have the whole file in memory)? I guess I could do
something like:
import std.algorithm, std.stdio, std.csv, std.conv;
void main() {
auto file = File(foo.csv);
auto chars = joiner(file.byLine(), '\n');
auto reader = csvReader(chars);
}
If this would work, though, then it should be documented. I'd also like
to see csvReader tested with lowest-common-denominator input ranges
instead of just strings, which are bidirectional ranges and can be
treated as random access if they only have ASCII characters. Also, IMHO
we really need a ByChar range in std.stdio instead of the joiner kludge
I used, though I'm not sure about the details with regard to how Unicode
support should work.
Still no support for writing CSVs? I understand writing is complicated
from an API design perspective. Maybe it would be easiest to just
provide an enquote() function that adds quotes to a field and escapes
any that are already inside the field and let the user handle the higher
level stuff, since this is pretty simple.
Minor documentation nitpicks:
CSVException: IncompletCellException - IncompleteCellException (typo)
The first csvReader example: You declare the variable count but don't
use it.
Records, Record: front(), empty(), popFront() should not mention
std.range.InputRange. These interfaces are virtual function-based
interfaces in case someone needs virtual function-based access to a
range. They are not used in most cases when ranges are used because
templates are usually better.
Re: moving wxd to github
FWIW the samples compile fine with the latest changesets, using dmd make. Thanks for your work, Anders!
Re: RFC curl
On 11/9/2011 5:13 PM, Jonathan M Davis wrote: On Wednesday, November 09, 2011 16:58 bearophile wrote: Is the (just) Windows compiled version present in the DMD zip? I don't remember what was the decision on this (I'd like it to be present). Currently, no version of libcurl is included in the zip file. I don't believe that there has been any decision on what to do about it. But if we do end up including it, then that's one more reason to consider splitting up the zip file by OS. I don't want us to get caught in the rat race of the version that comes with the compiler is out of date. libcurl has its own development cycle, and dmd should not be slaved to that.
Re: Bartosz about Chapel
It means D can do the same thing with more explanatory keywords, yet in a more concise way. On 09/11/2011 7:46 PM, Caligo wrote: On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright newshou...@digitalmars.com mailto:newshou...@digitalmars.com wrote: On 11/9/2011 2:45 PM, Danni Coy wrote: how many keywords in D are needed because the preprocessor is built into the language itself? It's true, people forget about the preprocessor keywords when counting C++ keywords. You're right, I did forget about the preprocessor. Besides the usual things in the header files, I always try to avoid macros. There are about 20 directives, so that puts the keywords count for C++ to 101. It's still fewer than D. Does that mean D is more complex than C++? Python with 33, I think most would agree that is has a very consice grammer.
Re: Bartosz about Chapel
On Thu, Nov 10, 2011 at 11:46 AM, Caligo iteronve...@gmail.com wrote: On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright newshou...@digitalmars.comwrote: On 11/9/2011 2:45 PM, Danni Coy wrote: how many keywords in D are needed because the preprocessor is built into the language itself? It's true, people forget about the preprocessor keywords when counting C++ keywords. You're right, I did forget about the preprocessor. Besides the usual things in the header files, I always try to avoid macros. There are about 20 directives, so that puts the keywords count for C++ to 101. It's still fewer than D. Does that mean D is more complex than C++? Do keywords like unittest make the language more or less complex? (to use one that isn't in C++). Python with 33, I think most would agree that is has a very consice grammer. Being a dynamic language python would not have keywords for data types right? That has to be a large part of the difference. That said I do have to say that Python does feel very concise.
Re: RFC curl
On 11/9/11 6:24 PM, Walter Bright wrote: I tend to like references to things in other modules to be hyperlinks. For example, writeln should be $(LINK2 http://www.d-programming-language.org/phobos/std_stdio.html#writeln, writeln) That should be XREF actually. Andrei
Re: Bartosz about Chapel
On 11/9/2011 5:46 PM, Caligo wrote: There are about 20 directives, so that puts the keywords count for C++ to 101. It's still fewer than D. Does that mean D is more complex than C++? C++ has unsigned, long, and unsigned long while D has uint, long, and ulong. That's one more keyword; does that make D more complex than C++? Python with 33, I think most would agree that is has a very consice grammer. Python lacks a lot of powerful features that are in D.
Re: RFC curl
On Wednesday, November 09, 2011 18:38:48 Walter Bright wrote: On 11/9/2011 5:13 PM, Jonathan M Davis wrote: On Wednesday, November 09, 2011 16:58 bearophile wrote: Is the (just) Windows compiled version present in the DMD zip? I don't remember what was the decision on this (I'd like it to be present). Currently, no version of libcurl is included in the zip file. I don't believe that there has been any decision on what to do about it. But if we do end up including it, then that's one more reason to consider splitting up the zip file by OS. I don't want us to get caught in the rat race of the version that comes with the compiler is out of date. libcurl has its own development cycle, and dmd should not be slaved to that. Yeah. That's one reason why I'm not a fan of the idea of distributing it with dmd. So, it won't hurt my feelings any if it never gets put into the zip file. However, we're going to have to make it clear in the documentation on how to get your hands on an appropriate libcurl library (especially since any version of it that you're likely to find online would be in the wrong library format). - Jonathan M Davis
Re: How about a 100% CTFE?
On 11/8/11 10:44 AM, deadalnix wrote:
Le 08/11/2011 14:31, Gor Gyolchanyan a écrit :
Well except that module can modify a and not be in the tree.
A single compilation includes only two parts: compiling D source code
and linking in object files or static libraries. object files and
static libraries are by no means involved in compile-time activity,
which leaves us with with compiling D source code. A single
compilation of D source code can be viewed as a list of import trees,
originating from the enlisted modules to be compiled. After
eliminating duplicates we have a list of small trees, which can be
rooted together to form a single tree, which in turn can be processed
as described above. Optionally, in order to allow separate
compilations, a cache can be maintained to hold the results of
previous compile-time computations to be used in the next ones inside
a project (to be defined).
module a;
int a = 0;
---
module b;
import a;
int somefunction() {
return ++a;
}
static assert(somefunction() = 1);
---
module c;
import a;
int somefunction() {
return ++a;
}
static assert(somefunction() = 1);
There answer here is: who cares?
Is your point to prove that you can make some code that is useless? Why
not make something useful with CTFE?
It's sad to see people come here proposing great ideas (I think CTFE
beyond what D is capable is great, and I'm implementing that in my own
language) and other people come with nonsense useless examples to ask
What happens here?
Use the tool to make magic, not to show how you can get undefined
behaviour...
Re: Version Identifiers for Platforms / Architectures not supported byDMD
Walter Bright newshou...@digitalmars.com wrote:
On 11/9/2011 6:46 AM, Daniel Murphy wrote:
But, as it is a breaking change (very slightly), and a
special case, I doubt this will ever happen unless Walter loves the idea.
Walter?
Sorry, I don't love the idea. I dislike it for its inconsistency with the
rest of the language. The trend in programming languages and operating
systems has, for a long time, been towards case sensitivity.
BTW, the correct way to write version sensitive code is:
version (linux)
{
...
}
else version (OSX)
{
...
}
else
static assert(0, unsupported OS version);
Otherwise, it's miserable to find and tweak all the version sensitive
code in your codebase. Here's a WRONG WRONG WRONG way:
version (linux)
{
...
}
else /* Windows */
{
...
}
Looks stupid, but I tend to often see stuff like this in C, C++ and D
source code. Even in my own. This is also why there's no ! for versions:
version (!linux)
{
...
}
Aaaaggg. I'm pretty fed up with seeing that crap in C code. And if
you see any of it in dmd or phobos sources, please file a bugzilla report!
Show no mercy.
Perhaps DMD should generate a warning if a version of platforms does not
have an else clause or that version's else clause's content is not another
version statement or a static assert.
Re: Integer overflow bug in windows
Marco Leise Wrote: Am 09.11.2011, 22:34 Uhr, schrieb Kagamin s...@here.lot: http://blogs.technet.com/b/srd/archive/2011/11/08/assessing-the-exploitability-of-ms11-083.aspx Solution: upgrade all computers to 64-bit In windows ULONG is used for reference count, which is still 32-bit on 64-bit system.
Re: assert(obj) is an atrocity
On 11/08/2011 11:42 PM, Timon Gehr wrote: On 11/09/2011 04:52 AM, bcs wrote: On 11/08/2011 04:28 PM, Timon Gehr wrote: On 11/09/2011 01:21 AM, Timon Gehr wrote: On 11/09/2011 01:18 AM, Martin Nowak wrote: On Tue, 08 Nov 2011 23:35:33 +0100, Alex Rønne Petersen xtzgzo...@gmail.com wrote: Hi, As the title suggests, I'm going to be rather blunt about this. assert(obj) testing the invariant *without* doing a null check is insane for the following reasons: 1) It is not what a user expects. It is *unintuitive*. 2) assert(!obj) does an is-null check. assert(obj) is a completely broken opposite of this. 3) No AssertError is thrown, which is the entire point of the built-in assert(). 4) The few added instructions for the null check hardly matter in a *debug* build of all things. I don't mind assert(obj) testing the invariant of obj. In fact, that very much makes sense. But please, please, *please* check the object for null first. This is a random inconsistency in the language with no other justification than seg faults are convenient in a debugger. By the same logic, we might as well not have array bounds checks. However, the state of things is that array bounds checks are emitted by default and users can disable them for e.g. a release build. I don't see why this case is any different. - Alex It does check for null. Only it's a runtime support function (_d_invariant) and druntime is likely compiled without assertions. Are you really suggesting to add a null check before every method call? martin No, he is suggesting to add a null check for assert(objref);, a construct that *looks* as if it was a null check, but does something almost unrelated. BTW, the number of occurrences of assert(objref 1); in my code is huge. I would have used assert(!!obj) because it's shorter. If you have already typed 'assert(obj', it is not shorter. Faster to type? No. Shorter? Yes it still is. I spend enough more time reading and thinking about code that size is more relevant then typing speed.
Re: Integer overflow bug in windows
Solution: upgrade all computers to 64-bit In windows ULONG is used for reference count, which is still 32-bit on 64-bit system. Although 32-bit counter may prove to be inadequate for 64-bit address space.
Re: Version Identifiers for Platforms / Architectures not supported byDMD
On Thursday, November 10, 2011 04:07:43 kennytm wrote: Perhaps DMD should generate a warning if a version of platforms does not have an else clause or that version's else clause's content is not another version statement or a static assert. Well, that does get a bit fuzzy. For instance, rather than duplicating that else clause all over the place in std.file, only the first static if-else clause has the else with the static assert in it. All of the others just have the branches that work and don't have an else clause. If we were to require that there be an else like that, then std.file wouldn't compile. And while it wouldn't be all that bad to have to put an else on all of those static-ifs, it _would_ result in unnecessary code duplication. - Jonathan M Davis
Re: Bartosz about Chapel
Caligo Wrote: You're right, I did forget about the preprocessor. Besides the usual things in the header files, I always try to avoid macros. There are about 20 directives, so that puts the keywords count for C++ to 101. It's still fewer than D. Does that mean D is more complex than C++? Python with 33, I think most would agree that is has a very consice grammer. If a language doesn't have `abstract`, `out` or `pure` it's fail rather than win.
Re: RFC curl
Windows is generally a place where people expect to not have to go and install other external packages for things like this, but rather have it bundled with the installer (zip in this case). Whereas on Linux, you could just use your package manager to install the libraries, for Windows, you'd have to actually find the website, find the library, possibly compile it (difficult on Windows), implib/coffimplib it (something which has little to no documentation and is very hard for new people to figure out, and something I had a LOT of problems with trying to figure out originally; it doesn't even come with DMD), and finally link it and hope for the best. It would be MUCH better and simpler to just include it in the zip for Windows. On 09/11/2011 6:58 PM, bearophile wrote: Walter: Thank you so much for doing this. I think it's a nice piece of work. I agree. As they say, easy things should be easy and hard things should be possible. * libcurl should be a link to where people can read up on what it is. I suggest http://curl.haxx.se/libcurl Point out that the user will need libcurl installed on their system in order to use etc.curl. Is the (just) Windows compiled version present in the DMD zip? I don't remember what was the decision on this (I'd like it to be present). Bye, bearophile
Re: Type Qualifiers and Wild Cards
Walter Bright Wrote: On 11/8/2011 11:10 AM, Martin Nowak wrote: I personally find it much more astonishing that inout methods finally work. In retrospect, it seems like a fairly straightforward solution, but it took us many, many hours and gallons of coffee. And, as far as I know, this solution has not been seen before in any other language, though there is a crying need for it in C++. I don't think so. `inout` is needed in D because you get const data from const object because of transitivity, you have nothing like this in C++ POD. One can try to emulate transitive const with corresponding accessors, but is it used in C++ widely?
Re: assert(obj) is an atrocity
Agreed on all points. It's pathetic that this is still a problem. Check the object for null. To not do so is a _bug_, even if Walter disagrees. SDC will not replicate DMD's behaviour in this regard. -Bernard.
Re: assert(obj) is an atrocity
Because it's a design issue, not a learning issue?
Re: bug in std.array.insertInPlace ?
On 2011-11-09 22:14:25 +0400, Jonathan M Davis said: On Tuesday, November 08, 2011 23:55 Ruslan Mullakhmetov wrote: Hi, I found some strange behavior of std.array.insertInPlace leading to segfault. The example below works for int, it is failed for reference type with array becoming of length bigger 1024 on windows (x64) and 512 on linux (x64). code: http://cloud.theambient.org/0O360r1d2t1g09171F1m Is it my bug or compiler? It might by related to http://d.puremagic.com/issues/show_bug.cgi?id=6874 - Jonathan M Davis thakns. so i won't submit an issue. -- BR, Ruslan Mullakhmetov
Re: Version Identifiers for Platforms / Architectures not supported byDMD
Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday, November 10, 2011 04:07:43 kennytm wrote: Perhaps DMD should generate a warning if a version of platforms does not have an else clause or that version's else clause's content is not another version statement or a static assert. Well, that does get a bit fuzzy. For instance, rather than duplicating that else clause all over the place in std.file, only the first static if-else clause has the else with the static assert in it. All of the others just have the branches that work and don't have an else clause. If we were to require that there be an else like that, then std.file wouldn't compile. And while it wouldn't be all that bad to have to put an else on all of those static-ifs, it _would_ result in unnecessary code duplication. - Jonathan M Davis I said version(Platform)s, not static if.
Re: Reminder: Two days left to review Jesse Phillips' CSV Parser
On Wed, 09 Nov 2011 20:46:51 -0500, dsimcha wrote:
On 11/9/2011 8:02 PM, dsimcha wrote:
As a reminder, the review of Jesse Phillips' CSV parser ends at the end
of Friday and will be followed by one week of voting. Please speak up
now about any remaining issues.
BTW, here's my second round of review now that some changes have been
made:
Design-level stuff:
How do I use csvReader to process a CSV file as it's being read in (i.e.
I don't want to ever have the whole file in memory)? I guess I could do
something like:
import std.algorithm, std.stdio, std.csv, std.conv;
void main() {
auto file = File(foo.csv);
auto chars = joiner(file.byLine(), '\n');
auto reader = csvReader(chars);
}
If this would work, though, then it should be documented.
I do not see why the CSV documentation should be the place to document
how to read a file in parts. As we don't have byChar and this is non-
trivial workaround I could see wanted to have it somewhere and CSV
parsing might be a place to apply it.
What really don't like about it is that you don't get to see the input.
It would be like std.algorithm showing how sorting worked by showing how
to read in an array from a file and sorting it.
This is something people need to know how to do so we should have a good
tutorial on it, but I don't think this is the place to document it (stdio
or std.file is more appropriate). If you strongly disagree I will find
some place to throw in another example.
I'd also like
to see csvReader tested with lowest-common-denominator input ranges
instead of just strings, which are bidirectional ranges and can be
treated as random access if they only have ASCII characters.
Yeah, through in a unittest wrapping a wstring with only input range
interface.
Also, IMHO
we really need a ByChar range in std.stdio instead of the joiner kludge
I used, though I'm not sure about the details with regard to how Unicode
support should work.
I thought there was an undocumented such function, but maybe not.
Still no support for writing CSVs? I understand writing is complicated
from an API design perspective. Maybe it would be easiest to just
provide an enquote() function that adds quotes to a field and escapes
any that are already inside the field and let the user handle the higher
level stuff, since this is pretty simple.
I'm going to make something, try a couple ideas out. Thanks for the
naming suggestion. I ended up deciding not to do anything on it as even
if I did get it done, it wouldn't have appropriate review time. So I'll
let the voting be the deciding factor on whether the library is delayed
because it doesn't have csvFormatter.
After more thought I think an enquote() type function must exist even
with a csvFormatter, but even laying out documentation on that isn't
trivial.
Minor documentation nitpicks:
CSVException: IncompletCellException - IncompleteCellException (typo)
The first csvReader example: You declare the variable count but don't
use it.
Records, Record: front(), empty(), popFront() should not mention
std.range.InputRange. These interfaces are virtual function-based
interfaces in case someone needs virtual function-based access to a
range. They are not used in most cases when ranges are used because
templates are usually better.
Yes, my bad. I keep forgetting we have such interfaces there. I've
instead pointed it to isInputRange which is what I meant to do. But then
I still call it an interface... which it is, but I don't know what we
want to call them. Concepts? :D I want this link in there so if you have
better suggestions...
Thank you.
Re: RFC curl
On Wed, Nov 9, 2011 at 9:31 PM, Kapps ka...@notvalidemail.com wrote: Windows is generally a place where people expect to not have to go and install other external packages for things like this, but rather have it bundled with the installer (zip in this case). Whereas on Linux, you could just use your package manager to install the libraries, for Windows, you'd have to actually find the website, find the library, possibly compile it (difficult on Windows), implib/coffimplib it (something which has little to no documentation and is very hard for new people to figure out, and something I had a LOT of problems with trying to figure out originally; it doesn't even come with DMD), and finally link it and hope for the best. It would be MUCH better and simpler to just include it in the zip for Windows. I agree. Python's batteries included style approach is a huge boon. The number of users who would need a different version than the one included pales in comparison to the productivity gains of including it. People who need a different version can just replace it themselves. We could also just make the installer give the user a choice of installing it or not. On 09/11/2011 6:58 PM, bearophile wrote: Walter: Thank you so much for doing this. I think it's a nice piece of work. I agree. As they say, easy things should be easy and hard things should be possible. * libcurl should be a link to where people can read up on what it is. I suggest http://curl.haxx.se/libcurl Point out that the user will need libcurl installed on their system in order to use etc.curl. Is the (just) Windows compiled version present in the DMD zip? I don't remember what was the decision on this (I'd like it to be present). Bye, bearophile
Re: RFC curl
2011/11/9 Brad Anderson e...@gnuk.net On Wed, Nov 9, 2011 at 9:31 PM, Kapps ka...@notvalidemail.com wrote: Windows is generally a place where people expect to not have to go and install other external packages for things like this, but rather have it bundled with the installer (zip in this case). Whereas on Linux, you could just use your package manager to install the libraries, for Windows, you'd have to actually find the website, find the library, possibly compile it (difficult on Windows), implib/coffimplib it (something which has little to no documentation and is very hard for new people to figure out, and something I had a LOT of problems with trying to figure out originally; it doesn't even come with DMD), and finally link it and hope for the best. It would be MUCH better and simpler to just include it in the zip for Windows. I agree. Python's batteries included style approach is a huge boon. The number of users who would need a different version than the one included pales in comparison to the productivity gains of including it. People who need a different version can just replace it themselves. We could also just make the installer give the user a choice of installing it or not. On 09/11/2011 6:58 PM, bearophile wrote: Walter: Thank you so much for doing this. I think it's a nice piece of work. I agree. As they say, easy things should be easy and hard things should be possible. * libcurl should be a link to where people can read up on what it is. I suggest http://curl.haxx.se/libcurl Point out that the user will need libcurl installed on their system in order to use etc.curl. Is the (just) Windows compiled version present in the DMD zip? I don't remember what was the decision on this (I'd like it to be present). Bye, bearophile I agree, on Windows it would be best to have a competent installer that does this.
Re: How about a 100% CTFE?
Don Wrote:
On 09.11.2011 16:30, foobar wrote:
Don Wrote:
On 09.11.2011 09:17, foobar wrote:
Don Wrote:
On 07.11.2011 14:13, Gor Gyolchanyan wrote:
After reading
http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c
I had a thought:
Why not compile and run CTFE code in a separate executable, write it's
output into a file, read that file and include it's contents into the
object file being compiled?
This would cover 100% of D in CTFE, including external function calls
and classes;
String mixins would simply repeat the process of compiling and running
an extra temporary executable.
This would open up immense opportunities for such things as
library-based build systems and tons of unprecedented stuff, that I
can't imagine ATM.
First comment: classes and exceptions now work in dmd git. The remaining
limitations on CTFE are intentional.
With what you propose:
Cross compilation is a _big_ problem. It is not always true that the
source CPU is the same as the target CPU. The most trivial example,
which applies already for DMD 64bit, is size_t.sizeof. Conditional
compilation can magnify these differences. Different CPUs don't just
need different backend code generation; they may be quite different in
the semantic pass. I'm not sure that this is solvable.
version(ARM)
{
immutable X = armSpecificCode(); // you want to run this on an
X86???
}
I think we discussed those issues before.
1. size_t.sizeof:
auto a = mixin(size_t.sizeof); // HOST CPU
auto a = size_t.sizeof; // TARGET CPU
That doesn't work. mixin happens _before_ CTFE. CTFE never does any
semantics whatsoever.
If I wasn't clear before - the above example is meant to illustrate how
multilevel compilation *should* work.
Sorry, I don't understand what you're suggesting here.
If you want, we can make it even clearer by replacing 'mixin' above with
'macro'.
That doesn't help me. Unless it means that what you're talking about
goes far, far beyond CTFE.
Take std.bigint as an example, and suppose we're generating code for ARM
on an x86 machine. The final executable is going to be using BigInt, and
CTFE uses it as well.
The semantic pass begins. The semantic pass discards all of the
x86-specific code in favour of the ARM-specific stuff. Now CTFE runs.
How can it then run natively on x86? All the x86 code is *gone* by then.
How do you deal with this?
What I'm suggesting is to generalize C++'s two level compilation into arbitrary
N-level compilation.
The model is actually simpler and requires much less language support.
It works like this:
level n: you write *regular* run-time code as a macro using the compiler's
public API to access its data structures. You compile into object form plug-ins
loadable by the compiler.
level n+1 : you write *regular* run-time code. You provide the compiler the
relevant plug-ins from level n, the compiler loads them and then compiles level
n+1 code.
of course, this has arbitrary n levels since you could nest macros.
So to answer your question, I do want to go far beyond CTFE.
The problem you describe above happens due to the fact that CTFE is *not* a
separate compilation step. With my model bigint would be compiled twice - once
for X86 and another for ARM.
As far as I understand this scenario is currently impossible - you can't use
bigint with CTFE.
2. version (ARM) example - this needs clarification of the semantics. Two
possible options are:
a. immutable X = ... will be performed on TARGET as is the case today.
require 'mixin' to call it on HOST. This should be backwards compatible
since we keep the current CTFE and add support for multi-level
compilation.
b. immutable x = ... is run via the new system which requires the
function armSpecificCode to be compiled ahead of time and provided to
the compiler in an object form. No Platform incompatibility is possible.
I don't see any problems with cross-compilation. It is a perfectly sound
design (Universal Turing machine) and it was successfully implemented
several times before: Lisp, scheme, Nemerle, etc.. It just requires to be
a bit careful with the semantic definitions.
AFAIK all these languages target a virtual machine.
Nope. See http://www.cons.org/cmucl/ for a native lisp compiler.
That looks to me, as if it compiles to a virtual machine IR, then
compiles that. The real question is whether the characteristics of the
real machine are allowed to affect front-end semantics. Do any of those
languages do that?
ODBC component licenses
The libraries for unixODBC and for FreeTDS (communication with SQL Server) are LGPL. Would a D ODBC driver that used these be compatible with Phobos? Steve
Re: Bartosz about Chapel
On Wed, Nov 9, 2011 at 8:58 PM, Walter Bright newshou...@digitalmars.comwrote: On 11/9/2011 5:46 PM, Caligo wrote: There are about 20 directives, so that puts the keywords count for C++ to 101. It's still fewer than D. Does that mean D is more complex than C++? C++ has unsigned, long, and unsigned long while D has uint, long, and ulong. That's one more keyword; does that make D more complex than C++? In that example, I prefer the D way. But, in both cases the different data types exist because of speed and efficiency.Semantically, int is more or less a subset of long, so why do we need separate data types? We don't, really, and it's lame to clutter up the semantics of the language like that. Something like this would have been better, and if I recall this is how Chapel is doing it: int(32) a; // int int(64) b; // long Python with 33, I think most would agree that is has a very consice grammer. Python lacks a lot of powerful features that are in D. I know, and I wasn't trying to say that Python is more powerful.
Re: Version Identifiers for Platforms / Architectures not supported byDMD
On Thursday, November 10, 2011 05:08:03 kennytm wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote:
On Thursday, November 10, 2011 04:07:43 kennytm wrote:
Perhaps DMD should generate a warning if a version of platforms does
not
have an else clause or that version's else clause's content is not
another version statement or a static assert.
Well, that does get a bit fuzzy. For instance, rather than duplicating
that else clause all over the place in std.file, only the first static
if-else clause has the else with the static assert in it. All of the
others just have the branches that work and don't have an else clause.
If we were to require that there be an else like that, then std.file
wouldn't compile. And while it wouldn't be all that bad to have to put
an else on all of those static-ifs, it _would_ result in unnecessary
code duplication.
- Jonathan M Davis
I said version(Platform)s, not static if.
LOL. Yes. And I meant version(Platform). I obviously had my wires crossed when
I wrote that. std.file uses
version(Posix)
{}
else version(Windows)
{}
without an else block, except for the first one in the file which _does_ have
an
else which has a static assert(0) in it. Requiring that all such version
blocks had elses would invalidate that approach.
- Jonathan M Davis
Re: Bartosz about Chapel
On 2011-11-09 23:45, Danni Coy wrote: On Wed, Nov 9, 2011 at 10:31 AM, Simen Kjærås simen.kja...@gmail.com mailto:simen.kja...@gmail.com wrote: On Tue, 08 Nov 2011 05:39:07 +0100, Caligo iteronve...@gmail.com mailto:iteronve...@gmail.com wrote: On Mon, Nov 7, 2011 at 7:51 PM, bearophile bearophileh...@lycos.com mailto:bearophileh...@lycos.com wrote: Bartosz talks a bit about the very nicely designed Chapel language: http://bartoszmilewski.__wordpress.com/2011/11/07/__supercomputing-in-seattle/ http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/ (But my appreciation for Chapel design is on other things). Bye, bearophile Interesting (maybe useless) facts: Chapel has 59 keywords. D has, I think, 107 keywords. C++11, I think, 81. Python has 33. Interesting, questionably. Useless, indeed. how many keywords in D are needed because the preprocessor is built into the language itself? A couple of extra, but we also reuse some existing once, i.e. static if. -- /Jacob Carlborg
Re: RFC curl
On 2011-11-09 21:53, Jonas Drewsen wrote: Hi, So after the last review of the etc.curl there were some requests for making it simpler. After some thinking, refactoring and documentation I've come up with a somewhat changed API. Before sending it for official review again I would really like some comments on the new API and if you think it is better or worse etc. http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Thanks, Jonas I like the new high level API, that's how easy it should be to download a file or get the content of a webpage. What is the actual Phobos guideline in naming things that are keywords in D. I'm thinking about Method.del, shouldn't it be Method.delete_ or something similar, don't know what the guidelines say in this case. BTW, I would really like to have more official guidelines somewhere at the dpl page. -- /Jacob Carlborg
Re: RFC curl
On 2011-11-09 21:53, Jonas Drewsen wrote: Hi, So after the last review of the etc.curl there were some requests for making it simpler. After some thinking, refactoring and documentation I've come up with a somewhat changed API. Before sending it for official review again I would really like some comments on the new API and if you think it is better or worse etc. http://freeze.steamwinter.com/D/web/phobos/etc_curl.html Thanks, Jonas BTW, why is this etc.culr and not std.curl. -- /Jacob Carlborg
Re: Bartosz about Chapel
Caligo Wrote: On Mon, Nov 7, 2011 at 7:51 PM, bearophile bearophileh...@lycos.com wrote: Bartosz talks a bit about the very nicely designed Chapel language: http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/ (But my appreciation for Chapel design is on other things). Bye, bearophile Interesting (maybe useless) facts: Chapel has 59 keywords. D has, I think, 107 keywords. C++11, I think, 81. Python has 33. brbrdiv class=gmail_quoteOn Mon, Nov 7, 2011 at 7:51 PM, bearophile span dir=ltrlt;a href=mailto:bearophileh...@lycos.com;bearophileh...@lycos.com/agt;/span wrote:brblockquote class=gmail_quote style=margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex; Bartosz talks a bit about the very nicely designed Chapel language:br br a href=http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/; target=_blankhttp://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle//abr br (But my appreciation for Chapel design is on other things).br br Bye,br font color=#88bearophilebr /font/blockquote/divbrdivInteresting (maybe useless) facts: Chapel has 59 keywords. D has, I think, 107 keywords. C++11, I think, 81. Python has 33./div Smalltalk has 5. How many does lisp have? brainfuck? whiltespace? Many people (me included) consider smalltalk to be one of the friendliest languages to use. It really is like talking with the computer. Measuring keyword count is wrong. what should be measured is *what* keywords are used and ease of expressiveness the language provides. On such a scale, Small talk would be best and APL would probably be worst with C+ a tight competition for 2nd worst. Regarding D, it's far better than c++ but still much further from smalltalk, python, and other very readable languages. Last comment, to all those who keep character/word counts and try to shorten words - code is read 1000 as much as written so readability is many orders of magnitude more important than conciseness. Best example is c+= =0 for abstract/pure virtual.
Spurious imports in Phobos ?
Hello, When I display the dependencies with dmd -deps=depends, I see that simply importing std.stdio imports dozens of modules, among which std.ranges, std.datetime, std.c.windows.winsock, std.regex, etc In fact, the depends file is 433 lines long. I noticed that std.string imports quite a lot of stuff. Here is a copypasta of the code: import core.exception : onRangeError; import core.vararg, core.stdc.stdlib, core.stdc.string, std.algorithm, std.ascii, std.conv, std.exception, std.format, std.functional, std.metastrings, std.range, std.regex, std.traits, std.typetuple, std.uni, std.utf; //Remove when repeat is finally removed. They're only here as part of the //deprecation of these functions in std.string. public import std.algorithm : startsWith, endsWith, cmp, count; public import std.array : join, split; So as an experiment, I tried to remove a few imports: std.range, std.regex, std.traits and std.algorithm as well as the two lines of public import. To my surprise, it still compiles ! The depends file goes down to 402 lines, but the executable size is understandably not reduced because all the removed dependencies are still used elsewhere. Then I thought this may be due to public imports from other modules, which makes me think that public imports are a bad idea, as we can compile a module only because we imported unknowingly a namespace from imported modules. My question is: how do we know if std.range, std.regex, std.traits and std.algorithm are spurious imports or if we can (and threfore should) remove them safely from std.string ? Dude
Re: Spurious imports in Phobos ?
Le 09/11/2011 10:14, Somedude a écrit : My question is: how do we know if std.range, std.regex, std.traits and std.algorithm are spurious imports or if we can (and threfore should) remove them safely from std.string ? Dude I meant: how do we know if std.range, std.regex, std.traits and std.algorithm are necessary imports or if we can (and threfore should) remove them safely from std.string ?
Re: assert(obj) is a mystery
On Tuesday, November 08, 2011 21:51:46 Davidson Corry wrote: OK. Not addressing Alex's objections at all, it's not clear to me why anyone would *need* to test the invariant of an object. I wouldn't expect it to be something that you'd need to do very often. However, if you give access to the member variables in your class or struct - either directly or indirectly - allowing code outside the type to modify that type's state, then the invariant can be violated. Now, it's arguably bad design to allow such access when using an invariant (if not in general), but it _is_ a case where the invariant can be invalidated. - Jonathan M Davis
Internal error: e2ir.c 1242
I'd say, I found another compiler bug.
-
import std.stdio;
template Struct(alias bar)
{
struct S
{
void foo()
{
FancyFunc!(this, bar).fn();
}
}
}
template FancyFunc(alias context, alias f)
{
void fn()
{
writeln(before);
f(context);
writeln(after);
}
}
void bar(CT)(CT context)
{
writeln(CT.stringof);
}
void main()
{
alias Struct!(bar).S MyStruct;
MyStruct s = MyStruct();
s.foo();
}
--
Compile it with dmd and dmd will print:
Internal error: e2ir.c 1242
Should the aliasing of this in FancyFunc!(this, bar) work, if there were
no internal compiler error?
In any case I've filed a report
(http://d.puremagic.com/issues/show_bug.cgi?id=6918).
--
Tobias
Re: Fake global associative array literals
On Fri, Oct 28, 2011 at 5:53 PM, bearophile bearophileh...@lycos.com wrote:
What do you think about a rewrite rule that changes code like:
int[int] aa = [1:2, 3:4];
void main() {}
Into:
int[int] aa;
static this() {
aa = [1:2, 3:4];
}
void main() {}
Its not quite same case, but still could be useful - what I usually do
if I need global or static immutable AA behavior:
int f_aa(int key)
{
switch (key) {
case 1: return 2;
case 3: return 4;
default: return int.init;
}
}
void main()
{
// f_aa == [1:2, 3:4]
static assert (f_aa(1) == 2);
static assert (f_aa(3) == 4);
}
For immutable data or CTFE I cannot see other way to get AA-like data.
The function itself could be generated on compile-time as string
mixin, but I usually don't bother.
--
serg.
Re: web development in D programming
bioinfornatics wrote: I am a little disapointed, so if you have many request for a web page this lib http://arsdnet.net/dcode/ is usable or not ? I am developing an implementation of the FastCGI protocol (http://www.fastcgi.com) in D2 with the main goal go have multiplexing support. However the development is slow due to the lack of time. I believe a good http server implementation would be appreciated by the community, but FastCGI server will make it possible to create a highly- scalable web applications using some of the well-known web servers (I use Lighttpd for an example). Your code is usable, but not production-ready.
