Re: Interesting Observation from JAXLondon
On Sunday, 21 October 2018 at 01:12:44 UTC, Nick Sabalausky (Abscissa) wrote: On 10/12/18 4:05 AM, Vijay Nayar wrote: But the D community has also been very receptive of changes to the language The community is. I don't feel like it's been true of the leadership for some years now (and I don't mean just W) One thing that does concern me, is the avenues in which people can discover D. For me personally, after a particularly nasty C++ project, I just googled for "alternatives to C++" and that's how I found D back in 2009 or so. But the same search today turns up nothing about D. I'm not sure sure how people are supposed to find D. This is a VERY important thing, and it's true for many of us (myself included). This why it was a HUGE mistake when the community decided it should become taboo to promote D as a redesigned C++. That was ALWAYS D's core strength, we all know it, that's why many (if not most) of us are here, and hell, that's literally what D was *intentionally designed* to be. But then political correctness came and threw that angle out the window, in favor of this awkward "fast code fast" nonsense, and we've been fighting the uphill "I don't understand the point of D" image battle ever since. Simple, C++ is increasingly seen as irrelevant by those choosing a new language, so D's real competition is now Go, Rust, Swift, Nim, Zig, etc. These are people who want to write "fast code fast," well except for Rust users, who value ownership more. Also, D can pitch itself to Java/C# users who need more performance with that softer pitch, because many of them have been burned by C++ and would recoil if you made the explicit C++ comparison. It is well-known that Rust and Go are attracting users from the Java and scripting communities, D needs to attract them too, as the Tilix dev noted to me last year: "[M]y background is in Java. I found it quite interesting at DConf when I asked how many people came from a non C/C++ background that only one other fellow raised his hand... I tend to get more annoyed about the negativity in the forums with regards to GC. I do feel that sometimes people get so wrapped up in what D needs for it to be a perfect systems language (i.e. no GC, memory safety, etc.), it gets overlooked that it is a very good language for building native applications as it is now. While D is often compared to Rust, in some ways the comparison to Go is more interesting to me. Both are GC-based languages and both started as systems languages, however Go pivoted and doubled down on the GC and has seen success. One of the Red Hat products I support, OpenShift, leverages Kubernetes (a Google project) for container orchestration and it’s written in Go. I think D as a language is far superior to Go, and I wish we would toot our horn a little more in this regard instead of the constant negative discussion around systems programming." https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/
Re: shared - i need it to be useful
On Sat, Oct 20, 2018 at 10:10 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Saturday, 20 October 2018 at 16:48:05 UTC, Nicholas Wilson
> wrote:
> > On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright
> > wrote:
> >> On 10/19/2018 11:18 PM, Manu wrote:
> >>> The reason I ask is because, by my definition, if you have:
> >>> int* a;
> >>> shared(int)* b = a;
> >>>
> >>> While you have 2 numbers that address the same data, it is
> >>> not actually aliased because only `a` can access it.
> >>
> >> They are aliased,
> >
> > Quoting Wikipedia:
> >
> >>two pointers A and B which have the same value, then the name
> >>A[0] aliases the name B[0]. In this case we say the pointers A
> >>and B alias each other. Note that the concept of pointer
> >>aliasing is not very well-defined – two pointers A and B may or
> >>may not alias each other, depending on what operations are
> >>performed in the function using A and B.
> >
> > In this case given the above: `a[0]` does not alias `b[0]`
> > because `b[0]` is ill defined under Manu's proposal, because
> > the memory referenced by `a` is not reachable through `b`
> > because you can't read or write through `b`.
> >
> >> by code that believes it is unshared
> >
> > you cannot `@safe`ly modify the memory through `b`, `a`'s view
> > of the memory is unchanged in @safe code.
>
> And that's already a bug, because the language can't enforce
> threadsafe access through `a`, regardless of presence of `b`.
> Only the programmer can.
>
> >> and, code that believes it is shared.
> >
> > you cannot have non-atomic access though `b`, `b` has no @safe
> > view of the memory, unless it is atomic (which by definition is
> > synchronised).
>
> Synchronized with what? You still have `a`, which isn't `shared`
> and doesn't require any atomic access or synchronization. At this
> point it doesn't matter if it's an int or a struct. As soon as
> you share `a`, you can't just pretend that reading or writing `a`
> is safe.
`b` can't read or write `a`... accessing `a` is absolutely safe.
Someone must do something unsafe to undermine your threadsafety... and
if you write unsafe code and don't know what you're doing, there's
nothing that can help you.
Today, every interaction with shared is unsafe. Creating a safe
interaction with shared will lead to people not doing unsafe things at
every step.
> Encapsulate it all you want, safety only remains a
> contract of convention, the language can't enforce it.
You're talking about @trusted code again. You're fixated on unsafe
interactions... my proposal is about SAFE interactions. I'm trying to
obliterate unsafe interactions with shared.
> module expertcode;
>
> @safe:
>
> struct FileHandle {
> @safe:
>
> void[] read(void[] storage) shared;
> void[] write(const(void)[] buffer) shared;
> }
>
> FileHandle openFile(string path);
> // only the owner can close
> void closeFile(ref FileHandle);
>
> void shareWithThreads(shared FileHandle*); // i.e. generate a
> number of jobs in some queue
> void waitForThreads(); // waits until all
> processing is done
>
> module usercode;
>
> import expertcode;
>
> void processHugeFile(string path) {
> FileHandle file = openFile(path);
> shareWithThreads();// implicit cast
> waitForThreads();
> file.closeFile();
> }
This is a very strange program... I'm dubious it is in fact
"expertcode"... but let's look into it.
File handle seems to have just 2 methods... and they are both threadsafe.
Open and Close are free-functions. Close does not promise threadsafety
itself (but of course, it doesn't violate read/write's promise, or the
program is invalid).
I expect the only possible way to achieve this is by an internal mutex
to make sure read/write/close calls are serialised. read and write
will appropriately check their file-open state each time they perform
their actions. What read/write do in the case of being called on a
closed file... anyones guess? I'm gonna say they do no-op... they
return a null pointer to indicate the error state.
Looking at the meat of the program; you open a file, and distribute it
to do accesses (I presume?)
Naturally, this is a really weird thing to do, because even if the API
is threadsafe such that it doesn't crash and reads/writes are
serialised, the sequencing of reads/writes will be random, so I don't
believe any sane person (let alone an expert) would write this
program... but moving on.
Then you wait for them to finish, and close the file.
Fine. You have a file with randomly interleaved data... for whatever reason.
> Per your proposal, everything in 'expertcode' can be written
> @safe, i.e. not violating any of the points that @safe forbids,
> or doing so only in a @trusted manner. As far as the language is
> concerned, this would mean that processHugeFile can be @safe as
> well.
This program does appear to be safe (assuming that the implementations
aren't invalid), but a very strange program nonetheless.
>
Re: Just found this debugger...
On 21/10/2018 5:59 PM, solidstate1991 wrote: On Wednesday, 3 October 2018 at 13:08:50 UTC, Vladimir Panteleev wrote: On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: and I don't want to go back to VisualD after VSCode for either a usable mago or VS native debug. Visual Studio makes a decent stand-alone source-level debugger. Just select the .exe file, and right-click it in the project/solution pane to start a debugging session. (Of course, you need to build with -m32mscoff or -m64 as well as -g). VisualD isn't even needed, though VS by itself won't understand D types like arrays/strings. I cannot find that option... Open it as a solution/project if I remember right.
Re: Just found this debugger...
On Wednesday, 3 October 2018 at 13:08:50 UTC, Vladimir Panteleev wrote: On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: and I don't want to go back to VisualD after VSCode for either a usable mago or VS native debug. Visual Studio makes a decent stand-alone source-level debugger. Just select the .exe file, and right-click it in the project/solution pane to start a debugging session. (Of course, you need to build with -m32mscoff or -m64 as well as -g). VisualD isn't even needed, though VS by itself won't understand D types like arrays/strings. I cannot find that option...
[Issue 19202] deprecated eponymous template prints no warning
https://issues.dlang.org/show_bug.cgi?id=19202 --- Comment #3 from elpenguin...@gmail.com --- It seems the PR was closed without comment...? --
We need an internal keyword.
So that classes can share some of their variables but not others
in a module.
IE.
class A
{
internal int A; //This is shared in the module
private int B; // But not this.
}
No need to reintroduce the "Friend" feature from cpp.
How do I debug externally with Visual Studio?
I use VSCode since it has better D support, however until I make mago-mi usable (it doesn't even support all the commands currently it claims, --args seems to be completely broken) or find again a working copy of LLDB for Windows (doesn't want to compile with Mingw also being installed), I cannot really debug. The only way I can debug programs is to attach to them after they have started, however it's very clunky to use this way, some programs even execute too fast to do this way.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On 10/20/18 6:28 AM, Gregor Mückl wrote: Even though web and mobile UIs seem to be the rage at the moment, I believe a solid support for desktop UIs is very important for a general purpose language, if it wants to be successful in the market. I think that may be doubly true in the case of D, given D's focus on efficiency. HTML-based interfaces (whether web or app) are notoriously rife with inefficiencies: That's likely to be a major turn-off for exactly the very same audiences that D would appeal to most.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On 10/20/18 5:25 AM, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. And KDE. I've heard a lot of very good things about GtkD, and honestly, I have no doubts about any of it. Unfortunately though, the main problem with GtkD is simply GTK itself :( D has always had an excellent story in the "connect to C linkage libraries", has any of the work in D on C++ linkage over the last few years changed the landscape so that a D binding for Qt and QML could be as good as the GtkD binding is to GTK+? I really hope so! No idea personally though :( What about DWT? It seemed pretty good from what I could tell, though I still haven't ventured into D GUIs just yet myself. Are there issues people have with DWT? Or WxD?
Re: Interesting Observation from JAXLondon
On 10/12/18 4:05 AM, Vijay Nayar wrote: But the D community has also been very receptive of changes to the language The community is. I don't feel like it's been true of the leadership for some years now (and I don't mean just W) One thing that does concern me, is the avenues in which people can discover D. For me personally, after a particularly nasty C++ project, I just googled for "alternatives to C++" and that's how I found D back in 2009 or so. But the same search today turns up nothing about D. I'm not sure sure how people are supposed to find D. This is a VERY important thing, and it's true for many of us (myself included). This why it was a HUGE mistake when the community decided it should become taboo to promote D as a redesigned C++. That was ALWAYS D's core strength, we all know it, that's why many (if not most) of us are here, and hell, that's literally what D was *intentionally designed* to be. But then political correctness came and threw that angle out the window, in favor of this awkward "fast code fast" nonsense, and we've been fighting the uphill "I don't understand the point of D" image battle ever since.
[Issue 19322] A lot of memory is consumed and not freed to the system when Exception is formatted with stacktrace in debug
https://issues.dlang.org/show_bug.cgi?id=19322 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #1 from ki...@gmx.net --- This is probably because at least for ELF, the .debug_line section data is mmap()ped from the executable file and not unmapped after looking up file and line infos for the frames in the backtrace. The mmapped section data is owned by the ElfSection struct (via its its MMapRegion member) created in the return statement in Image.getDebugLineSectionData(). What's actually returned is the data array via alias this, and the ElfSection struct (and its MMapRegion member) apparently aren't destructed, which seems to be a bug in its own right. I only know because I 'had' to replicate this leaking behavior in https://github.com/dlang/druntime/pull/2330/files#diff-a10edf024597f176f219ea3c0cb2bdafR64, otherwise the data array was invalid (unmapped) as soon as the data slice was returned. Possible fix: pass a delegate processing the section data (something like `Image.processDebugLineSectionData(dg)`), so that the Image type can hold and release the data itself. --
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 22:19:48 UTC, 12345swordy wrote: On Saturday, 20 October 2018 at 16:37:07 UTC, Atila Neves wrote: On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote: [...] It turns out that translating C++ is *hard*. Partly because the language is huge and complicated, but also partly because libclang isn't all it's cracked up to be. But... dpp is probably a few full work days away from being to #include . Hopefully with the translation actually working. [...] There this pull request https://github.com/dlang/dmd/pull/8787 but apparently Manu is burn out from working on it I don't want to judge, but I need to point out that we have managed to make this discussion progress from outward-facing marketing to technical difficulties and related pull requests. This is not bad, but it is also a perfect example of how inward-facing the community can be and that is a part of what started this thread.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 16:37:07 UTC, Atila Neves wrote: On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote: [...] It turns out that translating C++ is *hard*. Partly because the language is huge and complicated, but also partly because libclang isn't all it's cracked up to be. But... dpp is probably a few full work days away from being to #include . Hopefully with the translation actually working. [...] There this pull request https://github.com/dlang/dmd/pull/8787 but apparently Manu is burn out from working on it.
Re: Which Docker to use?
On Friday, 19 October 2018 at 22:16:04 UTC, Ky-Anh Huynh wrote: On Wednesday, 17 October 2018 at 23:15:53 UTC, Jon Degenhardt wrote: I need to use docker to build static linked Linux executables. My reason is specific, may be different than the OP's. I'm using Travis-CI to build executables. Travis-CI uses Ubuntu 14.04, but static linking fails on 14.04. The standard C library from Ubuntu 16.04 or later is needed. There may be other/better ways to do this, I don't know. Yes I'm also using Travis-CI and that's why I need some Docker support. I'm using dlanguage/ldc. The reason for that choice was because it was what was available when I put the travis build together. As you mentioned, it hasn't been updated in a while. I'm still producing this build with an older ldc version, but when I move to a more current version I'll have to switch to a different docker image. My travis config is here: https://github.com/eBay/tsv-utils/blob/master/.travis.yml. Look for the sections referencing the DOCKERSPECIAL environment variable.
Re: shared - i need it to be useful
On Saturday, 20 October 2018 at 18:30:59 UTC, Manu wrote:
On Sat, Oct 20, 2018 at 9:45 AM Stanislav Blinov via
Digitalmars-d wrote:
On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
> class C {
> void f();
> void g() shared;
> }
Those are not "ok". They're only "ok" under Manu's proposal so
long as the author of C promises (via documentation) that
that's indeed "ok". There can be no statically-enforced
guarantees that those calls are "ok", or that issuing them in
that order is "ok". Yet Manu keeps insisting that somehow
there is.
I only insist that if you write a shared method, you promise
that it is threadsafe.
If f() undermines g() threadsafety, then **g() is NOT
threadsafe**, and you just write an invalid program.
You can write an invalid program in any imaginable number of
ways; that's just not an interesting discussion. An interesting
discussion is what we might to to help prevent writing such an
invalid program... I don't suggest here what we can do to
statically encorce this, but I suspect there does exist *some*
options which may help, which can be further developments.
What I also assert is that *this unsafe code is rare*... it
exists only at the bottom of the tooling stack, and anyone else
using a shared object will not do unsafe, and therefore will
not be able to create the problem. If you do unsafety anywhere
near `shared`, you should feel nervous. I'm trying to make a
world where you aren't *required* to do unsafety at every
single interaction.
Understand: f() can only undermine g() promise of threadsafety
**if f() is not @safe**. Users won't create this situation
accidentally, they can only do it deliberately.
---
module expertcode;
@safe:
struct FileHandle {
@safe:
void[] read(void[] storage) shared;
void[] write(const(void)[] buffer) shared;
}
FileHandle openFile(string path);
// only the owner can close
void closeFile(ref FileHandle);
void shareWithThreads(shared FileHandle*); // i.e. generate a
number of jobs in some queue
void waitForThreads(); // waits until all
processing is done
module usercode;
import expertcode;
void processHugeFile(string path) {
FileHandle file = openFile(path);
shareWithThreads();// implicit cast
waitForThreads();
file.closeFile();
}
---
Per your proposal, everything in 'expertcode' can be written
@safe, i.e. not violating any of the points that @safe forbids,
or doing so only in a @trusted manner. As far as the language is
concerned, this would mean that processHugeFile can be @safe as
well.
Remove the call to `waitForThreads()` (assume user just forgot
that, i.e. the "accident"). Nothing would change for the
compiler: all calls remain @safe. And yet, if we're lucky, we get
a consistent instacrash. If we're unlucky, we get memory
corruption, or an unsolicited write to another currently open
file, either of which can go unnoticed for some time.
Of course the program becomes invalid if you do that, there's no
question about it, this goes for all buggy code. The problem is,
definition of "valid" lies beyond the type system: it's an
agreement between different parts of code, i.e. between expert
programmers who wrote FileHandle et al., and users who write
processHugeFile(). The main issue is that certain *runtime*
conditions can still violate @safe-ty.
Your proposal makes the language more strict wrt. to writing
@safe 'expertmodule', thanks to disallowing reads and writes
through `shared`, which is great.
However the implicit conversion to `shared` doesn't in any way
improve the situation as far as user code is concerned, unless
I'm still missing something.
[Issue 19322] A lot of memory is consumed and not freed to the system when Exception is formatted with stacktrace in debug
https://issues.dlang.org/show_bug.cgi?id=19322 Tomáš Chaloupka changed: What|Removed |Added CC||d...@me.com --
[Issue 19322] New: A lot of memory is consumed and not freed to the system when Exception is formatted with stacktrace in debug
https://issues.dlang.org/show_bug.cgi?id=19322
Issue ID: 19322
Summary: A lot of memory is consumed and not freed to the
system when Exception is formatted with stacktrace in
debug
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: chalu...@gmail.com
Original issue filed in vibe-d: https://github.com/vibe-d/vibe.d/issues/2221
Test code:
```
#!/usr/bin/env dub
/+ dub.sdl:
name "memleak"
dependency "vibe-d:core" version="~>0.8.4"
subConfiguration "vibe-d:core" "libevent"
+/
import core.memory;
import std.stdio;
import std.experimental.logger;
import vibe.core.core; // comment this out to behave normally
void main()
{
foreach (i; 0..1000)
{
try throw new Exception("some message");
catch (Exception ex)
{
errorf("Error: %s", ex);
//errorf("Error: %s", ex.msg);
}
}
info("Done");
GC.collect();
GC.minimize();
readln();
}
```
Can be run with: dub --single sample.d
If I run this with dmd >= 2.081.0 the process is almost 500MB in memory.
GC.collect() and GC.minimize() doesn't matter.
If run with new vibe-core it's somewhat better at about 400MB in memory.
When just exception message is logged, process is at 6MB - what a difference.
Same when run with dmd-2.080.1 or without vibe-d.
Tested on fedora 28 x86_64 with multiple dmd versions and vibe-d-0.8.4.
Tested also on Ubuntu 18.04.1 x86_64
I tried to bisect this using digger with:
bad = https://github.com/dlang/phobos/pull/6700
good = https://github.com/dlang/phobos/pull/4941
And the winner seems to be: https://github.com/dlang/druntime/pull/2169
And due to it's change context it seems to be really connected with this even
though it should affect only OSX.
dmd --profile=gc and valgrind tools doesn't seems to lead anywhere.
What I've found after all is that it is unrelated to vibe-d (so I moved it
here).
If tried with for example pretty large botan library: dependency "botan"
version="~>1.12.10"
Resulted process memory (VmRSS) is much larger. So it seems to be some problem
with size of the included libraries and probably some memory fragmentation when
building the stacktrace?
It's ok in release build.
--
Re: shared - i need it to be useful
On Sat, Oct 20, 2018 at 9:45 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
>
> > class C {
> > void f();
> > void g() shared;
> > }
> >
> > void t1(shared C c) {
> > c.g; // ok
> > c.f; // error
> > }
> >
> > void t2(shared C c) {
> > c.g; // ok
> > c.f; // error
> > }
> >
> > auto c = new C();
> > spawn(, c);
> > spawn(, c);
> > c.f; // ok
> > c.g; // ok
>
> Those are not "ok". They're only "ok" under Manu's proposal so
> long as the author of C promises (via documentation) that that's
> indeed "ok". There can be no statically-enforced guarantees that
> those calls are "ok", or that issuing them in that order is "ok".
> Yet Manu keeps insisting that somehow there is.
I only insist that if you write a shared method, you promise that it
is threadsafe.
If f() undermines g() threadsafety, then **g() is NOT threadsafe**,
and you just write an invalid program.
You can write an invalid program in any imaginable number of ways;
that's just not an interesting discussion. An interesting discussion
is what we might to to help prevent writing such an invalid program...
I don't suggest here what we can do to statically encorce this, but I
suspect there does exist *some* options which may help, which can be
further developments.
What I also assert is that *this unsafe code is rare*... it exists
only at the bottom of the tooling stack, and anyone else using a
shared object will not do unsafe, and therefore will not be able to
create the problem. If you do unsafety anywhere near `shared`, you
should feel nervous. I'm trying to make a world where you aren't
*required* to do unsafety at every single interaction.
Understand: f() can only undermine g() promise of threadsafety **if
f() is not @safe**. Users won't create this situation accidentally,
they can only do it deliberately.
Re: shared - i need it to be useful
On Sat, Oct 20, 2018 at 2:05 AM Walter Bright via Digitalmars-d wrote: > > On 10/19/2018 11:18 PM, Manu wrote: > > The reason I ask is because, by my definition, if you have: > > int* a; > > shared(int)* b = a; > > > > While you have 2 numbers that address the same data, it is not actually > > aliased > > because only `a` can access it. > > They are aliased, by code that believes it is unshared, and code that believes > it is shared. This situation could only occur if you do unsafe code badly. Unlike today, where you must do unsafe code to do any interaction of any kind, you will be able to do fully-safe interaction with the stack of tooling. In that world, any unsafe code and *particularly* where it interacts with shared will be an obnoxious and scary code smell. If it was possible to interact with shared safely, it would be blindingly suspicious when people are likely to be shooting themselves in the foot. The situation you describe here is *exactly* what we have right now, and I'm trying to prevent that. > This is not going to work This is an unfair dismissal. Have you tried it? I have. Write me the rules in a patch that I can take for a drive and demonstrate what the stack looks like. > > Exclusively distinguishing shared and unshared data is not an interesting > > distinction if shared data has no access. > > Somehow, you still have to find a way to give the shared path access, through > a > gate or a cast or a lock or whatever. I'm not sure you've understood the proposal. This is the reason for the implicit conversion. It provides safe transition. That's why I'm so insistent on it. > And then it breaks, because two different > threads are accessing the same data each thinking that data is not shared. This can only occur if you deliberately violate your @safety, and then mess up. This is *exactly* the interaction prescribed to shared today. This is what I'm fixing by making a fully @safe path! I think you demonstrate here that you haven't understood the reason, or the semantics of my proposal. I'm not sure how to clarify it, what can I give you?
Re: shared - i need it to be useful
On Saturday, 20 October 2018 at 17:06:22 UTC, Stanislav Blinov wrote: On Saturday, 20 October 2018 at 16:48:05 UTC, Nicholas Wilson wrote: On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright wrote: by code that believes it is unshared you cannot `@safe`ly modify the memory through `b`, `a`'s view of the memory is unchanged in @safe code. And that's already a bug, because the language can't enforce threadsafe access through `a`, regardless of presence of `b`. Only the programmer can. access through `a` is through the owned reference threadsafety through a does't mean anything, all _other_ access must ensure that the are ordered correctly. and, code that believes it is shared. you cannot have non-atomic access though `b`, `b` has no @safe view of the memory, unless it is atomic (which by definition is synchronised). Synchronized with what? You still have `a`, which isn't `shared` and doesn't require any atomic access or synchronization. Synchronized w.r.t any writes to that memory, e.g. from `a`. At this point it doesn't matter if it's an int or a struct. Yes. As soon as you share `a`, you can't just pretend that reading or writing `a` is safe. You can if no-one else writes to it, which is the whole point of Manu's proposal. Perhaps it should be const shared instead of shared but still.
Re: shared - i need it to be useful
On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov
wrote:
On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
class C {
void f();
void g() shared;
}
void t1(shared C c) {
c.g; // ok
c.f; // error
}
void t2(shared C c) {
c.g; // ok
c.f; // error
}
auto c = new C();
spawn(, c); // line 20
spawn(, c); // line 21
c.f; // ok
c.g; // ok // line 23
Those are not "ok". They're only "ok" under Manu's proposal so
long as the author of C promises (via documentation) that
that's indeed "ok". There can be no statically-enforced
guarantees that those calls are "ok", or that issuing them in
that order is "ok". Yet Manu keeps insisting that somehow there
is.
Backing up a bit and making a few observations (after adding
imports and wrapping the bottom code in a function):
1. the code above currently does not compile, error messages are:
i. line 20 & 21: spawn fails to instantiate because c is not
shared
ii. line 23: shared method C.g is not callable using a
non-shared object
iii. the lines already marked // error
2. in order to fix 1.i, one must cast c to shared at the call
site, this is not @safe
3 fixing 1.ii requires doing `(cast(shared)c).g`, this is also
not @safe
4 fixing 1.iii fixing requires casting away shared, this is not
only not @safe, but also wrong. c is a class so one could try
locking it although I'm not sure what the implications are for
doing that when another thread owns the data, probably bad.
5 the current means of dealing with shared with lock and cast
away shared is also not @safe
6 under Manu's proposal reading and writing shared objects
results in compilation error
7 The static guarantees we have in the language are type safety
and @safe
8 under Manu's proposal to do anything one must call shared
functions on said object, this implies a "@trusted"
implementation at the bottom of the stack for ensuring thread
safety (atomics and lock + cast (assuming it is not wrong), other
sync primitives) that are not @safe, but not outright wrong
either.
The question then becomes: assuming the implementation _is_ @safe
type correct and thread safe etc., can the author of C provide
guarantees of @safe and type correctness? and can this guarantee
be free of false positives?
Currently the answer is no: the requirement to cast to and from
shared is un-@safe and that burden is on the user which means
that they must understand the inner workings of C to know it that
is the case.
Manu's proposal is slightly more interesting. shared becomes a
guarantee that accesses to that object will not race, assuming
that the @trusted implementation at the bottom of the stack are
correct. In the above if t1 and t2 took `const shared C` and `g`
was also const shared, then I think that it could.
Re: Shared - Another Thread
On Sat., 20 Oct. 2018, 7:00 am Stanislav Blinov via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On Saturday, 20 October 2018 at 02:09:56 UTC, Dominikus Dittes > Scherkl wrote: > > On Saturday, 20 October 2018 at 00:46:36 UTC, Nicholas Wilson > > wrote: > >> Mutable = value may change > >> const = I will not change the value > >> immutable = the value will not change > >> > >> unshared = I (well the current thread) owns the reference > >> shared = reference not owned, no unordered access, no > >> (unordered) writes > >> threadsafe = ??? > > unshared = the current thread owns the reference > > threadsafe = I guarantee no race conditions or deadlocks will > > occur > > shared = every thread may have references > > Exactly, "thredsafe" in nothing more than a contract between > programmers. > When you have "const" data, it is trivial for the compiler to > enforce that: it just doesn't allow you to mutate it. But the > compiler cannot reason about whether your logic is "threadsafe" > or not, there can be no static enforcement of "thread-safety". It > only holds as an implicit contract between programmers: the > authors of data and functions, and the users of that data and > functions, i.e. the API and the callers. > Only at the level of the trusted functions. It is *very* easy to write a correct Atomic implementation. Queues and stuff are well understood and have great reference implementations. If you don't write @trusted functions (most wouldn't!), then you can't mess up. >
Re: shared - i need it to be useful
On Saturday, 20 October 2018 at 16:48:05 UTC, Nicholas Wilson wrote: On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright wrote: On 10/19/2018 11:18 PM, Manu wrote: The reason I ask is because, by my definition, if you have: int* a; shared(int)* b = a; While you have 2 numbers that address the same data, it is not actually aliased because only `a` can access it. They are aliased, Quoting Wikipedia: two pointers A and B which have the same value, then the name A[0] aliases the name B[0]. In this case we say the pointers A and B alias each other. Note that the concept of pointer aliasing is not very well-defined – two pointers A and B may or may not alias each other, depending on what operations are performed in the function using A and B. In this case given the above: `a[0]` does not alias `b[0]` because `b[0]` is ill defined under Manu's proposal, because the memory referenced by `a` is not reachable through `b` because you can't read or write through `b`. by code that believes it is unshared you cannot `@safe`ly modify the memory through `b`, `a`'s view of the memory is unchanged in @safe code. And that's already a bug, because the language can't enforce threadsafe access through `a`, regardless of presence of `b`. Only the programmer can. and, code that believes it is shared. you cannot have non-atomic access though `b`, `b` has no @safe view of the memory, unless it is atomic (which by definition is synchronised). Synchronized with what? You still have `a`, which isn't `shared` and doesn't require any atomic access or synchronization. At this point it doesn't matter if it's an int or a struct. As soon as you share `a`, you can't just pretend that reading or writing `a` is safe. Encapsulate it all you want, safety only remains a contract of convention, the language can't enforce it.
Re: shared - i need it to be useful
On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright wrote: On 10/19/2018 11:18 PM, Manu wrote: The reason I ask is because, by my definition, if you have: int* a; shared(int)* b = a; While you have 2 numbers that address the same data, it is not actually aliased because only `a` can access it. They are aliased, Quoting Wikipedia: two pointers A and B which have the same value, then the name A[0] aliases the name B[0]. In this case we say the pointers A and B alias each other. Note that the concept of pointer aliasing is not very well-defined – two pointers A and B may or may not alias each other, depending on what operations are performed in the function using A and B. In this case given the above: `a[0]` does not alias `b[0]` because `b[0]` is ill defined under Manu's proposal, because the memory referenced by `a` is not reachable through `b` because you can't read or write through `b`. by code that believes it is unshared you cannot `@safe`ly modify the memory through `b`, `a`'s view of the memory is unchanged in @safe code. and, code that believes it is shared. you cannot have non-atomic access though `b`, `b` has no @safe view of the memory, unless it is atomic (which by definition is synchronised). This is not going to work. Aú contraire.
Re: shared - i need it to be useful
On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
class C {
void f();
void g() shared;
}
void t1(shared C c) {
c.g; // ok
c.f; // error
}
void t2(shared C c) {
c.g; // ok
c.f; // error
}
auto c = new C();
spawn(, c);
spawn(, c);
c.f; // ok
c.g; // ok
Those are not "ok". They're only "ok" under Manu's proposal so
long as the author of C promises (via documentation) that that's
indeed "ok". There can be no statically-enforced guarantees that
those calls are "ok", or that issuing them in that order is "ok".
Yet Manu keeps insisting that somehow there is.
[Issue 7006] std.math.pow (integral, integral) crashes on negative exponents
https://issues.dlang.org/show_bug.cgi?id=7006 Cristian Creteanu changed: What|Removed |Added CC||cristiancretean...@gmail.co ||m --- Comment #5 from Cristian Creteanu --- I provided a fix for the issue. However, I noticed that the return type of the function is an integer, which will make it impossible to have results different from 0 or 1 for negative exponents (2 to -2 is 0.5, but pow will return 0; 1 will be returned for powers of 1, of course). I believe that pow, no matter the arguments that are provided to it, should always return a floating point number. --
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 10:28:47 UTC, Gregor Mückl wrote: On Saturday, 20 October 2018 at 09:25:58 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Gtk is clearly working on Windows from a technical point of view. Gimp on Windows is proof of that. But the look and feel are too different from what Windows users expect in my eyes and I did have a few unpleasant experiences with Gtk in the past. So I personally do not have any real desire to use it. My encounters with Qt were more involved and generally very pleasant and successful. I want to stress that this is only my personal view that I arrived at over the years. Any bias in it is purely mine. Qt appears to be C++ battering ram against all other languages other than Python. Go has failed to get a really good binding, except perhaps to QML. D has failed to get a really good binding to Qt or QML. I guess I should check out the Rust binding, except that I am in the gtk-rs and gstreamer-rs camp these days on all things GUI. Qt did have very good bindings to Java in the form of Qt Jambi, which was commercially developed back in the day by (then) Trolltech. Unfortunately for me, they killed that product off just as it reached 1.0. But a lot of the generator code was reused for PySide which was started around that time. Qt really depends on the code generated by the moc preprocessor. Even though the generated code is not really all that complicated, filling in the same gaps in bindings for other languages is quite hard. I think that Python has such good bindings only because both PyQt and PySide were commercially backed from the start. I can't think of any other currently maintained language bindings that have that luxury. Even though web and mobile UIs seem to be the rage at the moment, I believe a solid support for desktop UIs is very important for a general purpose language, if it wants to be successful in the market. D could be well suited for various kinds of applications in that area, especially those that have complex logic with some really performance critical parts and require rich user interfaces. Productivity, CAD, DCC and data processing/visualization would probably be among the extreme categories here. D has always had an excellent story in the "connect to C linkage libraries", has any of the work in D on C++ linkage over the last few years changed the landscape so that a D binding for Qt and QML could be as good as the GtkD binding is to GTK+? […] Excellent question! All I know is that Binderoo and dpp are two WIP projects that want to make binding to C++ easier. The authors are active in the forum, aren't they? It turns out that translating C++ is *hard*. Partly because the language is huge and complicated, but also partly because libclang isn't all it's cracked up to be. But... dpp is probably a few full work days away from being to #include . Hopefully with the translation actually working. The namespace hack Walter suggested doesn't work in practice, but now that extern(C++, "ns") is a thing I just need to massively refactor the code and use that instead. I've also realised that there are parts of C++ that are probably unstranslatable no matter what I do. Hopefully a pragmatic "you can #include but you can't use std::is_reference from "* approach will let us call enough of C++ in practice. Right now I'm blacklisting several things in ... Atila * std::is_reference is untranslatable: there are no reference types in D. It's likely to get used with SFINAE, and while that is translatable by hand, I have no idea how I'd write an algorithm to figure out SFINAE when it happens and translate that to template constraints in D.
[Issue 19321] New: Unions "may not" have fields with destructors
https://issues.dlang.org/show_bug.cgi?id=19321 Issue ID: 19321 Summary: Unions "may not" have fields with destructors Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: stanislav.bli...@gmail.com The spec (https://dlang.org/spec/struct.html#struct-destructor) says: "2. Unions may not have fields that have destructors." That's not true anymore, e.g. see https://issues.dlang.org/show_bug.cgi?id=16104 https://github.com/dlang/dmd/pull/5830 Perhaps, a better way to describe this in the spec is in order? E.g.: "2. Destructors are not automatically called for union fields. If destruction is desired, it must be explicit. For example, by adding a call `u.field.__xdtor`." Or just excise that entry altogether? --
Re: shared - i need it to be useful
On Saturday, 20 October 2018 at 09:04:17 UTC, Walter Bright wrote:
Somehow, you still have to find a way to give the shared path
access, through a gate or a cast or a lock or whatever. And
then it breaks, because two different threads are accessing the
same data each thinking that data is not shared.
When you say that, then under Manu's proposal and the code below:
class C {
void f();
void g() shared;
}
void t1(shared C c) {
c.g; // ok
c.f; // error
}
void t2(shared C c) {
c.g; // ok
c.f; // error
}
auto c = new C();
spawn(, c);
spawn(, c);
c.f; // ok
c.g; // ok
Do you mean the implementation of C.g? Since that is shared
wouldn't that just be a normal understanding that you'd need to
synchronize the data access in shared since it's a shared method?
And if you mean C.f, then if that accessed data (that was
accessed by C.g) unsafely, then that's just a bad implementation
no? Or?
Cheers,
- Ali
[Issue 19317] dip1008 doesn't call the throwable's destructor in _d_delThrowable
https://issues.dlang.org/show_bug.cgi?id=19317 --- Comment #2 from Nicholas Wilson --- Hmm, the actual problem seems to be that _d_delThrowable takes a Throwable [1] (N.B: not the most derived type) and after checking its not null, is ref counted, and `GC.removeRange(t);`ing if necessary, proceeds to call rt_finalize on it[2], which recursively calls the destructors of t and is parent classes (i.e. Throwable and Object) but misses any derived destructors. [1]: https://github.com/dlang/druntime/blob/master/src/rt/ehalloc.d#L76 [2]: https://github.com/dlang/druntime/blob/master/src/rt/ehalloc.d#L114 --
Re: Truly @nogc Exceptions?
On Saturday, 20 October 2018 at 14:56:37 UTC, Mike Parker wrote: On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi wrote: If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`... But I admit that that change would be controversial... https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md Yep, you are right, of course... 8-/ /P
Re: Building GUI projects with D
On Saturday, 20 October 2018 at 15:40:07 UTC, karis njiru wrote: Hi. Am a computer science student from Kenya and decided to use D for my class project on Principles of Programming Languages. Am having a lot of fun with D but have come across an issue. I have been using Visual D for the past 2 months for my coding but after a lot of research i found out that i cannot build GUI projects with visual D. So i took on Entice Designer which for the past week has been a nightmare for me to compile my code error being the system cannot find the path in the command prompt specified. I have installed DMD and DFL lots of times but there is still the same issue. Please help DFL is quite old and unmaintained since a long time too. So it's not surprising you have lots of errors when you try to build it with recent compilers. However, there are other GUI projects available for D, as you can see here [1] In this list you can try few of them, but keep in mind some might still have similar problems (DFL is still listed on this list). Maybe you can give a try to dlangui[2] [1] https://wiki.dlang.org/GUI_Libraries [2] https://github.com/buggins/dlangui
Building GUI projects with D
Hi. Am a computer science student from Kenya and decided to use D for my class project on Principles of Programming Languages. Am having a lot of fun with D but have come across an issue. I have been using Visual D for the past 2 months for my coding but after a lot of research i found out that i cannot build GUI projects with visual D. So i took on Entice Designer which for the past week has been a nightmare for me to compile my code error being the system cannot find the path in the command prompt specified. I have installed DMD and DFL lots of times but there is still the same issue. Please help
[Issue 15710] Replacement for std.utf.validate which does not throw
https://issues.dlang.org/show_bug.cgi?id=15710 Ioana Stefan changed: What|Removed |Added Status|NEW |ASSIGNED CC||ioana...@yahoo.com --
[Issue 18929] std.range.chain with single elements too
https://issues.dlang.org/show_bug.cgi?id=18929 Tiberiu Lepadatu changed: What|Removed |Added CC||tiberiulepadat...@gmail.com --- Comment #2 from Tiberiu Lepadatu --- Can I work on this? --
Re: More zero-initialization optimizations pending in std.experimental.allocator?
On Saturday, 20 October 2018 at 15:10:38 UTC, Nathan S. wrote:
Other opportunities would rely on being able to identify if
it's ever more efficient to write `memset(, 0,
typeof(x).sizeof)` instead of `x = typeof(x).init` which seems
like the kind of optimization that belongs in the compiler
instead.
Not unless `mem{set, cpy, move}` etc. are made into compiler
intrinsics. Carrying libc dependencies into low-level sensitive
code just stinks. If anything, the `memcpy` calls should be
removed from `moveEmplace`, not `memset` calls added to it.
They're also not CTFE-able.
Re: More zero-initialization optimizations pending in std.experimental.allocator?
On Friday, 19 October 2018 at 21:29:42 UTC, Per Nordlöw wrote: Now that https://github.com/dlang/phobos/pull/6411 has been merged and DMD stable soon has the new __traits(isZeroInit, T) found here https://dlang.org/changelog/2.083.0.html#isZeroInit are there more zero-initializations that can be optimized in std.experimental.allocator? I looked and identified low-hanging fruit in std.mutation.initializeAll & moveEmplace and in std.typecons.RefCounted (PR #6698), and in std.conv.emplaceInitializer (PR #6461). Other opportunities would rely on being able to identify if it's ever more efficient to write `memset(, 0, typeof(x).sizeof)` instead of `x = typeof(x).init` which seems like the kind of optimization that belongs in the compiler instead.
Re: D Binding to GUI libraries
On Saturday, 20 October 2018 at 14:24:56 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 12:43 +, tide via Digitalmars-d wrote: […] I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right. I do not disagree, especially about GTK+ not really being available on Windows and macOS, it is fundamentally a Linux and UNIX framework – I think we can ignore the fact that macOS is sort of FreeBSD in this circumstance due to macOS. I'd agree Qt is a much better cross-platform GUI framework that GTK+. I've use it with Python very successfully – originally with PySide, then PyQt, but now back with PySide2. I tried QML with Go to move to native code from Python, but it didn't really work for me as yet, though some people gave me a few tips a few weeks back that I haven't followed up on as yet. wxWidgets seems still to be going though and wxPython is rising as a phoenix . I haven't really used them though but maybe the latest version is worth a whirl. I guess people doing Qt stuff really do work with C++ if they don't work with Python? I'd call this an opportunity for D. The trick has to be to automate the creation of the binding. I have to admit I do not know what the technique is for PySide2 but PyQt certainly has a system for generation of the binding. Of course, Rust https://github.com/rust-qt As a company that will be hosted in the QT booth at SPS IPC Drives 2018 in Nuremberg at the end of November, C++ dominates. We are calling a little D codebase from a QT application, but just to leverage some legacy old code. I've used PySide, years ago, but nowadays the performance of the C++ compilers, and the agility of QT Creator are closing the bridge for a fast edit/compile/test cycle... the big advantage of PySide is the tremendous amount of python libraries that you can use in your application. Said that, we are using QML, but I don't love it a lot... - Paolo
Re: Truly @nogc Exceptions?
On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi wrote: If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`... But I admit that that change would be controversial... https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md
Re: D Binding to GUI libraries
On Sat, 2018-10-20 at 12:43 +, tide via Digitalmars-d wrote: > […] > I mean it *may* work, but that isn't the problem if the > developers completely lack support for the platform. I can > download Qt with prebuilt libraries and it works out of the box > with MSVC. There's an obvious difference between the two > developers support. As someone else said GTK look like ass on > Windows, Qt is really the only crossplatform GUI API written in a > native-compile-able language out there that gets most things > right. I do not disagree, especially about GTK+ not really being available on Windows and macOS, it is fundamentally a Linux and UNIX framework – I think we can ignore the fact that macOS is sort of FreeBSD in this circumstance due to macOS. I'd agree Qt is a much better cross-platform GUI framework that GTK+. I've use it with Python very successfully – originally with PySide, then PyQt, but now back with PySide2. I tried QML with Go to move to native code from Python, but it didn't really work for me as yet, though some people gave me a few tips a few weeks back that I haven't followed up on as yet. wxWidgets seems still to be going though and wxPython is rising as a phoenix . I haven't really used them though but maybe the latest version is worth a whirl. I guess people doing Qt stuff really do work with C++ if they don't work with Python? I'd call this an opportunity for D. The trick has to be to automate the creation of the binding. I have to admit I do not know what the technique is for PySide2 but PyQt certainly has a system for generation of the binding. Of course, Rust https://github.com/rust-qt -- 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: Shared - Another Thread
On Saturday, 20 October 2018 at 02:09:56 UTC, Dominikus Dittes Scherkl wrote: On Saturday, 20 October 2018 at 00:46:36 UTC, Nicholas Wilson wrote: Mutable = value may change const = I will not change the value immutable = the value will not change unshared = I (well the current thread) owns the reference shared = reference not owned, no unordered access, no (unordered) writes threadsafe = ??? unshared = the current thread owns the reference threadsafe = I guarantee no race conditions or deadlocks will occur shared = every thread may have references Exactly, "thredsafe" in nothing more than a contract between programmers. When you have "const" data, it is trivial for the compiler to enforce that: it just doesn't allow you to mutate it. But the compiler cannot reason about whether your logic is "threadsafe" or not, there can be no static enforcement of "thread-safety". It only holds as an implicit contract between programmers: the authors of data and functions, and the users of that data and functions, i.e. the API and the callers.
Re: Truly @nogc Exceptions?
On Thursday, 20 September 2018 at 17:14:12 UTC, Steven Schveighoffer wrote: On 9/20/18 12:24 PM, Adam D. Ruppe wrote: On Thursday, 20 September 2018 at 15:52:03 UTC, Steven Schveighoffer wrote: I needed to know what the slice parameters that were failing were. Aye. Note that RangeError is called by the compiler though, so you gotta patch dmd to make it pass the arguments to it for index. Ugh. I did a PR for this once but it got shot down because of an allegeded (without evidence btw) performance degradation. Ugh. Well, you can always override that. Just do the check yourself and throw the error you want ;) In my case, that's what I did anyway. I don't know how a performance problem can occur on an error being thrown anyway -- the process is about to end. -Steve If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`... But I admit that that change would be controversial... - Paolo
[Issue 19320] New: Unittest error: Variable used before set in std/array.d
https://issues.dlang.org/show_bug.cgi?id=19320 Issue ID: 19320 Summary: Unittest error: Variable used before set in std/array.d Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: ioana...@yahoo.com When building the unittest with this command: make -f posix.mak std/array.test I encountered the following error: std/array.d(4179): Error: variable theArray used before set When building the unittest for the entire hierarchy with this command: make -f posix.mak -j8 unittest I did not encounter the error and all the tests passed. --
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Friday, 19 October 2018 at 03:53:12 UTC, Walter Bright wrote: On 10/15/2018 2:23 PM, Walter Bright wrote: I'm giving a presentation at: http://nwcpp.org/ See you there! Had a nice crowd there last night. Apparently lots of people were interested in this topic! Video: https://www.youtube.com/watch?v=lbp6vwdnE0k=youtu.be Slides: http://nwcpp.org/talks/2018/code_smells.pdf https://www.youtube.com/watch?v=lbp6vwdnE0k#t=42m01s Or it's a pain in the ass to try to get more than one pull request merged in due to lack of overseers. It's hard enough trying to get one pull request merged in, but trying to split one pull request into 4 and then try to micro manage it so that they are merged in order as the changes depend on each other (eg spelling error for a function). That becomes a nightmare when you don't have merging permission for a repo, especially for something like DMD where it's hard enough to get even a simple fix through the door.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 09:25:58 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Last time I tried to use GTK on windows I had to build i from source myself, from the looks of it that hasn't changed. It has a huge dependency list, and some of those dependencies have their own dependencies. They all have to be built their own different way on Windows. It's a pain in the ass to do, i tried and didn't bother after trying to compile cairo or whatever. Kind of odd they don't have any sort of build script, I guess they just use Mingw which not very many people use. It may work on Windows, but the amount of effort to set it up is not worth it at all. The developers of the library obviously don't care enough either to try to reduce that barrier. Why not provide a built shared library? Something tells me they haven't even bothered to compile it with MSVC themselves. Their guide to build with MSVC links to a 3+ year old Gnome article where someone not even affiliated with GTK wrote a powershell script to build it with MSVC. The other links to an article that is still using VS 2010 and 2008 for the build. I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right.
Re: BindBC -- The successor to Derelict
On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote: I plan to port the more used Derelict bindings over the course of the next few weeks. I've got another massive project I'm working on that will make use of some of the BindBC packages, so I'll be focusing first on the ones I need for that. Unfortunately it's unlikely I will have the time to port: - DerelictBgfx - DerelictENet - DerelictCUDA to BindBC so they are also in limited maintenance mode. So I'm looking for someone to take ownership of those libraries! BindBC is great news regardless for those of us without runtime or in -betterC! We use a derelict-util fork to this effect until now.
[Issue 19319] New: No line number when std.math is missing for x ^^ y
https://issues.dlang.org/show_bug.cgi?id=19319 Issue ID: 19319 Summary: No line number when std.math is missing for x ^^ y Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ibuc...@gdcproject.org Something like: --- __gshared x = 0; auto y = 7 ^^ y; --- Will produce the error: Error: module `math` is in file 'std/math.d' which cannot be read Specify path to file 'std/math.d' with -I switch Which is not very indicative of where compilation went wrong. See https://github.com/dlang/dmd/pull/8852 --
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 09:25:58 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Gtk is clearly working on Windows from a technical point of view. Gimp on Windows is proof of that. But the look and feel are too different from what Windows users expect in my eyes and I did have a few unpleasant experiences with Gtk in the past. So I personally do not have any real desire to use it. My encounters with Qt were more involved and generally very pleasant and successful. I want to stress that this is only my personal view that I arrived at over the years. Any bias in it is purely mine. Qt appears to be C++ battering ram against all other languages other than Python. Go has failed to get a really good binding, except perhaps to QML. D has failed to get a really good binding to Qt or QML. I guess I should check out the Rust binding, except that I am in the gtk-rs and gstreamer-rs camp these days on all things GUI. Qt did have very good bindings to Java in the form of Qt Jambi, which was commercially developed back in the day by (then) Trolltech. Unfortunately for me, they killed that product off just as it reached 1.0. But a lot of the generator code was reused for PySide which was started around that time. Qt really depends on the code generated by the moc preprocessor. Even though the generated code is not really all that complicated, filling in the same gaps in bindings for other languages is quite hard. I think that Python has such good bindings only because both PyQt and PySide were commercially backed from the start. I can't think of any other currently maintained language bindings that have that luxury. Even though web and mobile UIs seem to be the rage at the moment, I believe a solid support for desktop UIs is very important for a general purpose language, if it wants to be successful in the market. D could be well suited for various kinds of applications in that area, especially those that have complex logic with some really performance critical parts and require rich user interfaces. Productivity, CAD, DCC and data processing/visualization would probably be among the extreme categories here. D has always had an excellent story in the "connect to C linkage libraries", has any of the work in D on C++ linkage over the last few years changed the landscape so that a D binding for Qt and QML could be as good as the GtkD binding is to GTK+? […] Excellent question! All I know is that Binderoo and dpp are two WIP projects that want to make binding to C++ easier. The authors are active in the forum, aren't they?
Re: Need help with setting up LDC to cross-compile to Android/ARM
On Friday, 19 October 2018 at 22:19:31 UTC, H. S. Teoh wrote: On Fri, Oct 19, 2018 at 02:41:48PM -0700, H. S. Teoh via Digitalmars-d wrote: [...] In the meantime, is there a particular version of the NDK that I should use? Currently I have android-ndk-r13b-linux-x86_64.zip installed. Will it work? [...] Haha, I feel so silly now. NDK r13b does not seem to have the sysroot subdir required by the clang build command, that's why it couldn't find the system headers. So I ditched r13b and installed r17b instead, and now I can build the runtime successfully! Ah, that makes sense, that NDK is ancient, ;) it came out two years ago: https://developer.android.com/ndk/downloads/revision_history Official D support for Android was added to ldc 1.4 last September, which was after NDK r15c came out, when they switched to that sysroot directory with unified headers for all Android versions, so that's what ldc uses. Before that, each Android version had its headers in a separate directory, which isn't supported by LDC. I tried ldc-build-runtime with --ninja and it came back with a bunch of errors about "cortex-a8" being an unsupported target, and then segfaulted. That's likely because you left off the double-quotes around the list of semicolon-separated flags passed to ldc-build-runtime --dFlags: the double quotes are required, as shown in the docs. On Saturday, 20 October 2018 at 04:01:37 UTC, H. S. Teoh wrote: On Fri, Oct 19, 2018 at 08:50:36PM +, Joakim via Digitalmars-d wrote: On Wednesday, 17 October 2018 at 21:23:21 UTC, H. S. Teoh wrote: > I'm trying to follow the instructions on this page: > > https://wiki.dlang.org/Build_D_for_Android [...] On a side note, the last section on that page mentions not knowing how to create a keystore from scratch; actually, it's very simple with the `keytool` utility that comes with the Oracle JRE. I added the steps on the talk page. The only thing I'm unsure about is whether keytool is available natively on Android. If not, then you'll have to generate the keystore on a PC and copy it over to Android afterwards. From scratch meaning without using keytool, ie OpenSSL or some other hashing/fingerprinting tool alone, because keytool isn't available in the Termux app. As mentioned at the end of the wiki page, I used to manually edit the apk hashed manifests using OpenSSL alone until that apksigner tool was added later.
Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: > […] > I periodically look at how I can make use of D for small > projects. Most often, I shy away because I want to build a GUI > and none of the libraries that I can find look mature and well > maintained enough to put my faith in. For C++ there's Qt, which > is *phenomenally* good (despite some warts), but there's been at > least half a dozen attempts at creating D bindings for that, all > in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Qt appears to be C++ battering ram against all other languages other than Python. Go has failed to get a really good binding, except perhaps to QML. D has failed to get a really good binding to Qt or QML. I guess I should check out the Rust binding, except that I am in the gtk-rs and gstreamer-rs camp these days on all things GUI. D has always had an excellent story in the "connect to C linkage libraries", has any of the work in D on C++ linkage over the last few years changed the landscape so that a D binding for Qt and QML could be as good as the GtkD binding is to GTK+? […] -- 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
[Issue 19318] New: Variables captured from outer functions not visible in debugger
https://issues.dlang.org/show_bug.cgi?id=19318
Issue ID: 19318
Summary: Variables captured from outer functions not visible in
debugger
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Keywords: symdeb
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
int fun() @nogc
{
int x;
auto foo() scope
{
int nested()
{
return x;
}
return nested();
}
return foo();
}
Variable 'x' is not visible in the debugger when stepping through 'foo' or
'nested'. Instead, only an opaque 'void* this' is shown.
--
Re: shared - i need it to be useful
On 10/19/2018 11:18 PM, Manu wrote: The reason I ask is because, by my definition, if you have: int* a; shared(int)* b = a; While you have 2 numbers that address the same data, it is not actually aliased because only `a` can access it. They are aliased, by code that believes it is unshared, and code that believes it is shared. This is not going to work. Exclusively distinguishing shared and unshared data is not an interesting distinction if shared data has no access. Somehow, you still have to find a way to give the shared path access, through a gate or a cast or a lock or whatever. And then it breaks, because two different threads are accessing the same data each thinking that data is not shared.
Re: Interesting Observation from JAXLondon
On Friday, 12 October 2018 at 10:27:53 UTC, Peter Alexander wrote: As long as D continues to be a nice language to work in for hobbyists, there will always be potential for a killer use case to come along. D just needs to make sure it doesn't piss off its fans. vibe.d happened because a single person was a fan of D. You don't need a lot of marketing for that to happen. Maybe vibe.d hasn't been the killer app for D, but the next thing might be, so you just need fans. I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. I think that there is just no good story for D on the graphical desktop. The language would be well suited for bread and butter CRUD applications with desktop UIs and similar boring stories. These things get made, but mostly in complete isolation behind company walls. This is a kind of market that is willing to pay good money if you have a believable story about how to develop large amounts of boring, moderately complex logic with drab cookie-cutter user interfaces *quickly*. D is far from having that story. Almost all successful languages offer good solutions. A lot of other library bindings to existing stand-out libraries are the same as the Qt bindings (with the Derelict set of bindings being a noteworthy exception!). It's a chicken and egg problem to some extent. I would want to use D to get my project done fast. But the prospect of missing or incomplete/buggy bindings consistently turns me off. I freely admit that I don't want to mess with that kind of stuff - it's really, really boring work to maintain bindings and I feel that I can put my time to use on more interesting things. Certainly, I'm not the only one who thinks that way. But on the other hand, libraries thrive best when they have a large set of dependent projects that puts them through their paces. Also, it seems to me that many library maintainers get more motivated if they see their libraries being picked up and used actively by others. Looking back at the last ~25 years, it seems to me that the programming language market has actually been very stable or stagnant. C++ and Perl were introduced in the 90s, Java, JS, PHP and Python in the 90s, C# is one of the youngest of the big programming languages with its release in the early 2000s. Newer languages have had to stay at the sidelines for very long. The only serious new contenders are Go (Google), Rust (Mozilla) and Swift (Apple). All three of them needed a big push from a wealthy company to get where they are today and they are still in niches. Part of the stagnation is certainly because heaps of existing code that work and cannot just be thrown away and rewritten. But how big is this effect really?
Re: Shared - Another Thread
On Sat., 20 Oct. 2018, 12:10 am Dominikus Dittes Scherkl via Digitalmars-d, wrote: > On Saturday, 20 October 2018 at 06:04:45 UTC, Manu wrote: > > How can you find that such a construct carries its weight with > > respect > > to its rare-ness, when its usefulness is very limited to begin > > with? > > I suggested it only because of the resistance to the proposed > implicit cast to shared. But I agree - a cast from mutable to > immutable could also be implicit, and would rarely cause any > problems. Still, I'm sure you would face equally strong > resistance against that. > If an implicit cast from mutable to immutable existed, then immutable would just be const ;) >
Re: Shared - Another Thread
On Sat., 20 Oct. 2018, 12:10 am Dominikus Dittes Scherkl via Digitalmars-d, wrote: > On Saturday, 20 October 2018 at 06:04:45 UTC, Manu wrote: > > How can you find that such a construct carries its weight with > > respect > > to its rare-ness, when its usefulness is very limited to begin > > with? > > I suggested it only because of the resistance to the proposed > implicit cast to shared. But I agree - a cast from mutable to > immutable could also be implicit, and would rarely cause any > problems. Still, I'm sure you would face equally strong > resistance against that. > It is necessary. My dream of a @safe shared is immaterial without that single important detail. I can't make use of shared without it, at least, not safely, and then we might as well all just pack up and go home. >
Re: Shared - Another Thread
On Saturday, 20 October 2018 at 06:04:45 UTC, Manu wrote: How can you find that such a construct carries its weight with respect to its rare-ness, when its usefulness is very limited to begin with? I suggested it only because of the resistance to the proposed implicit cast to shared. But I agree - a cast from mutable to immutable could also be implicit, and would rarely cause any problems. Still, I'm sure you would face equally strong resistance against that.
Re: shared - i need it to be useful
On Fri, Oct 19, 2018 at 9:45 AM Steven Schveighoffer via Digitalmars-d
wrote:
>
> On 10/18/18 9:09 PM, Manu wrote:
> > On Thu, Oct 18, 2018 at 5:30 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 18.10.18 23:34, Erik van Velzen wrote:
> >>> If you have an object which can be used in both a thread-safe and a
> >>> thread-unsafe way that's a bug or code smell.
> >>
> >> Then why do you not just make all members shared? Because with Manu's
> >> proposal, as soon as you have a shared method, all members effectively
> >> become shared.
> >
> > No they don't, only facets that overlap with the shared method.
> > I tried to present an example before:
> >
> > struct Threadsafe
> > {
> >int x;
> >Atomic!int y;
> >void foo() shared { ++y; } // <- shared interaction only affects 'y'
> >void bar() { ++x; ++y; } // <- not threadsafe, but does not violate
> > foo's commitment; only interaction with 'y' has any commitment
> > associated with it
> >void unrelated() { ++x; } // <- no responsibilities are transposed
> > here, you can continue to do whatever you like throughout the class
> > where 'y' is not concerned
> > }
> >
> > In practise, and in my direct experience, classes tend to have exactly
> > one 'y', and either zero (pure utility), or many such 'x' members.
> > Threadsafe API interacts with 'y', and the rest is just normal
> > thread-local methods which interact with all members thread-locally,
> > and may also interact with 'y' while not violating any threadsafety
> > commitments.
>
> I promised I wouldn't respond, I'm going to break that (obviously).
>
> But that's because after reading this description I ACTUALLY understand
> what you are looking for.
>
> I'm going to write a fuller post later, but I can't right now. But the
> critical thing here is, you want a system where you can divvy up a type
> into pieces you share and pieces you don't. But then you *don't* want to
> have to share only the shared pieces. You want to share the whole thing
> and be sure that it can't access your unshared pieces.
>
> This critical requirement makes things a bit more interesting. For the
> record, the most difficult thing to reaching this understanding was that
> whenever I proposed anything, your answer was something like 'I just
> can't work with that', and when I asked why, you said 'because it's
> useless', etc. Fully explaining this point is very key to understanding
> your thinking.
>
> To be continued...
I'm glad that there's movement here... but I'm still not 100%
convinced you understood me; perhaps getting close though.
I only say that because your description above has a whole lot more
words and complexity than is required to express my proposal. If you
perceive that complexity in structural terms, then I am still not
clearly understood.
> "divvy up a type into pieces"
This is an odd mental model of what I'm saying, and I can't sympathise
with those words, but if they work for you, and we agree on the
semantics, then sure...
If you write an object with some const methods and some non-const
methods, then take a const instance of the object... you can only call
the const methods. Have you 'divvied up the type' into a const portion
and a non-const portion? If the answer is yes, then I can accept your
description.
I would talk in terms of restriction:
An object has 4 functions, 2 are mutable, 2 are const... you apply
const to the type and you are *restricted* to only calling the 2 const
functions.
An object has 4 functions, 2 are unsahred, 2 are shared... you apply
shared to the type and you are *restricted* to only calling the 2
shared (threadsafe) functions.
I haven't 'broken the type up', I'm just restricting what you can do
to it from within a particular context. In the const context, you
can't mutate it. In the shared context, you can't do un-threadsafe to
it, and the guarantee of that is embedded in the rules:
1. shared data can not be read or written
2. shared methods must be threadsafe
a. this may require that they be @trusted at the low-level, like the
methods of `Atomic(T)`
b. no other method may violate the shared method's promise,
otherwise it does not actually deliver its promise
i. I have extensive experience with this and it's just not a
problem in practise, but compiler technology to assist would be
welcome!
ii. This does NOT mean the not-shared methods are somehow shared;
they just need to be careful when interacting with some (usually
small) subset of members
This design implies strong encapsulation, but that's a naturally
occurring tendency implementing anything that's threadsafe.
As a helpful best-practise to assure that non-shared methods don't
undermine a shared method's commitment; prefer to interact with
volatile members via accessors or properties that are themselves
shared (can be private if you like).
You will find that it's not actually hard to deliver on the object's commitment.
If you write tooling that is at the level one-up from the
Re: shared - i need it to be useful
On Fri., 19 Oct. 2018, 3:10 am Walter Bright via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On 10/17/2018 12:20 AM, Manu wrote: > > What does it mean 'aliased' precisely? > > Aliasing means there are two paths to the same piece of data. That could > be two > pointers pointing to the same data, or one pointer to a variable that is > accessible by name. > The reason I ask is because, by my definition, if you have: int* a; shared(int)* b = a; While you have 2 numbers that address the same data, it is not actually aliased because only `a` can access it. It is not aliased in any practical sense. > It doesn't really give us > > anything in practice that we don't have in C++. > > It provides a standard, enforced way to distinguish shared data from > unshared > data, and no way to bypass it in @safe code. There's no way to do that in > C++. > Right, but we can do so much better. I want shared to model "what is thread-@safe to do", because that models what you are able to do, and what API's should encourage when operating on `shared` things. Exclusively distinguishing shared and unshared data is not an interesting distinction if shared data has no access. I've been trying to say over and over; ignore what you think you know about that definition, accept my rules strictly as given (they're very simple and concise, there's only 2 rules), such that shared will mean "is threadsafe to call with this data" when applied to function args... Build the thought experiment outward from there. That's an interesting and useful definition for shared, and it leads to a framework where shared is useful in a fully @safe SMP program, and even models @safe transitions across unshared -> shared boundaries (parallel for, map/reduce, etc, fork and join style workloads), which are typical lock-free patterns. Lock-and-cast semantics are preserved unchanged for those that interact in the way shared is prescribed today, but strictly modeling that workflow is uninteresting, because it's unsafe by definition. I'm not losing that, but I'm trying to introduce a safe workflow that exists in complement, and my model works. I don't even know if we have a mutex defined in our codebase, we don't use them... but we can max out a 64core thread ripper. >
Re: Shared - Another Thread
On Fri, Oct 19, 2018 at 5:05 PM Dominikus Dittes Scherkl via Digitalmars-d wrote: > > Therefore it is possible to implicitly cast from mutable or > immutable to const but not in any other direction. > > I think for unshared, shared and threadsave it should be the same: > The second is a declaration attribute, the third a parameter > attribute. I certainly had this thought... if you take a purist point of view, it sounds reasonable. BUT, I think it's a bad choice for practical reasons: 1. Adding a new attribute is heavy handed. 2. It's also unnecessary; the one that would be analogous to immutable is not actually very interesting. At best, it offers the potential for a small number of optimisations, which can be accessed without it. 3. Threadsafety carries a VERY small surface area in the language and in code in general... we don't need to add a pile of machinery for this. Sure, immutable is kinda nice, but in strict terms, it's unnecessary... we could all get on without it. If immutable were removed from the language completely, it would barely affect me. We couldn't get on without const. The same applies here, we must have the const analogous one. Can't live without that. Consider the frequency of immutable to const in any code you've ever seen. This is a very real view of the relative usefulness of the 2 constructs. Now imagine the same comparison to shared... you hardly see shared at all to begin with; and the one analogous to immutable would be relatively so much more rare still. How can you find that such a construct carries its weight with respect to its rare-ness, when its usefulness is very limited to begin with?
