Dne 14.2.2017 v 07:48 TheGag96 via Digitalmars-d-learn napsal(a):
https://dpaste.dzfl.pl/adc05892344f (btw, any reason why certificate
validation on dpaste fails right now?)
Because certificate is expired, dpaste use certs from Lets Encrypt which
has short time of validity
I have same issue
On Tuesday, 14 February 2017 at 02:32:33 UTC, Jerry wrote:
On Monday, 13 February 2017 at 22:40:55 UTC, Ali Çehreli wrote:
On 02/13/2017 06:28 AM, Mike Parker wrote:
https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/
I claimed there is a performance improvement
Tonight I stumbled upon Andrei's concept of policy-based design
(https://en.wikipedia.org/wiki/Policy-based_design) and tried to
implement their example in D with the lack of multiple
inheritance in mind.
https://dpaste.dzfl.pl/adc05892344f (btw, any reason why
certificate validation on
`#std.stdio.File` doesn't work, we don't know where is the module
separator:
that could mean `module std` with a class stdio with a field File.
so the syntax would have be:
`std.stdio SYMBOL File`
frankly I don't care which symbol, so long it looks like that. And as I
said, `std.stdio::File` is
On Tuesday, 14 February 2017 at 03:49:28 UTC, Timothee Cour wrote:
What about allowing syntax sugar as an alternative to relying
on the new `from/Module` inline import idiom:
```
void fun(T)(std.stdio::File input, T value) if
(std.traits::isIntegral!T)
{...}
```
instead of:
```
void
As I know, native languages like rust, go, pony, crystal all can
recover from dividing zero fault.
as for language change, I believe the proposed syntax (`::`) can be reduced
to a minimum if we we make `fullyqualifiedName` `::` a reduction to the
from/Module inline import idiom. No complex corner case or new bug
introduced, it could be done as a pure AST transformation
On Mon, Feb 13, 2017 at
> The only thing from has going for it is that it doesn't require a
language change. Yours does, so it should be compared to the proposals in
DIP1005 and not just from.
indeed. But just because something can be done in library code doesn't mean
it should. Same exact rationale for:
`lazy`, `=>`,
On Tuesday, 14 February 2017 at 03:49:28 UTC, Timothee Cour wrote:
What about allowing syntax sugar as an alternative to relying
on the new `from/Module` inline import idiom:
```
void fun(T)(std.stdio::File input, T value) if
(std.traits::isIntegral!T)
{...}
```
instead of:
```
void
https://issues.dlang.org/show_bug.cgi?id=17169
--- Comment #3 from Nick Sabalausky ---
P1 is in a separate "Summary" div further up from the Description div shown
here. This, I understand, is intentional as the first paragraph is considered
to be the "summary", and
What about allowing syntax sugar as an alternative to relying on the new
`from/Module` inline import idiom:
```
void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T)
{...}
```
instead of:
```
void fun(T)(Module!"std.stdio".File input, T value) if
https://issues.dlang.org/show_bug.cgi?id=17180
Issue ID: 17180
Summary: to!string('\0') makes "\0" which breaks concatination
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
On 2/13/17 12:12 PM, Paul Backus wrote:
On Sunday, 12 February 2017 at 11:47:26 UTC, Timothee Cour wrote:
* std.stdio.tempfile creates an (unnamed) File. How do I create a
temporary
fifo instead?
my workaround is to use tempnam but docs says it's not recommended (
On Monday, 13 February 2017 at 22:40:55 UTC, Ali Çehreli wrote:
On 02/13/2017 06:28 AM, Mike Parker wrote:
https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/
I claimed there is a performance improvement in compilation.
Can someone answer kibwen's question on this
https://issues.dlang.org/show_bug.cgi?id=17169
Walter Bright changed:
What|Removed |Added
CC|
On Monday, 13 February 2017 at 22:59:11 UTC, John Colvin wrote:
[ snip ]
sorry, made a typo, that should have been
alias int1 = Initial!(int, 1);
static assert(int1.initial == 1); // typeof(int1.initial)
== int
static assert(int1.init == 1); // typeof(int1.init) == int1
On 02/13/2017 04:59 PM, David Zhang wrote:
I have a struct with two immutable members, and I want to make an array
of them. How do I to this? I'm using allocators for this.
I realize that I misunderstood you; see below for a mutable array.
The following code produces an immutable array
Hi,
I have a struct with two immutable members, and I want to make an
array of them. How do I to this? I'm using allocators for this.
string[] paths;
struct FileDesc {
immutable string path;
immutable uint index;
}
_fileDesc = /*something*/;
You can't use alloc.makeArray because it
On Mon, 13 Feb 2017 15:09:31 +, Kagamin wrote:
> On Monday, 13 February 2017 at 14:46:38 UTC, Mike Parker wrote:
>> "References cannot be upcast to the enclosing class object, nor can
>> they be downcast to a derived interface."
>>
>> https://dlang.org/spec/interface.html#com-interfaces
>
>
On Monday, 13 February 2017 at 22:57:18 UTC, Ali Çehreli wrote:
All interesting stuff! Look how much interest the
self-important idiom received, which the original author had
thought to be a trivial matter:
I hear you but for digital consumer products the driver of sales
is from what
On 02/13/2017 02:18 PM, Guillaume Piolat wrote:
>
https://www.auburnsounds.com/blog/2017-02-13_Vibrant-2.0-released-free-demo.html
>
>
> There is nothing terribly interesting to say technically.
I disagree because you've already given interesting details like the
following and you said
On Monday, 13 February 2017 at 22:16:36 UTC, Bastiaan Veelo wrote:
On Monday, 13 February 2017 at 16:40:02 UTC, Daniel Kozak wrote:
https://dlang.org/phobos/std_typecons.html#.Typedef
Thanks for the pointers. Both Typedef and Proxy create types
that don't mix with the base type, which I want
On Wednesday, 1 February 2017 at 14:01:39 UTC, Sönke Ludwig wrote:
Am 01.02.2017 um 10:46 schrieb aberba:
On Wednesday, 1 February 2017 at 09:35:02 UTC, Sönke Ludwig
wrote:
Am 31.01.2017 um 12:11 schrieb Sönke Ludwig:
The first release of the revamped core module [1] is
nearing, and along
On 02/13/2017 06:28 AM, Mike Parker wrote:
https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/
I claimed there is a performance improvement in compilation. Can someone
answer kibwen's question on this subthread please:
On Monday, 13 February 2017 at 21:42:12 UTC, Ali Çehreli wrote:
Typo: "I didn't expected"
This was fixed after the video was uploaded and tagged so I kept
it :|
Have you already written a blog about developing this game? ;)
Ali
Thanks for the interest!
v2.0:
On Monday, 13 February 2017 at 16:40:02 UTC, Daniel Kozak wrote:
https://dlang.org/phobos/std_typecons.html#.Typedef
Thanks for the pointers. Both Typedef and Proxy create types that
don't mix with the base type, which I want to the contrary. So I
guess I'll go with
struct Initial(T, T
On 02/13/2017 06:22 AM, Guillaume Piolat wrote:
It's the 10th update for this abstract shooter made in D.
And this one update is pretty major: levels, asteroids, storyline, game
modes... everything changed, everything went under scrutiny.
Now using LDC 1.1.0 and supporting Windows, Mac and
On Monday, 13 February 2017 at 19:46:42 UTC, Jacob Carlborg wrote:
On 2017-02-13 15:22, Guillaume Piolat wrote:
It's the 10th update for this abstract shooter made in D.
And this one update is pretty major: levels, asteroids,
storyline, game
modes... everything changed, everything went under
https://issues.dlang.org/show_bug.cgi?id=17169
Jacob Carlborg changed:
What|Removed |Added
CC||d...@me.com
--- Comment #1
On Monday, 13 February 2017 at 21:04:05 UTC, Johan Engelen wrote:
On Monday, 13 February 2017 at 20:09:45 UTC, Daniel Nielsen
wrote:
I still suspect there will be a difference in real-world
applications even with LDC.
Why would you expect there to be a difference?
Module ctors/dtors are
On Monday, 13 February 2017 at 12:26:14 UTC, Stefan Koch wrote:
I am currently working on && again,
So far I hit a curious situation when handling
(b1 && b2 && b3)
everything works fine except that b3 will be evaluated 3 times.
It's a puzzler :)
I just reverted every change of last week I
On Monday, 13 February 2017 at 20:09:45 UTC, Daniel Nielsen wrote:
I still suspect there will be a difference in real-world
applications even with LDC.
Why would you expect there to be a difference?
Module ctors/dtors are still pulled in, regardless of the import
being selective or not.
https://issues.dlang.org/show_bug.cgi?id=17177
--- Comment #1 from alexandru.ermic...@gmail.com ---
I have made a pull request for this bug:
https://github.com/dlang/phobos/pull/5119
The problem was in generation of "parent" symbol for body code, that denoted
the super.overridenMember. In
On Monday, 13 February 2017 at 19:41:11 UTC, Johan Engelen wrote:
But for a full program, compile time is the same (it's really
short so you can't really conclude much from it), and binary
size as well (LDC 1.1.0, -O3). For my test cases below, the
binaries are identical, except for around 30
On 2017-02-13 15:22, Guillaume Piolat wrote:
It's the 10th update for this abstract shooter made in D.
And this one update is pretty major: levels, asteroids, storyline, game
modes... everything changed, everything went under scrutiny.
Now using LDC 1.1.0 and supporting Windows, Mac and Linux
On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote:
Daniel Nielsen put together a post ...
[1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/
I also liked the post, nicely written.
I didn't check, but if this idiom is not already tested in
dmd-testsuite, please add it!
On Monday, 13 February 2017 at 15:04:53 UTC, Daniel N wrote:
On Monday, 13 February 2017 at 15:00:24 UTC, jmh530 wrote:
With the Jack Stouffer comparison, wouldn't it be fairer to do:
import std.datetime : Systime;
import std.traits : isIntegral;
Probably, please help measuring your idea
On 02/07/2017 04:28 PM, deadalnix wrote:
On Saturday, 4 February 2017 at 23:54:12 UTC, David Gileadi wrote:
That's obviously a self important lookup.
This. So much this.
I'm afraid you are the only one who appreciate my humor :)
"self-important" is official now:
https://issues.dlang.org/show_bug.cgi?id=17179
Issue ID: 17179
Summary: dmd 2.073 betas segfault while trying to build vibe.d
project
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
On Monday, 13 February 2017 at 14:20:05 UTC, Kagamin wrote:
Thread unsafe methods shouldn't be marked shared, it doesn't
make sense. If you don't want to provide thread-safe interface,
don't mark methods as shared, so they will not be callable on a
shared instance and thus the user will be
On Sunday, 12 February 2017 at 11:47:26 UTC, Timothee Cour wrote:
* std.stdio.tempfile creates an (unnamed) File. How do I create
a temporary
fifo instead?
my workaround is to use tempnam but docs says it's not
recommended (
http://man7.org/linux/man-pages/man3/tempnam.3.html)
I believe the
On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote:
Daniel Nielsen put together a post
[1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/
An entertaining read!
Dne 13.2.2017 v 17:40 Daniel Kozak napsal(a):
Dne 13.2.2017 v 16:28 Bastiaan Veelo via Digitalmars-d-learn napsal(a):
Hi,
In Extended Pascal, you can derive from a basic type and change the
default initialiser like so:
type int1 = integer value 1;
var i : int1;
ii : int1 value
On Monday, 13 February 2017 at 16:17:49 UTC, jmh530 wrote:
So I tried it again comparing all three versions on my machine.
This time I didn't notice a difference in compilation speed or
binary size between the version with
import std.datetime;
import std.traits;
and the one with
import
Dne 13.2.2017 v 16:28 Bastiaan Veelo via Digitalmars-d-learn napsal(a):
Hi,
In Extended Pascal, you can derive from a basic type and change the
default initialiser like so:
type int1 = integer value 1;
var i : int1;
ii : int1 value 2;
assert(i = 1);
assert(ii = 2);
I have it
On Monday, 13 February 2017 at 15:04:53 UTC, Daniel N wrote:
Probably, please help measuring your idea and post it here. I
intentionally chose a test made by someone else to avoid
biasing from my part. It was the only test I found at time of
writing.
The first time I did it, I got a ~60%
On Saturday, 4 February 2017 at 17:56:55 UTC, Stefan wrote:
in 10 days will be our next Munich D Meetup.
Would be awesome to welcome some of you there.
Agenda:
• 18:00: Get together with Pizza and beer
• 18:45: D and the Cloud, by Ozan
• 19:30: Short Break
• 19:40: Usage of the D Compiler in
Hi,
In Extended Pascal, you can derive from a basic type and change
the default initialiser like so:
type int1 = integer value 1;
var i : int1;
ii : int1 value 2;
assert(i = 1);
assert(ii = 2);
I have it working in D, but it seems a little clumsy. Is there a
better way?
Second beta for the 2.073.1 point release.
This version resolves a few regressions and bugs in the 2.073.0
release.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.073.1.html
Please report any bugs at https://issues.dlang.org
-Martin
On Monday, 13 February 2017 at 14:46:38 UTC, Mike Parker wrote:
"References cannot be upcast to the enclosing class object, nor
can they be downcast to a derived interface."
https://dlang.org/spec/interface.html#com-interfaces
COM interfaces can't be downcasted indeed, but it should be
On Monday, 13 February 2017 at 15:00:24 UTC, jmh530 wrote:
On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote:
Daniel Nielsen put together a post describing the import idiom
that came to light in a recent forum discussion regarding DIP
1005 [3]. The relevant links are at [1] and
On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote:
Daniel Nielsen put together a post describing the import idiom
that came to light in a recent forum discussion regarding DIP
1005 [3]. The relevant links are at [1] and [2].
[1]
On Monday, 13 February 2017 at 13:38:23 UTC, Kagamin wrote:
On Monday, 13 February 2017 at 13:21:44 UTC, Daniel Kozak wrote:
and I guess even ComObject does not inherit from Object
This compiles:
void f()
{
import core.sys.windows.com;
ComObject a;
Object b=a;
}
It's the 10th update for this abstract shooter made in D.
And this one update is pretty major: levels, asteroids,
storyline, game modes... everything changed, everything went
under scrutiny.
Now using LDC 1.1.0 and supporting Windows, Mac and Linux x86_64
(tested: Debian and Ubuntu).
Daniel Nielsen put together a post describing the import idiom
that came to light in a recent forum discussion regarding DIP
1005 [3]. The relevant links are at [1] and [2].
[1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/
[2]
On Sunday, 12 February 2017 at 20:08:05 UTC, bitwise wrote:
Given that both the data and the method are 'shared', a caller
should know that race conditions are possible and that they
should aquire a lock before accessing either of them...or so it
would seem.
Thread unsafe methods shouldn't
On Monday, 13 February 2017 at 13:21:44 UTC, Daniel Kozak wrote:
and I guess even ComObject does not inherit from Object
This compiles:
void f()
{
import core.sys.windows.com;
ComObject a;
Object b=a;
}
On Monday, 13 February 2017 at 13:18:33 UTC, Daniel Kozak wrote:
Not all classes, extern(C++) classes does not
C++ only has C++ interfaces and they are different from D
interfaces.
Dne 13.2.2017 v 14:12 Kagamin via Digitalmars-d napsal(a):
On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright wrote:
not all interfaces are Objects
Do you have an example? How it can be? Only classes can implement
interfaces, and classes inherit from Object.
and I guess even
Dne 13.2.2017 v 14:12 Kagamin via Digitalmars-d napsal(a):
On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright wrote:
not all interfaces are Objects
Do you have an example? How it can be? Only classes can implement
interfaces, and classes inherit from Object.
Not all classes,
On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright
wrote:
not all interfaces are Objects
Do you have an example? How it can be? Only classes can implement
interfaces, and classes inherit from Object.
https://issues.dlang.org/show_bug.cgi?id=17178
anonymous4 changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=13183
anonymous4 changed:
What|Removed |Added
CC|
I am currently working on && again,
So far I hit a curious situation when handling
(b1 && b2 && b3)
everything works fine except that b3 will be evaluated 3 times.
It's a puzzler :)
Hi All,
The Berlin February D meetup is happening this Friday (17th) at
19:30 at Berlin Co-Op (http://co-up.de/) on the fifth floor.
Mihails Strasuns will be presenting a talk on "Testing D projects
with GitLab CI and Docker" and a brief introductions is below.
"Hobby projects often
On Sunday, 12 February 2017 at 15:30:40 UTC, Vladimir Panteleev
wrote:
I accept that this shouldn't have taken a week to fix, and the
initial change in question (tmpfs move) would have been better
done in a test environment. FWIW, in parallel I've been working
on a full-disk backup strategy to
On Monday, 13 February 2017 at 08:21:38 UTC, Timothee Cour wrote:
https://issues.dlang.org/show_bug.cgi?id=17178
dmd -c -o- bar.d
Error: namespace bar.std conflicts with import bar.std at
bar.d(2)
```
module bar;
import std.exception;
extern (C++, std) { struct Foo1 { } }
```
this seems
https://issues.dlang.org/show_bug.cgi?id=17178
dmd -c -o- bar.d
Error: namespace bar.std conflicts with import bar.std at bar.d(2)
```
module bar;
import std.exception;
extern (C++, std) { struct Foo1 { } }
```
this seems like a serious blocker to interface with C++ ; what's a
workaround?
https://issues.dlang.org/show_bug.cgi?id=17178
Timothee Cour changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=17178
Issue ID: 17178
Summary: namespace bar.std conflicts with namespace bar.std
Product: D
Version: D2
Hardware: x86
OS: All
Status: NEW
Severity: blocker
70 matches
Mail list logo