hi,
Is there any other documents related about ddoc usage? the only
thing I can find is:
https://dlang.org/spec/ddoc.html#using_ddoc_to_generate_examples
But I found it never mentioned something like $(LI a list item),
is there a full ddoc document available?
And, is there any info
https://issues.dlang.org/show_bug.cgi?id=11174
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime
https://github.com/dlang/druntime/commit/d7b855a0f816b9e376ecfb187dd618be90a8d8d7
Fix Issue 11174 - Define non-standard address
https://issues.dlang.org/show_bug.cgi?id=11174
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wed, Oct 17, 2018 at 6:15 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 17.10.2018 14:24, Timon Gehr wrote:
> > and unshared methods are only allowed to access unshared members.
>
> This is actually not necessary, let me reformulate:
>
> You want:
>
> - if you have a C c and a shared(C) s,
On Wednesday, 17 October 2018 at 16:50:36 UTC, Paul Backus wrote:
On Wednesday, 17 October 2018 at 07:01:21 UTC, test wrote:
simple example: you can not use functionAttributes from betterC
On Wed, Oct 17, 2018 at 6:50 PM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/17/18 6:37 PM, Manu wrote:
> > On Wed, Oct 17, 2018 at 12:35 PM Steven Schveighoffer via
> > Digitalmars-d wrote:
> >>
> >> On 10/17/18 2:46 PM, Manu wrote:
> >>> On Wed, Oct 17, 2018 at 10:30 AM Steven
On Wednesday, 17 October 2018 at 23:12:48 UTC, Manu wrote:
On Wed, Oct 17, 2018 at 2:15 PM Stanislav Blinov via
Digitalmars-d wrote:
On Wednesday, 17 October 2018 at 19:25:33 UTC, Manu wrote:
> On Wed, Oct 17, 2018 at 12:05 PM Stanislav Blinov via
> Digitalmars-d wrote:
>>
>> On Wednesday,
On Wed, Oct 17, 2018 at 5:35 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Wednesday, 17 October 2018 at 23:12:48 UTC, Manu wrote:
> > On Wed, Oct 17, 2018 at 2:15 PM Stanislav Blinov via
> > Digitalmars-d wrote:
> >>
> >> On Wednesday, 17 October 2018 at 19:25:33 UTC, Manu wrote:
> >> >
On 10/17/18 6:37 PM, Manu wrote:
On Wed, Oct 17, 2018 at 12:35 PM Steven Schveighoffer via
Digitalmars-d wrote:
On 10/17/18 2:46 PM, Manu wrote:
On Wed, Oct 17, 2018 at 10:30 AM Steven Schveighoffer via
What the example demonstrates is that while you are trying to disallow
implicit
On Wednesday, 17 October 2018 at 16:14:14 UTC, Neia Neutuladh
wrote:
On Wednesday, 17 October 2018 at 14:02:20 UTC, Jesse Phillips
wrote:
Wait, why does each get a special bailout? Doesn't until full
that role?
`until` is lazy. We could have `doUntil` instead, which would
be eager and would
I don't have anything to add that hasn't been said yet but it's
good to see some thinking on this subject. It feels like progress.
On Wednesday, 17 October 2018 at 23:12:48 UTC, Manu wrote:
On Wed, Oct 17, 2018 at 2:15 PM Stanislav Blinov via
Digitalmars-d wrote:
On Wednesday, 17 October 2018 at 19:25:33 UTC, Manu wrote:
> On Wed, Oct 17, 2018 at 12:05 PM Stanislav Blinov via
> Digitalmars-d wrote:
>>
>> On Wednesday,
On Tuesday, 16 October 2018 at 02:20:09 UTC, Soulsbane wrote:
Have you tried melatonin? My doctor has me take a 1mg tablet
and split it in two. So I take 1/2 at bedtime. That is the
sweet spot. If you take more than that you will end up groggy.
No, but I'll since I used to have this issue
On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe
wrote:
On Wednesday, 17 October 2018 at 17:37:37 UTC, Kai wrote:
I just ran into this linker issue (see answer below that I
grabbed from the vibe.d forum) as well - where can I ask/track
about the progress on this issue?
Do you
On Wednesday, 17 October 2018 at 22:37:53 UTC, Stanislav Blinov
wrote:
On Wednesday, 17 October 2018 at 22:30:31 UTC, Jordan Wilson
wrote:
Ideally, I'd check args before I take the time to load up data.
https://dlang.org/phobos/core_runtime.html#.Runtime
Here I was looking through
On Wednesday, 17 October 2018 at 16:50:36 UTC, Paul Backus wrote:
You can't append to an array in betterC code, because making
space for the new elements requires allocating memory, and that
uses the GC.
In theory, since you're only using the GC during CTFE, it
shouldn't be a problem, but
On Wednesday, 17 October 2018 at 07:32:37 UTC, aliak wrote:
lazy S x = () {
// do some heavy stuff
}();
if (condition) {
func(x.y); // heavy stuff evaluated here
}
auto x = () {
// do some heavy stuff
};
if (condition) {
func(x().y); // heavy stuff evaluated here
}
If you want
I'm referring mainly to the `dagon` game engine.
Doing:
dub build :tutorial1
dub run :tutorial1
works on windows 10.
I'm not sure how to replicate this build process with Visual
Studio 2017 project settings.
Dagon is building, but I'm getting errors with a basic Hellow
World app in Dagon.
On Wednesday, 17 October 2018 at 08:08:44 UTC, Gary Willoughby
wrote:
On Wednesday, 17 October 2018 at 03:37:21 UTC, Ky-Anh Huynh
wrote:
Hi,
I need to build some static binaries with LDC. I also need to
execute builds on both platform 32-bit and 64-bit.
From Docker Hub there are two image
On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
On Wed, Oct 17, 2018 at 10:13:37PM +, Stefan Koch via
Digitalmars-d wrote:
On Wednesday, 17 October 2018 at 21:55:48 UTC, H. S. Teoh
wrote:
[...]
> But nobody will be building a fusion engine out of race
> conditions anytime
On Wed, Oct 17, 2018 at 2:15 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Wednesday, 17 October 2018 at 19:25:33 UTC, Manu wrote:
> > On Wed, Oct 17, 2018 at 12:05 PM Stanislav Blinov via
> > Digitalmars-d wrote:
> >>
> >> On Wednesday, 17 October 2018 at 18:46:18 UTC, Manu wrote:
> >>
>
Answer: they don't connect uniquely, you have to manage that
yourself.
On Wed, Oct 17, 2018 at 10:13:37PM +, Stefan Koch via Digitalmars-d wrote:
> On Wednesday, 17 October 2018 at 21:55:48 UTC, H. S. Teoh wrote:
[...]
> > But nobody will be building a fusion engine out of race conditions
> > anytime in the foreseeable future. :-D
[...]
> Now my analogy sounds
On Wednesday, 17 October 2018 at 22:30:31 UTC, Jordan Wilson
wrote:
Ideally, I'd check args before I take the time to load up data.
https://dlang.org/phobos/core_runtime.html#.Runtime
On Wed, Oct 17, 2018 at 12:35 PM Steven Schveighoffer via
Digitalmars-d wrote:
>
> On 10/17/18 2:46 PM, Manu wrote:
> > On Wed, Oct 17, 2018 at 10:30 AM Steven Schveighoffer via
>
> >> What the example demonstrates is that while you are trying to disallow
> >> implicit casting of a shared pointer
Hello,
Is there a way to access command line arguments outside of main?
// main.d
module main;
import data;
void main(string args[]) {
}
// data.d
module data
immutable programData;
static this() {
// read in data
}
Ideally, I'd check args before I take the time to load up data.
On Wednesday, 17 October 2018 at 21:55:48 UTC, H. S. Teoh wrote:
Nah, that's not even anywhere close to nuclear fusion.
The atoms which make up your body (and basically everything
else) are mostly empty, with just a tiny speck of a nucleus,
and a bunch of extremely tiny electrons zipping
On Wednesday, 17 October 2018 at 21:55:48 UTC, H. S. Teoh wrote:
But nobody will be building a fusion engine out of race
conditions anytime in the foreseeable future. :-D
We should be so blessed...
On Wed, Oct 17, 2018 at 09:29:07PM +, Stefan Koch via Digitalmars-d wrote:
> On Wednesday, 17 October 2018 at 21:12:49 UTC, Stefan Koch wrote:
> > [another person] cannot actually occupy the same space. It is
> > physically impossible.
>
> Actually, that's not quite true, If they were to try
On Wednesday, 17 October 2018 at 21:40:35 UTC, Stanislav Blinov
wrote:
Now, I perfectly understand what Manu wants: for `shared` to
stop being a stupid keyword that nobody uses, and start
bringing in value to the language. At the moment, the compiler
happily allows you to write and read
On Wednesday, 17 October 2018 at 21:29:07 UTC, Stefan Koch wrote:
in any case it would certainly mess up
the state of everyone involved; which is exactly what happens
win multi-threaded situations.
^ that is very true. And that is why:
- one must not keep shared and local data close
On Wednesday, 17 October 2018 at 21:12:49 UTC, Stefan Koch wrote:
[another person] cannot actually occupy the same space. It is
physically impossible.
Actually, that's not quite true, If they were to try hard enough
the result would be nuclear fusion, (I am guessing (I am not a
phsysist)),
On Wednesday, 17 October 2018 at 20:53:02 UTC, Vijay Nayar wrote:
This particular use of "scope" I overheard at the last DConf,
and I believe it has been added to the official documentation
here: https://dlang.org/spec/expression.html#new_expressions
If a NewExpression is used as an
On 10/17/2018 01:53 PM, Vijay Nayar wrote:
> https://dlang.org/spec/expression.html#new_expressions
>
> If a NewExpression is used as an initializer for a function local
> variable with
> scope storage class, and the ArgumentList to new is empty, then the
> instance is
> allocated
On Wednesday, 17 October 2018 at 19:25:33 UTC, Manu wrote:
On Wed, Oct 17, 2018 at 12:05 PM Stanislav Blinov via
Digitalmars-d wrote:
On Wednesday, 17 October 2018 at 18:46:18 UTC, Manu wrote:
> I've said this a bunch of times, there are 2 rules:
> 1. shared inhibits read and write access to
Hi,
reading the other shared thread "shared - i need to be
useful"(https://forum.dlang.org/thread/mailman.4299.1539629222.29801.digitalmar...@puremagic.com)
let me to an important realisation concerning the reason
shareding data across threads is so unintuitve and hard to get
right.
The
On 17.10.18 20:46, Manu wrote:
struct NotThreadsafe
{
int x;
void local()
{
++x; // <- invalidates the method below, you violate the other
function's `shared` promise
}
void notThreadsafe() shared
{
atomicIncrement();
}
}
In the `shared` method you'd get a nice
On Wednesday, 17 October 2018 at 20:41:24 UTC, Ali Çehreli wrote:
On 10/17/2018 01:24 PM, Vijay Nayar wrote:
I have a snippet of code like this:
scope chordAngle = new S1ChordAngle(_center,
other._center);
return _radius + other._radius >= chordAngle;
The reason the "scope"
On Wednesday, 17 October 2018 at 20:51:29 UTC, Stanislav Blinov
wrote:
On Wednesday, 17 October 2018 at 20:24:56 UTC, Vijay Nayar
wrote:
I have a snippet of code like this:
scope chordAngle = new S1ChordAngle(_center,
other._center);
return _radius + other._radius >= chordAngle;
The
On Wednesday, 17 October 2018 at 20:24:56 UTC, Vijay Nayar wrote:
I have a snippet of code like this:
scope chordAngle = new S1ChordAngle(_center, other._center);
return _radius + other._radius >= chordAngle;
The reason the "scope" temporary variable exists is to avoid a
heap
On 10/17/2018 12:32 AM, aliak wrote:
Hi,
Is there any notion of lazy vars in D (i see that there're parameters)?
i.e:
struct S {
//...
int y;
//...
}
lazy S x = () {
// do some heavy stuff
}();
if (condition) {
func(x.y); // heavy stuff evaluated here
}
Cheers,
- Ali
I have a snippet of code like this:
scope chordAngle = new S1ChordAngle(_center, other._center);
return _radius + other._radius >= chordAngle;
The reason the "scope" temporary variable exists is to avoid a
heap allocation and instead prefer a value be created on the
stack. Is there a
On 10/17/2018 01:24 PM, Vijay Nayar wrote:
I have a snippet of code like this:
scope chordAngle = new S1ChordAngle(_center, other._center);
return _radius + other._radius >= chordAngle;
The reason the "scope" temporary variable exists is to avoid a heap
allocation and instead prefer
On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:
I have done two mistakes: I underestimated the scope of the
project and overestimated my capabilities. This caused a chain
reaction, which in turn made the first milestone unreachable.
Hi, I'm one of the other participants to
I don't see any problem with this proposal as long as these
points hold:
- Shared <-> Unshared is never implicit, either requiring an
explicit cast (both ways) or having a language support which
allows the conversion gracefully.
- Shared methods are called by compiler if the type is shared or
On 10/17/18 2:46 PM, Manu wrote:
On Wed, Oct 17, 2018 at 10:30 AM Steven Schveighoffer via
What the example demonstrates is that while you are trying to disallow
implicit casting of a shared pointer to an unshared pointer, you have
inadvertently allowed it by leaving behind an unshared
On Sunday, 14 October 2018 at 19:04:51 UTC, Sebastiaan Koppe
wrote:
On Sunday, 14 October 2018 at 06:03:10 UTC, Bogdan wrote:
Awesome work! I remember that, at some point the
https://glimmerjs.com/ authors wanted to write their vm in
rust for better performance. It looks like D is a new option
On Wed, Oct 17, 2018 at 12:05 PM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Wednesday, 17 October 2018 at 18:46:18 UTC, Manu wrote:
>
> > I've said this a bunch of times, there are 2 rules:
> > 1. shared inhibits read and write access to members
> > 2. `shared` methods must be threadsafe
>
On Tuesday, 16 October 2018 at 07:57:12 UTC, Sebastiaan Koppe
wrote:
On Tuesday, 16 October 2018 at 03:23:21 UTC, Jesse Phillips
wrote:
It would be cool if D provided the easiest way to develop
webasm first to see if it could claim that market.
If you have some minutes to spare it would be
On Wednesday, 17 October 2018 at 18:46:18 UTC, Manu wrote:
I've said this a bunch of times, there are 2 rules:
1. shared inhibits read and write access to members
2. `shared` methods must be threadsafe
From there, shared becomes interesting and useful.
Oh God...
void atomicInc(shared int*
On 10/17/18 2:03 PM, Carl Sturtivant wrote:
On Monday, 15 October 2018 at 13:39:59 UTC, Steven Schveighoffer wrote:
But that's just the thing -- merge sort *does* depend on the container
type. It requires the ability to rearrange the elements structurally,
since you merge the sets of items
On Wed, Oct 17, 2018 at 10:30 AM Steven Schveighoffer via
Digitalmars-d wrote:
>
> On 10/17/18 12:27 PM, Nicholas Wilson wrote:
> > On Wednesday, 17 October 2018 at 15:51:04 UTC, Steven Schveighoffer wrote:
> >> On 10/17/18 9:58 AM, Nicholas Wilson wrote:
> >>> On Wednesday, 17 October 2018 at
On Wednesday, 17 October 2018 at 15:18:43 UTC, Vladimir Panteleev
wrote:
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak
wrote:
Glad to announce the first beta for the 2.083.0 release, ♥ to
the 48 contributors for this release.
Thanks!
CppRuntime_* version identifiers -
On Monday, 15 October 2018 at 13:39:59 UTC, Steven Schveighoffer
wrote:
But that's just the thing -- merge sort *does* depend on the
container type. It requires the ability to rearrange the
elements structurally, since you merge the sets of items
together. This requires making another list
On Wednesday, 17 October 2018 at 17:37:37 UTC, Kai wrote:
I just ran into this linker issue (see answer below that I
grabbed from the vibe.d forum) as well - where can I ask/track
about the progress on this issue?
Do you have the new dmd installed? Using the x86_64 should work
now if all
Hi,
I just ran into this linker issue (see answer below that I
grabbed from the vibe.d forum) as well - where can I ask/track
about the progress on this issue?
Thanks!
"This is currently an unfortunate limitation on Windows, where
the DigitalMars linker runs into a crash when building with
On 10/17/18 12:27 PM, Nicholas Wilson wrote:
On Wednesday, 17 October 2018 at 15:51:04 UTC, Steven Schveighoffer wrote:
On 10/17/18 9:58 AM, Nicholas Wilson wrote:
On Wednesday, 17 October 2018 at 13:25:28 UTC, Steven Schveighoffer
wrote:
It's identical to the top one. You now have a new
On Wednesday, 17 October 2018 at 07:01:21 UTC, test wrote:
test1:
module test1;
import test2;
enum X = getR(1,3);
void main(string[] args){}
test2:
module test2;
struct R {
int i;
}
R[] getR(int a, int b){
R[] r;
r ~=
On Wednesday, 17 October 2018 at 14:14:56 UTC, Nicholas Wilson
wrote:
On Wednesday, 17 October 2018 at 07:24:13 UTC, Stanislav Blinov
wrote:
On Wednesday, 17 October 2018 at 05:40:41 UTC, Walter Bright
wrote:
When Andrei and I came up with the rules for:
mutable
const
shared
On Wednesday, 17 October 2018 at 14:44:19 UTC, Guillaume Piolat
wrote:
The fact that this _type constructor_ finds its way into
_identifiers_ create some concern:
https://github.com/dlang/phobos/blob/656798f2b385437c239246b59e0433148190938c/std/experimental/allocator/package.d#L642
Well,
On Wednesday, 17 October 2018 at 15:51:04 UTC, Steven
Schveighoffer wrote:
On 10/17/18 9:58 AM, Nicholas Wilson wrote:
On Wednesday, 17 October 2018 at 13:25:28 UTC, Steven
Schveighoffer wrote:
It's identical to the top one. You now have a new unshared
reference to shared data. This is done
On Wednesday, 17 October 2018 at 00:12:13 UTC, H. S. Teoh wrote:
I'm not sure what's the reasoning behind the saying that
throwing exceptions in ctors is bad, but exceptions are exactly
the kind of thing designed for handling this sort of situation.
If the parser detects a problem early (i.e.,
On Wednesday, 17 October 2018 at 14:02:20 UTC, Jesse Phillips
wrote:
Wait, why does each get a special bailout? Doesn't until full
that role?
`until` is lazy. We could have `doUntil` instead, which would be
eager and would return a boolean indicating whether to continue.
We could all write
On Wednesday, 17 October 2018 at 15:51:21 UTC, Codifies wrote:
okay I should have carried on reading the blog, its so
uninitialized values stick out when debugging...
Indeed, the initial value is not supposed to be useful, it's
there because dealing with garbage memory when forgetting to
On 10/17/18 8:20 AM, Mike Parker wrote:
I had intended to publish the next GC series post early this month, but
after many revisions and discussions with a couple of reviewers, I've
decided to put it on hold until something gets worked out about the
conflation of destruction and finalization
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.083.0 release, ♥ to
BTW, title says Beta 2.082.0 :)
On 10/17/18 9:58 AM, Nicholas Wilson wrote:
On Wednesday, 17 October 2018 at 13:25:28 UTC, Steven Schveighoffer wrote:
It's identical to the top one. You now have a new unshared reference
to shared data. This is done WITHOUT any agreed-upon synchronization.
It isn't, you typo'd it (I
On Wednesday, 17 October 2018 at 15:48:16 UTC, Codifies wrote:
I'd have thought it ought to be 0.0 ?
So far I seen carefully considered and sensible reasons for
doing things in D, so why NAN ?
You are supposed to initialize your own variables explicitly. NaN
is a somewhat easy way to
On Wednesday, 17 October 2018 at 15:48:16 UTC, Codifies wrote:
I'd have thought it ought to be 0.0 ?
So far I seen carefully considered and sensible reasons for
doing things in D, so why NAN ?
okay I should have carried on reading the blog, its so
uninitialized values stick out when
On 10/17/18 10:33 AM, Nicholas Wilson wrote:
On Wednesday, 17 October 2018 at 14:26:43 UTC, Timon Gehr wrote:
On 17.10.2018 16:14, Nicholas Wilson wrote:
I was thinking that mutable -> shared const as apposed to mutable ->
shared would get around the issues that Timon posted.
Unfortunately
On 10/17/18 10:18 AM, Timon Gehr wrote:
On 17.10.2018 15:40, Steven Schveighoffer wrote:
On 10/17/18 8:02 AM, Timon Gehr wrote:
Now, if a class has only shared members, that is another story. In
this case, all references should implicitly convert to shared.
There's a DIP I meant to write
I'd have thought it ought to be 0.0 ?
So far I seen carefully considered and sensible reasons for doing
things in D, so why NAN ?
On Wednesday, 17 October 2018 at 15:18:43 UTC, Vladimir Panteleev
wrote:
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak
wrote:
Glad to announce the first beta for the 2.083.0 release, ♥ to
the 48 contributors for this release.
Thanks!
CppRuntime_* version identifiers -
On Wednesday, 17 October 2018 at 14:06:49 UTC, FrankLike wrote:
Where can get the new dmd or ldc2 that's no 'Trojan horse
virus' ?
https://dlang.org/download.html
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya wrote:
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should
bring that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does have D file
I had intended to publish the next GC series post early this
month, but after many revisions and discussions with a couple of
reviewers, I've decided to put it on hold until something gets
worked out about the conflation of destruction and finalization
in D (something I'll be pushing for
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.083.0 release, ♥ to
the 48 contributors for this release.
Thanks!
CppRuntime_* version identifiers -
https://dlang.org/changelog/2.083.0.html#cppVersions
When is this different from
On Wednesday, 17 October 2018 at 07:20:20 UTC, Manu wrote:
Shared is uninteresting and mostly useless as spec-ed, everyone
knows this.
Interaction with shared via barely-controlled blunt casting in
@trusted blocks is feeble and boring. It doesn't really give us
anything in practice that we
On Wednesday, 17 October 2018 at 14:26:43 UTC, Timon Gehr wrote:
On 17.10.2018 16:14, Nicholas Wilson wrote:
I was thinking that mutable -> shared const as apposed to
mutable -> shared would get around the issues that Timon
posted.
Unfortunately not. For example, the thread with the
https://issues.dlang.org/show_bug.cgi?id=11499
--- Comment #2 from RazvanN ---
PR : https://github.com/dlang/dmd/pull/8839
--
https://issues.dlang.org/show_bug.cgi?id=9274
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #2 from
On 17.10.2018 16:14, Nicholas Wilson wrote:
I was thinking that mutable -> shared const as apposed to mutable ->
shared would get around the issues that Timon posted.
Unfortunately not. For example, the thread with the mutable reference is
not obliged to actually make the changes that are
On 17.10.2018 15:40, Steven Schveighoffer wrote:
On 10/17/18 8:02 AM, Timon Gehr wrote:
Now, if a class has only shared members, that is another story. In
this case, all references should implicitly convert to shared. There's
a DIP I meant to write about this. (For all qualifiers, not just
On Wednesday, 17 October 2018 at 07:24:13 UTC, Stanislav Blinov
wrote:
On Wednesday, 17 October 2018 at 05:40:41 UTC, Walter Bright
wrote:
When Andrei and I came up with the rules for:
mutable
const
shared
const shared
immutable
and which can be implicitly converted to what,
On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.083.0 release, ♥ to
the 48 contributors for this release.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.083.0.html
Wait, why does each get a special bailout?
On Wednesday, 17 October 2018 at 13:50:03 UTC, Stanislav Blinov
wrote:
On Wednesday, 17 October 2018 at 13:48:04 UTC, FrankLike wrote:
What can I do?
Delete the bloatware that you downloaded.
Where can get the new dmd or ldc2 that's no 'Trojan horse virus' ?
On Wednesday, 17 October 2018 at 13:25:28 UTC, Steven
Schveighoffer wrote:
On 10/16/18 8:26 PM, Manu wrote:
On Tue, Oct 16, 2018 at 2:20 PM Steven Schveighoffer via
Digitalmars-d
wrote:
There is in fact, no difference between:
int *p;
shared int *p2 = p;
int *p3 = cast(int*)p2;
Totally
https://issues.dlang.org/show_bug.cgi?id=11499
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
See Also|
https://issues.dlang.org/show_bug.cgi?id=9274
RazvanN changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
|
On Wednesday, 17 October 2018 at 13:48:04 UTC, FrankLike wrote:
What can I do?
Delete the bloatware that you downloaded.
Hi,teacher:
I like D lang,when I download the soft from
http://www.360totalsecurity.com/en/, but I find, the link.exe of
dmd or ldc2,all have the ‘Trojan horse virus’.
dmd.2.082.1.windows.7z:HEUR/QVM19.1.92C9.Malware.Gen
file MD5:91ce2a59f06151902a1f3fc49e0a4752
On 10/17/18 8:02 AM, Timon Gehr wrote:
Now, if a class has only shared members, that is another story. In this
case, all references should implicitly convert to shared. There's a DIP
I meant to write about this. (For all qualifiers, not just shared).
When you say "shared members", you mean
On Wednesday, 17 October 2018 at 13:36:53 UTC, Stanislav Blinov
wrote:
Explicit cast from mutable to unsafe, on the other hand:
Blargh, to shared of course.
Jesus Manu, it's soon 8 pages of dancing around a trivial issue.
Implicit casting from mutable to shared is unsafe, case closed.
Explicit cast from mutable to unsafe, on the other hand:
- is an assertion (on programmer's behalf) that this instance is
indeed unique
- is self-documenting
- is
On 10/16/18 8:26 PM, Manu wrote:
On Tue, Oct 16, 2018 at 2:20 PM Steven Schveighoffer via Digitalmars-d
wrote:
On 10/16/18 4:26 PM, Manu wrote:
On Tue, Oct 16, 2018 at 11:30 AM Steven Schveighoffer via
Digitalmars-d wrote:
int x;
shared int *p = // allow implicit conversion, currently
On Wednesday, 17 October 2018 at 08:35:09 UTC, Russel Winder
wrote:
D + GtkD (inc GStreamerD) is really quite nice. The biggest
downside is the documentation presenting all the C examples not
D ones, and the lack of non- trivial examples of use. The
biggest problem is really not enough
On 17.10.2018 14:24, Timon Gehr wrote:
and unshared methods are only allowed to access unshared members.
This is actually not necessary, let me reformulate:
You want:
- if you have a C c and a shared(C) s, typeof(s.x) == typeof(c.x).
- shared methods are not allowed to access unshared
On 10/16/18 6:24 PM, Nicholas Wilson wrote:
On Tuesday, 16 October 2018 at 21:19:26 UTC, Steven Schveighoffer wrote:
OK, so here is where I think I misunderstood your point. When you said
a lock-free queue would be unusable if it wasn't shared, I thought you
meant it would be unusable if we
On 17.10.2018 14:29, Timon Gehr wrote:
to access c.m iff m is not shared
Unfortunate typo. This should be if, not iff (if and only if).
On 17.10.2018 09:20, Manu wrote:
Timon Gehr has done a good job showing that they still stand
unbreached.
His last comment was applied to a different proposal.
His only comment on this thread wasn't in response to the proposal in
this thread.
If you nominate Timon as your proxy, then he needs
1 - 100 of 125 matches
Mail list logo
