Re: __gshared as part of alias
On Wednesday, January 17, 2018 07:30:30 Nicholas Wilson via Digitalmars-d-
learn wrote:
> On Wednesday, 17 January 2018 at 02:37:07 UTC, Steven
>
> Schveighoffer wrote:
> > On 1/11/18 11:25 PM, Nicholas Wilson wrote:
> >> Is there a way to make __gshared part of an alias?
> >
> > No, __gshared is a storage class, not a type constructor, so it
> > has no meaning as part of a type:
> >
> > __gshared int x;
> > int y;
> >
> > static assert(is(typeof(x) == typeof(y)));
> >
> >> as in
> >>
> >> enum AddrSpace : uint
> >> {
> >>
> >> Private = 0,
> >> Global = 1,
> >> Shared = 2,
> >> Constant = 3,
> >> Generic = 4,
> >>
> >> }
> >>
> >> struct Variable(AddrSpace as, T)
> >> {
> >>
> >> T val;
> >> alias val this;
> >>
> >> }
> >> alias Global(T) = __gshared Variable!(AddrSpace.Global, T);
> >
> > dmd famously doesn't complain about attributes that do nothing,
> > as in this case.
> >
> > -Steve
>
> I kluged this into place in LDC
> https://github.com/ldc-developers/ldc/pull/2509/commits/7cf6f417f95a5bffa4
> b18f2d8b132ca8f0e900d3#diff-33d7d08455db33f1182e3936fd2ba3f9R896
I don't know what you're doing, and maybe __gshared is the appropriate
solution for what you're trying to do, but in general, if you're not trying
to bind to a C global variable, you should be using shared, and using
__gshared is risking bugs precisely because it is not considered part of the
type and does not prevent you from using it a thread-local context. The
compiler will treat it as thread-local, risking subtle bugs that shared
would catch.
- Jonathan M Davis
Re: private selective import + overload = breaks accessibility rules
On Wednesday, 17 January 2018 at 02:23:40 UTC, Seb wrote: On Tuesday, 16 January 2018 at 19:05:51 UTC, rumbu wrote: On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote: Which version of the compiler is this? I'm pretty sure the std.math.isNaN imported by module a should not be visible in module b. The latest compiler should emit a deprecation warning for this. 2.078, but also 2.077. Deprecation is emitted only if there is no overload; Of course, it's possible that having a public symbol in module a that overloads an imported symbol may have triggered a buggy corner case in the compiler. If so, a bug should be filed. Done: https://issues.dlang.org/show_bug.cgi?id=18243 1) Imports are by default private 2) This is a known bug. See: https://github.com/dlang/phobos/pull/5584 https://issues.dlang.org/show_bug.cgi?id=17630 On the good side, there's WIP to fix this, e.g. https://github.com/dlang/dmd/pull/7668 Are you sure about this? I thought such module-scope selective imports were supposed to be private by default since Martin's fixes for bug 314, which is why you submitted pull 5584. Bug 17630 is about something different, that selective imports pull symbols out of the imported module's non-selective imports, but he's not using any selective imports in his module b. I ran this code example through my symbol-dumping dmd (http://forum.dlang.org/thread/pbpckzwmfglzgwqve...@forum.dlang.org) and module b from his first example is indeed getting isNaN from std.math, which implies the older bug that selective imports at module scope are still leaking out.
Re: __gshared as part of alias
On Wednesday, 17 January 2018 at 02:37:07 UTC, Steven
Schveighoffer wrote:
On 1/11/18 11:25 PM, Nicholas Wilson wrote:
Is there a way to make __gshared part of an alias?
No, __gshared is a storage class, not a type constructor, so it
has no meaning as part of a type:
__gshared int x;
int y;
static assert(is(typeof(x) == typeof(y)));
as in
enum AddrSpace : uint
{
Private = 0,
Global = 1,
Shared = 2,
Constant = 3,
Generic = 4,
}
struct Variable(AddrSpace as, T)
{
T val;
alias val this;
}
alias Global(T) = __gshared Variable!(AddrSpace.Global, T);
dmd famously doesn't complain about attributes that do nothing,
as in this case.
-Steve
I kluged this into place in LDC
https://github.com/ldc-developers/ldc/pull/2509/commits/7cf6f417f95a5bffa4b18f2d8b132ca8f0e900d3#diff-33d7d08455db33f1182e3936fd2ba3f9R896
Re: __gshared as part of alias
On 1/11/18 11:25 PM, Nicholas Wilson wrote:
Is there a way to make __gshared part of an alias?
No, __gshared is a storage class, not a type constructor, so it has no
meaning as part of a type:
__gshared int x;
int y;
static assert(is(typeof(x) == typeof(y)));
as in
enum AddrSpace : uint
{
Private = 0,
Global = 1,
Shared = 2,
Constant = 3,
Generic = 4,
}
struct Variable(AddrSpace as, T)
{
T val;
alias val this;
}
alias Global(T) = __gshared Variable!(AddrSpace.Global, T);
dmd famously doesn't complain about attributes that do nothing, as in
this case.
-Steve
Re: private selective import + overload = breaks accessibility rules
On Tuesday, 16 January 2018 at 19:05:51 UTC, rumbu wrote: On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote: Which version of the compiler is this? I'm pretty sure the std.math.isNaN imported by module a should not be visible in module b. The latest compiler should emit a deprecation warning for this. 2.078, but also 2.077. Deprecation is emitted only if there is no overload; Of course, it's possible that having a public symbol in module a that overloads an imported symbol may have triggered a buggy corner case in the compiler. If so, a bug should be filed. Done: https://issues.dlang.org/show_bug.cgi?id=18243 1) Imports are by default private 2) This is a known bug. See: https://github.com/dlang/phobos/pull/5584 https://issues.dlang.org/show_bug.cgi?id=17630 On the good side, there's WIP to fix this, e.g. https://github.com/dlang/dmd/pull/7668
Re: Function hijack on selective import
On Tuesday, 16 January 2018 at 20:30:43 UTC, H. S. Teoh wrote:
On Tue, Jan 16, 2018 at 07:14:00PM +, rumbu via
Even specialized, now I have another problem:
std.math:
int signbit(X)(X x) { ... }
mylibrary:
int signbit(D: Decimal!bits, int bits) { ... }
=
end user:
import std.math;
import mylibrary;
Decimal!32 d;
float f;
auto y = signbit(f); //ok, call to std.math.signbit
auto x = signbit(d); //error, also calls std.math.signbit
Arguably, this is a defect in Phobos. Looking at the
definition of std.math.signbit, it's obvious that it's only
meant to handle built-in floating-point types, yet there are no
sig constraints to that effect.
Fix: https://github.com/dlang/phobos/pull/6040
T
Thank you for the pull request, but the list is longer :)
https://issues.dlang.org/show_bug.cgi?id=18244
Re: Function hijack on selective import
On Tue, Jan 16, 2018 at 07:14:00PM +, rumbu via Digitalmars-d-learn wrote:
> On Tuesday, 26 December 2017 at 20:21:11 UTC, Adam D. Ruppe wrote:
> > On Tuesday, 26 December 2017 at 19:41:47 UTC, rumbu wrote:
> > > "Custom" is a templated struct. I cannot imagine all the
> > > instantiations of Custom to write template specialisations for
> > > each of them.
> >
> > You can specialize on templated structs generically.
> >
> > int foo(T : Bar!(X, Y), X, Y)
> >
> > that kind of thing covers any case of Bar!(X,y)
>
> Even specialized, now I have another problem:
>
> std.math:
>
> int signbit(X)(X x) { ... }
>
> mylibrary:
>
> int signbit(D: Decimal!bits, int bits) { ... }
>
> =
>
> end user:
>
> import std.math;
> import mylibrary;
>
> Decimal!32 d;
> float f;
>
> auto y = signbit(f); //ok, call to std.math.signbit
> auto x = signbit(d); //error, also calls std.math.signbit
Arguably, this is a defect in Phobos. Looking at the definition of
std.math.signbit, it's obvious that it's only meant to handle built-in
floating-point types, yet there are no sig constraints to that effect.
Fix: https://github.com/dlang/phobos/pull/6040
T
--
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
Re: Alias to single function of object inside class
On 01/16/2018 11:00 AM, ARaspiK wrote:
I have a class Foo, which has functions a(), b(), and c().
I have a class Bar that has baz, an instance of Foo.
How do I link Bar.b() -> baz.b() without also linking Foo.a() and Foo.c()?
I know we can do an alias this, but I only want to link over b().
Why not show it with code? :) Is the following accurate and sufficient?
class Foo {
void a() {
}
void b() {
}
void c() {
}
}
class Bar {
Foo baz;
this() {
baz = new Foo();
}
void b() {
baz.b();
}
}
void main() {
auto b = new Bar();
static assert(!__traits(compiles, b.a()));
b.b();
static assert(!__traits(compiles, b.c()));
}
Ali
Re: Function hijack on selective import
On Tuesday, 26 December 2017 at 20:21:11 UTC, Adam D. Ruppe wrote:
On Tuesday, 26 December 2017 at 19:41:47 UTC, rumbu wrote:
"Custom" is a templated struct. I cannot imagine all the
instantiations of Custom to write template specialisations for
each of them.
You can specialize on templated structs generically.
int foo(T : Bar!(X, Y), X, Y)
that kind of thing covers any case of Bar!(X,y)
Even specialized, now I have another problem:
std.math:
int signbit(X)(X x) { ... }
mylibrary:
int signbit(D: Decimal!bits, int bits) { ... }
=
end user:
import std.math;
import mylibrary;
Decimal!32 d;
float f;
auto y = signbit(f); //ok, call to std.math.signbit
auto x = signbit(d); //error, also calls std.math.signbit
Re: private selective import + overload = breaks accessibility rules
On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote: Which version of the compiler is this? I'm pretty sure the std.math.isNaN imported by module a should not be visible in module b. The latest compiler should emit a deprecation warning for this. 2.078, but also 2.077. Deprecation is emitted only if there is no overload; Of course, it's possible that having a public symbol in module a that overloads an imported symbol may have triggered a buggy corner case in the compiler. If so, a bug should be filed. Done: https://issues.dlang.org/show_bug.cgi?id=18243
Alias to single function of object inside class
I have a class Foo, which has functions a(), b(), and c(). I have a class Bar that has baz, an instance of Foo. How do I link Bar.b() -> baz.b() without also linking Foo.a() and Foo.c()? I know we can do an alias this, but I only want to link over b().
Re: private selective import + overload = breaks accessibility rules
On Tue, Jan 16, 2018 at 06:13:27PM +, rumbu via Digitalmars-d-learn wrote:
> module a;
>
> private import std.math: isNaN;
>
> //custom overload
> public bool isNaN(int i) { return false; }
>
>
> =
>
> module b;
> import a;
>
> void foo()
> {
> bool b = isNaN(float.nan);
> //compiles successfully calling std.math.isNaN even it should not be
> visible.
> }
>
> Is this normal behavior or a bug?
Which version of the compiler is this? I'm pretty sure the
std.math.isNaN imported by module a should not be visible in module b.
The latest compiler should emit a deprecation warning for this.
Of course, it's possible that having a public symbol in module a that
overloads an imported symbol may have triggered a buggy corner case in
the compiler. If so, a bug should be filed.
> OK, let's try another:
>
> module b;
> import a;
> import std.math; // <== note this
>
> void foo()
> {
> bool b = isNaN(float.nan);
> }
>
> It ends in a very funny error message:
>
> Error: std.math.isNaN!float.isNaN at src\phobos\std\math.d(5335) conflicts
> with std.math.isNaN!float.isNaN at src\phobos\std\math.d(5335)
[...]
LOL! Yeah, if this is the latest compiler, it's definitely a bug.
T
--
First Rule of History: History doesn't repeat itself -- historians merely
repeat each other.
private selective import + overload = breaks accessibility rules
module a;
private import std.math: isNaN;
//custom overload
public bool isNaN(int i) { return false; }
=
module b;
import a;
void foo()
{
bool b = isNaN(float.nan);
//compiles successfully calling std.math.isNaN even it should
not be visible.
}
Is this normal behavior or a bug?
OK, let's try another:
module b;
import a;
import std.math; // <== note this
void foo()
{
bool b = isNaN(float.nan);
}
It ends in a very funny error message:
Error: std.math.isNaN!float.isNaN at src\phobos\std\math.d(5335)
conflicts with std.math.isNaN!float.isNaN at
src\phobos\std\math.d(5335)
Real life context:
the private import:
https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L320
the overload:
https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L4201
If the end user wants to use my module like this:
import std.math;
import decimal;
he'll get the nice error message above.
Re: Using Postgres connection functions
On Saturday, 13 January 2018 at 17:58:14 UTC, Joe wrote: ...ddb. The latter perhaps has the distinction that it doesn't use libpq, but rather implements the Postgres FE/BE protocol. That's a bit *too* native for my taste. It means the library maintainer has to keep up with changes to the internal protocol, which although published, the Postgres group doesn't have to maintain compatibility from version to version. Not that it matters, but client-server protocol is actually the most stable one, it hasn't changed since Postgress 7.4 (Release date: 2003-11-17). It's the language-level abstractions like libpq that keep being changed\updated on almost each release.
Re: Web Browser
It looks like there are some unmaintained D bindings for sciter: https://github.com/sciter-sdk/Sciter-Dport
Re: need help with vibe.d receive()
On Tuesday, 16 January 2018 at 08:54:58 UTC, Sönke Ludwig wrote:
...
The problem is with the `immutable struct StopEvent {}`
Thanks!
...
So, removing the `immutable` from the declaration solved the
issue for me, but if possible I'd rather remove the
`cast(shared Unqual!EventType)` from `emit`, and pass
`shared`/`immutable` events to it from the outside (or plain
events with no unshared indirections).
No, I can't remove casting here, because some other services
can't work with immutable or shared, so I just fix StopEvent type.
Web Browser
I'm used to use Qt's QWebView when I need an application to show a HTML page and change some elements on it. This time, if possible, I'd like to use D instead. Are there any web browsers ports in D?
Re: class initialization
On Tuesday, 16 January 2018 at 03:23:20 UTC, Marc wrote: But can't figure out if D does have that for classes. I believe there's no such thing for classes, you're supposed to use constructors. Class objects are in many aspects more abstract things than POD structs: instead of accessing their data directly there are constructors, virtual (by default) methods, and there is inheritance and interfaces which require the accesses to be rather abstract and indirect to work well.
Re: Vibe-d issue with timer in separate thread on debug builds
Am 10.01.2018 um 15:40 schrieb Andres Clari:
Hi, I have an app that uses vibe tasks, fibers and timers extensively,
and I found an issue only for debug builds, when canceling a timer.
However the code in question works just fine in the release build.
But having this here makes testing certain things in my program a pain,
since it'll crash on the assert in question:
vibe-d-0.8.2/vibe-d/core/vibe/core/drivers/libevent2.d:474
debug assert(m_ownerThread is () @trusted { return Thread.getThis(); } ());
Also, not sure I understand that assert properly... Is it checking the
stop timer call is fired from the main thread the event loop is running?
That would be bad, since basically that timer run from a child thread.
The basic requirement for almost all vibe.d primitives is that they may
only be used within the same thread in which they were created. Anything
else requires message passing (e.g. using std.concurrency) to issue the
operation in the owner thread.
There incidentally is a recent thread on the vibe.d forum on this topic:
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/48663/
Re: need help with vibe.d receive()
Am 10.01.2018 um 15:39 schrieb crimaniak:
Hi!
I make multi-task event bus, but there is a problem with the task stops.
Please see end of file
https://github.com/crimaniak/d-vision/blob/master/src/vision/eventbus.d
Expected behavior: After sending the StopEvent message in line 244 it is
must be detected in listeners (line 147), so all listeners must set exit
flag to 'true' and quit immediately.
De-facto behavior: StopEvent() message is not detected by the first
delegate in line 147 (logger task logs this message by the handler in
line 185), so subscribed tasks never exit and test stops on line 248.
I tried to play with yield() and sleep(), with 'shared' attributes and
so on, but without result. Can you say please what I am doing wrong here?
'dub test' can be used to play with tests.
The problem is with the `immutable struct StopEvent {}` declaration and
the use of `shared(Unqual!StopEvent)` - `shared(StopEvent)` is actually
reduced to just `StopEvent`, which internally is expanded to
`immutable(StopEvent)` and `immutable` already implies `shared`.
However, `Unqual!StopEvent` actually removes the implicit `immutable`
from the type, so that `shared(Unqual!StopEvent)` is really just
`shared(StopEvent)` and consequently treated as a different type by
`receive`.
So, removing the `immutable` from the declaration solved the issue for
me, but if possible I'd rather remove the `cast(shared
Unqual!EventType)` from `emit`, and pass `shared`/`immutable` events to
it from the outside (or plain events with no unshared indirections).
