Help needed for D support in SCons on Windows
Hi, I know there are a number of people out there who use SCons to build D codes. I know there are a number of those people who work on Windows. Your help is being asked for. All the work I have done for D support in SCons has been based entirely on Debian Sid, but tested on Fedora Rawhide, and on occasion OSX El Capitan. It turns out there are a number problems with the SCons tests running on Windows, many of them associated with the D support. https://github.com/SCons/scons/issues/3205 As you will see I am choosing not to get involved in anything to do with Windows. The D support in SCons on Windows does though need some work, and so SCons needs some people to get involved – due to enlightened self-interest. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Wrong module initialization order when building with Dub on Windows?
On Tuesday, 2 October 2018 at 01:57:00 UTC, Vladimir Panteleev wrote: Ran into this today, don't have time to dig in now but maybe someone ran into this too. Steps to reproduce: - git clone https://github.com/CyberShadow/ae - cd ae/demo/inputtiming - (download/unpack https://www.libsdl.org/release/SDL2-2.0.8-win32-x86.zip or https://www.libsdl.org/release/SDL2-2.0.8-win32-x64.zip to current directory) - dub On Windows, I get a range violation (in ae.sys.log) which indicates that Runtime.args has length 0, which should never happen. This doesn't happen if I build as usual with rdmd, or on Linux (either rdmd or Dub). I'd take a look at what arguments are passed to DMD with rdmd vs. dub. Maybe to module order is different?
Dlang tour - Unittesting example
There appears to be a problem with the example at https://tour.dlang.org/tour/en/gems/unittesting If compiled with -unittest, the resulting program crashes. It happens with ldc2 on Linux but it can also be seen if you click on "Export" and run it with dmd -unittest.
Use std.traits.getSymbolsByUDA to access members of instance.
I can use `std.traits.getSymbolsByUDA` to get all the members of a class that have a particular UDA `getSymbolsByUDA(ValueType, UDA)`. But how do I get the values with it? Is there a more convenient way than `__traits(getMember, value, getSymbolsByUDA(ValueType, UDA)[0].stringof)`?
Re: Funny way to crash dmd and brick the whole computer
On Friday, 28 September 2018 at 11:58:25 UTC, Zardoz wrote:
CTE fib :
module fib_cte;
import std.stdio;
long fib(long n) {
if (n <= 1) return 1;
return fib(n - 1) + fib(n - 2);
}
static immutable valueFib = fib(46);
void main() {
writeln(valueFib);
}
I tried it on Android with LDC, it eventually just kills the
process. You need to get a real OS. ;)
Re: Warn on unused imports?
On Monday, October 1, 2018 8:03:39 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 10/01/2018 04:58 PM, Jonathan M Davis wrote: > > On Monday, October 1, 2018 2:44:32 PM MDT Nick Sabalausky (Abscissa) via > > > > Digitalmars-d wrote: > >> Nobody said anything about making them part of the build process. We're > >> talking about them being included in the compiler, not about them being > >> in the build process. Please don't move the goalposts. > > > > dmd -w > > > > and > > > > dmd -wi > > > > build your program. Printing warnings is part of the build process. > > dmd > > or > > dmd -w -o- > > Just like external tools, they're NOT part of the build process unless > you CHOOSE to make them part of your build process. (Though, with > external tools, there's an unavoidable added performance penalty. But if > you don't want them part of the build then I guess that penalty becomes > moot.) The very fact that we have -w causes problems, because it forks the language. e.g. anyone that doesn't compile a library with -wi or -w and then releases it with dub can cause problems when someone else uses that project and then _does_ compile with -w, because suddenly, those warnings become errors. And even if we only had -wi and not -w, the fact that the warnings are part of the compiler tends to create a culture where folks expect you to have them as part of your build and "fix" them all. So, while they _are_ a choice, IMHO, it's still a problem that they're part of the compiler, and IMHO, they cause more harm than good. > >> That is purely playing around with word semantics. Deprecations in DMD > >> are a non-fatal message about something that might need fixed sooner or > >> later. That is what a warning is. Implementation details do nothing to > >> change that. > > > > Deprecations are fundamentally different from compiler warnings. In the > > case of a deprecation, your code _will_ break if you don't change it > > once the deprecation period ends, whereas a compiler warning is just > > telling you about something that the compiler thinks might be wrong > > wiith your code. > If not fixing it *will* cause breakage then, by your stance, shouldn't > it be an error (or silence)? I thought you were against the build > process pointing out issues with your code without making them outright > errors? > > If you're opposed to a warnings' non-error status because the warning > *might* indicate a problem, then *certainly* you'd also be opposed to > non-error status for something that *will* be a problem, right? Do you > *really* consider "maybe a problem" more serious than "definitely a > problem"? > > But you're splitting hairs anyway. Either way, you have things that > likely[1] should be improved (or at least looked into), but don't > immediately require action. Fundamentally, same effing thing. > > [1] Yes, the strength of this "likely" varies from warning to warning. > But it does so even aside from deprecations. I don't want the compiler to ever be telling me something that isn't guaranteed to be a problem. Period. I am sick and tired of compilers spitting out junk that's wrong that has to be "fixed" to shut it up. Deprecations are an entirely different beast, because they're telling you about something that you definitely must fix, but they're not errors, because if they were, then deprecating anything would break code immediately, which would mean that we could never deprecate anything, because it would break code, and people would scream. By having it just print a message and allowing folks to either fix their code immediately or put it off, we avoid that immediate breakage. But eventually, they're going to have to fix their code or incur the breakage, which is in stark contrast to warnings, which could be useful information, or they could be utterly and completely wrong - but either way, because they get spit out as part of the build, you're forced to "fix" them. Anyway, as I said before, we're clearly not going to agree here. And we seem to just be getting less civil about the whole thing. I absolutely detest warnings, think that they have no business in compilers, and want them in a separate tool designed to help the programmer find bugs in their program and not be anywhere near the build process, whereas you like warnings, think that they're helpful more often than not, and want them to be part of the compiler. We have pretty much opposite positions on the matter and at best are going to agree to disagree. I don't think that discussing it further is really going to help anyone. - Jonathan M Davis
Re: `shared`...
On Mon, Oct 1, 2018 at 5:00 PM Timon Gehr via Digitalmars-d wrote: > > On 02.10.2018 01:09, Manu wrote: > > Your entire example depends on escaping references. I think you missed > > the point? > > There was no 'scope' in the OP, and no, that is not sufficient either, > because scope is not transitive but shared is. Surely `scope` must be transitive? How could it work otherwise?
Re: Warn on unused imports?
On 10/01/2018 04:58 PM, Jonathan M Davis wrote: On Monday, October 1, 2018 2:44:32 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote: Nobody said anything about making them part of the build process. We're talking about them being included in the compiler, not about them being in the build process. Please don't move the goalposts. dmd -w and dmd -wi build your program. Printing warnings is part of the build process. dmd or dmd -w -o- Just like external tools, they're NOT part of the build process unless you CHOOSE to make them part of your build process. (Though, with external tools, there's an unavoidable added performance penalty. But if you don't want them part of the build then I guess that penalty becomes moot.) That is purely playing around with word semantics. Deprecations in DMD are a non-fatal message about something that might need fixed sooner or later. That is what a warning is. Implementation details do nothing to change that. Deprecations are fundamentally different from compiler warnings. In the case of a deprecation, your code _will_ break if you don't change it once the deprecation period ends, whereas a compiler warning is just telling you about something that the compiler thinks might be wrong wiith your code. If not fixing it *will* cause breakage then, by your stance, shouldn't it be an error (or silence)? I thought you were against the build process pointing out issues with your code without making them outright errors? If you're opposed to a warnings' non-error status because the warning *might* indicate a problem, then *certainly* you'd also be opposed to non-error status for something that *will* be a problem, right? Do you *really* consider "maybe a problem" more serious than "definitely a problem"? But you're splitting hairs anyway. Either way, you have things that likely[1] should be improved (or at least looked into), but don't immediately require action. Fundamentally, same effing thing. [1] Yes, the strength of this "likely" varies from warning to warning. But it does so even aside from deprecations.
Wrong module initialization order when building with Dub on Windows?
Ran into this today, don't have time to dig in now but maybe someone ran into this too. Steps to reproduce: - git clone https://github.com/CyberShadow/ae - cd ae/demo/inputtiming - (download/unpack https://www.libsdl.org/release/SDL2-2.0.8-win32-x86.zip or https://www.libsdl.org/release/SDL2-2.0.8-win32-x64.zip to current directory) - dub On Windows, I get a range violation (in ae.sys.log) which indicates that Runtime.args has length 0, which should never happen. This doesn't happen if I build as usual with rdmd, or on Linux (either rdmd or Dub).
Re: `shared`...
On 10/1/2018 4:56 PM, Timon Gehr wrote: There was no 'scope' in the OP, and no, that is not sufficient either, because scope is not transitive but shared is. Oops, I missed that point. Glad you noticed it.
Re: Yet another binding generator (WIP)
On Monday, 1 October 2018 at 15:35:30 UTC, Stefan Koch wrote: On Monday, 1 October 2018 at 13:51:10 UTC, evilrat wrote: Hi, Early access program is now live! Limited offer! Preorder until 12.31.2017 BC and you will receive* unique pet - "Cute Space Hamster"! !! *(Limited quantity in stock) [...] How does it compare to dstep? To be honest I don't know. Also dstep is written in D and using only 'stable' clang C API, right? This tool is based on full 'unstable' C++ API, so in theory it is possible to do broader range of features, such as template substitution for wrapper generating (or just writting .cpp file for compiler to generate actual code). If you asking about actual C/C++ support I have no idea, also dstep is probably can do Objective-C as well (but not this tool), and on average at this moment dstep probably has better C support. Recently there is also "dpp" showed up, it also seems to do same C API approach as dstep, probably has little-to-none C++ support, might be wrong though. Oh wait, no Windows? nice... But if you only ever do linux stuff and C only then it probably even better choice. There is also Calypso (which I assume won't work on Windows as well), that probably should just work with anything you throw in. But this approach has one small downside - no autocompletion and syntax checking.
Re: Yet another binding generator (WIP)
On Monday, 1 October 2018 at 15:39:42 UTC, Jonathan Marler wrote: On Monday, 1 October 2018 at 13:51:10 UTC, evilrat wrote: Hi, Early access program is now live! Limited offer! Preorder until 12.31.2017 BC and you will receive* unique pet - "Cute Space Hamster"! !! *(Limited quantity in stock) [...] Based on clang? I approve. I'll have to try it out sometime. To be precise it is based on clang libtooling API, and not the clang itself, it does not implements or extends the compiler, but uses its reach API's for handle stuff. Sorry for a poor misleading wording.
Re: `shared`...
On 10/1/18 7:09 PM, Manu wrote:
On Mon, Oct 1, 2018 at 8:55 AM Timon Gehr via Digitalmars-d
wrote:
On 01.10.2018 04:29, Manu wrote:
struct Bob
{
void setThing() shared;
}
As I understand, `shared` attribution intends to guarantee that I dun
synchronisation internally.
This method is declared shared, so if I have shared instances, I can
call it... because it must handle thread-safety internally.
void f(ref shared Bob a, ref Bob b)
{
a.setThing(); // I have a shared object, can call shared method
b.setThing(); // ERROR
}
This is the bit of the design that doesn't make sense to me...
The method is shared, which suggests that it must handle
thread-safety. My instance `b` is NOT shared, that is, it is
thread-local.
So, I know that there's not a bunch of threads banging on this
object... but the shared method should still work! A method that
handles thread-safety doesn't suddenly not work when it's only
accessed from a single thread.
...
shared on a method does not mean "this function handles thread-safety".
It means "the `this` pointer of this function is not guaranteed to be
thread-local". You can't implicitly create an alias of a reference that
is supposed to be thread-local such that the resulting reference can be
freely shared among threads.
I don't understand. That's the point of `scope`... is that it won't
escape the reference. 'freely shared' is the antithesis of `scope`.
I feel like I don't understand the design...
mutable -> shared should work the same as mutable -> const... because
surely that's safe?
No. The main point of shared (and the main thing you need to understand)
is that it guarantees that if something is _not_ `shared` is is not
shared among threads. Your analogy is not correct, going from
thread-local to shared is like going from mutable to immutable.
We're talking about `mutable` -> `shared scope`. That's like going
from mutable to const.
`shared scope` doesn't say "I can share this", what it says is "this
may be shared, but *I won't share it*", and that's the key.
By passing a thread-local as `shared scope`, the receiver accepts that
the argument _may_ be shared (it's not in this case), but it will not
become shared in the call. That's the point of scope, no?
If the suggested typing rule was implemented, we would have the
following way to break the type system, allowing arbitrary aliasing
between mutable and shared references, completely defeating `shared`:
class C{ /*...*/ }
shared(C) sharedGlobal;
struct Bob{
C unshared;
void setThing() shared{
sharedGlobal=unshared;
}
}
void main(){
C c = new C(); // unshared!
Bob(c).setThing();
shared(D) d = sharedGlobal; // shared!
assert(c !is d); // would fail (currently does not even compile)
// sendToOtherThread(d);
// c.someMethod(); // (potential) race condition on unshared data
}
Your entire example depends on escaping references. I think you missed
the point?
The problem with mutable wildcards is that you can assign them.
This exposes the problem in your design. The reason const works is
because you can't mutate it. Shared is not the same.
simple example:
void foo(scope shared int *a, scope shared int *b)
{
a = b;
}
If I can bind a to a local mutable int pointer, and b as a pointer to
global shared int, the assignment is now considered OK (types and scopes
are the same), but now my local points at a shared int without the
shared adornments.
The common wildcard you need between shared and mutable is *unique*.
That is, even though it's typed as shared or unshared, the compiler has
guaranteed there is no other reference to that data. In that case, you
can move data from one place to another without compromising the system
(as you assign from one unique pointer to another, the original must
have to be nullified, otherwise the wildcard still would not work, and
the unique property would cease to be accurate).
IMO, the correct way to deal with shared would be to make it 100%
unusable. Not readable, or writable. And then you have to cast away
shared to make it work (and hopefully performing the correct locking to
make sure your changes are defined). I don't think there's a magic
bullet that can fix this.
-Steve
Re: `shared`...
On 02.10.2018 01:09, Manu wrote: Your entire example depends on escaping references. I think you missed the point? There was no 'scope' in the OP, and no, that is not sufficient either, because scope is not transitive but shared is.
Re: `shared`...
On 10/1/18 7:56 PM, Steven Schveighoffer wrote:
On 10/1/18 7:09 PM, Manu wrote:
Your entire example depends on escaping references. I think you missed
the point?
The problem with mutable wildcards is that you can assign them.
This exposes the problem in your design. The reason const works is
because you can't mutate it. Shared is not the same.
simple example:
void foo(scope shared int *a, scope shared int *b)
{
a = b;
}
Haha, of course, this has no effect!
In order for it to show the problem, a has to be ref'd.
-Steve
Re: How to implement D to HTML pages ?
On Mon, 01 Oct 2018 19:29:56 +, Aurélien Plazzotta wrote: On Mon, 01 Oct 2018 19:29:56 +, Aurélien Plazzotta wrote: > Hello guys, > > I would like to implement a forum and a blog within my website > (currently including only HTML, CSS and JS, written without CMS), using > D and SQL but I really don't know how to proceed. How can I integrate D > into HTML pages? Are there any kind of include's commands like PHP ? > > Also, do I have to use vibe.d ? Or is it optional? I admit I didn't read > the book yet (D Web Development), but only "Programming in D", which > doesn't deal much with website workflow. If you're most comfortable with PHP you may want to look at Adam Ruppe's arsd[0]; the readme has an overview of web-related and database-related modules. vibe.d has more of a node.js feel. There's also DiamondMVC[1], which reminds me of ASP.NET (I'm not 100% sure whether that's intentional, and I haven't tried Diamond) and includes an ORM. > Finally, what database system do you recommand to interact with for > data-oriented website purpose? Perhaps, there are some standard or > tierce-party librairies or ORM for PostgreSQL or SQLite ? > > Thanks for all the light anyone will be willing to spread :) There are low-level bindings for MySQL/MariaDB, Postgres, SqLite, and some people have made higher-level libraries and ORMs[2]. You may want to browse a bit and see what you like. I believe the Diamond ORM can be used without the rest of the framework, and the hunt-entity ORM is actively developed. [0]: Repo: https://github.com/adamdruppe/arsd Docs: https://arsd-official.dpldocs.info/index.html (note that not everything is documented) [1]: https://github.com/DiamondMVC/Diamond [2]: http://code.dlang.org/?sort=updated=20=library.database
Re: `shared`...
On Mon, Oct 1, 2018 at 11:45 AM deadalnix via Digitalmars-d
wrote:
>
> On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:
> > I feel like I don't understand the design...
> > mutable -> shared should work the same as mutable -> const...
> > because
> > surely that's safe?
> >
>
> Nope. Consider.
>
> struct A {
> A* a;
> }
>
> void foo(shared A* a) {
> a.a = new shared(A))();
> }
>
> Now you have effectively made a.a accessible as a mutable when it
> is shared.
I think you mean `scope shared A* a`, but that's fine.
This is okay; the new 'A' is not actually shared, so the demotion to
thread-local on return is actually correct.
I think I can imagine constructions like this that demonstrate the
issue you're trying to suggest.
Is there a tighter ruleset that can prevent the sort of escape you're
trying to demonstrate? We need to find the right rules...
[Issue 17276] BaseClassesTuple fails on extern C++ classes that implement an interface without a base class
https://issues.dlang.org/show_bug.cgi?id=17276 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/0648b8706f3f23996ea1c4c6d561b3efb3ca1e81 Fix issue 17276 added additional case for objects that do not have as root class Object. https://github.com/dlang/phobos/commit/da299506766d39910e01d130aad783f5e76ec10b Merge pull request #6724 from aermicioi/master Fix issue 17276 added additional case for objects that do not have as root class Object. merged-on-behalf-of: Nathan Sashihara --
[Issue 17276] BaseClassesTuple fails on extern C++ classes that implement an interface without a base class
https://issues.dlang.org/show_bug.cgi?id=17276 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19282] hashOf segfaults for non-null C++ objects
https://issues.dlang.org/show_bug.cgi?id=19282 Nathan S. changed: What|Removed |Added Summary|hashOf segfaults for|hashOf segfaults for |non-null C++ objects that |non-null C++ objects |don't inherit from | |object.Object | --
Re: Use nested functions as callbacks with Windows API functions?
On Monday, 1 October 2018 at 21:03:24 UTC, Boris-Barboris wrote:
On Monday, 1 October 2018 at 20:27:43 UTC, spikespaz wrote:
I was hoping I could use something more akin to JavaScript's
syntax: (void* hWnd, long) => {}.
I tried this but I'm getting errors with the signature, it
says the function is a delegate and apparently Windows API
can't accept a delegate.
You can make it a non-delegate by passing a pointer to hWndList
in lParams as it was supposed to by WinApi devs, instead of
zero, and not implicitly capturing stack pointer by referencing
hWndList directly from the body.
https://run.dlang.io/is/t4k4Nc
The problem with the code you have is that the callback needs to
be extern (Windows). I don't know how to do that with a "lambda".
===
import core.sys.windows.windows: EnumWindows;
import std.stdio: writeln;
void main() {
void*[] hWndList;
EnumWindows((void* hWnd, void* lParam) nothrow {
*(cast(void*[] *) lParam) ~= hWnd;
return true;
}, );
writeln(hWndList);
}
===
source\cb.d(7): Error: function
core.sys.windows.winuser.EnumWindows(extern (Windows) int
function(void*, long) nothrow, long) is not callable using
argument types (bool function(void* hWnd, void* lParam) pure
nothrow @system, void*[]*)
source\cb.d(7):cannot pass argument __lambda1 of type
bool function(void* hWnd, void* lParam) pure
nothrow @system to parameter extern (Windows) int function(void*,
long) nothrow
Re: `shared`...
On Mon, Oct 1, 2018 at 8:55 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 01.10.2018 04:29, Manu wrote:
> > struct Bob
> > {
> >void setThing() shared;
> > }
> >
> > As I understand, `shared` attribution intends to guarantee that I dun
> > synchronisation internally.
> > This method is declared shared, so if I have shared instances, I can
> > call it... because it must handle thread-safety internally.
> >
> > void f(ref shared Bob a, ref Bob b)
> > {
> >a.setThing(); // I have a shared object, can call shared method
> >
> >b.setThing(); // ERROR
> > }
> >
> > This is the bit of the design that doesn't make sense to me...
> > The method is shared, which suggests that it must handle
> > thread-safety. My instance `b` is NOT shared, that is, it is
> > thread-local.
> > So, I know that there's not a bunch of threads banging on this
> > object... but the shared method should still work! A method that
> > handles thread-safety doesn't suddenly not work when it's only
> > accessed from a single thread.
> > ...
>
> shared on a method does not mean "this function handles thread-safety".
> It means "the `this` pointer of this function is not guaranteed to be
> thread-local". You can't implicitly create an alias of a reference that
> is supposed to be thread-local such that the resulting reference can be
> freely shared among threads.
I don't understand. That's the point of `scope`... is that it won't
escape the reference. 'freely shared' is the antithesis of `scope`.
> > I feel like I don't understand the design...
> > mutable -> shared should work the same as mutable -> const... because
> > surely that's safe?
>
> No. The main point of shared (and the main thing you need to understand)
> is that it guarantees that if something is _not_ `shared` is is not
> shared among threads. Your analogy is not correct, going from
> thread-local to shared is like going from mutable to immutable.
We're talking about `mutable` -> `shared scope`. That's like going
from mutable to const.
`shared scope` doesn't say "I can share this", what it says is "this
may be shared, but *I won't share it*", and that's the key.
By passing a thread-local as `shared scope`, the receiver accepts that
the argument _may_ be shared (it's not in this case), but it will not
become shared in the call. That's the point of scope, no?
> If the suggested typing rule was implemented, we would have the
> following way to break the type system, allowing arbitrary aliasing
> between mutable and shared references, completely defeating `shared`:
>
> class C{ /*...*/ }
>
> shared(C) sharedGlobal;
> struct Bob{
> C unshared;
> void setThing() shared{
> sharedGlobal=unshared;
> }
> }
>
> void main(){
> C c = new C(); // unshared!
> Bob(c).setThing();
> shared(D) d = sharedGlobal; // shared!
> assert(c !is d); // would fail (currently does not even compile)
> // sendToOtherThread(d);
> // c.someMethod(); // (potential) race condition on unshared data
> }
Your entire example depends on escaping references. I think you missed
the point?
Re: Use nested functions as callbacks with Windows API functions?
On Monday, 1 October 2018 at 21:03:24 UTC, Boris-Barboris wrote:
On Monday, 1 October 2018 at 20:27:43 UTC, spikespaz wrote:
I was hoping I could use something more akin to JavaScript's
syntax: (void* hWnd, long) => {}.
I tried this but I'm getting errors with the signature, it
says the function is a delegate and apparently Windows API
can't accept a delegate.
You can make it a non-delegate by passing a pointer to hWndList
in lParams as it was supposed to by WinApi devs, instead of
zero, and not implicitly capturing stack pointer by referencing
hWndList directly from the body.
https://run.dlang.io/is/t4k4Nc
I don't know how to do this. I'm not the best with pointers, I'm
still learning D and I'm unfamiliar with functional programming.
==
import core.sys.windows.windows: EnumWindows;
import std.stdio: writeln;
extern (Windows) int callback(void* hWnd, long hWndList) nothrow {
hWndList ~= hWnd;
return true;
}
void main() {
void*[] hWndList;
EnumWindows(, );
writeln(hWndList);
}
==
Clearly I can't use to pass the reference, how would I
access the variable by the memory address inside the callback?
Re: `shared`...
On Mon, Oct 1, 2018 at 3:51 AM Jonathan M Davis via Digitalmars-d wrote: > > pure is not sufficient regardless of what happens with threads, [..] #truefacts > Certainly, it's way, way simply just to use scope and force > the programmer to continue to cast in those cases that the compiler can't > prove correctness just like we have to do now. This words.
[Issue 15374] [internal] Nothing should import ddmd.mars
https://issues.dlang.org/show_bug.cgi?id=15374 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/b8655054d09c4a451b2aef4fc68118a6883f7f89 fix Issue 15374 - Move genCmain into Compiler struct. https://github.com/dlang/dmd/commit/11573d214097d3fcb7eeb388eba0f6ddf8335694 Merge pull request #7534 from ibuclaw/issue15374 fix Issue 15374 - Move genCmain into Compiler struct. merged-on-behalf-of: Iain Buclaw --
[Issue 15374] [internal] Nothing should import ddmd.mars
https://issues.dlang.org/show_bug.cgi?id=15374 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19282] hashOf segfaults for non-null C++ objects that don't inherit from object.Object
https://issues.dlang.org/show_bug.cgi?id=19282 Nathan S. changed: What|Removed |Added Summary|hashOf segfaults for|hashOf segfaults for |non-null C++ objects and|non-null C++ objects that |interfaces |don't inherit from ||object.Object --
[Issue 19282] hashOf segfaults for non-null C++ objects and interfaces
https://issues.dlang.org/show_bug.cgi?id=19282 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2318 --
[Issue 19282] New: hashOf segfaults for non-null C++ objects and interfaces
https://issues.dlang.org/show_bug.cgi?id=19282
Issue ID: 19282
Summary: hashOf segfaults for non-null C++ objects and
interfaces
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: n8sh.second...@hotmail.com
The following code crashes:
---
extern(C++)
{
class C {}
}
void main()
{
C c = new C();
size_t h = .hashOf(c);
}
---
--
Re: Use nested functions as callbacks with Windows API functions?
On Monday, 1 October 2018 at 20:27:43 UTC, spikespaz wrote:
I was hoping I could use something more akin to JavaScript's
syntax: (void* hWnd, long) => {}.
I tried this but I'm getting errors with the signature, it says
the function is a delegate and apparently Windows API can't
accept a delegate.
You can make it a non-delegate by passing a pointer to hWndList
in lParams as it was supposed to by WinApi devs, instead of zero,
and not implicitly capturing stack pointer by referencing
hWndList directly from the body.
https://run.dlang.io/is/t4k4Nc
Re: Warn on unused imports?
On Monday, October 1, 2018 2:44:32 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 10/01/2018 03:32 PM, Jonathan M Davis wrote: > > On Monday, October 1, 2018 12:36:49 PM MDT Nick Sabalausky (Abscissa) > > via > > > > Digitalmars-d wrote: > >> Yes, that's exactly what warnings are for. If people need to treat them > >> differently than that (ex: C++), that's a failing of the language. > > > > As soon as warnings are part of the build process, > > Nobody said anything about making them part of the build process. We're > talking about them being included in the compiler, not about them being > in the build process. Please don't move the goalposts. dmd -w and dmd -wi build your program. Printing warnings is part of the build process. > >> Plus, other warnings (like deprecations, for example) which have proven > >> extremely helpful would have been a major problem had they been > >> outright > >> errors. > > > > Technically, deprecations aren't warnings, and dmd treats them quite > > differently. They aren't affected by either -wi or -w, and from a > > semantic perspective, they're completely different. > > That is purely playing around with word semantics. Deprecations in DMD > are a non-fatal message about something that might need fixed sooner or > later. That is what a warning is. Implementation details do nothing to > change that. Deprecations are fundamentally different from compiler warnings. In the case of a deprecation, your code _will_ break if you don't change it once the deprecation period ends, whereas a compiler warning is just telling you about something that the compiler thinks might be wrong wiith your code. In some cases, it's right; in some cases, it's wrong. In the case of deprecations, it's always right, and you always have to change your code. You just don't have to change it immediately. - Jonathan M Davis
Re: Warn on unused imports?
On 10/01/2018 03:32 PM, Jonathan M Davis wrote: On Monday, October 1, 2018 12:36:49 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote: Yes, that's exactly what warnings are for. If people need to treat them differently than that (ex: C++), that's a failing of the language. As soon as warnings are part of the build process, Nobody said anything about making them part of the build process. We're talking about them being included in the compiler, not about them being in the build process. Please don't move the goalposts. Plus, other warnings (like deprecations, for example) which have proven extremely helpful would have been a major problem had they been outright errors. Technically, deprecations aren't warnings, and dmd treats them quite differently. They aren't affected by either -wi or -w, and from a semantic perspective, they're completely different. That is purely playing around with word semantics. Deprecations in DMD are a non-fatal message about something that might need fixed sooner or later. That is what a warning is. Implementation details do nothing to change that.
Use nested functions as callbacks with Windows API functions?
I have the following code, this works.
import core.sys.windows.windows: EnumWindows;
import std.stdio: writeln;
void*[] hWndList;
extern (Windows) int callback(void* hWnd, long /* lParams */ )
nothrow {
hWndList ~= hWnd;
return true;
}
void main() {
EnumWindows(, 0);
writeln(hWndList);
}
I was hoping I could use something more akin to JavaScript's
syntax: (void* hWnd, long) => {}.
I tried this but I'm getting errors with the signature, it says
the function is a delegate and apparently Windows API can't
accept a delegate.
import core.sys.windows.windows: EnumWindows;
import std.stdio: writeln;
void main() {
void*[] hWndList;
EnumWindows((void* hWnd, long /* lParams */ ) nothrow {
hWndList ~= hWnd; return true;
}, 0);
writeln(hWndList);
}
I'm not going to even paste the compiler error because I am very
clearly going about this the wrong way.
Of course there is nothing wrong with defining each callback as a
separate function, but then comes the issue of naming them. I
also don't like the way it makes my code look.
Thanks.
Re: Prevent opening binary/other garbage files
On Monday, 1 October 2018 at 15:21:24 UTC, helxi wrote: I tried out https://dlang.org/library/std/utf/validate.html before manually checking for encoding myself so I ended up with the code below. I was fairly surprised that "*.o" (object) files are UTF encoded! Is it normal? Yes. Any random collection of bytes <= 127 is valid utf-8. Lines will read until it sees a byte 10, and cut off from there. Quite a few file formats have a 10 early on to detect text/binary transmission corruption, but even if they don't, it is a fairly common byte to see before too long and that cuts off your scan for later bytes. You really are better off looking for those <32 bytes like I described earlier - a .o file will likely have some 1's and 3's early on which that will quickly detect, but those will also pass the validate test.
Re: Warn on unused imports?
On Monday, October 1, 2018 12:36:49 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 09/25/2018 09:13 PM, Jonathan M Davis wrote: > > IMHO, the only time that anything along the lines of a warning > > makes sense is when the programmer is proactively running a tool to > > specifically ask to be informed of a potential type of problem where > > they > > will then go look at each of them individually and decide whether what > > the tool is telling them is valid or not - at which point, some of what > > the tool says will be followed, and some if it will be ignored. > > Yes, that's exactly what warnings are for. If people need to treat them > differently than that (ex: C++), that's a failing of the language. As soon as warnings are part of the build process, that's not how they're treated. I have _never_ seen them treated that way. That's not to say that no one ever has done it, but I have consistently seen that what happens is that either they're either all "fixed," or they're left on, generating a wall of text. And I've seen it with more than just C++ or D (though in D, we have very few warnings, and the typical approach is to either not turn them on or to use -w, which means that you can get different semantics depending on how the code was compiled, so we end up with a different set of problems). But I honestly don't see how you can expect any project to _not_ end up with most warnings either being "fixed" or ignored when the compiler throws a whole wall of text at you about what _might_ be wrong with your program during the normal build process. If you don't "fix" them all, then you always have a wall of text, and it makes it very difficult to find the ones that matter. And if you do "fix" them, then you're making all kinds of unnecessary (and potentially wrong) changes to your code just to shut the compiler up. Sure, when a project first starts, there may not be very many warnings, but they're quickly going to spiral out of control as it increases in size unless you "fix" them all as you go along or the compiler is actually smart enough to only tell you when your code is actually wrong. And if the compiler is guaranteed to be right about it, then it should be an error, not a warning. IMHO, if warnings are part of the normal build process, then there's a serious problem with them. > Plus, other warnings (like deprecations, for example) which have proven > extremely helpful would have been a major problem had they been outright > errors. Technically, deprecations aren't warnings, and dmd treats them quite differently. They aren't affected by either -wi or -w, and from a semantic perspective, they're completely different. Warnings are something where the compiler is telling you about something that _might_ be wrong with your code. Deprecations are telling you something that _will_ be wrong with your code (but isn't yet), so you're going to have to fix it before the deprecation period expires, but you don't have to immediately. So, while the the help output from the compiler does unfortunately call deprecation messages "deprecation warnings" instead of deprecation messages, "deprecation warnings" and regular "warnings" are actually completely different, both in principle and in terms of how the compiler treats them. They're very much their own thing, and they don't have the same problems that regular warnings do. > And realistically, I, and likely most of us, frequently wouldn't have > bothered if they had been in a separate a tool, certainly not before > every commit. (Right, as if most C programmers actually *use* lint > regularly?) It's the same "built-in unittests and docs" effect. That's a valid point. A separate tool is less likely to be used, but honestly, from everything I've seen of warnings and how they've been used, I think that they do far more harm than good in general if they're just a compiler flag. And since I really think that the correct way to handle them is for a responsible programmer to proactively run a tool to figure out what problems might exist in his code anyway (just like he might choose to run a fuzzer on it to find problems), I don't think that it's ultimately a problem. Though I think that it's pretty clear that we're going to have to agree to disagree on that. - Jonathan M Davis
How to implement D to HTML pages ?
Hello guys, I would like to implement a forum and a blog within my website (currently including only HTML, CSS and JS, written without CMS), using D and SQL but I really don't know how to proceed. How can I integrate D into HTML pages? Are there any kind of include's commands like PHP ? Also, do I have to use vibe.d ? Or is it optional? I admit I didn't read the book yet (D Web Development), but only "Programming in D", which doesn't deal much with website workflow. Finally, what database system do you recommand to interact with for data-oriented website purpose? Perhaps, there are some standard or tierce-party librairies or ORM for PostgreSQL or SQLite ? Thanks for all the light anyone will be willing to spread :)
Re: `shared`...
On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:
I feel like I don't understand the design...
mutable -> shared should work the same as mutable -> const...
because
surely that's safe?
Nope. Consider.
struct A {
A* a;
}
void foo(shared A* a) {
a.a = new shared(A))();
}
Now you have effectively made a.a accessible as a mutable when it
is shared.
Re: Warn on unused imports?
On 09/25/2018 09:13 PM, Jonathan M Davis wrote: IMHO, the only time that anything along the lines of a warning makes sense is when the programmer is proactively running a tool to specifically ask to be informed of a potential type of problem where they will then go look at each of them individually and decide whether what the tool is telling them is valid or not - at which point, some of what the tool says will be followed, and some if it will be ignored. Yes, that's exactly what warnings are for. If people need to treat them differently than that (ex: C++), that's a failing of the language. > If it is, then inevitably > what happens is that either all of the warnings get "fixed" (at > which point, they might as well have all been errors), They only "might as well have all been errors" if the programmer always fixes them all before running any of his intermediary builds. It's one matter if it's right before a release or often a VCS commit, but plenty of very helpful messages can become a major pain while *developing* an individual commit. > or they all get > ignored, meaning that you get a huge wall of them, and > they're completely useless. I'd probably have a tendency to fall into one of those two traps too if I were using C++. Outside of C++, I'm not in either of those categories. So, so much for that false dichotomy being "inevitable". As such, I really have nothing good to say about having any kind of warnings being built into the compiler. Whether or not they're built into the compiler is completely orthogonal to the acceptable use-case you described above. As I understand it, on the whole, Walter agrees with me and that he only added them in to dmd, because he was essentially bullied into it, And I'm very glad he was, because many of those warnings have saved my ass on more than one occasion, but would've been completely non-existent it if were completely up to Walter. Plus, other warnings (like deprecations, for example) which have proven extremely helpful would have been a major problem had they been outright errors. And realistically, I, and likely most of us, frequently wouldn't have bothered if they had been in a separate a tool, certainly not before every commit. (Right, as if most C programmers actually *use* lint regularly?) It's the same "built-in unittests and docs" effect.
[Issue 15956] Incorrect value inside enum using simd vectors, weird tym errors, and weird if(true) {} partial solution.
https://issues.dlang.org/show_bug.cgi?id=15956 --- Comment #2 from jo...@mail.de --- As far as I can tell this problem stems from the fact, that some of the types in core.simd are not working AT ALL. Consider this simple example: double4 f; f[0] = 1.0; f[1] = 2.0; f[2] = 3.0; f[3] = 4.0; writeln(f); This outputs: [1, 2, 0, 6.95325e-310] I wonder has noone ever tried to use this type in any program or did not notice this obviously completely wrong result? Edit: Does work correctly with gdc. --
[Issue 15956] Incorrect value inside enum using simd vectors, weird tym errors, and weird if(true) {} partial solution.
https://issues.dlang.org/show_bug.cgi?id=15956 --- Comment #1 from jo...@mail.de --- As far as I can tell this problem stems from the fact, that some of the types in core.simd are not working AT ALL. Consider this simple example: double4 f; f[0] = 1.0; f[1] = 2.0; f[2] = 3.0; f[3] = 4.0; writeln(f); This outputs: [1, 2, 0, 6.95325e-310] I wonder has noone ever tried to use this type in any program or did not notice this obviously completely wrong result? --
[Issue 15956] Incorrect value inside enum using simd vectors, weird tym errors, and weird if(true) {} partial solution.
https://issues.dlang.org/show_bug.cgi?id=15956 jo...@mail.de changed: What|Removed |Added CC||jo...@mail.de Severity|major |critical --
Re: `shared`...
On 01.10.2018 04:29, Manu wrote:
struct Bob
{
void setThing() shared;
}
As I understand, `shared` attribution intends to guarantee that I dun
synchronisation internally.
This method is declared shared, so if I have shared instances, I can
call it... because it must handle thread-safety internally.
void f(ref shared Bob a, ref Bob b)
{
a.setThing(); // I have a shared object, can call shared method
b.setThing(); // ERROR
}
This is the bit of the design that doesn't make sense to me...
The method is shared, which suggests that it must handle
thread-safety. My instance `b` is NOT shared, that is, it is
thread-local.
So, I know that there's not a bunch of threads banging on this
object... but the shared method should still work! A method that
handles thread-safety doesn't suddenly not work when it's only
accessed from a single thread.
...
shared on a method does not mean "this function handles thread-safety".
It means "the `this` pointer of this function is not guaranteed to be
thread-local". You can't implicitly create an alias of a reference that
is supposed to be thread-local such that the resulting reference can be
freely shared among threads.
I feel like I don't understand the design...
mutable -> shared should work the same as mutable -> const... because
surely that's safe?
No. The main point of shared (and the main thing you need to understand)
is that it guarantees that if something is _not_ `shared` is is not
shared among threads. Your analogy is not correct, going from
thread-local to shared is like going from mutable to immutable.
If the suggested typing rule was implemented, we would have the
following way to break the type system, allowing arbitrary aliasing
between mutable and shared references, completely defeating `shared`:
class C{ /*...*/ }
shared(C) sharedGlobal;
struct Bob{
C unshared;
void setThing() shared{
sharedGlobal=unshared;
}
}
void main(){
C c = new C(); // unshared!
Bob(c).setThing();
shared(D) d = sharedGlobal; // shared!
assert(c !is d); // would fail (currently does not even compile)
// sendToOtherThread(d);
// c.someMethod(); // (potential) race condition on unshared data
}
[Issue 18456] crt_constructor/crt_destructor segfaults if -lib
https://issues.dlang.org/show_bug.cgi?id=18456 --- Comment #2 from ponce --- Can be workarounded by using LDC. Can be workarounded by compiling in one bunch with --combined of course. --
[Issue 18456] crt_constructor/crt_destructor segfaults if -lib
https://issues.dlang.org/show_bug.cgi?id=18456
ponce changed:
What|Removed |Added
CC||alil...@gmail.com
--- Comment #1 from ponce ---
Same here, we also hit this:
main.d --
extern(C) pragma(crt_destructor) void deactivateDRuntime()
{
}
--
dmd -lib main.d
--
[Issue 3537] Casting objects with alias this takes the subtype
https://issues.dlang.org/show_bug.cgi?id=3537 RazvanN changed: What|Removed |Added Status|REOPENED|RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |DUPLICATE --- Comment #7 from RazvanN --- Marking this one as a duplicate, as there already is a PR referencing 6777 *** This issue has been marked as a duplicate of issue 6777 *** --
[Issue 6777] alias this disables casting for classes
https://issues.dlang.org/show_bug.cgi?id=6777 RazvanN changed: What|Removed |Added CC||tomeks...@gmail.com --- Comment #11 from RazvanN --- *** Issue 3537 has been marked as a duplicate of this issue. *** --
Re: Yet another binding generator (WIP)
On Monday, 1 October 2018 at 13:51:10 UTC, evilrat wrote: Hi, Early access program is now live! Limited offer! Preorder until 12.31.2017 BC and you will receive* unique pet - "Cute Space Hamster"! !! *(Limited quantity in stock) [...] Based on clang? I approve. I'll have to try it out sometime.
Re: Yet another binding generator (WIP)
On Monday, 1 October 2018 at 13:51:10 UTC, evilrat wrote: Hi, Early access program is now live! Limited offer! Preorder until 12.31.2017 BC and you will receive* unique pet - "Cute Space Hamster"! !! *(Limited quantity in stock) [...] How does it compare to dstep?
Re: Prevent opening binary/other garbage files
On Sunday, 30 September 2018 at 03:19:11 UTC, Adam D. Ruppe wrote:
On Saturday, 29 September 2018 at 23:46:26 UTC, helxi wrote:
Thanks. Would you say
https://dlang.org/library/std/encoding/get_bom.html is useful
in this context?
Eh, not really, most text files will not have one.
Hi,
I tried out https://dlang.org/library/std/utf/validate.html
before manually checking for encoding myself so I ended up with
the code below. I was fairly surprised that "*.o" (object) files
are UTF encoded! Is it normal?
import std.stdio : File, lines, stdout;
void panic(in string message, int exitCode = 1) {
import core.stdc.stdlib : exit;
import std.stdio : stderr, writeln;
stderr.writeln(message);
exit(exitCode);
}
void writeFunc(ulong occerenceNumber, ulong lineNumber, in ref
string fileName,
in ref string line, File ofile = stdout) {
import std.stdio : writef;
ofile.writef("%s: L:%s: F:\"%s\":\n%s\n", occerenceNumber,
lineNumber, fileName, line);
}
void treverseDirectories(in string path, in string term)
in {
import std.file : isDir;
if (!isDir(path))
panic("Cannot access directory: " ~ path);
}
do {
import std.file : dirEntries, SpanMode;
ulong occerenceNumber, filesChecked, filesIgnored; // = 0;
File currentFile;
foreach (string fileName; dirEntries(path, SpanMode.breadth)) {
try {
currentFile = File(fileName, "r");
++filesChecked;
foreach (ulong lineNumber, string currentLine;
lines(currentFile)) {
if (lineNumber == 0) {
// check if the file is encoded with
proper UTF
// if Line 0 is not UTF encoded, move
on to the next file
// I hope the compiler unrolls this if
condition
import std.utf : validate;
validate(currentLine);
// throws exception if
the file is not UTF encoded
}
import std.algorithm : canFind;
if (canFind(currentLine, term)) {
writeFunc(++occerenceNumber, lineNumber, fileName,
currentLine);
}
}
}
catch (Exception e) {
filesIgnored++;
}
}
//summarize
import std.stdio : writefln;
writefln("Total match found:\t%s\nTotal files
checked:\t%s\nTotal files ignored:\t%s\n",
occerenceNumber, filesChecked, filesIgnored);
}
void main(string[] args) {
import std.getopt : getopt;
string term, directory;
getopt(args, "term|t", , "directory|d", );
if (!directory) {
// if directory not specified, start working with the current
directory
import std.file : getcwd;
directory = getcwd();
}
if (!term)
panic("Term not specified.");
treverseDirectories(directory, term);
}
/*
Output: https://pastebin.com/PZ8nCaYf
Re: contracts in interfaces: do they work, do I have to do something to enable checking of contracts ?
On Monday, 1 October 2018 at 13:49:53 UTC, Emil wrote:
I am trying my hand at contracts and they work fine in plain
functions and in methods, but I can't make them work in
interfaces.
https://dlang.org/spec/interface.html#interface-contracts
$ dmd --version
DMD64 D Compiler v2.081.1
Copyright (C) 1999-2018 by The D Language Foundation, All
Rights Reserved written by Walter Bright
/
void main()
{
WillBloop test = new WillBloop();
// also tried
// Blooper test = new WillBloop();
// it compiles but the in contract does not seem enforced
test.limited(-1); // this does not croak
auto no_interface = new NoInterface();
no_interface.limited(-10); // this works as expected
}
interface Blooper
{
void limited(int some_other_name)
in
{
assert(some_other_name > 0, "asssert failed in
interface");
}
}
class WillBloop : Blooper
{
void limited(int a_name){
import std.stdio : writeln;
writeln(a_name);
}
}
class NoInterface
{
void limited(int another_name)
in
{
assert(another_name > 0, "assert failed in
NoInterface");
}
do
{
import std.stdio: writeln;
writeln(another_name);
}
}
Yeah... had such problems too, a while ago.
https://forum.dlang.org/thread/sadsceubvapbeezjy...@forum.dlang.org
Seems, that one of the tickets is closed, but the pull request is
not merged. Don't know how matters stand with this, actually.
Re: Yet another binding generator (WIP)
On Monday, 1 October 2018 at 13:59:42 UTC, JN wrote: Are there Windows binaries available somewhere? Try this https://1drv.ms/u/s!AgMDJgyotPu6ljpA5_GwX898gAcg It is x64 debug build without PDB. But from my experience it will not work due to debug C++ runtime being used. At least not without VS 2017 installed.
[Issue 19251] Alias this does not get called on struct qualified type
https://issues.dlang.org/show_bug.cgi?id=19251 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/37605ece47e30869b8dac103ad8f8cc789cd5b8f Fix Issue 19251 - Alias this does not get called on struct qualified type https://github.com/dlang/dmd/commit/94f39988bc40568a7d90dd581f2d05c76e26d11d Merge pull request #8711 from RazvanN7/Issue_19251 Fix Issue 19251 - Alias this does not get called on struct qualified type --
[Issue 19251] Alias this does not get called on struct qualified type
https://issues.dlang.org/show_bug.cgi?id=19251 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Yet another binding generator (WIP)
On Monday, 1 October 2018 at 13:51:10 UTC, evilrat wrote: Give it a try and let me know if you find something that is not on the limitations list, I will add it to the list, and everyone will be happy again! Are there Windows binaries available somewhere?
Yet another binding generator (WIP)
Hi, Early access program is now live! Limited offer! Preorder until 12.31.2017 BC and you will receive* unique pet - "Cute Space Hamster"! !! *(Limited quantity in stock) Ok, enough BS... So here is my personal tool for generating extern(C)/extern(C++) bindings[1]. I know there is several other tools exists, but this one is mine. Currently it is in early pre-pre-pre-alpha stage, and is probably doesn't even work on any somewhat serious codebase. Might not work on Linux, or Mac, or just any non-Windows 10 OS. There is example output in the repo, and the list of current features and known issues. So what it can actually do? Might work to do C conversion without manual editing, but in practice C stuff use a lot of defines as constants, so you will have to find them and write by hand, not convenient, true. Might work with basic C++ headers without much of templates/inlines/defines-as-constants Give it a try and let me know if you find something that is not on the limitations list, I will add it to the list, and everyone will be happy again! p.s. no, it is not belongs to the announce group, as the tool itself is still far away from being truly useful, but it might accelerate your binding making process as well, for example making bulk of code output and then manually adjust some stuff once per month isn't that much effort comparing to doing everything by hand, not even mentioning doing it on per month basis... [1] https://github.com/Superbelko/ohmygentool
Re: Performance of GC.collect() for single block of `byte`s
On 10/1/18 3:21 AM, Rainer Schuetze wrote: On 28/09/2018 14:21, Per Nordlöw wrote: On Monday, 24 September 2018 at 14:31:45 UTC, Steven Schveighoffer wrote: It's not scanning the blocks. But it is scanning the stack. Each time you are increasing the space it must search for a given *target*. It also must *collect* any previous items at the end of the scan. Note that a collection is going to mark every single page and bitset that is contained in the item being collected (which gets increasingly larger). Is this because of the potentially (many) slices referencing this large block? I assume the GC doesn't scan the `byte`-array for pointer-values in this case, but that happens for `void`-arrays and class/pointer-arrays right? Couldn't that scan be optimized by adding a bitset that indicates which pages need to be scanned? Is it common for GC's to treat large objects in this way? A profiler reveals that most of the time is spent in "sweeping" the memory, i.e. looking for allocations no longer referenced. The existing implementation checks every page which causes a linear growth of required CPU resources with used memory. Ouch! I hadn't thought of that. But we aren't checking actual *pages*, right, we are checking bits to see where allocations are present? I also remember that the way the bitsets work, they are always allocated for every 16 bytes, regardless of the block size for that page/pool. I didn't love that feature but maybe it is fixed by now. I would imagine that checking 64 pages at once should be possible by logic-anding the allocated and unmarked bits to check things as quickly as possible. This version https://github.com/rainers/druntime/tree/gc_opt_sweep takes advantage of the known size of allocations to skip unnecessary checks. The last commit also adds support for keeping track of the size of blocks of consecutive free pages. With this your example has more or less constant collection time (note that most of the program time is spent setting the array to zero, though not measured, and that the allocation often triggers a collection, too). Yes, especially when you are increasing the allocation size each time. I also noticed a rather serious bug for huge allocations: https://issues.dlang.org/show_bug.cgi?id=19281 -Steve
contracts in interfaces: do they work, do I have to do something to enable checking of contracts ?
I am trying my hand at contracts and they work fine in plain
functions and in methods, but I can't make them work in
interfaces.
https://dlang.org/spec/interface.html#interface-contracts
$ dmd --version
DMD64 D Compiler v2.081.1
Copyright (C) 1999-2018 by The D Language Foundation, All Rights
Reserved written by Walter Bright
/
void main()
{
WillBloop test = new WillBloop();
// also tried
// Blooper test = new WillBloop();
// it compiles but the in contract does not seem enforced
test.limited(-1); // this does not croak
auto no_interface = new NoInterface();
no_interface.limited(-10); // this works as expected
}
interface Blooper
{
void limited(int some_other_name)
in
{
assert(some_other_name > 0, "asssert failed in
interface");
}
}
class WillBloop : Blooper
{
void limited(int a_name){
import std.stdio : writeln;
writeln(a_name);
}
}
class NoInterface
{
void limited(int another_name)
in
{
assert(another_name > 0, "assert failed in NoInterface");
}
do
{
import std.stdio: writeln;
writeln(another_name);
}
}
Re: automem v0.3.5 - now with more vector (like std::vector, not Physics)!
On Sunday, 30 September 2018 at 19:54:07 UTC, ikod wrote:
On Thursday, 20 September 2018 at 14:57:42 UTC, Atila Neves
wrote:
If you've never heard of automem before, I wrote it to have
C++-style smart pointers in D that I could use in @nogc code:
http://code.dlang.org/packages/automem
Sorry for asking here.
Shouldn't this code work?
import automem;
struct X {
int i;
}
struct Y {
RefCounted!X x; // fails
//X x; // ok
}
void main()
{
Y y1;
Y y2;
y2 = y1;
}
https://run.dlang.io/is/k2qWhm
This really should have been a github issue, but thanks for
posting this anyway. I just fixed it.
Re: Quick C bindings
On Friday, 28 September 2018 at 16:39:14 UTC, Márcio Martins wrote: Hi y'all! If you'd be so kind and help me out here with a few questions/opinions: I would like to generate decent D bindings for https://github.com/libuv/libuv with as little pain as possible. What are you guys using these days to generate bindings? I remember trying Dstep a few years ago, but it didn't work very well for me at the time. What's new in this regard? I've been using the ones in dlang.org but have run into some issues, and would like to include bindings as part of my project, if it's not too painful. What is the state of shared libraries on the various platforms/compilers? I remember they were not supported everywhere and by all compilers, as this been addressed? also this exists: https://github.com/tamediadigital/libuv
Re: printed v0.0.3: a low-level API to generate self-contained PDF/SVG
On Monday, 1 October 2018 at 10:44:53 UTC, Guillaume Piolat wrote: Mmmm you mean dlib has a software renderer? Yes. https://github.com/gecko0307/dlib/blob/master/dlib/image/canvas.d Small and simple, but so far enough for my converter, as it pairs well with DLib's image file i/o.
[Issue 19266] Some source files names are no longer accepted
https://issues.dlang.org/show_bug.cgi?id=19266 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #2 from RazvanN --- Closing as it has been merged in stable --
Re: -O flag ; automatic cast in a bitshift
On Friday, 21 September 2018 at 01:44:33 UTC, Vladimir Panteleev wrote: On Thursday, 20 September 2018 at 11:14:05 UTC, Guillaume FYI, it's undefined in D mainly because the behavior of the actual Intel CPU instruction is undefined in such cases: https://c9x.me/x86/html/file_module_x86_id_285.html "it is undefined for SHL and SHR instructions where the count is greater than or equal to the size (in bits) of the destination operand". Thanks, good to know.
Re: lodash like utility/algorithms library for D
On Monday, 1 October 2018 at 00:51:24 UTC, Paul Backus wrote:
On Sunday, 30 September 2018 at 22:17:05 UTC, aliak wrote:
On Saturday, 29 September 2018 at 19:27:29 UTC, Paul Backus
wrote:
I agree that this is useful, but why not just return a naked
`SumType!(string, JSONError)` in that case? Is there some
additional value added by the `Expect` wrapper that I'm not
seeing?
That's an option as well I guess. But then you'd need to rely
on convention and you couldn't do SumType!(int, int) f(), and
Expect also gives you some more purposeful APIs that makes the
code's intent clear. Plus I'm considering range behavior as
well.
Is being able to write `Expect!(int, int)` actually desirable,
though? It seems to me like being forced to write something
like `SumType!(int, ErrorCode)` to distinguish the two cases
would be a good thing, even if ErrorCode itself is just a
renamed int (e.g., `struct ErrorCode { int code; alias code
this; }`).
Hard to say, I would try to avoid it if possible, but why should
it not be allowed if someone wants it? For now it feels like an
opinionated restriction that I think is better left out of
generic code when possible - at least for now. If it turns out
otherwise I'll change it - this is all still quite experimental
in me head.
Using SumType to denote success and failure would be more of a
convention though and would make for more "huh?" moments for
readability/maintainability, IMO. I like typing intents.
And being able to add an "alias this" in Expect for e.g. might be
nice. Or if I want to add a "make match has exactly two handlers"
so that you have to handle both cases would also be a plus.
I guess you could argue that `return
typeof(return).unexpected(...)` is better than `return
typeof(return)(ErrorCode(...))`, which is what you'd get with
SumType, but they look equally ugly to me. What's really needed
to make that look nice is implicit constructors.
*nods*
Treating an Expect as a range basically turns it into an
Optional, in the sense that it collapses any error information
it contains down to the boolean of empty vs not-empty. In fact,
probably the easiest way to add range behavior to Expect would
be to add a method that returns an Optional containing the
expected value, since Optional already has range behavior.
Good point. Agreed!
Could you also return a union voldermort type then instead of
a SumType?
Raw unions in D are horrifically unsafe, so I wouldn't
recommend it. If you want a voldemort SumType, you can get one
like this:
auto f()
{
struct Result { SumType(T, U) data; alias data this; }
return Result(...);
}
Re: `shared`...
On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:
struct Bob
{
void setThing() shared;
}
As I understand, `shared` attribution intends to guarantee that
I dun
synchronisation internally.
This method is declared shared, so if I have shared instances,
I can
call it... because it must handle thread-safety internally.
void f(ref shared Bob a, ref Bob b)
{
a.setThing(); // I have a shared object, can call shared
method
b.setThing(); // ERROR
}
Instead of making mutable->shared conversion implicit, you use
template this parameters:
struct B
{
void setThing(this T)()
{
static if(is(T == shared(B)))
{
/* do synchronisation */
}
else
{
/* all other cases */
}
}
}
I think that it's great that mutable(T) is not implicitly
convertible to shared(T) as it makes synchronization bugs a lot
more obvious.
Cheers,
RazvanN
Re: Linking with a non-default druntime
On Monday, 1 October 2018 at 08:27:54 UTC, Basile B. wrote: I think so. Apparently it's registered with a string, e.g "manual" and you pass a special druntime option with your program to select. Actually i would be interested to make the interface with assignable handlers since you don't seem to be very hot. Maybe tomorrow i can try. I'm almost sure that this could work but cant be 100% sure. Maybe there'll be issues with privacy and events to assign. Be my guest :) Thanks!
[Issue 19275] std.process: redirecting output in a non-console application fails
https://issues.dlang.org/show_bug.cgi?id=19275 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19275] std.process: redirecting output in a non-console application fails
https://issues.dlang.org/show_bug.cgi?id=19275 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/8f0aeedfc71c5036912c08660af1e77543a51e6a Fix issue 19275 - std.process: redirecting output in a non-console application fails MS runtime up to VS2013 used pseudo handle _NO_CONSOLE_FILENO in that case https://github.com/dlang/phobos/commit/a531a9ca97ca31104a30876ea08cbaa8f778959a Merge pull request #6722 from rainers/issue19275 Fix Issue 19275 - std.process: redirecting output in a non-console application fails merged-on-behalf-of: Nathan Sashihara --
Re: `shared`...
On Monday, October 1, 2018 3:55:41 AM MDT ag0aep6g via Digitalmars-d wrote: > On 10/01/2018 08:47 AM, Nicholas Wilson wrote: > > In order to be safe, a mutable parameter can be implicitly cast to > > shared iff the parameter is also scope (that includes the `this` > > reference`). With an implicit cast in place of the explicit cast under > > the new rules it would fail to compile because the `this` reference is > > not scope. > > I don't see why it would fail to compile. There's no reason why my > `doThing` couldn't be marked as `scope`. It doesn't leak anything. > > `pure` would break the example. I'm not sure if it would ensure safety, > though. Can a `pure` method spawn a new thread (that outlives the method > call)? pure is not sufficient regardless of what happens with threads, because it also has to be proven that no reference can escape through any of the parameters or the return value. E.G. depending on the parameters, it could actually be possible to assign to a module-level variable inside a pure function via a pointer that was a member variable of one of the parameters. Depending on how much information the compiler has about the types involved, _maybe_ it could prove it without scope if pure is involved, but it gets pretty thorny. Certainly, it's way, way simply just to use scope and force the programmer to continue to cast in those cases that the compiler can't prove correctness just like we have to do now. - Jonathan M Davis
Re: Invalid string literal in ASM
On Monday, 1 October 2018 at 09:24:47 UTC, Basile B. wrote: On Monday, 1 October 2018 at 08:14:07 UTC, dokutoku wrote: I get a compiler error when I try to put non-ASCII characters in a string literal in the inline assembler. Is this part of the specifications? It's not clear, see https://dlang.org/spec/iasm.html#raw_data: "if an operand is a string literal, it is as if there were length operands, where length is the number of characters in the string" db "e"; // ok db "é"; // error it seems that the second case should be accepted as db 195 db 169 BUG imo. length is 2. "é" should be interpreted as the 2 bytes of its data. Something with decoding is wrong here.
Re: printed v0.0.3: a low-level API to generate self-contained PDF/SVG
On Monday, 1 October 2018 at 10:19:12 UTC, Dukc wrote: On Monday, 1 October 2018 at 09:34:34 UTC, Guillaume Piolat wrote: printed is a low-level API to generate self-contained PDF 1.4/SVG 1.1 documents hopefully suitable for print. At work, I had to make a file converter which converts an obsolete CAD format to image files. It currently makes png and bmp files via dlib and svg files via dxml. This one will be useful if I need to extend it to pdf files. Thank you. Mmmm you mean dlib has a software renderer?
[Issue 19280] Remove unnecessary error checks in core.time.currSystemTick and currTime
https://issues.dlang.org/show_bug.cgi?id=19280 Nathan S. changed: What|Removed |Added Summary|Remove unnecessary error|Remove unnecessary error |checks in |checks in |core.time.currSystemTick|core.time.currSystemTick ||and currTime --
Re: Funny way to crash dmd and brick the whole computer
On Monday, 1 October 2018 at 09:24:18 UTC, Basile B. wrote:
On Friday, 28 September 2018 at 11:58:25 UTC, Zardoz wrote:
CTE fib :
module fib_cte;
import std.stdio;
long fib(long n) {
if (n <= 1) return 1;
return fib(n - 1) + fib(n - 2);
}
static immutable valueFib = fib(46);
void main() {
writeln(valueFib);
}
don't try to compile this one linux:
```
void main(){ asm{ db cast(ubyte[]) "é"; } }
```
Actually no, it's an IDE issue triggered by this code.
Re: `shared`...
On Monday, 1 October 2018 at 09:55:41 UTC, ag0aep6g wrote: On 10/01/2018 08:47 AM, Nicholas Wilson wrote: In order to be safe, a mutable parameter can be implicitly cast to shared iff the parameter is also scope (that includes the `this` reference`). With an implicit cast in place of the explicit cast under the new rules it would fail to compile because the `this` reference is not scope. I don't see why it would fail to compile. There's no reason why my `doThing` couldn't be marked as `scope`. It doesn't leak anything. Hmm, you are right. Its annoying because the use case for this is where the data is already shared and a lock has been taken. `pure` would break the example. I'm not sure if it would ensure safety, though. Can a `pure` method spawn a new thread (that outlives the method call)? Error: pure function onlineapp.f cannot call impure function core.thread.Thread.start
Re: printed v0.0.3: a low-level API to generate self-contained PDF/SVG
On Monday, 1 October 2018 at 09:34:34 UTC, Guillaume Piolat wrote: printed is a low-level API to generate self-contained PDF 1.4/SVG 1.1 documents hopefully suitable for print. At work, I had to make a file converter which converts an obsolete CAD format to image files. It currently makes png and bmp files via dlib and svg files via dxml. This one will be useful if I need to extend it to pdf files. Thank you.
Re: `shared`...
On Monday, 1 October 2018 at 08:04:38 UTC, Kagamin wrote:
Shared data may need different algorithms.
Yes, but those same algorithms will work on unshared (they might
be slower but they will work). The reverse is not true, it can
lead to race conditions.
If unshared data is
implicitly convertible to shared, you start to conflate shared
data with unshared, so you're back to C-style sharing.
No, when participating in overloading, an unshared method will be
preferred over a shared method for an unshared object. Same with
parameters that are not `this`.
This is how you can do it:
shared struct SharedBob
{
this(int){}
void setThing(){}
}
alias shared SharedBob Bob;
void f(ref shared Bob a, ref Bob b)
{
a.setThing(); // I have a shared object, can call shared
method
b.setThing(); // ok
}
int main()
{
auto b=Bob(0);
Bob c;
f(b,c);
return 0;
}
I'm not sure what that was supposed to demonstrate.
Re: `shared`...
On 10/01/2018 08:47 AM, Nicholas Wilson wrote: In order to be safe, a mutable parameter can be implicitly cast to shared iff the parameter is also scope (that includes the `this` reference`). With an implicit cast in place of the explicit cast under the new rules it would fail to compile because the `this` reference is not scope. I don't see why it would fail to compile. There's no reason why my `doThing` couldn't be marked as `scope`. It doesn't leak anything. `pure` would break the example. I'm not sure if it would ensure safety, though. Can a `pure` method spawn a new thread (that outlives the method call)?
printed v0.0.3: a low-level API to generate self-contained PDF/SVG
printed is a low-level API to generate self-contained PDF 1.4/SVG 1.1 documents hopefully suitable for print. Currently it does not provide any "layout" option, you are just provided a sort of 2D Canvas API which can then render to either SVG or PDF. No line-breaking, paragraphs, ligature, vertical glyphs, or any type of layout are provided, they would have to be implemented on top of it. The most saliant feature is that you are able to embed a TrueType/OpenType font inside the generated PDF, instead of being restricted to the default fonts of PDF. It includes an OpenType parser, font matching algorithms and a FontRegistry which deals with "finding whatever font are installed". http://code.dlang.org/packages/printed
Re: Funny way to crash dmd and brick the whole computer
On Friday, 28 September 2018 at 11:58:25 UTC, Zardoz wrote:
CTE fib :
module fib_cte;
import std.stdio;
long fib(long n) {
if (n <= 1) return 1;
return fib(n - 1) + fib(n - 2);
}
static immutable valueFib = fib(46);
void main() {
writeln(valueFib);
}
don't try to compile this one linux:
```
void main(){ asm{ db cast(ubyte[]) "é"; } }
```
Re: Invalid string literal in ASM
On Monday, 1 October 2018 at 08:14:07 UTC, dokutoku wrote: I get a compiler error when I try to put non-ASCII characters in a string literal in the inline assembler. Is this part of the specifications? It's not clear, see https://dlang.org/spec/iasm.html#raw_data: "if an operand is a string literal, it is as if there were length operands, where length is the number of characters in the string" db "e"; // ok db "é"; // error it seems that the second case should be accepted as db 195 db 169
Re: Linking with a non-default druntime
On Monday, 1 October 2018 at 07:17:59 UTC, Per Nordlöw wrote: On Sunday, 30 September 2018 at 19:53:02 UTC, Basile B. wrote: this way you can very easily change-compile-test, without recompiling the whole runtime and phobos each time. Ok, thanks. Is it possible to register an extra GC in a separate program by overriding the logic in `gc.proxy` in druntime? That would be the most effective way. I think so. Apparently it's registered with a string, e.g "manual" and you pass a special druntime option with your program to select. Actually i would be interested to make the interface with assignable handlers since you don't seem to be very hot. Maybe tomorrow i can try. I'm almost sure that this could work but cant be 100% sure. Maybe there'll be issues with privacy and events to assign.
Invalid string literal in ASM
I get a compiler error when I try to put non-ASCII characters in a string literal in the inline assembler. Is this part of the specifications?
[Issue 19280] Remove unnecessary error checks in core.time.currSystemTick
https://issues.dlang.org/show_bug.cgi?id=19280 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/6e8b3793dbe7f30e46ee2ba243d1d221550fff8c Fix Issue 19280 - Remove unnecessary error checks in core.time.currSystemTick QueryPerformanceCounter doesn't fail on Windows XP or later. https://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx gettimeofday called with a valid timeval address and a null second parameter doesn't fail. http://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html clock_gettime called with a valid clock_id and a valid timespec address is in principle allowed to fail if the number of seconds doesn't fit in time_t, so even though no known implementation does this it is probably best to retain the error check at this time. http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html https://github.com/dlang/druntime/commit/e807e29472fa5973c438f97cd5d4b390ef1a4a5c Merge pull request #2315 from n8sh/issue-19280 Fix Issue 19280 - Remove unnecessary error checks in core.time.currSystemTick merged-on-behalf-of: Petar Kirov --
[Issue 19280] Remove unnecessary error checks in core.time.currSystemTick
https://issues.dlang.org/show_bug.cgi?id=19280 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: `shared`...
On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:
So, I know that there's not a bunch of threads banging on this
object... but the shared method should still work! A method that
handles thread-safety doesn't suddenly not work when it's only
accessed from a single thread.
Shared data may need different algorithms. If unshared data is
implicitly convertible to shared, you start to conflate shared
data with unshared, so you're back to C-style sharing.
This is how you can do it:
shared struct SharedBob
{
this(int){}
void setThing(){}
}
alias shared SharedBob Bob;
void f(ref shared Bob a, ref Bob b)
{
a.setThing(); // I have a shared object, can call shared method
b.setThing(); // ok
}
int main()
{
auto b=Bob(0);
Bob c;
f(b,c);
return 0;
}
Re: Performance of GC.collect() for single block of `byte`s
On 28/09/2018 14:21, Per Nordlöw wrote: On Monday, 24 September 2018 at 14:31:45 UTC, Steven Schveighoffer wrote: It's not scanning the blocks. But it is scanning the stack. Each time you are increasing the space it must search for a given *target*. It also must *collect* any previous items at the end of the scan. Note that a collection is going to mark every single page and bitset that is contained in the item being collected (which gets increasingly larger). Is this because of the potentially (many) slices referencing this large block? I assume the GC doesn't scan the `byte`-array for pointer-values in this case, but that happens for `void`-arrays and class/pointer-arrays right? Couldn't that scan be optimized by adding a bitset that indicates which pages need to be scanned? Is it common for GC's to treat large objects in this way? A profiler reveals that most of the time is spent in "sweeping" the memory, i.e. looking for allocations no longer referenced. The existing implementation checks every page which causes a linear growth of required CPU resources with used memory. This version https://github.com/rainers/druntime/tree/gc_opt_sweep takes advantage of the known size of allocations to skip unnecessary checks. The last commit also adds support for keeping track of the size of blocks of consecutive free pages. With this your example has more or less constant collection time (note that most of the program time is spent setting the array to zero, though not measured, and that the allocation often triggers a collection, too). I also noticed a rather serious bug for huge allocations: https://issues.dlang.org/show_bug.cgi?id=19281
Re: Linking with a non-default druntime
On Sunday, 30 September 2018 at 19:53:02 UTC, Basile B. wrote: this way you can very easily change-compile-test, without recompiling the whole runtime and phobos each time. Ok, thanks. Is it possible to register an extra GC in a separate program by overriding the logic in `gc.proxy` in druntime? That would be the most effective way.
[Issue 19281] New: GC mishandles allocations >= 4GB
https://issues.dlang.org/show_bug.cgi?id=19281
Issue ID: 19281
Summary: GC mishandles allocations >= 4GB
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: major
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
Huge allocations are mistreated by the GC, e.g.
import core.memory;
import std.stdio;
void main()
{
size_t sz = 2L^^32;
auto ptr = GC.malloc(sz);
auto info = GC.query(ptr);
writeln(info);
assert(info.size >= sz);
}
>dmd -m64 -run test.d
BlkInfo_(1F953FE, 0, 0)
core.exception.AssertError@large.d(10): Assertion failure
=> The returned size is reported as 0.
The problem ist that the size of large allocations are stored in a uint-array
bPageOffsets, which causes bPageOffsets[p]*PAGESIZE to overflow.
--
Re: `shared`...
On Monday, 1 October 2018 at 06:06:31 UTC, ag0aep6g wrote:
`shared` isn't analogous to `const`. It's analogous to
`immutable`. Functions dealing with `shared` data can assume
that other threads also see the data as `shared`. If you allow
calling `shared` methods on non-`shared` objects, you're
breaking that.
Example:
struct Bob
{
int* p;
void doThing() shared
{
p =
}
}
shared int s;
void main()
{
Bob bob;
(cast(shared Bob)bob).doThing();/* You'd make the cast
implicit. */
import core.thread;
import core.atomic;
enum n = 1_000_000;
auto t = new Thread(() { foreach (i; 0 .. n) atomicOp!"+="(s,
1); });
t.start();
foreach (i; 0 .. n) ++*bob.p;
thread_joinAll();
import std.stdio;
writeln(s); /* usually not "200", because of race */
}
We've realised that.
In order to be safe, a mutable parameter can be implicitly cast
to shared iff the parameter is also scope (that includes the
`this` reference`). With an implicit cast in place of the
explicit cast under the new rules it would fail to compile
because the `this` reference is not scope.
[Issue 19280] Remove unnecessary error checks in core.time.currSystemTick
https://issues.dlang.org/show_bug.cgi?id=19280 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2315 --
Re: `shared`...
On 10/01/2018 04:29 AM, Manu wrote:
struct Bob
{
void setThing() shared;
}
[...]
void f(ref shared Bob a, ref Bob b)
{
a.setThing(); // I have a shared object, can call shared method
b.setThing(); // ERROR
}
This is the bit of the design that doesn't make sense to me...
The method is shared, which suggests that it must handle
thread-safety. My instance `b` is NOT shared, that is, it is
thread-local.
[...]
I feel like I don't understand the design...
mutable -> shared should work the same as mutable -> const... because
surely that's safe?
`shared` isn't analogous to `const`. It's analogous to `immutable`.
Functions dealing with `shared` data can assume that other threads also
see the data as `shared`. If you allow calling `shared` methods on
non-`shared` objects, you're breaking that.
Example:
struct Bob
{
int* p;
void doThing() shared
{
p =
}
}
shared int s;
void main()
{
Bob bob;
(cast(shared Bob)bob).doThing();/* You'd make the cast implicit. */
import core.thread;
import core.atomic;
enum n = 1_000_000;
auto t = new Thread(() { foreach (i; 0 .. n) atomicOp!"+="(s, 1); });
t.start();
foreach (i; 0 .. n) ++*bob.p;
thread_joinAll();
import std.stdio;
writeln(s); /* usually not "200", because of race */
}
