Re: std.experimental.yesnogc
On Thursday, 14 January 2016 at 07:44:16 UTC, Jacob Carlborg wrote: std.experimental.memory with submodules for the different use cases: std.experimental.memory.rc std.experimental.memory.gc std.experimental.memory.manual // or something Agreed.
Re: std.experimental.yesnogc
On Thursday, 14 January 2016 at 00:35:53 UTC, Andrei Alexandrescu wrote: Ideas? Andrei std.experimental.rusty
Re: extern(C++, ns)
On 14 January 2016 at 15:39, Walter Bright via Digitalmars-d
wrote:
> On 1/13/2016 5:33 PM, Manu via Digitalmars-d wrote:
>>
>> I managed to quickly reduce to this point again:
>>
>> module m.x;
>> alias X2 = X;
>> extern (C++, ns) struct X {}
>>
>> Error: undefined identifier 'X'
>
>
>
> It's a bug. Thanks for finding and posting it.
>
> https://issues.dlang.org/show_bug.cgi?id=15565
>
> As a workaround for the moment, you can either move the alias past the
> extern, or qualify X with ns.X.
Isn't this exactly what you fixed the other day? What's the difference
between this and that prior forward referencing case?
Re: [dlang.org] new forum design - preview
On Wednesday, 13 January 2016 at 21:35:15 UTC, tsbockman wrote: On Wednesday, 13 January 2016 at 20:11:07 UTC, Jacob Carlborg wrote: On 2016-01-13 14:55, Vladimir Panteleev wrote: As soon as anyone comes up with a way to fit it into the design that doesn't look awful. I don't think this [1] looks so awful. [1] https://drive.google.com/open?id=0B7UtafxGD9vEX0NVYXlyWHhDX3c Yes. Please add this; the need to scroll all the way down to find the pager has been annoying me ever since I started reading these forums. It's probably the main reason I switched over to using the horizontal-split view, although now I could never give that up.
Struct initialization using member syntax without variable
To initialize a struct with the member names a variable is required.
Example:
struct Foo
{
int a;
int b;
}
Foo foo = { a: 3, b: 4 };
That's a bit annoying when you want to pass the struct to a function or
return it.
Foo bar()
{
return { a: 3, b: 4 }; // error
}
void bar(Foo foo);
bar({ a: 3, b: 4 }); // error
Is there any reason for this limitation? I guess it will make function
overloading more difficult, but that could easily be solved with the
following syntax:
bar(Foo{ a: 3, b: 4 });
Or this:
bar(Foo(a: 3, b: 4));
This would also allow one to use "auto" when declaring a variable:
auto foo = Foo{ a: 3, b: 4 };
--
/Jacob Carlborg
Re: std.experimental.yesnogc
On Thursday, 14 January 2016 at 07:44:16 UTC, Jacob Carlborg wrote: std.experimental.memory with submodules for the different use cases: std.experimental.memory.rc std.experimental.memory.gc std.experimental.memory.manual // or something this has my vote I guess the first submodule should be the allocators!?
Re: std.experimental.yesnogc
On Thursday, 14 January 2016 at 00:35:53 UTC, Andrei Alexandrescu wrote: Ideas? import std.experimental.gcbypass; import std.experimental.gcfreedom; import std.experimental.shuntgc; import std.experimental.rcinstead; import std.experimental.manual;
Re: [dlang.org] new forum design - preview
On Thursday, 14 January 2016 at 05:46:55 UTC, Vladimir Panteleev wrote: On Thursday, 14 January 2016 at 03:55:23 UTC, Meta wrote: On Thursday, 14 January 2016 at 02:56:03 UTC, Vladimir Panteleev wrote: On Wednesday, 13 January 2016 at 09:22:54 UTC, Meta wrote: On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev wrote: My only complaint is that it does not utilize the horizontal space available, unlike the current design. Otherwise it nicely matches the front page redesign. The navigation sidebar has been made narrower. How does it look now? We can make it a bit narrower still by removing the redundant "About this forum" link. I don't think that 100%-width is great, as above certain line length readability suffers. Readability is subjective and depends on the reader. Line length should not be the concern of the designer, but of the user who should have control over line length by adjusting the width of the browser. There's a good 30% of the screen or more that's not being used, and this is only on a 1920x1080 monitor. Well, I would argue that this is not a problem that needs fixing. There is just no content to fill in that space. Making the posts themselves fill all available horizontal space does not help readability either. I don't agree, I like the width of the old forum better. I have a large monitor and don't read full screen. So my browser is sized comfortably. Nevertheless, the new design wastes space and I'm feeling cramped...
Re: std.experimental.yesnogc
On Thursday, 14 January 2016 at 02:13:20 UTC, Ilya wrote: std.memory --Ilya That's a good one.
Re: Struct initialization using member syntax without variable
Maybe there is some parsing difficulty, but if it's possible to add something like this, I think it would be nice.
Re: [dlang.org] new forum design - preview
I love this redesign. Anyone who complains about not taking up the full width of the screen is wrong. If lines stretch on eternally, they become harder to scan with your eyes. It's a well known effect which has been studied and documented. There is some difference of opinion on what the maximum should be, but the hard limit seems to be 110 CPL. 80 CPL or 90 CPL are commonly used. You have to stop expanding elements at some point.
Re: DIP86: Consistency for the "deprecated" attribute/storage class
On Thursday, 14 January 2016 at 02:31:38 UTC, Brian Schott wrote: http://wiki.dlang.org/DIP86 Your thoughts? HAHAHAHAHA consistency, good one :)
Re: [dlang.org] new forum design - preview
On Thursday, 14 January 2016 at 12:31:51 UTC, w0rp wrote: I love this redesign. Anyone who complains about not taking up the full width of the screen is wrong. If lines stretch on eternally, they become harder to scan with your eyes. It's a well known effect which has been studied and documented. There is some difference of opinion on what the maximum should be, but the hard limit seems to be 110 CPL. 80 CPL or 90 CPL are commonly used. You have to stop expanding elements at some point. Yes please !
Re: Struct initialization using member syntax without variable
On 2016-01-14 13:22, w0rp wrote: Maybe there is some parsing difficulty, but if it's possible to add something like this, I think it would be nice. I hardly doubt it. -- /Jacob Carlborg
Re: Add "setBinaryMode" and "setTextMode" to stdio?
On Wednesday, 13 January 2016 at 01:48:13 UTC, Jakob Ovrum wrote: On Wednesday, 13 January 2016 at 00:13:13 UTC, Johan Engelen wrote: Should I work on a PR for setBinaryMode+setTextMode ? std.stdio is intended as a wrapper around stdio.h, which I don't think supports setting the mode post-fopen I decided to implement a setRawMode, that basically makes permanent the temporary changes that rawWrite/rawRead do. PR #3929: https://github.com/D-Programming-Language/phobos/pull/3929
Re: DIP86: Consistency for the "deprecated" attribute/storage class
On Thursday, 14 January 2016 at 02:54:01 UTC, Jack Stouffer wrote: On Thursday, 14 January 2016 at 02:31:38 UTC, Brian Schott wrote: http://wiki.dlang.org/DIP86 Your thoughts? I guess there's no reason not to, so LGTM. The use of the deprecated attribute on variables seems misguided in the first place though. I don't see much use for it vs possible use on functions, structs, classes, and modules other than with global variables. The number 10 is now deprecated. Please use 11 instead, which is 1 better.
Re: std.experimental.yesnogc
On 01/14/2016 12:48 AM, Vladimir Panteleev wrote: On Thursday, 14 January 2016 at 00:35:53 UTC, Andrei Alexandrescu wrote: Hey folks, I want to push things forward with artifacts dedicated to avoiding the GC, and of course my main worry is finding the right name. An obvious choice is std.experimental.nogc but we know from Marketing 101 that expressing something as a positive is better than a negative. Another possibility is std.experimental.rc, but that's imprecise because the artifacts in there will contain a variety of things in addition to reference counting-related artifacts. Ideas? std.experimental.lifetime noice -- Andrei
Re: extern(C++, ns)
On 01/14/2016 12:39 AM, Walter Bright wrote:
On 1/13/2016 5:33 PM, Manu via Digitalmars-d wrote:
I managed to quickly reduce to this point again:
module m.x;
alias X2 = X;
extern (C++, ns) struct X {}
Error: undefined identifier 'X'
It's a bug. Thanks for finding and posting it.
https://issues.dlang.org/show_bug.cgi?id=15565
As a workaround for the moment, you can either move the alias past the
extern, or qualify X with ns.X.
Thanks Manu for reducing the bug!! -- Andrei
Choosing D over C++, Go, Rust, Swift
Hi I wrote recently that I am looking at an alternative to C++ for a project currently being coded in C++. I am pleased to say based on preliminary investigations I have chosen D over Go, Rust, and Swift. I have yet to write a line of D code so I will give you an update after I do some coding but here are my reasons: 1. D appears to give me all the power of C++ - and in particular even greater power with templates. 2. D code is cleaner, more traditional (Java and C like), and easier to read and understand than some of the alternatives. Go is simpler of course and also easy to follow - but that is because it is a small language. I dislike the new syntax of Rust as it seems gratuitously different and (in my view) hard to read. 3. D gives me all the low level control while at the same time giving me the ability to write code at a higher level. C++ is similar but the other languages are all restrictive in some way or other. I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. I will provide an update as I start coding in D. Thanks and Regards Dibyendu
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: Hi I wrote recently that I am looking at an alternative to C++ for a project currently being coded in C++. I am pleased to say based on preliminary investigations I have chosen D over Go, Rust, and Swift. I have yet to write a line of D code so I will give you an update after I do some coding but here are my reasons: [...] What is it you're actually trying to write?
DIP83
Here are a few comments about http://wiki.dlang.org/DIP83: * Meta: We continue to be shorthanded at both reviewing and implementing DIPs. DIP83 has a few issues that are simple and obvious, and would be easily fixed upon review by the community. After approval, it will be difficult to find someone to carry the implementation. * Overall: The proposal is a good start but needs serious work toward making it a precise specification. Right now it is not ready to act as a blueprint of an implementation, or be converted to a section of the language reference. By paragraph: * Minor phrasing: "when flagged for in call to compiler" - the meaning is understandable only after having read the entire document. Suggestion: "Allow for assert to do pretty printing of its failing expression when a specific command line flag is passed to the compiler." * Why is this feature subject to a compiler flag? The document should explain why, or just enable the feature regardless. * Minor phrasing: "This extra, so called, pretty printing" -> "This extra so-called pretty printing" or better yet "This additional pretty printing". * "give no hint" -> "gives no hint". I won't submit further proofreading comments. * The rationale mentions unary operators. However, those are unlikely to be of use: -, +, ~, *. Additionally, ++ and -- are straight unrecommended inside an assert. Only assert(!e) may be arguably interesting, although I can't think of good examples. I suggest we drop unary operators altogether. * The proposal should enumerate what top-level BINOPs are considered. For example, are the assignment operators part of the set? Probably not. My understanding is the proposal has been written mainly with these in mind: ==, !=, <, <=, >, >=. && is also interesting. || is only interesting if more decomposition is done on its operands. "in" would be great. Off the top of my head, I'm not sure about these: +, -, *, /, %, ^^, &, |, ^, <<, >>, >>>, ~. The point here is it needs to be clearly stated which operators are allowed. * I fail to see how "Non-Operator Lowering" could be useful. assert(e) fails if e is zero or null. The only possible case would be the odd overloading of opCast!bool, in which case the document should explain and motivate that with examples. * The section "Non-Equality Operator Lowering" should be demoted because it's just an implementation note. At the level of this DIP, != is treated as an operator of its own. * The onAssertFailed example imports std.traits but we're here in druntime. This illustrates a broader discussion - without std.conv and generally Phobos, onAssertFailed will only have little capability to format nice strings. I don't have a good idea on how to address this. Andrei
Re: DIP83
Ok I'll bite: it doesn't matter. This DIP is additive. The problem with D is not that we don't have stuff in there, is most of the stuff in there are half backed. Adding more half baked things in there only makes things worse. We don't have line number in stack traces, what does a better assert error message (that one can configure by code) will do ? Worse, how is that consistent with the position that "Segfault are good enough with a debugger" and null by default reference types ? There is no point in discussing the doorbell when the house has no window.
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 14:02:58 UTC, Joakim wrote: On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: Hi I wrote recently that I am looking at an alternative to C++ for a project currently being coded in C++. I am pleased to say based on preliminary investigations I have chosen D over Go, Rust, and Swift. I have yet to write a line of D code so I will give you an update after I do some coding but here are my reasons: [...] What is it you're actually trying to write? Hi - apologies I am unable to discuss, as it is not an OpenSource project. But let's say it requires lot of numeric computing.
local import hijacking
I got burned by this yesterday, this code should not compile
import std.experimental.logger : trace;
void foo() {
import std.net.curl : trace;
trace("hello");
}
void main() {
foo();
}
Not sure if this is a duplicate
https://issues.dlang.org/show_bug.cgi?id=15567
Re: DIP86: Consistency for the "deprecated" attribute/storage class
On Thursday, 14 January 2016 at 02:31:38 UTC, Brian Schott wrote: http://wiki.dlang.org/DIP86 Your thoughts? OK. Is deprecated on variables used by anyone here?
Re: local import hijacking
V Thu, 14 Jan 2016 14:25:43 +
Byron Heads via Digitalmars-d napsáno:
> I got burned by this yesterday, this code should not compile
>
> import std.experimental.logger : trace;
>
>
> void foo() {
> import std.net.curl : trace;
> trace("hello");
> }
>
>
> void main() {
> foo();
> }
>
>
> Not sure if this is a duplicate
> https://issues.dlang.org/show_bug.cgi?id=15567
>
>
>
No this is OK, there is no reason to not compile.
It is same as:
import std.stdio;
string trace = "trace";
void foo() {
int trace = 7;
writeln(trace);
}
void main() {
foo();
writeln(trace);
}
local symbols can hide global symbols
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 14:29:24 UTC, Dibyendu Majumdar wrote: Hi - apologies I am unable to discuss, as it is not an OpenSource project. But let's say it requires lot of numeric computing. Are you familiar with https://github.com/dlangscience https://gitter.im/DlangScience/public
Re: std.experimental.yesnogc
On Thursday, 14 January 2016 at 07:44:16 UTC, Jacob Carlborg wrote: std.experimental.memory.rc std.experimental.memory.gc std.experimental.memory.manual // or something +1
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. Do you have specific suggestions for improvements? The difficulty is predicting where someone will look for that information.
Re: std.experimental.yesnogc
On 01/14/2016 09:50 AM, bachmeier wrote: On Thursday, 14 January 2016 at 07:44:16 UTC, Jacob Carlborg wrote: std.experimental.memory.rc std.experimental.memory.gc std.experimental.memory.manual // or something +1 I don't see how this categorization works. E.g. there's no need for special tooling related to the GC. -- Andrei
Re: local import hijacking
On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak wrote:
V Thu, 14 Jan 2016 14:25:43 +
Byron Heads via Digitalmars-d
napsáno:
I got burned by this yesterday, this code should not compile
import std.experimental.logger : trace;
void foo() {
import std.net.curl : trace;
trace("hello");
}
void main() {
foo();
}
Not sure if this is a duplicate
https://issues.dlang.org/show_bug.cgi?id=15567
No this is OK, there is no reason to not compile.
It is same as:
import std.stdio;
string trace = "trace";
void foo() {
int trace = 7;
writeln(trace);
}
void main() {
foo();
writeln(trace);
}
local symbols can hide global symbols
import std.experimental.logger;
void foo() {
import std.net.curl;
lots of curl calls
trace("hello");
.. more curl calls
}
void main() {
foo();
}
std.net.curl.CurlException@std\net\curl.d(4033): Couldn't resolve
host name on handle 2188398
0x00405F65
0x00405F10
0x0040275B
0x0040259E
0x0040202B
0x00402035
0x004257A7
0x004256A8
0x0041B7FF
0x769F337A in BaseThreadInitThunk
0x77429882 in RtlInitializeExceptionChain
0x77429855 in RtlInitializeExceptionChain
This was a 4 hour debug which made it worse as I was adding more
trace calls to figure out what was going on. My boss is now on
the fence, to many compiler bugs with D, he asked me to switch to
Java if I have to deal to many more issues like this..
(https://issues.dlang.org/show_bug.cgi?id=15457 another issue we
had)
And this awesome stack trace helped me so much to track this
issue down...
Re: local import hijacking
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote:
On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak
wrote:
[...]
import std.experimental.logger;
void foo() {
import std.net.curl;
lots of curl calls
trace("hello");
.. more curl calls
}
void main() {
foo();
}
std.net.curl.CurlException@std\net\curl.d(4033): Couldn't
resolve host name on handle 2188398
0x00405F65
0x00405F10
0x0040275B
0x0040259E
0x0040202B
0x00402035
0x004257A7
0x004256A8
0x0041B7FF
0x769F337A in BaseThreadInitThunk
0x77429882 in RtlInitializeExceptionChain
0x77429855 in RtlInitializeExceptionChain
This was a 4 hour debug which made it worse as I was adding
more trace calls to figure out what was going on. My boss is
now on the fence, to many compiler bugs with D, he asked me to
switch to Java if I have to deal to many more issues like
this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another
issue we had)
And this awesome stack trace helped me so much to track this
issue down...
Also why is this not allowed then?
import std.stdio;
void main() {
auto x = "foo";
for(int x = 0; x < 10; ++x) {
writeln(x);
}
}
Error: variable x is shadowing variable f335.main.x
Shadowing is bad and leads to bugs!
Re: local import hijacking
On 14.01.2016 15:25, Byron Heads wrote:
I got burned by this yesterday, this code should not compile
import std.experimental.logger : trace;
void foo() {
import std.net.curl : trace;
trace("hello");
}
void main() {
foo();
}
I don't see a problem with that specific code. You're explicitly
importing `trace` from std.net.curl, so it can't be surprising that it's
called.
But change one little detail and this qualifies as hijacking, I think:
void foo() {
import std.net.curl; /* not mentioning trace */
trace("hello");
}
Imagine that std.net.curl didn't have a `trace` function when the code
was written. std.experimental.logger.trace would have been called then.
When a `trace` function is then added to std.net.curl, the code suddenly
calls a different `trace`, without any warning. Hijacking.
Re: [dlang.org] new forum design - preview
On Thursday, 14 January 2016 at 12:31:51 UTC, w0rp wrote: I love this redesign. Anyone who complains about not taking up the full width of the screen is wrong. If lines stretch on eternally, they become harder to scan with your eyes. It's a well known effect which has been studied and documented. There is some difference of opinion on what the maximum should be, but the hard limit seems to be 110 CPL. 80 CPL or 90 CPL are commonly used. You have to stop expanding elements at some point. I don't use my browser in full screen mode, but the useless white margins are still there. With the horizontal-split mode the line length of the message is less than 60 characters. Compared to that, I would be happy with 80 or 90 you suggest. Besides, especially the margin that is on the left side of the navigation bar looks ugly, like it was rendered improperly.
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 14:40:05 UTC, bachmeier wrote: On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. Do you have specific suggestions for improvements? The difficulty is predicting where someone will look for that information. I think a prominent Link saying - Why choose D? on the home page. and maybe initially this could take to another page with links to articles, videos etc. But longer term it would better to have a more structured presentation of the benefits. Example - show with examples what can be done with D templates that is hard or not possible with C++. And similarly with other languages. I would suggest very aggressive 'marketing' of D advantages. Regards
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 14:35:27 UTC, bachmeier wrote: Are you familiar with https://github.com/dlangscience https://gitter.im/DlangScience/public Thank you for pointing me to above. Regards
Re: std.experimental.yesnogc
On 2016-01-14 15:52, Andrei Alexandrescu wrote: I don't see how this categorization works. E.g. there's no need for special tooling related to the GC. -- Andrei It was just a couple of suggestions. I don't know exactly what you're going to include in this module. -- /Jacob Carlborg
Re: local import hijacking
V Thu, 14 Jan 2016 16:17:41 +0100
anonymous via Digitalmars-d napsáno:
> On 14.01.2016 15:25, Byron Heads wrote:
> > I got burned by this yesterday, this code should not compile
> >
> > import std.experimental.logger : trace;
> >
> >
> > void foo() {
> > import std.net.curl : trace;
> > trace("hello");
> > }
> >
> >
> > void main() {
> > foo();
> > }
>
> I don't see a problem with that specific code. You're explicitly
> importing `trace` from std.net.curl, so it can't be surprising that
> it's called.
>
> But change one little detail and this qualifies as hijacking, I think:
>
>
> void foo() {
> import std.net.curl; /* not mentioning trace */
> trace("hello");
> }
>
>
> Imagine that std.net.curl didn't have a `trace` function when the
> code was written. std.experimental.logger.trace would have been
> called then. When a `trace` function is then added to std.net.curl,
> the code suddenly calls a different `trace`, without any warning.
> Hijacking.
Using local imports is dangerous. It should be used only with
selective imports
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 15:32:10 UTC, Dibyendu Majumdar wrote: On Thursday, 14 January 2016 at 14:40:05 UTC, bachmeier wrote: On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. Do you have specific suggestions for improvements? The difficulty is predicting where someone will look for that information. I think a prominent Link saying - Why choose D? on the home page. and maybe initially this could take to another page with links to articles, videos etc. But longer term it would better to have a more structured presentation of the benefits. Example - show with examples what can be done with D templates that is hard or not possible with C++. And similarly with other languages. I would suggest very aggressive 'marketing' of D advantages. You're right, D's not very good at marketing. On the other hand, have you ever found what you're suggesting on any other programming language's website? I haven't, so they're all in the same boat, each one as bad as the next. Of course, there's the argument that programmers who try out new languages hate marketing, so not having much traditional marketing is itself a form of "marketing" for that audience. :) In that case, you're one of the few who wants to be marketed to, and you may be out of luck. :D
Re: local import hijacking
On 01/14/2016 10:17 AM, anonymous wrote:
On 14.01.2016 15:25, Byron Heads wrote:
I got burned by this yesterday, this code should not compile
import std.experimental.logger : trace;
void foo() {
import std.net.curl : trace;
trace("hello");
}
void main() {
foo();
}
I don't see a problem with that specific code. You're explicitly
importing `trace` from std.net.curl, so it can't be surprising that it's
called.
But change one little detail and this qualifies as hijacking, I think:
void foo() {
import std.net.curl; /* not mentioning trace */
trace("hello");
}
Imagine that std.net.curl didn't have a `trace` function when the code
was written. std.experimental.logger.trace would have been called then.
When a `trace` function is then added to std.net.curl, the code suddenly
calls a different `trace`, without any warning. Hijacking.
Yes, this needs to be fixed. -- Andrei
Re: local import hijacking
On 01/14/2016 09:36 AM, Daniel Kozak via Digitalmars-d wrote:
V Thu, 14 Jan 2016 14:25:43 +
Byron Heads via Digitalmars-d napsáno:
I got burned by this yesterday, this code should not compile
import std.experimental.logger : trace;
void foo() {
import std.net.curl : trace;
trace("hello");
}
void main() {
foo();
}
Not sure if this is a duplicate
https://issues.dlang.org/show_bug.cgi?id=15567
No this is OK, there is no reason to not compile.
It is same as:
import std.stdio;
string trace = "trace";
void foo() {
int trace = 7;
writeln(trace);
}
void main() {
foo();
writeln(trace);
}
local symbols can hide global symbols
Correct. The implicitly introduced locals are the problem. Can anyone on
the compiler team work on this? -- Andrei
Re: std.experimental.yesnogc
On 01/14/2016 10:46 AM, Jacob Carlborg wrote: On 2016-01-14 15:52, Andrei Alexandrescu wrote: I don't see how this categorization works. E.g. there's no need for special tooling related to the GC. -- Andrei It was just a couple of suggestions. I don't know exactly what you're going to include in this module. Me neither, which adds to the problem :o). -- Andrei
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 16:08:24 UTC, Joakim wrote: You're right, D's not very good at marketing. On the other hand, have you ever found what you're suggesting on any other programming language's website? I haven't, so they're all in the same boat, each one as bad as the next. I think you're right. I'm not convinced that it is a problem that can be solved. One person is looking for a Java replacement, another wants a hobby language for a personal website, and yet another wants better metaprogramming than you get with C++. A good marketing pitch for any individual is at best an irrelevant one for most of the rest.
Re: local import hijacking
On Thu, Jan 14, 2016 at 11:09:29AM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
> Yes, this needs to be fixed. -- Andrei
This issue has been known for a long time:
https://issues.dlang.org/show_bug.cgi?id=10378
Kenji even has a PR for it.
My favorite blatant demonstration of its nastiness:
import std.stdio;
void func(string text) {
import std.conv;
writeln(text);
}
void main() {
func("Hello world");
}
Program output: (blank)
T
--
Жил-был король когда-то, при нём блоха жила.
Re: Choosing D over C++, Go, Rust, Swift
On 01/14/2016 05:47 AM, Dibyendu Majumdar wrote: > I had to go through many articles, video presentations etc. to > form my conclusions - it would have been nice if there was a > single page on the D website that explained why D should be > chosen over the other competing languages Can you please write that article while it's fresh on your mind. ;) Ali
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. http://dlang.org/overview.html
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 17:04:35 UTC, Ali Çehreli wrote: On 01/14/2016 05:47 AM, Dibyendu Majumdar wrote: > I had to go through many articles, video presentations etc. to > form my conclusions - it would have been nice if there was a > single page on the D website that explained why D should be > chosen over the other competing languages Can you please write that article while it's fresh on your mind. ;) Ali I will probably write something when I feel more confident about things (i.e. have validated my impressions), but right now that's not a priority for me. Regards
Re: extern(C++, ns)
On 1/14/2016 12:53 AM, Manu via Digitalmars-d wrote: Isn't this exactly what you fixed the other day? What's the difference between this and that prior forward referencing case? The difference is that for this one, "X" is in "ns" and "ns" has not yet had its members added to the symbol table.
Re: Google Summer of Code 2016
On Thursday, 31 December 2015 at 23:58:32 UTC, Craig Dillabaugh wrote: The deadline for the Google Summer of Code, 2016 is February 19th. Which means we have about a month and a half to put something together. For the time being I've recycled last years projects (with one dropped so far): [...] Deadline is getting closer, any new project ideas are welcome. Starting to get some contact from students now.
Re: local import hijacking
On Thursday, 14 January 2016 at 16:32:38 UTC, H. S. Teoh wrote:
On Thu, Jan 14, 2016 at 11:09:29AM -0500, Andrei Alexandrescu
via Digitalmars-d wrote: [...]
Yes, this needs to be fixed. -- Andrei
This issue has been known for a long time:
https://issues.dlang.org/show_bug.cgi?id=10378
Kenji even has a PR for it.
My favorite blatant demonstration of its nastiness:
import std.stdio;
void func(string text) {
import std.conv;
writeln(text);
}
void main() {
func("Hello world");
}
Program output: (blank)
T
Wow, can't believe his PR has been sitting unreviewed for 5
months:
https://github.com/D-Programming-Language/dmd/pull/4915
Re: [dlang.org] new forum design - preview
On 14.01.2016 16:29, tn wrote: I don't use my browser in full screen mode, but the useless white margins are still there. With the horizontal-split mode the line length of the message is less than 60 characters. Compared to that, I would be happy with 80 or 90 you suggest. This is an issue with the horizontal split mode, right? In the other modes you should get more than 80 characters on a line. I agree that horizontal split looks quite cramped right now, unless you hide the navigation. Besides, especially the margin that is on the left side of the navigation bar looks ugly, like it was rendered improperly. Would a border help? http://i.imgur.com/XoPddxr.png Or how about making the whole area gray? http://i.imgur.com/AXrmKU4.png
Re: std.experimental.yesnogc
On 2016-01-14 17:11, Andrei Alexandrescu wrote: Me neither, which adds to the problem :o). -- Andrei You need to at least have some ideas, otherwise there's no point in a new module :) -- /Jacob Carlborg
Re: DIP83
On 2016-01-14 15:28, deadalnix wrote: There is no point in discussing the doorbell when the house has no window. +1. And AST macros would solve the problem (and a lot of other problems). -- /Jacob Carlborg
Re: DIP86: Consistency for the "deprecated" attribute/storage class
On Thursday, 14 January 2016 at 12:33:19 UTC, deadalnix wrote: HAHAHAHAHA consistency, good one :) We can dream.
Re: [dlang.org] new forum design - preview
On Thursday, 14 January 2016 at 12:31:51 UTC, w0rp wrote: Anyone who complains about not taking up the full width of the screen is wrong. If lines stretch on eternally, they become harder to scan with your eyes. It's a well known effect which has been studied and documented. There is some difference of opinion on what the maximum should be, but the hard limit seems to be 110 CPL. 80 CPL or 90 CPL are commonly used. You have to stop expanding elements at some point. At any moment user can reduce the window, if want. I want read full headers and posts, not "Re: D extensions to python, inline in..." "[Bug 119] GDC needs friendlier com..." "[Issue 14699] ICE: segfaults on array..." "[D-runtime] [D-Programming-Langu..." etc
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 17:10:34 UTC, Jack Stouffer wrote: On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar wrote: I did find that I had to go through many articles, video presentations etc. to form my conclusions - it would have been nice if there was a single page on the D website that explained why D should be chosen over the other competing languages. The information is all there but scattered all over the place. http://dlang.org/overview.html Nice - but it is under Getting Started? So it assumes people already want to get started in D? Why not put the first few sections on the main page. Another example of what I think ought to be easily accessible is Andrei's response to following: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why Anyway, I am glad that there is material out there and that I was able to find what I needed! Regards Dibyendu
Re: local import hijacking
On 01/14/2016 02:10 PM, Joakim wrote: Wow, can't believe his PR has been sitting unreviewed for 5 months: https://github.com/D-Programming-Language/dmd/pull/4915 I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei
Re: Choosing D over C++, Go, Rust, Swift
On Thursday, 14 January 2016 at 20:33:50 UTC, Dibyendu Majumdar wrote: Another example of what I think ought to be easily accessible is Andrei's response to following: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why BTW I hadn't seen above before I wrote my reasons - just read it now ... which is my point.
Re: How do you keep up with the Kardashi^W^W github?
On 01/13/2016 10:04 AM, Dicebot wrote: 2) Use GitHub assignments and labels to sort and search through pull requests in a systematic manner according to own plan I just added a label "@andralex" to phobos as an experiment. Consider it a batsignal to be used when my input is waited for on anything. -- Andrei
Re: How do you keep up with the Kardashi^W^W github?
On Thursday, 14 January 2016 at 20:47:30 UTC, Andrei Alexandrescu wrote: On 01/13/2016 10:04 AM, Dicebot wrote: 2) Use GitHub assignments and labels to sort and search through pull requests in a systematic manner according to own plan I just added a label "@andralex" to phobos as an experiment. Consider it a batsignal to be used when my input is waited for on anything. -- Andrei When I was still part of Phobos maintainer team I have added "decision block" label for similar purpose (PR that can't move forward without your/Walter decision or approval). I see that it is still at least occasionally used : https://github.com/D-Programming-Language/phobos/labels/decision%20block It probably makes sense to reassign all PR's with that label to new "@andralex" and delete "decision block" to avoid accumulating label garbage ;)
Re: local import hijacking
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote: std.net.curl.CurlException@std\net\curl.d(4033): Couldn't resolve host name on handle 2188398 0x00405F65 0x00405F10 0x0040275B 0x0040259E 0x0040202B 0x00402035 0x004257A7 0x004256A8 0x0041B7FF 0x769F337A in BaseThreadInitThunk 0x77429882 in RtlInitializeExceptionChain 0x77429855 in RtlInitializeExceptionChain This was a 4 hour debug which made it worse as I was adding more trace calls to figure out what was going on. My boss is now on the fence, to many compiler bugs with D, he asked me to switch to Java if I have to deal to many more issues like this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another issue we had) And this awesome stack trace helped me so much to track this issue down... What compiler are you using? The useless stack traces got fixed in a fairly recent version of DMD - as have many, many other issues which are still present in GDC, whose front end is several versions out-of-date. It is recommended to do your testing with DMD because of issues like this, and mostly use GDC for making optimized release builds. Alternately, if you don't want to mix two compilers like that, LDC has good performance and is currently significantly more up-to-date than GDC. Or, you could even just use DMD, as the performance of its generated binaries has improved a whole lot in the past two releases, although it is of course still not as good as GDC or LDC in this respect. More generally, though, much as we might not like to admit it, D2 is still beta quality software. It is *vastly* more stable and less frustrating to work with than it was a few years ago when I first tried it, but it still has a long way to go before compiler problems cease to be a part of normal day-to-day usage. If that's not acceptable to you or your business, you really probably should just use something else and check back in five years or so...
Re: [dlang.org] new forum design - preview
On Thursday, 14 January 2016 at 19:46:33 UTC, anonymous wrote: On 14.01.2016 16:29, tn wrote: I don't use my browser in full screen mode, but the useless white margins are still there. With the horizontal-split mode the line length of the message is less than 60 characters. Compared to that, I would be happy with 80 or 90 you suggest. This is an issue with the horizontal split mode, right? In the other modes you should get more than 80 characters on a line. I agree that horizontal split looks quite cramped right now, unless you hide the navigation. Besides, especially the margin that is on the left side of the navigation bar looks ugly, like it was rendered improperly. Would a border help? http://i.imgur.com/XoPddxr.png Or how about making the whole area gray? http://i.imgur.com/AXrmKU4.png Cant you do a max-width on the container holding the main page? I agree it should be an entire 2k display but my laptop the sidebar could easily push the edge of the window.
Re: [dlang.org] new forum design - preview
On Thursday, 14 January 2016 at 19:46:33 UTC, anonymous wrote: Would a border help? http://i.imgur.com/XoPddxr.png Or how about making the whole area gray? http://i.imgur.com/AXrmKU4.png Either of those would be an improvement.
Re: local import hijacking
On Thu, Jan 14, 2016 at 03:37:54PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 01/14/2016 02:10 PM, Joakim wrote: > >Wow, can't believe his PR has been sitting unreviewed for 5 months: > > > >https://github.com/D-Programming-Language/dmd/pull/4915 > > I notice Kenji has been absent for a while, could anyone take over > that PR? -- Andrei It's almost an entire month since he suddenly went silent. Completely silent, in fact -- no activity whatsoever on his github account. Is he OK?? T -- Unix is my IDE. -- Justin Whear
Re: [dlang.org] new forum design - preview
On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ https://github.com/CyberShadow/DFeed/pull/51 I like the new layout, but I like the actual color scheme.
Re: std.experimental.yesnogc
On 15/01/16 5:11 AM, Andrei Alexandrescu wrote: On 01/14/2016 10:46 AM, Jacob Carlborg wrote: On 2016-01-14 15:52, Andrei Alexandrescu wrote: I don't see how this categorization works. E.g. there's no need for special tooling related to the GC. -- Andrei It was just a couple of suggestions. I don't know exactly what you're going to include in this module. Me neither, which adds to the problem :o). -- Andrei I can already suggest one thing. I'm currently working on a library solution to my managed memory concept. I should have it completed within a day or so. I will be replacing the dummy ref counted solution I built for alphaPhobos with this. As it allows me a LOT more control over the memory. And it will be wonderful for containers with secondary ownership and all that :) http://wiki.dlang.org/User:Alphaglosined/ManagedMemory
Re: extern(C++, ns)
On 1/13/2016 9:39 PM, Walter Bright wrote: https://issues.dlang.org/show_bug.cgi?id=15565 https://issues.dlang.org/show_bug.cgi?id=15565
Re: extern(C++, ns)
On 1/14/2016 6:24 PM, Walter Bright wrote: On 1/13/2016 9:39 PM, Walter Bright wrote: https://issues.dlang.org/show_bug.cgi?id=15565 https://issues.dlang.org/show_bug.cgi?id=15565 I meant: https://github.com/D-Programming-Language/dmd/pull/5351
Re: Google Summer of Code 2016
On 01/14/2016 01:56 PM, Craig Dillabaugh wrote: Deadline is getting closer, any new project ideas are welcome. Starting to get some contact from students now. A few quick ideas: * Bringing a parser generator library into phobos, either based on pegged or independent * SQL parser, binder, validator * Anything building on the strengths on D: introspection, compile-time stuff, DSL, etc. * Improving the GC * Theoretical work - core language semantics, proving immutable provides guarantees etc. Andrei
Re: Google Summer of Code 2016
On Friday, 15 January 2016 at 03:33:23 UTC, Andrei Alexandrescu wrote: On 01/14/2016 01:56 PM, Craig Dillabaugh wrote: Deadline is getting closer, any new project ideas are welcome. Starting to get some contact from students now. A few quick ideas: * Bringing a parser generator library into phobos, either based on pegged or independent * SQL parser, binder, validator * Anything building on the strengths on D: introspection, compile-time stuff, DSL, etc. * Improving the GC * Theoretical work - core language semantics, proving immutable provides guarantees etc. Andrei Thanks.
So... let's document dmd
https://github.com/D-Programming-Language/dlang.org/pull/1196 https://github.com/D-Programming-Language/dmd/pull/5352 Destroy!! Andrei
Re: [dlang.org] new forum design - preview
On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ https://github.com/CyberShadow/DFeed/pull/51 Not an improvement at all, hurts my eyes.
Re: [dlang.org] new forum design - preview
On Friday, 15 January 2016 at 05:52:51 UTC, Tofu Ninja wrote: On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ https://github.com/CyberShadow/DFeed/pull/51 Not an improvement at all, hurts my eyes. Unfortunately this form of criticism is not actionable. What would be more helpful (least to most): - A specific list of things that can be improved - What can be done to improve things - A mock-up image of how you would improve things - A pull request to improve things
Re: [dlang.org] new forum design - preview
On Friday, 15 January 2016 at 05:56:37 UTC, Vladimir Panteleev wrote: On Friday, 15 January 2016 at 05:52:51 UTC, Tofu Ninja wrote: On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ https://github.com/CyberShadow/DFeed/pull/51 Not an improvement at all, hurts my eyes. Unfortunately this form of criticism is not actionable. What would be more helpful (least to most): - A specific list of things that can be improved - What can be done to improve things - A mock-up image of how you would improve things - A pull request to improve things Why do people want to change the way the forums look? I quite like them the way they are now, soft on the eyes, fairly good layout. The forums main disadvantage is features, no code highlight, no formatting, no embedding content like images or videos into posts, ect. Also voting on posts/threads could be very useful to see what people agree with and what they dont. Right now we just have people replying with "+1". This could be exceptionally helpful for help/opinion request threads, the best answer would be upvoted, shit answers down voted.
Re: [dlang.org] new forum design - preview
On Friday, 15 January 2016 at 06:12:23 UTC, Tofu Ninja wrote: On Friday, 15 January 2016 at 05:56:37 UTC, Vladimir Panteleev wrote: On Friday, 15 January 2016 at 05:52:51 UTC, Tofu Ninja wrote: On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ https://github.com/CyberShadow/DFeed/pull/51 Not an improvement at all, hurts my eyes. Unfortunately this form of criticism is not actionable. What would be more helpful (least to most): - A specific list of things that can be improved - What can be done to improve things - A mock-up image of how you would improve things - A pull request to improve things Why do people want to change the way the forums look? I quite like them the way they are now, soft on the eyes, fairly good layout. To match the new dlang.org design. I'm guessing you've missed the other threads? The forums main disadvantage is features, no code highlight, no formatting, no embedding content like images or videos into posts, ect. Also voting on posts/threads could be very useful to see what people agree with and what they dont. Right now we just have people replying with "+1". This could be exceptionally helpful for help/opinion request threads, the best answer would be upvoted, shit answers down voted. These issues have been previously discussed many times. (The conclusion summary is that since the same content needs to be available via multiple media - mailing lists / NNTP - content has to be restricted to the lowest common denominator, these features are controversial as the add bloat and noise, and we seem to be doing just fine without them). Now is not the time to discuss them, because the current effort is on the dlang.org redesign. I'm sorry, but so far you still haven't provided any useful criticism.
Re: [dlang.org] new forum design - preview
On Friday, 15 January 2016 at 06:20:13 UTC, Vladimir Panteleev wrote: To match the new dlang.org design. I'm guessing you've missed the other threads? Oh we doing that again... seems like we want a website re-skin every 6 months or so. These issues have been previously discussed many times. (The conclusion summary is that since the same content needs to be available via multiple media - mailing lists / NNTP - content has to be restricted to the lowest common denominator, these features are controversial as the add bloat and noise, and we seem to be doing just fine without them). Now is not the time to discuss them, because the current effort is on the dlang.org redesign. I'm sorry, but so far you still haven't provided any useful criticism. My criticism is why are people spending more time redesigning the look of the website again... we haven't even had this one that long. There are better ways to improve the website than re-skinning it. Nothing is really changing, just the colors and layout.
Re: Google Summer of Code 2016
On Thursday, 14 January 2016 at 18:56:21 UTC, Craig Dillabaugh wrote: On Thursday, 31 December 2015 at 23:58:32 UTC, Craig Dillabaugh wrote: The deadline for the Google Summer of Code, 2016 is February 19th. Which means we have about a month and a half to put something together. For the time being I've recycled last years projects (with one dropped so far): [...] Deadline is getting closer, any new project ideas are welcome. Starting to get some contact from students now. It might be helpfull if they can help with: * proper fast JSON parser (this is already worked on I think here: https://github.com/s-ludwig/std_data_json, but it seems to need a help with to finally get it to Phobos as we are constantly bit by it on public: https://github.com/kostya/benchmarks) * same with the XML parser * one probably crazy idea - WCF[1] interoperability for vibe.d (it might be helpfull in commercial field if one can use vibe.d as a backend server with WCF capability so .Net clients can call it directly with autogenerated protocol). But it will be a lot of work to implement all features.. [1] https://msdn.microsoft.com/en-us/library/ms731082%28v=vs.110%29.aspx
