Re: Shared - Another Thread
On Fri, Oct 19, 2018 at 4:45 PM Dominikus Dittes Scherkl via Digitalmars-d wrote: > > On Friday, 19 October 2018 at 18:11:50 UTC, Manu wrote: > > On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via > > Digitalmars-d wrote: > >> > >> On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote: > >> > [...] What issues am I failing to address? > >> [...] Another point is the part of "how can the compiler > >> support the expert in writing threadsave methods" - which you > >> answered with "not a little bit at the moment, but we may > >> improve this in the future" - and that is not at all > >> satisfying. > > > > I think you've misunderstood. > > My proposal is @safe... if you stay @safe, you will receive > > guarantee that your code is threadsafe. > On user side, yes. > > If you want to implement a low-level device, you must implement > > a @trusted function, and I don't know what the compiler can do > > to help you. > Yes, but that's seldom. More often the "expert" will write new > shared types using the low level trusted functions like anybody > else. But that > still requires special care - he has to consider tread-safety in > every > method of a new type, even the non-shared ones. And he has to > fill any > possible gap like construction and assignment so that the > end-user is really sure to not accidentally misusing the type! > And I think a serious proposal need to address this - I think the > compiler could really help here (e.g. prescribe what operators > need to be overloaded and check that all methods use the proper > mechanisms to lock the shared members before operating on them > etc.) > > > So saying that my response that "there is @trusted code at the > > bottom of the stack" is not satisfying is really just a comment > > on your opinion about @trusted code in general. > That just comes on top of it. > > > My proposal is designed to be useful and @safe for *users* as > > primary goal. > I agree with you, but others seem not so convinced (yet?). > [...] > > The user has manually cast to unshared inside their > > unsafe/(@trusted?) function, what more signal do they need that > > they've engaged in an unsafe operation? > Some hints what to do to be able to trust them? > You asked what issues you were failing to address. That was just > some ideas of mine what you may address in addition. I understand. I don't have good ideas to add mechanical guarantees, other than something extremely likely to flag false-positives like "any `shared` piece of data involved in an unsafe cast in any function should look suspicious when accessed elsewhere within this module"...? I think this is an area for further development, but I don't think it's a barrier to making shared a useful @safe language construct with respect to the type safety. It is possible to define the typesafety rules correctly and then start writing experimental code. > More often the "expert" will write new > shared types using the low level trusted functions like anybody > else. But that > still requires special care - he has to consider tread-safety in > every > method of a new type, even the non-shared ones. This shouldn't be true unless they're writing new @trusted functions. If they're staying @safe, then there is nothing you can do to the lower-level utility that's not threadsafe, so you can freely use it throughout your new type. If this is true, then the @trusted function is not threadsafe as it promises. One thing I know is, your proposition above is unusual. In my experience among hundreds, perhaps thousands of colleagues, people don't just start presuming to write threadsafe tooling. We have 4-5 such threadsafe tools in our library, they are at the bottom of the stack, and would contain @trusted functions under my proposal... all other code just makes use of them (and quite extensive use of them!). People don't write new thredsafe machinery for fun, it's a very serious endeavour. The countless uses of those tools and the structure built on top should be @safely interactible, which is possible under my proposal.
Re: Need help with setting up LDC to cross-compile to Android/ARM
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. T -- Computers shouldn't beep through the keyhole.
[Issue 19317] dip1008 doesn't call the throwable's destructor in _d_delThrowable
https://issues.dlang.org/show_bug.cgi?id=19317 Nicholas Wilson changed: What|Removed |Added CC||iamthewilsona...@hotmail.co ||m --- Comment #1 from Nicholas Wilson --- _d_delThrowable does call it https://github.com/dlang/druntime/blob/9a8edfb48e4842180c706ee26ebd8edb10be53f4/src/rt/ehalloc.d#L114 so this must be some compiler buggery that just free's it directly. --
Re: Shared - Another Thread
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
Re: Truly @nogc Exceptions?
On Friday, 19 October 2018 at 23:46:29 UTC, Nicholas Wilson wrote: On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote: On Thursday, 20 September 2018 at 12:48:13 UTC, Steven Schveighoffer wrote: How is the exception destroyed when dip1008 is enabled? Apparently, it isn't. Which renders dip1008 pretty much useless since we could already use static immutable exceptions before. Wow, that is useless! Is that an implementation bug or was that specified by the DIP? I hope it's a bug - I opened an issue: https://issues.dlang.org/show_bug.cgi?id=19317
Re: BindBC -- The successor to Derelict
On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote: In the 14.5 (!) years I've been maintaining the Derelict bindings, I've restructured the source tree a few times (Derelict 1 - 3 to DerelictOrg), had three implementations of the loader (that I can remember), switched from Subversion to Git, and supported a few different approaches to building (bud, dss, Visual D projects, a couple of custom scripts) before finally settling exclusively DUB. [...] Great Stuff! Thank you very much!
Re: Shared - Another Thread
On Saturday, 20 October 2018 at 00:00:49 UTC, Dominikus Dittes Scherkl wrote: Hmm. mutable, immutable and const form a triple, the second is a declaration attribute, the last an parameter attribute, indicating that you don't want to modify the parameter, may it be because you can't (as it is immutable) or you only don't need to despite it would be possible (if it was mutable). The later is your responsibility to guarantee (with the help from the compiler). 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. The first two can implicitly be cast to threadsave, may be because it is thread-local and therefore no race condition is possible, or may be because you take special care in your type to guarantee the thread safety by using atomic operations or locking or whatever. That make it possible, that the implicit cast from shared to unshared can be avoided while still providing functions that can take both kinds of arguments. Yes, that would add a little to the attribute bloat (new keyword) but not to the number of attributes per type or parameter. 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 = ???
Re: Shared - Another Thread
On Friday, 19 October 2018 at 15:46:20 UTC, Stanislav Blinov wrote: On Friday, 19 October 2018 at 13:40:54 UTC, Dominikus Dittes Scherkl wrote: Conflating "shared" and "threadsave" in that manner was, I think, the biggest mistake of your proposal. He talked about it in a previous thread, and generally I would agree with him that such conflation is indeed beneficial provided that some concessions are made for `shared`. Moreover, yet another attribute? Please no... Hmm. mutable, immutable and const form a triple, the second is a declaration attribute, the last an parameter attribute, indicating that you don't want to modify the parameter, may it be because you can't (as it is immutable) or you only don't need to despite it would be possible (if it was mutable). The later is your responsibility to guarantee (with the help from the compiler). 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. The first two can implicitly be cast to threadsave, may be because it is thread-local and therefore no race condition is possible, or may be because you take special care in your type to guarantee the thread safety by using atomic operations or locking or whatever. That make it possible, that the implicit cast from shared to unshared can be avoided while still providing functions that can take both kinds of arguments. Yes, that would add a little to the attribute bloat (new keyword) but not to the number of attributes per type or parameter.
Re: DMD Linker Issue on Windows
On Thursday, 18 October 2018 at 16:21:00 UTC, Kai wrote: On Thursday, 18 October 2018 at 07:51:07 UTC, Andre Pany wrote: On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote: On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe wrote: [...] Hmm - wish it was so. When architecture not specified, the linker crashes. When it's given, this happens (seems to be a vibe issue?): [...] As far as I can see, there are some Windows libraries missing. These libraries are part of the Windows sdk (You can use the vs build tools installer). Maybe we can include at least the libraries needed for vibe.d into the dmd Windows package? Kind regards Andre I have multiple incarnations of both libs on my machine. I copied the latest version of each into my the lib folder of the DMD install path and it still fails with neither of them being found. What am I doing wrong? Where do they need to go? Thanks for any help once more... Who knows what path it is using for libs, I don't know if it does for lld-link and the config file was removed almost entirely. It determines these things on it's own and I'm not sure if there is any way to display what it is actually using without looking through the source. Try using the "-v" argument with DMD and look for the command it uses to run the linker. There might be a parameter passed for library paths there. Those two files were removed since VS 2015 I think, so odds are that's why it can't find it. If it is using a newer VS install path.
Re: Truly @nogc Exceptions?
On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote: On Thursday, 20 September 2018 at 12:48:13 UTC, Steven Schveighoffer wrote: How is the exception destroyed when dip1008 is enabled? Apparently, it isn't. Which renders dip1008 pretty much useless since we could already use static immutable exceptions before. Wow, that is useless! Is that an implementation bug or was that specified by the DIP?
Re: Can opApply be made @nogc?
On Friday, 19 October 2018 at 23:32:44 UTC, solidstate1991 wrote: Since it's a bit difficult to make tree traversal through range (especially if someone wants to make it @nogc), I thought I'll make it through opApply override, however the delegate passed by it doesn't have the @nogc attribute, which would automatically make it incapable to be used in a @nogc context. I also don't know if it would work with structs instead of classes, since they're easier to handle in a @nogc situation. https://forum.dlang.org/thread/erznqknpyxzxqivaw...@forum.dlang.org
Re: Can opApply be made @nogc?
On 20/10/2018 12:32 PM, solidstate1991 wrote:
Since it's a bit difficult to make tree traversal through range
(especially if someone wants to make it @nogc), I thought I'll make it
through opApply override, however the delegate passed by it doesn't have
the @nogc attribute, which would automatically make it incapable to be
used in a @nogc context.
I also don't know if it would work with structs instead of classes,
since they're easier to handle in a @nogc situation.
class Foo
{
uint[2] array;
int opApply(scope int delegate(ref uint) @nogc dg) @nogc
{
int result = 0;
for (int i = 0; i < array.length; i++)
{
result = dg(array[i]);
if (result)
break;
}
return result;
}
}
void test()
{
Foo a = new Foo();
a.array[0] = 73;
a.array[1] = 82;
foreach (uint u; a)
{
printf("%d\n", u);
}
}
Re: Shared - Another Thread
On Friday, 19 October 2018 at 18:11:50 UTC, Manu wrote: On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via Digitalmars-d wrote: On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote: > [...] What issues am I failing to address? [...] Another point is the part of "how can the compiler support the expert in writing threadsave methods" - which you answered with "not a little bit at the moment, but we may improve this in the future" - and that is not at all satisfying. I think you've misunderstood. My proposal is @safe... if you stay @safe, you will receive guarantee that your code is threadsafe. On user side, yes. If you want to implement a low-level device, you must implement a @trusted function, and I don't know what the compiler can do to help you. Yes, but that's seldom. More often the "expert" will write new shared types using the low level trusted functions like anybody else. But that still requires special care - he has to consider tread-safety in every method of a new type, even the non-shared ones. And he has to fill any possible gap like construction and assignment so that the end-user is really sure to not accidentally misusing the type! And I think a serious proposal need to address this - I think the compiler could really help here (e.g. prescribe what operators need to be overloaded and check that all methods use the proper mechanisms to lock the shared members before operating on them etc.) So saying that my response that "there is @trusted code at the bottom of the stack" is not satisfying is really just a comment on your opinion about @trusted code in general. That just comes on top of it. My proposal is designed to be useful and @safe for *users* as primary goal. I agree with you, but others seem not so convinced (yet?). [...] The user has manually cast to unshared inside their unsafe/(@trusted?) function, what more signal do they need that they've engaged in an unsafe operation? Some hints what to do to be able to trust them? You asked what issues you were failing to address. That was just some ideas of mine what you may address in addition.
[Issue 19317] New: dip1008 doesn't call the throwable's destructor in _d_delThrowable
https://issues.dlang.org/show_bug.cgi?id=19317
Issue ID: 19317
Summary: dip1008 doesn't call the throwable's destructor in
_d_delThrowable
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: atila.ne...@gmail.com
The last assertion in the code below fails. This makes 1008 far less useful
than it could be. Exceptions have error messages, and the only way to construct
a useful message with runtime information is to allocate. Given that the
purpose of dip1008 is to avoid the GC and still be able to use exceptions, the
non error-prone way of doing this is to use an RAII string class.
However, that means that _d_delThrowable should call the class's destructor,
which it doesn't right now, resulting in a either a leak or the programmer
having to manually dispose of the memory.
---
class MyException: Exception {
static int numInstances;
this(string msg) {
super(msg);
++numInstances;
}
~this() {
--numInstances;
}
}
void main() {
assert(MyException.numInstances == 0);
try
throw new MyException("oops");
catch(MyException _)
assert(MyException.numInstances == 1);
assert(MyException.numInstances == 0);
}
---
% dmd -dip1008 -run exception.d
core.exception.AssertError@exception.d(21): Assertion failure
--
Re: Truly @nogc Exceptions?
On Thursday, 20 September 2018 at 12:48:13 UTC, Steven
Schveighoffer wrote:
On 9/20/18 6:48 AM, Atila Neves wrote:
On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven
Schveighoffer wrote:
Given dip1008, we now can throw exceptions inside @nogc code!
This is really cool, and helps make code that uses exceptions
or errors @nogc. Except...
The mechanism to report what actually went wrong for an
exception is a string passed to the exception during
*construction*. Given that you likely want to make such an
exception inside a @nogc function, you are limited to passing
a compile-time-generated string (either a literal or one
generated via CTFE).
I expressed my concern for DIP1008 and the `msg` field when it
was first announced. I think the fix is easy and a one line
change to dmd. I also expressed this on that thread but was
apparently ignored. What's the fix? Have the compiler insert a
call to the exception's destructor at the end of the
`catch(scope Exception)` block. That's it. The `msg` field is
just a slice, point it to RAII managed memory and you're good
to go.
Give me deterministic destruction of exceptions caught by
scope when using dip1008 and I'll give you @nogc exception
throwing immediately. I've even already written the code!
I thought it already did that?
Nope:
---
class MyException: Exception {
static int numInstances;
this(string msg) {
super(msg);
++numInstances;
}
~this() {
--numInstances;
}
}
void main() {
assert(MyException.numInstances == 0);
try
throw new MyException("oops");
catch(MyException _)
assert(MyException.numInstances == 1);
assert(MyException.numInstances == 0);
}
---
% dmd -dip1008 -run exception.d
core.exception.AssertError@exception.d(21): Assertion failure
How is the exception destroyed when dip1008 is enabled?
Apparently, it isn't. Which renders dip1008 pretty much useless
since we could already use static immutable exceptions before.
But this means you still have to build msg when throwing the
error/exception. It's not needed until you print it, and
there's no reason anyway to make it allocate, even with RAII.
For some reason D forces msg to be built, but it does't e.g.
build the entire stack trace string before hand, or build the
string that shows the exception class name or the file/line
beforehand.
Allocating and building the string doesn't bother me - in all of
my uses it's eventually going to get printed (which means the
string needed to be built), and the exceptional path can be slow,
I don't mind.
But, one could always store a tuple of members in an exception
class instead and only build the string on demand.
I just think it's easier with an RAII string.
Can opApply be made @nogc?
Since it's a bit difficult to make tree traversal through range (especially if someone wants to make it @nogc), I thought I'll make it through opApply override, however the delegate passed by it doesn't have the @nogc attribute, which would automatically make it incapable to be used in a @nogc context. I also don't know if it would work with structs instead of classes, since they're easier to handle in a @nogc situation.
Re: Need help with setting up LDC to cross-compile to Android/ARM
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! T -- Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.
Re: Which Docker to use?
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.
Re: Need help with setting up LDC to cross-compile to Android/ARM
On Fri, Oct 19, 2018 at 02:41:48PM -0700, H. S. Teoh via Digitalmars-d wrote: [...] > 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. So I'm going to try the "official" LDC release instead... [...] I'm getting the same error with the official LDC 12.0. Running with --ninja revealed that it's not just sys/types.h, but seems that a bunch of standard C headers (possibly all?) that are mysteriously missing: $ ldc-build-runtime --targetPreset=Android-arm --dFlags=-w;-mcpu=cortex-a8 --buildDir=droid32 --ninja -- Configuring done -- Generating done CMake Warning (dev): Policy CMP0058 is not set: Ninja requires custom command byproducts to be explicit. Run "cmake --help-policy CMP0058" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This project specifies custom command DEPENDS on files in the build tree that are not specified as the OUTPUT or BYPRODUCTS of any add_custom_command or add_custom_target: ldc-src/runtime/druntime/src/core/atomic.d ldc-src/runtime/druntime/src/core/attribute.d ldc-src/runtime/druntime/src/core/bitop.d ldc-src/runtime/druntime/src/core/checkedint.d ldc-src/runtime/druntime/src/core/cpuid.d ldc-src/runtime/druntime/src/core/demangle.d ldc-src/runtime/druntime/src/core/exception.d ldc-src/runtime/druntime/src/core/internal/abort.d ldc-src/runtime/druntime/src/core/internal/arrayop.d ldc-src/runtime/druntime/src/core/internal/convert.d For compatibility with versions of CMake that did not have the BYPRODUCTS option, CMake is generating phony rules for such files to convince 'ninja' to build. Project authors should add the missing BYPRODUCTS or OUTPUT options to the custom commands that produce these files. This warning is for project developers. Use -Wno-dev to suppress it. -- Build files have been written to: /mnt/3/usr/src/d/android/droid32 [1/40] Building C object CMakeFiles/phobos2-ldc.dir/phobos/etc/c/zlib/gzwrite.c.o FAILED: CMakeFiles/phobos2-ldc.dir/phobos/etc/c/zlib/gzwrite.c.o /usr/lib/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -DHAVE_UNISTD_H -fPIC -ffunction-sections -funwind-tables -fstack-protector-strong -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -no-canonical-prefixes -g -DNDEBUG -DANDROID -D__ANDROID_API__=21 -Wa,--noexecstack -Wformat -Werror=format-security -fpie -target armv7-none-linux-androideabi21 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -Os -gcc-toolchain /usr/lib/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 --sysroot /usr/lib/android-ndk/sysroot -isystem /usr/lib/android-ndk/sysroot/usr/include/arm-linux-androideabi -fno-integrated-as -MD -MT CMakeFiles/phobos2-ldc.dir/phobos/etc/c/zlib/gzwrite.c.o -MF CMakeFiles/phobos2-ldc.dir/phobos/etc/c/zlib/gzwrite.c.o.d -o CMakeFiles/phobos2-ldc.dir/phobos/etc/c/zlib/gzwrite.c.o -c ldc-src/runtime/phobos/etc/c/zlib/gzwrite.c In file included from ldc-src/runtime/phobos/etc/c/zlib/gzwrite.c:6: ldc-src/runtime/phobos/etc/c/zlib/gzguts.h:21:10: fatal error: 'stdio.h' file not found #include ^ 1 error generated. [2/40] Building C object CMakeFiles/phobos2-ldc-debug.dir/phobos/etc/c/zlib/compress.c.o FAILED: CMakeFiles/phobos2-ldc-debug.dir/phobos/etc/c/zlib/compress.c.o /usr/lib/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -DHAVE_UNISTD_H -fPIC -ffunction-sections -funwind-tables -fstack-protector-strong -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -no-canonical-prefixes -g -DNDEBUG -DANDROID -D__ANDROID_API__=21 -Wa,--noexecstack -Wformat -Werror=format-security -fpie -target armv7-none-linux-androideabi21 -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -Os -gcc-toolchain /usr/lib/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 --sysroot /usr/lib/android-ndk/sysroot -isystem /usr/lib/android-ndk/sysroot/usr/include/arm-linux-androideabi -fno-integrated-as -MD -MT CMakeFiles/phobos2-ldc-debug.dir/phobos/etc/c/zlib/compress.c.o -MF CMakeFiles/phobos2-ldc-debug.dir/phobos/etc/c/zlib/compress.c.o.d -o CMakeFiles/phobos2-ldc-debug.dir/phobos/etc/c/zlib/compress.c.o -c ldc-src/runtime/phobos/etc/c/zlib/compress.c In file included from ldc-src/runtime/phobos/etc/c/zlib/compress.c:9: In file included from ldc-src/runtime/phobos/etc/c/zlib/zlib.h:34: ldc-src/runtime/phobos/etc/c/zlib/zconf.h:444:14: fatal error: 'sys/types.h' file not found #include /* for off_t */
Re: Need help with setting up LDC to cross-compile to Android/ARM
On Fri, Oct 19, 2018 at 08:54:25PM +, Joakim via Digitalmars-d wrote: [...] > Also, if you're using a system-provided LDC, it may not support Android, if > it wasn't built against our slightly tweaked llvm: > > https://github.com/ldc-developers/llvm > > In that case, use the LDC download from github instead: > > https://github.com/ldc-developers/ldc/releases 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. So I'm going to try the "official" LDC release instead... 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? T -- I'm still trying to find a pun for "punishment"...
More zero-initialization optimizations pending in std.experimental.allocator?
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?
Re: Need help with setting up LDC to cross-compile to Android/ARM
On Friday, 19 October 2018 at 20:50:36 UTC, Joakim 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 [...] Hmm, that's weird: can you extract the full compiler command for that file? For example, if you use Ninja, by appending --ninja to ldc-build-runtime, it will tell you the full command that failed. Not sure if Make has a way to get that too. Also, if you're using a system-provided LDC, it may not support Android, if it wasn't built against our slightly tweaked llvm: https://github.com/ldc-developers/llvm In that case, use the LDC download from github instead: https://github.com/ldc-developers/ldc/releases
Re: Need help with setting up LDC to cross-compile to Android/ARM
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 [...] Hmm, that's weird: can you extract the full compiler command for that file? For example, if you use Ninja, by appending --ninja to ldc-build-runtime, it will tell you the full command that failed. Not sure if Make has a way to get that too.
Re: BindBC -- The successor to Derelict
On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote: dpp almost completely kills the reason to use any BindBC package in its static binding configuration. The I've used the OpenGL and GLFW BindBC bindings for a few days or so now, and its certainly a lot more convenient to use that dpp... I really like that you can load whatever version of a lib is present and act accordingly - for example if only OpenGL 3v3 is available or OpenGL 4v5 you can configure your renderer accordingly There is also great feedback when something goes wrong, great if someone reports a bug in your app...
Re: shared - i need it to be useful
On Friday, 19 October 2018 at 18:00:47 UTC, Atila Neves wrote: Because int or int* does not have threadsafe member functions. https://dlang.org/phobos/core_atomic.html Atomic and thread-safe are two very different concepts. Thread-safe is more of an ecosystem thing - if there are ways to do non-thread-safe operations on something, atomic operations are not enough to make things thread-safe. This is what core.atomic does: https://i.imgur.com/PnKMigl.jpg If you close the other openings, atomics are fantastic building blocks to making something thread-safe, but on their own they are not enough. -- Simen
Re: BindBC -- The successor to Derelict
On Friday, 19 October 2018 at 17:34:10 UTC, Mike Parker wrote: [...] When I saw the packages appearing on dub, I knew an announcement was imminent. This is great stuff! I don't think dpp obsoletes this. If you aren't already using dpp, being able to just add a dependency from dub is less of a barrier than keeping a C header and incorporating d++ and .dpp files in your project.
Re: shared - i need it to be useful
On 20/10/2018 2:07 AM, Dominikus Dittes Scherkl wrote: This document provide no reasoning about what usecases it supports: It was a basic idea of mine... It was never meant to be PR'd.
Re: custom sorting of lists ?
On Friday, 19 October 2018 at 17:53:58 UTC, Stanislav Blinov wrote: On Friday, 19 October 2018 at 17:40:59 UTC, Carl Sturtivant wrote: If we imagine an Ordered Range being a finite Range of some kind with the additional property that its values are ordered (--- exact definition needed ---)... There's already a SortedRange: https://dlang.org/phobos/std_range.html#.SortedRange That's nice. So perhaps all this can be done in using the existing machinery in Phobos.
Re: [OT] Android
On Fri, Oct 19, 2018 at 06:34:50PM +, Joakim via Digitalmars-d wrote: > On Thursday, 18 October 2018 at 19:37:24 UTC, H. S. Teoh wrote: [...] > > Eventually I resorted to generating Java code from D for some fo the > > most painful repetitive parts, and the way things are looking, I'm > > likely to be doing a lot more of that. I fear the way things are going > > will have be essentially writing a D to Java compiler at some point! > > Why not just use the Android port of D? I want to. But I couldn't get the cross-compiler setup properly: https://forum.dlang.org/post/mailman.4361.1539811552.29801.digitalmar...@puremagic.com If I can get past that hurdle, Java is going out the window pronto. :-D T -- Everybody talks about it, but nobody does anything about it! -- Mark Twain
[Issue 19316] New: GC runtime breaks @safe
https://issues.dlang.org/show_bug.cgi?id=19316
Issue ID: 19316
Summary: GC runtime breaks @safe
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: stanislav.bli...@gmail.com
Per @safe-ty rules, @safe functions shall not call @system functions.
Unfortunately, the GC may run finalizers during collection, even when that
collection is triggered from within @safe function:
import std.stdio;
class C {
~this() // @system!
{
printf("Called @system function\n");
}
}
void safeFunc() @safe {
auto a = new int[10^^6]; // 'new' may require collection
// do 'safe' things with 'a'
}
void main() {
new C; // the object is no longer referenced, will be collected, i.e.
assume that this happened elsewhere in the program via last reference going out
of scope
printf("Entering @safe function\n");
safeFunc(); // if this triggers collection, it effectively calls @system
C.__dtor inside @safe safeFunc
printf("Exited @safe function\n");
}
Output with default GC options:
Entering @safe function
Called @system function
Exited @safe function
Thus, arbitrary non-@safe code may 'escape' into @safe context. This of course
applies to struct destructors as well.
This issue is made worse by the fact that the behavior is non-deterministic:
collection may or may not trigger depending on the GC state, destructor may or
may not be called depending on program state.
--
[Issue 19315] New: #line inside token string affect outside code
https://issues.dlang.org/show_bug.cgi?id=19315
Issue ID: 19315
Summary: #line inside token string affect outside code
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: d...@me.com
The static assert in the following code unexpectadely passes:
enum code = q{
#line 10
};
static assert(__LINE__ == 11);
"#line 10" when used inside a token string affects the code outside of the
string.
--
[Issue 19307] Variables moved to a closure show nonsense in debugger
https://issues.dlang.org/show_bug.cgi?id=19307 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #2 from Rainer Schuetze --- https://github.com/dlang/dmd/pull/8847 --
Re: shared - i need it to be useful
On Thursday, 18 October 2018 at 21:24:53 UTC, jmh530 wrote: On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote: [snip] Assuming this world... how do you use shared? https://github.com/atilaneves/fearless I had posted your library before to no response... I had two questions, if you'll indulge me. The first is perhaps more wrt automem. I noticed that I couldn't use automem's Unique with @safe currently. Is there any way to make it @safe, perhaps with dip1000? Yeah, I punted on making anything there @safe. I have to go back and fix it. At least I wrote Vector from scratch to be @safe. Second, Rust's borrow checker is that you can only have one mutable borrow. This is kind of like Exclusive, but it does it at compile-time, rather than with GC/RC. Is this something that can be incorporated into fearless? Well, Rust's version of Exclusive is Mutex, and that's pretty much always used with Arc. The closest we have to a borrow checker is DIP1000 and that's what fearless relies on.
[OT] Android
On Thursday, 18 October 2018 at 19:37:24 UTC, H. S. Teoh wrote: On Thu, Oct 18, 2018 at 07:09:42PM +, Patrick Schluter via Digitalmars-d wrote: [...] I often have the impression that a lot of things are going slower than necessary because a mentality where the perfect is in the way of good. That is indeed an all-too-frequent malady around these parts, sad to say. Which has the sad consequence that despite all efforts, there are still unfinished areas in D, and promises that haven't materialized in years (like multiple alias this). Still, the parts of D that are working well form a very powerful and comfortable-to-use language. Not quite the ideal we wish it to be, but IMO much closer than any other language I've seen yet. Recently I began dabbling in Android programming, and the one thing that keeps sticking out to me is how painful writing Java is. Almost every day of writing Java code has me wishing for this or that feature in D. Slices. Closures. Meta-programming. I found most of my time spent fighting with language limitations rather than make progress with the problem domain. Yes, this is why I began the Android port: I couldn't imagine writing Java. Eventually I resorted to generating Java code from D for some fo the most painful repetitive parts, and the way things are looking, I'm likely to be doing a lot more of that. I fear the way things are going will have be essentially writing a D to Java compiler at some point! Why not just use the Android port of D?
Re: Shared - Another Thread
On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via Digitalmars-d wrote: > > On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote: > > On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote: > >> What cracks me up with Manu's proposal is that it is its > >> simplicity and lack of ambition that is criticized the most. > >> shared is a clusterfuck, according to what I gathered from the > >> forum, I never had yet to use it in my code. Manu's idea makes > >> it a little less of a clusterfuck, and people attack the idea > >> because it doesn't solve all and everything that's wrong with > >> shared. Funny. > >> > > > > Elaborate on this... It's clearly over-ambitious if anything. > > What issues am I failing to address? > > First of all, you called it "shared", but what your concept > describes is "theadsave". > If you had called it the later, it would have been clear to > everybody that thread local data is indeed automatically > threadsave, because only one thread has access to it (that > "implicit conversion"). But if something is "shared" (in the > common-world sense), it is of course no more "threadsave" - you > have to implement special methods to treat it. > > Conflating "shared" and "threadsave" in that manner was, I think, > the biggest mistake of your proposal. > > Another point is the part of "how can the compiler support the > expert in writing threadsave methods" - which you answered with > "not a little bit at the moment, but we may improve this in the > future" - and that is not at all satisfying. I think you've misunderstood. My proposal is @safe... if you stay @safe, you will receive guarantee that your code is threadsafe. If you want to implement a low-level device, you must implement a @trusted function, and I don't know what the compiler can do to help you. You will have to produce unsafe casts, so at least it will be completely clear every operation you perform that is unsafe. Users of your @trusted library though will experience @safe code upward through the stack. So saying that my response that "there is @trusted code at the bottom of the stack" is not satisfying is really just a comment on your opinion about @trusted code in general. My proposal is designed to be useful and @safe for *users* as primary goal. Authors that are composing low-level tools/libs will enjoy @safe guarantees. Only authors implementing ground-level machinery would need to write @trusted code... and that's the nature of the whole @safe stack. @safe can't practically exist without @trusted at the bottom of the stack. > Are there really no > ideas? I have some ideas, but I don't think they're practical to implement. Some cross-referencing of access would be required for the compiler to suspect foul-play. Functions would need to be analysed in conjunction; that sounds hard to implement. > No check that the proper atomic funtions are used or the > cast to "unshared" is ok at where it is used? The user has manually cast to unshared inside their unsafe/(@trusted?) function, what more signal do they need that they've engaged in an unsafe operation? > Even the expert > needs a little help to find the upcomming and well hidden bugs in > their oh so threadsave API... I think a lot of people probably over-estimate the number of tooling libs that live at the bottom of the stack. The list is fairly short: Atomic, Mutex/Semaphore, and a couple of lock-free-queue/list type structures. I don't know what other useful constructs exist... they will all be in libraries. Users would almost never come in contact with unsafe code, and again, that's the whole point of my design!
Re: shared - i need it to be useful
On Thursday, 18 October 2018 at 19:04:58 UTC, Erik van Velzen wrote: On Thursday, 18 October 2018 at 17:47:29 UTC, Stanislav Blinov wrote: On Thursday, 18 October 2018 at 17:17:37 UTC, Atila Neves wrote: On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote: Assuming the rules above: "can't read or write to members", and the understanding that `shared` methods are expected to have threadsafe implementations (because that's the whole point), what are the risks from allowing T* -> shared(T)* conversion? int i; tid.send(); ++i; // oops, data race Doesn't work. No matter what you show Manu or Simen here they think it's just a bad contrived example. You can't sway them by the fact that the compiler currently *prevents* this from happening. Manu said clearly that the receiving thread won't be able to read or write the pointer. Not directly - but obviously there must be *some* way to using it, in this case since it's an int with one of the core.atomic functions. At that point the spawned thread will be accessing it correctly, but the parent thread can modify the int in a non-atomic fashion. Because int or int* does not have threadsafe member functions. https://dlang.org/phobos/core_atomic.html
Re: custom sorting of lists ?
On Friday, 19 October 2018 at 17:40:59 UTC, Carl Sturtivant wrote: If we imagine an Ordered Range being a finite Range of some kind with the additional property that its values are ordered (--- exact definition needed ---)... There's already a SortedRange: https://dlang.org/phobos/std_range.html#.SortedRange
Re: custom sorting of lists ?
On Wednesday, 17 October 2018 at 19:02:00 UTC, Steven Schveighoffer wrote: On 10/17/18 2:03 PM, Carl Sturtivant wrote: On Monday, 15 October 2018 at 13:39:59 UTC, Steven Schveighoffer wrote: But that's just the thing -- merge sort *does* depend on the container type. It requires the ability to rearrange the elements structurally, since you merge the sets of items together. This requires making another list from the original list, and ranges don't lend themselves to that. One thing you *can* do is allocate an array beside the original container, and move things back and forth. But this is not required if you have a linked-list type which can simply be restructured without moving. Doesn't this just mean a new special kind of range is needed to be defined? I don't think it fits into range primitives. Basically, I need to rearrange one element from one place to another in O(1) time (and without actually moving/copying the data). This really just is a linked-list special feature. One thing to note is that in a range of T, this move has nothing to do with the T. -Steve If we imagine an Ordered Range being a finite Range of some kind with the additional property that its values are ordered (--- exact definition needed ---). And work with Ranges of Ordered Ranges, can't we then sort by starting with a Range of single element Ranges (which are automatically ordered), and then pairwise merge repeatedly, i.e. get the next two elements (which are ordered ranges) and merge them & repeat, producing a Range of Ordered Ranges with half as many elements --- this is what I meant by pairwise merging --- and apply that pairwise merge repeatedly to the original range. I'm speculating intuitively, but it does look like there exists a possible extension of the notion of Range that would do the job.
BindBC -- The successor to Derelict
In the 14.5 (!) years I've been maintaining the Derelict bindings, I've restructured the source tree a few times (Derelict 1 - 3 to DerelictOrg), had three implementations of the loader (that I can remember), switched from Subversion to Git, and supported a few different approaches to building (bud, dss, Visual D projects, a couple of custom scripts) before finally settling exclusively DUB. Along the way, my approach to the overall architecture has become a headache to maintain and a more confusing than it needs to be for users to know which version of a binding they need for a given C library version. Moreover, the loader as implemented now is not usable in -betterC mode, is only partially @nogc, and is not nothrow at all. And I've never once had a full set of documentation for any iteration of Derelict. When I sat down to see how I could rectify those issues, I decided it's time for Derelict to ride off into the sunset. Better just to start an entirely new project. I immediately saw an obvious way (that I couldn't believe I had missed before) to ease my maintenance burden while also making it easier for users to match the bindings with specific versions of the C libraries. Everything is configurable at compile time, including which version of a C library you'd like to bind to. Most of the packages will have both dynamic and static versions. The loader is compatible with -betterC (not enabled by default) and is 100% @nogc and nothrow. No more pain for me when updating a package to support new C library versions. No more worries about matching up Derelict package versions with C library versions and git branches. I first implemented the loader and the SDL binding a few months back. Since that time, dpp has been announced. Before anyone asks me why they should use BindBC over dpp, let me just give you my answer: You shouldn't. What I mean is, I don't care if you use BindBC or not. It's there if you want it. dpp almost completely kills the reason to use any BindBC package in its static binding configuration. The only marginal benefit BindBC provides as a static binding is that you don't need to add dpp to your workflow or worry about the C headers. Using dpp to generate the binding for you means you can always be up to date, and accurate, with the latest version of the C library, you don't have to wait on me, and you don't have to worry about my typos. Aside from that, if you find you need or want a dynamic binding where you don't need to worry about link-time dependencies and the shared libraries are loaded at run time, then BindBC and Derelict are the only games in town. I don't recommend Derelict for new projects unless you need a binding I haven't ported over yet. Currently, all of the Derelict packages in DerelictORG that I maintain (I can't speak for Guillaume) can be considered in limited maintenance mode. I'll fix bugs, but I have no plans to update any of the bindings to the latest C libraries unless someone absolutely, positively can't live without it. 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. Currently ported: bindbc-sdl (includes SDL_image, SDL_mixer, and SDL_ttf) https://github.com/BindBC/bindbc-sdl http://bindbc-sdl.dub.pm/ bindbc-glfw https://github.com/BindBC/bindbc-glfw http://bindbc-glfw.dub.pm/ bindbc-opengl https://github.com/BindBC/bindbc-opengl http://bindbc-opengl.dub.pm/ The README for each project should have all you need to know to use each binding. Be sure to READ FIRST if you do use them. Anyone who would like to port their one Derelict bindings over can use the bindbc-loader package to do the loading. I have no documentation yet on how you should structure a BindBC binding, but it isn't hard to derive from the existing packages. Look at the READMEs and the source code for inspiration. https://github.com/BindBC/bindbc-loader http://bindbc-loader.dub.pm/
Re: shared - i need it to be useful
On Fri., 19 Oct. 2018, 6:10 am Dominikus Dittes Scherkl via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On Friday, 19 October 2018 at 06:25:00 UTC, rikki cattermole > wrote: > > On 19/10/2018 7:09 PM, Norm wrote: > > > [0] > > https://github.com/rikkimax/DIPs/blob/shared/DIPs/DIP1xxx-RC2.md > > This document provide no reasoning about what usecases it > supports: > > Is it possible to create objects that are shared just for short > periods during their livetime and guarantee that they can be used > threadsave like Manu want it to be? > > Does it prohibit misuse any better than Manus proposal (that > requires the "Expert" to implement all theadsave API)? > No, a key misunderstanding. My proposal is @safe. The only thing an expert must do is write the few @trusted implementations that live at the very bottom of the stack. That would always be in a lib. When was the last time you rewrote std::map because you thought you could do better? The whole stack from there on up (the user stack) is safe, and you can have confidence in the @safe-ty. My goal is to make it safe, clearly communicate how a user interact with the API, and mechanically confirm that users do the right stuff. My proposal is specifically structured to not require *any* unsafe interactions at the user level. Only core machinery that is @trusted needs expert attention. I don't think it's possible to invent a proposal with a higher degree of verifiable safety.
Re: shared - i need it to be useful
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...
-Steve
Re: Shared - Another Thread
On Friday, 19 October 2018 at 13:40:54 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh
wrote:
What cracks me up with Manu's proposal is that it is its
simplicity and lack of ambition that is criticized the most.
shared is a clusterfuck, according to what I gathered from
the forum, I never had yet to use it in my code. Manu's idea
makes it a little less of a clusterfuck, and people attack
the idea because it doesn't solve all and everything that's
wrong with shared. Funny.
Elaborate on this... It's clearly over-ambitious if anything.
What issues am I failing to address?
First of all, you called it "shared", but what your concept
describes is "theadsave".
If you had called it the later, it would have been clear to
everybody that thread local data is indeed automatically
threadsave, because only one thread has access to it (that
"implicit conversion"). But if something is "shared" (in the
common-world sense), it is of course no more "threadsave" - you
have to implement special methods to treat it.
Conflating "shared" and "threadsave" in that manner was, I
think, the biggest mistake of your proposal.
He talked about it in a previous thread, and generally I would
agree with him that such conflation is indeed beneficial provided
that some concessions are made for `shared`. Moreover, yet
another attribute? Please no...
struct X {
void foo(threadsafe const shared Bar* bar) @nogc @trusted
notrhow pure const shared threadsafe;
}
Attribute explosion is bad enough already.
[Issue 12206] Can't "alias this" to a template instantiation
https://issues.dlang.org/show_bug.cgi?id=12206 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- This is a weird case. The alias is part of the struct, but the actual function is not. I would say that the correct behavior is the current one: Error : no property foo for type S. Note that writing s.t.foo works. In my opinion, this is the real bug. --
[Issue 19238] no-arg splitter should work on ranges of characters
https://issues.dlang.org/show_bug.cgi?id=19238 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19238] no-arg splitter should work on ranges of characters
https://issues.dlang.org/show_bug.cgi?id=19238 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/f7154ec86a21029d16784c698d152ed33ef16dd4 Fix issue 19238 - Allow splitter on random-access ranges of characters that aren't character arrays. --
Re: Shared - Another Thread
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote: On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote: What cracks me up with Manu's proposal is that it is its simplicity and lack of ambition that is criticized the most. shared is a clusterfuck, according to what I gathered from the forum, I never had yet to use it in my code. Manu's idea makes it a little less of a clusterfuck, and people attack the idea because it doesn't solve all and everything that's wrong with shared. Funny. Elaborate on this... It's clearly over-ambitious if anything. What issues am I failing to address? First of all, you called it "shared", but what your concept describes is "theadsave". If you had called it the later, it would have been clear to everybody that thread local data is indeed automatically threadsave, because only one thread has access to it (that "implicit conversion"). But if something is "shared" (in the common-world sense), it is of course no more "threadsave" - you have to implement special methods to treat it. Conflating "shared" and "threadsave" in that manner was, I think, the biggest mistake of your proposal. Another point is the part of "how can the compiler support the expert in writing threadsave methods" - which you answered with "not a little bit at the moment, but we may improve this in the future" - and that is not at all satisfying. Are there really no ideas? No check that the proper atomic funtions are used or the cast to "unshared" is ok at where it is used? Even the expert needs a little help to find the upcomming and well hidden bugs in their oh so threadsave API...
Buildkite and the Project Tester
Hi, So for those of you who have contributed to D on GitHub in the last few months, you might have noticed the new Buildkite CI status checks. tl;dr: - it's the replacement for the Jenkins project tester (which has been deactivated ~ three months ago) - it allows us to add our own agents to the build fleet [1, 2] - it's intended to unify all CI systems on the long run (currently not possible due to a lack of build resources) So what are the other CIs doing? auto-tester: normal testing pipeline DAutotest: documentation testing (diff + preview) CircleCi: code coverage builds + style checks SemaphoreCI: self-bootstrapping (build dmd with LDC, GDC or a freshly built dmd) AppVeyor: 64-bit Windows builds + Visual Studio builds Travis: only used for tools, dlang.org and dub (test steps) CodeCov: code coverage diff (install the browser extension to see uncovered lines in the diff) Why can't I access the Buildkite build logs? Unfortunately Buildkite doesn't allow public access to their logs yet (though they are working on it). This is why I have just sent out a few more invitations. If I haven't gotten you, I'm sorry, but please send me a ping [3]. Otherwise you can also use the read-only dummy account below. Having an account has the advantage that you can restart builds, the dummy account is read-only. My build is failing and I think the failure isn't related to my changes --- Report this on #ci in Slack or https://github.com/dlang/ci The Auto-tester has its own GitHub repository: https://github.com/braddr/d-tester/issues Dlang-Bot has its own GitHub repository too: https://github.com/dlang-bots/dlang-bot I want my project to be tested on the Project Tester Your project's testsuite will be run on every PR which should prevent any regressions with a new DMD release. Open an issue (or a PR) here: https://github.com/dlang/ci I have resources I can spare for more testing agents Awesome! Talk to us in #ci or https://github.com/dlang/ci Dummy Account - user: du...@dlang.io password: dlangrocks Happy hacking! [1] https://buildkite.com/docs/agent/v3 [2] https://buildkite.com/docs/agent/v3/ubuntu [3] https://github.com/wilzbach
Re: shared - i need it to be useful
On Friday, 19 October 2018 at 06:25:00 UTC, rikki cattermole wrote: On 19/10/2018 7:09 PM, Norm wrote: [0] https://github.com/rikkimax/DIPs/blob/shared/DIPs/DIP1xxx-RC2.md This document provide no reasoning about what usecases it supports: Is it possible to create objects that are shared just for short periods during their livetime and guarantee that they can be used threadsave like Manu want it to be? Does it prohibit misuse any better than Manus proposal (that requires the "Expert" to implement all theadsave API)? Is the "normal" User still enforced to do some unsave casts? Has the normal User to have high knownledge of how a threadsave API is to be used or can the compiler provide any guarantees that using them can only fail if the implementation behind the API has bugs (e.g. provide some encapsulation)? Or any other usecases why and how this design is better than what we have now? And also some ideas how to implement some useacases (examples) are completely missing.
[Issue 19288] memory corruption in attached threads
https://issues.dlang.org/show_bug.cgi?id=19288 Mihails Strasuns changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #5 from Mihails Strasuns --- Sub issue #2 https://issues.dlang.org/show_bug.cgi?id=19314 Closing this one - please follow details of specific sub-issues. --
[Issue 19314] New: Thread object destruction may result in UB
https://issues.dlang.org/show_bug.cgi?id=19314 Issue ID: 19314 Summary: Thread object destruction may result in UB Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: mihails.stras...@gmail.com Split from https://issues.dlang.org/show_bug.cgi?id=19288 Expectation is that after thread is detached from druntime, it becomes responsibility of external environment to terminate it properly (for example, by calling `join` from C/C++ code). However, `Thread` object for that thread will still remain and will eventually be collected by GC. Destructor tries to call `pthread_detach` unconditionally but it is undefined behaviour if thread was alread joined before (see `man pthread_detach`). --
[Issue 19313] New: Attaching external thread may result in segfault
https://issues.dlang.org/show_bug.cgi?id=19313
Issue ID: 19313
Summary: Attaching external thread may result in segfault
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: mihails.stras...@gmail.com
Split from https://issues.dlang.org/show_bug.cgi?id=19288 as on of sub-issues
Essence of the issue:
```
import core.sys.posix.pthread;
import core.memory;
extern(C)
void* entry_point(void*)
{
// in real world case this may be called through `thread_attachThis`:
GC.collect();
return null;
}
void main()
{
// ensure some garbage exists
auto x = new int[1000];
pthread_t thread;
auto status = pthread_create(, null, _point, null);
assert(status == 0);
pthread_join(thread, null);
}
```
Same applies to other operating systems. Problems comes from the fact that GC
implementation is not ready for `Thread.getThis()` to be `null` and will crash
in several places if this happens. And because `thread_attachThis` has to call
`new Thread` to allocate new context, collection may happen before thread is
actually registered.
--
[Issue 19288] memory corruption in attached threads
https://issues.dlang.org/show_bug.cgi?id=19288 --- Comment #4 from Mihails Strasuns --- Sub-issue #1 https://issues.dlang.org/show_bug.cgi?id=19313 --
[Issue 8663] AliasThis is not used in comparison
https://issues.dlang.org/show_bug.cgi?id=8663 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16633 --
[Issue 16633] Case where an alias this is tried before the object itself
https://issues.dlang.org/show_bug.cgi?id=16633 RazvanN changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=8663 --
[Issue 16633] Case where an alias this is tried before the object itself
https://issues.dlang.org/show_bug.cgi?id=16633 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- PR: https://github.com/dlang/dmd/pull/8846 --
Re: Norwich 2018-11-07
On Wednesday, 17 October 2018 at 13:15:44 UTC, bachmeier wrote: I can definitely see that. I wanted to write a GUI program some time ago and looked at GtkD. It wasn't easy to see where to start with GtkD, and I eventually ended up running a local web server and creating the GUI in the browser. This is a good example of the non-technical things holding D back, largely because of the small community. Same here. I once started a GUI program using JavaFX + D (JNI) and then switched to GtkD + Glade. I could find my way around (with some difficulty), reading the docs / examples in C and translating them to GtkD in my head. It worked, but I always had the feeling of "Is that best practice?". When I re-opened the project after 2 years or so, I just couldn't be bothered to go through all that again. I just used my JavaFX code again and extended the app in no time. It also made me realize a lot of things about D and its "small community". Something is rotten in the state of D... PS No, I won't write GtkD docs myself (may the Universe forgive me!), because by the eternal DIY logic I would have had to implement D for ARM, write GtkD docs and whatnot...instead of using D to actually write programs.
Re: LDC 1.12.0
On Friday, 19 October 2018 at 10:03:17 UTC, jmh530 wrote: On Friday, 19 October 2018 at 02:18:38 UTC, Shigeki Karita wrote: [snip] https://github.com/jmmartinez/easy-just-in-time/blob/master/doc/slides/cppcon'18.pdf Thanks for those! I'm a little confused about using the jit in run.dlang.org (copying that simple example over). It doesn't seem to work (adding assert(0); as the first line after main does nothing)...maybe that's because it is using rldc? https://run.dlang.io/is/Xd5WZ4
Re: shared - i need it to be useful
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. 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++.
Re: LDC 1.12.0
On Friday, 19 October 2018 at 02:18:38 UTC, Shigeki Karita wrote: [snip] https://github.com/jmmartinez/easy-just-in-time/blob/master/doc/slides/cppcon'18.pdf Thanks for those!
Re: assigment to null class object member compiled? is this a bug?
On Friday, 19 October 2018 at 06:53:32 UTC, dangbinghoo wrote:
hi,
why the code bellow compiles?
---
import std.stdio;
class A {
int m;
}
void main() {
A a;
a.m = 1;
}
---
and running this code get:
`segmentation fault (core dumped) ./test`
I consider this couldn't be compiled according to book Programming Language>.
The latest dmd (2.082) and LDC2 behaves the same.
Technically the code you have is syntactically correct. You are
permitted to create a class variable without assigning it to a
class object. (Assigning it to a class object would look like "A
a = new A();")
Which section of The D Programming Language book makes you think
this would not compile? I have the book as well, but I'm not
quite sure what part of the book you're referring to.
[Issue 5577] Incorrectly generated di file with extern (C) and alias
https://issues.dlang.org/show_bug.cgi?id=5577 --- Comment #2 from Jacob Carlborg --- (In reply to Mathias LANG from comment #1) > I'm going to close this. That's fine, it don't even remember how/where I encountered this :) --
Re: shared - i need it to be useful
On 19/10/2018 9:02 PM, Walter Bright wrote: On 10/17/2018 4:29 AM, jmh530 wrote: Isn't that also true for isolated data (data that only allows one alias)? That's colloquially called "unique" data. And yes, it is also true for that. That's why casting the return value of malloc() to 'shared' is safe. It's just that the language has no way to semantically identify unique data with its current type system. Actually we kind of have a way to do this (I think). Scope. It can't cross the thread boundary and it has a pretty clear owner as far as the stack is concerned. Given a bit of time and empowering of scope, we could do a @scopeonly type attribute for functions.
Re: shared - i need it to be useful
On 10/17/2018 4:29 AM, jmh530 wrote: Isn't that also true for isolated data (data that only allows one alias)? That's colloquially called "unique" data. And yes, it is also true for that. That's why casting the return value of malloc() to 'shared' is safe. It's just that the language has no way to semantically identify unique data with its current type system.
assigment to null class object member compiled? is this a bug?
hi,
why the code bellow compiles?
---
import std.stdio;
class A {
int m;
}
void main() {
A a;
a.m = 1;
}
---
and running this code get:
`segmentation fault (core dumped) ./test`
I consider this couldn't be compiled according to book Programming Language>.
The latest dmd (2.082) and LDC2 behaves the same.
Re: shared - i need it to be useful
On 19/10/2018 7:09 PM, Norm wrote: There's another way; Stanislav isn't one you need to convince so if that particular discussion is unproductive and disruptive just ignore it. I.e technical discussions should be robust but once they become personal just ignore that input and move on. Isn't always possible I know but in this case I reckon you can. Trust me, I think a few of us at least have already figured that out. Convincing Walter, Andrei and the rest of the core dev team of course will require a DIP. Keep going on this, it is the first hint of movement with shared since like foreva! As long as it doesn't look like my idea[0] (Andrei doesn't like it, I may have asked) it should have some sort of legs. [0] https://github.com/rikkimax/DIPs/blob/shared/DIPs/DIP1xxx-RC2.md
Re: shared - i need it to be useful
On Friday, 19 October 2018 at 02:20:22 UTC, Manu wrote: On Thu., 18 Oct. 2018, 7:10 pm Stanislav Blinov via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: On Friday, 19 October 2018 at 01:53:00 UTC, Manu wrote: > This is a red-herring. > In short, he made up this issue, it doesn't exist. > This is just hot air, and only strengthen my conviction. >> Produce, or drop this presumptious crap. > You are an obscene person. I'm out. Oooh, I'm srry, come baack! Really though, what is it that you wanted to achieve here? You ask for counter-arguments, are given them on *17 pages already*, are asked numerous times to actually demonstrate the value of a small contained portion of your proposal, and all you do is shrug this all off just because you presume to "know better", and on top of that have the audacity to call someone else *obscene*? Wow... just... wow! > You win. I didn't know it was a contest. I've given use cases constantly, about taking object ownership, promotions, and distribution for periods (think parallel for), I can achieve all my goals with full @safety, absolutely no casts in user code, and I have infrastructure in production that applies these patterns successfully. It's worth pursuing. I've spent years thinking on this, I'm trying to move the needle on this issue for the first time in over a decade at least, and you have violently opposed, in principle, from the very first post, and make no effort to actually understand the proposition. It's clearly a contest from your insurance that my proposal in worthless in every single post you've made. You want me to admit defeat and desist. Fuck you. You win. I don't have the time or energy to argue against a wall. You are obscene, you're complete unproductive, and destructive from no apparent reason. I hope you continue to love shared, just the way it is... useless. There's another way; Stanislav isn't one you need to convince so if that particular discussion is unproductive and disruptive just ignore it. I.e technical discussions should be robust but once they become personal just ignore that input and move on. Isn't always possible I know but in this case I reckon you can. Convincing Walter, Andrei and the rest of the core dev team of course will require a DIP. Keep going on this, it is the first hint of movement with shared since like foreva! bye, norm bye, Norm
[Issue 9088] static static
https://issues.dlang.org/show_bug.cgi?id=9088 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |WONTFIX --- Comment #3 from Mathias LANG --- Since this is an enhancement request, it should go to the DIP queue if you want to pursue it. --
[Issue 4612] (D1 only) DMD DDoc marks both static and final methods of interfaces as abstract in generated documentation
https://issues.dlang.org/show_bug.cgi?id=4612 Mathias LANG changed: What|Removed |Added Status|NEW |RESOLVED CC||pro.mathias.l...@gmail.com Resolution|--- |WONTFIX --- Comment #3 from Mathias LANG --- D1 only, closing --
