Re: Member function passed through template alias only requiring `this` in certain conditions?
On Thursday, 19 July 2018 at 22:16:22 UTC, Ali Çehreli wrote:
On 07/19/2018 08:12 AM, Emma wrote:
> [...]
> If I try to compile it, dmd complains, which I guess makes
sense:
>
> ---
> Error: need this for bar of type void()
> Error: need this for baz of type void()
> ---
>
> [...]
I think it's a compiler bug. The second template argument
should be a lambda as well. When I added the following lines to
test()
pragma(msg, typeof(fn1));
pragma(msg, typeof(fn2));
the output is different:
void delegate() @system
void()
That is for the version of calling test with one lamdba and one
function? (`test!(() => bar, baz)`)
Just a question: The compiler should not automatically convert
those (functions) to lambdas?
Interesting is this:
void test(alias fn1, alias fn2)()
{
pragma(msg, typeof(fn1)); // void delegate() @system
pragma(msg, typeof(fn2)); // void()
fn1();
fn2(); // Error: this for baz needs to be type Boo not type
Foo
}
struct Foo
{
void foo()
{
test!(()=>bar, b.baz);
}
int i = 1337;
struct Boo
{
int j = 3;
void baz()
{writeln(j);}
}
Boo b;
void bar()
{writeln(i);}
}
unittest
{
auto foo = Foo();
foo.foo();
}
Looks like the compiler just assumes the context of the first
delegate to be applicable for the second function?
I think it's a bug probably related to multiple local lambdas.
We had similar issues in the past. Although it works as is, I
recommend you make the second one a lambda as well.
Others, please confirm that it's a bug and let's create a bug
report.
Ali
Re: Windows 64-bit import library
On Friday, 20 July 2018 at 04:31:38 UTC, Jordan Wilson wrote: I don't have MSVC, so I built it using mingw, which generated a .a lib. I shall google some more, as I understand it DMD -m64 uses Mingw libs as a fall back when MSVC not found, I compiled Lua using mingw, I can't be too much further away from being able to link in a 64-bit lua import lib in a 64-bit DMD compiled program... In that case, you may be better off using the DerelictLua binding [1] so that you can avoid the link-time dependency and just load the Lua DLL manually at runtime via `DerelictLua.load` [2]. Then it doesn't matter which compiler the DLL was compiled with or which toolchain you use to compile your app. Version 2.0.0-beta.2 (master and 2.0 branches) binds to Lua 5.3 (don't let the beta tag scare you -- it's stable). If you need Lua 5.2 instead, version 1.3.0 binds to it. [1] https://code.dlang.org/packages/derelict-lua [2] https://github.com/DerelictOrg/DerelictLua
Re: Windows 64-bit import library
On Friday, 20 July 2018 at 01:34:39 UTC, Mike Parker wrote: On Thursday, 19 July 2018 at 21:43:35 UTC, Jordan Wilson wrote: Is there any way I can generate the appropriate lib? Else I think I'll need to get hold of the proper import libs that come with the Lua distribution. Lua is extremely easy to build. That will generate the import lib for you. I don't have MSVC, so I built it using mingw, which generated a .a lib. I shall google some more, as I understand it DMD -m64 uses Mingw libs as a fall back when MSVC not found, I compiled Lua using mingw, I can't be too much further away from being able to link in a 64-bit lua import lib in a 64-bit DMD compiled program...
Re: Windows 64-bit import library
On Thursday, 19 July 2018 at 21:43:35 UTC, Jordan Wilson wrote: Is there any way I can generate the appropriate lib? Else I think I'll need to get hold of the proper import libs that come with the Lua distribution. Lua is extremely easy to build. That will generate the import lib for you.
Re: Member function passed through template alias only requiring `this` in certain conditions?
On 07/19/2018 08:12 AM, Emma wrote:
> void test(alias fn1, alias fn2)()
> {
> fn1();
> fn2();
> }
>
> struct Foo
> {
> void foo()
> {
> test!(bar, baz);
> }
>
> void bar()
> {}
>
> void baz()
> {}
> }
> ---
>
> If I try to compile it, dmd complains, which I guess makes sense:
>
> ---
> Error: need this for bar of type void()
> Error: need this for baz of type void()
> ---
>
> However, if I change line 13 from `test!(bar, baz);` to `test!(() =>
> bar, baz);`, it compiles and executes fine, calling both the `bar` and
> `baz` member functions.
>
> Why is this? Shouldn’t it complain about `baz` needing `this`? Does the
> lambda in the first template argument somehow “pull in” the `this`
> reference for `baz`, too?
>
> Thanks!
I think it's a compiler bug. The second template argument should be a
lambda as well. When I added the following lines to test()
pragma(msg, typeof(fn1));
pragma(msg, typeof(fn2));
the output is different:
void delegate() @system
void()
I think it's a bug probably related to multiple local lambdas. We had
similar issues in the past. Although it works as is, I recommend you
make the second one a lambda as well.
Others, please confirm that it's a bug and let's create a bug report.
Ali
Windows 64-bit import library
I'm trying to create an import library from a dll (in this case, a Lua dll). Using dumpbin, I end up with a .def file: EXPORTS luaL_addlstring luaL_addstring luaL_addvalue luaL_argerror luaL_buffinit ... I then use MS lib tool to generate a lib file: lib /def:lua53.def /out:lua53.lib /machine:x64 I'm able to link the lib without errors (i.e. no "not valid lib" errors or anything), but that's as far as I get...any attempt to call functions results in: undefined symbol: luaL_newstate etc. Is there any way I can generate the appropriate lib? Else I think I'll need to get hold of the proper import libs that come with the Lua distribution. Thanks, Jordan
hasUDA with this
I wanted to create a struct with a member function whose behavior
was different depending on whether the struct instance had a
particular UDA.
However, it seems like hasUDA doesn't seem to produce the result
I would have expected here. I tried using getAttributes, but that
didn't work either.
Am I missing something, or should I submit an enhancement request?
import std.traits : hasUDA;
enum test;
struct Foo
{
int x;
bool checkUDA()
{
static if (hasUDA!(this, test))
{
return true;
}
else
{
return false;
}
}
}
void main()
{
import std.stdio : writeln;
@test Foo foo = Foo(1);
static assert(hasUDA!(foo, test));
writeln(foo.checkUDA()); //prints false, expected true
}
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 12:44:30 UTC, Radu wrote:
---
int foo()
{
import std.algorithm, std.range;
auto r = 100.iota.stride(2).take(5);
return r.sum();
}
---
ldc2 -mtriple=wasm32-unknown-unknown-wasm -betterC
-link-internally -L-allow-undefined -release -Os wasm.d
ldc\bin\..\import\core\stdc\stdio.d(31): Error: module
`core.stdc.stdint` import intptr_t not found
ldc\bin\..\import\core\stdc\stdio.d(1149): Error: undefined
identifier FILE
This is a prime example of stuff that should just workTM on
targets like that. I would like to submit some fixes but I
think there needs to be a more systematic approach on making
more core APIs modular.
Removing some superfluous explicit druntime dependencies from
Phobos would be a start. Your (nice) example compiles fine with
this 4-lines Phobos hack:
---
diff --git a/std/ascii.d b/std/ascii.d
index 8622785b1..b3815cafd 100644
--- a/std/ascii.d
+++ b/std/ascii.d
@@ -105,10 +105,10 @@ enum LetterCase : bool
/// Newline sequence for this system.
version(Windows)
immutable newline = "\r\n";
-else version(Posix)
+else// version(Posix)
immutable newline = "\n";
-else
-static assert(0, "Unsupported OS");
+//else
+//static assert(0, "Unsupported OS");
/++
diff --git a/std/typecons.d b/std/typecons.d
index 203ab05f4..49edebfaf 100644
--- a/std/typecons.d
+++ b/std/typecons.d
@@ -68,7 +68,8 @@ Authors: $(HTTP erdani.org, Andrei
Alexandrescu),
*/
module std.typecons;
-import core.stdc.stdint : uintptr_t;
+//import core.stdc.stdint : uintptr_t;
+alias uintptr_t = size_t;
import std.format : singleSpec, FormatSpec, formatValue;
import std.meta; // : AliasSeq, allSatisfy;
import std.range.primitives : isOutputRange;
---
Importing core.stdc.stdint for `uintptr_t` in std.typecons is
particularly troublesome and totally unnecessary. It leads to
importing (see -v output):
core.stdc.stdint
core.stdc.config
core.stdc.stddef
core.stdc.signal
core.stdc.wchar_
core.stdc.stdarg
core.stdc.stdio
core.stdc.time
whereas after the hack, it's only `core.stdc.stdarg`, and no
core.stdc.* hacks for `version(WebAssembly)` are required to
import std.algorithm and std.range.
[I'll open a PR for std.typecons.]
Re: I can has @nogc and throw Exceptions?
On Friday, 13 February 2015 at 19:03:10 UTC, Jonathan Marler
wrote:
This question comes from wanting to be able to throw an
exception in code that is @nogc.
https://dlang.org/changelog/2.079.0.html#dip1008
```d
void main() @nogc
{
throw new Exception("I'm @nogc now");
}
```
Re: Trying to use the libclang Dub package
On Thursday, 19 July 2018 at 14:21:51 UTC, bachmeier wrote: [...] .dub/build/unittest-unittest-linux.posix-x86_64-dmd_2081-A8A607969A46E4CDF45479E7A30874E9/ut.o: In function `_D5parse3raw17__unittest_L64_C9FZ12__dgliteral1MFNaNbNiNfZk': /home/office/.dub/packages/libclang-0.0.6/libclang/tests/parse/raw.d:88: undefined reference to `clang_visitChildren' collect2: error: ld returned 1 exit status Error: linker exited with status 1 /usr/bin/dmd failed with exit code 1. Found the problem. The libclang package is looking for /usr/lib/llvm-3.9/lib/libclang.so. For some reason, Ubuntu has libclang.so.1. Creating a symlink in that directory to libclang.so is a solution.
Member function passed through template alias only requiring `this` in certain conditions?
Hello,
I’ve got this piece of code:
---
import std.stdio;
void test(alias fn1, alias fn2)()
{
fn1();
fn2();
}
struct Foo
{
void foo()
{
test!(bar, baz);
}
void bar()
{}
void baz()
{}
}
---
If I try to compile it, dmd complains, which I guess makes sense:
---
Error: need this for bar of type void()
Error: need this for baz of type void()
---
However, if I change line 13 from `test!(bar, baz);` to `test!(()
=> bar, baz);`, it compiles and executes fine, calling both the
`bar` and `baz` member functions.
Why is this? Shouldn’t it complain about `baz` needing `this`?
Does the lambda in the first template argument somehow “pull in”
the `this` reference for `baz`, too?
Thanks!
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 12:44:30 UTC, Radu wrote: Just tried something similar with new LDC Webassembly support [1] and it fails to compile ... This is a prime example of stuff that should just workTM on targets like that. I would like to submit some fixes but I think there needs to be a more systematic approach on making more core APIs modular. Also, CI support to make sure core API compile on such targets and there are no regressions. Webassembly would be an excellent target as it is both constrained and portable. To be fair, the WebAssembly support is still WIP and hasn't even been released yet ;-) Anyhow, here's how I think we can move forward for now: 1) Open the issue you experienced in the ldc issue tracker 2) Add more tests for -betterC to the test suites (and thus CI) For (2) I have an "old" PR staling around (https://github.com/dlang/phobos/pull/5952), which I should try to rebase and get into Phobos. Then it should be easier to add more -betterC tests for Phobos.
Trying to use the libclang Dub package
I haven't been able to get dpp to build. I've discovered that the problem is with libclang. It installs, but when running the tests, I get the lengthy message below. Obviously I need to install something (running Ubuntu 16.04) but I've got numerous libclang related packages installed already and have no idea what that could be. What dependency am I missing? $ dub test libclang Building package libclang in /home/office/.dub/packages/libclang-0.0.6/libclang/ Package unit-threaded can be upgraded from 0.7.40 to 0.7.46. Use "dub upgrade" to perform those changes. Running custom 'unittest' configuration. Performing "unittest" build using /usr/bin/dmd for x86_64. unit-threaded 0.7.40: target for configuration "library" is up to date. libclang 0.0.6: building configuration "unittest"... tests/parse/cooked.d(22,45): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(23,45): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(27,45): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(28,45): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(32,45): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(33,45): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(79,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(80,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(84,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(85,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(89,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(90,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(114,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(118,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(122,41): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(139,14): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/parse/cooked.d(159,36): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module parse.cooked tests/wrap.d(17,34): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module wrap tests/wrap.d(23,40): Deprecation: test.infra.file.NewTranslationUnit.Cursor is not visible from module wrap Linking... .dub/build/unittest-unittest-linux.posix-x86_64-dmd_2081-A8A607969A46E4CDF45479E7A30874E9/ut.o: In function `_D5clang5parseFNfxAyaxAQfxEQz9__mixin1620TranslationUnitFlagsZSQCj15TranslationUnit': /home/office/.dub/packages/libclang-0.0.6/libclang/source/clang/package.d:35: undefined reference to `clang_createIndex' /home/office/.dub/packages/libclang-0.0.6/libclang/source/clang/package.d:61: undefined reference to `clang_getNumDiagnostics' /home/office/.dub/packages/libclang-0.0.6/libclang/source/clang/package.d:62: undefined reference to `clang_getDiagnostic' /home/office/.dub/packages/libclang-0.0.6/libclang/source/clang/package.d:64: undefined reference to `clang_getDiagnosticSeverity' /home/office/.dub/packages/libclang-0.0.6/libclang/source/clang/package.d:67: undefined reference to `clang_formatDiagnostic' /home/office/.dub/packages/libclang-0.0.6/libclang/source/clang/package.d:63: undefined reference to `clang_disposeDiagnostic' .dub/build/unittest-unittest-linux.posix-x86_64-dmd_2081-A8A607969A46E4CDF45479E7A30874E9/ut.o: In function `_D5clang5parseFNfxAyaxAQfxEQz9__mixin1620TranslationUnitFlagsZ9__lambda5MFNeZEQCy9__mixin189ErrorCode': /home/office/.dub/packages/libclang-0.0.6/libclang/source/clang/package.d:51: undefined reference to `clang_parseTranslationUnit2' .dub/build/unittest-unittest-linux.posix-x86_64-dmd_2081-A8A607969A46E4CDF45479E7A30874E9/ut.o: In function `_D5clang15TranslationUnit6__ctorMFNbNcNfPSQBo1c5index21CXTranslationUnitImplZSQCyQCv': /home/office/.dub/packages/libclang-0.0.6/libclang/source/clang/package.d:108: undefined reference to `clang_getTranslationUnitCursor' .dub/build/unittest-unittest-linux.posix-x86_64-dmd_2081-A8A607969A46E4CDF45479E7A30874E9/ut.o: In function `_D5clang8toStringFNaNbNfSQx1c8CXStringQjZAya':
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 12:40:09 UTC, Zheng (Vic) Luo wrote: On Thursday, 19 July 2018 at 11:35:00 UTC, Seb wrote: Well, since 2.079 it's actually possible to use D without a dependency any runtime (even libc): https://dlang.org/changelog/2.079.0.html#minimal_runtime Also with -betterC you can actually use lots of things from core that don't depend on the runtime. For example, std.algorithm/range works in betterC: https://run.dlang.io/is/38yowj Now, I assume you are asking whether there are plans for a minimal -betterC runtime? There aren't "official" plans, but AFAICT a few people are independently working on this. It might be a good idea to join efforts with them. Thank you for the clarification. I am working on a libc-free project (SAOC project: 2D rasterizer on embedded devices) and just faced some missing symbols(__assert, _memset32) from various libraries in snippets like https://run.dlang.io/is/Kme62V (more missing symbols without C runtime). I am a little bit confused at the boundary of D components: - which subset of standard library can be used under -betterC? Unfortunately, it's not properly defined (or tested) as -betterC is still WIP and there's also WIP to make the standard library more opt-in (e.g. the GC only starts when you actually use it since 2.080). Anyhow, for -betterC there's a lot of all currently supported features: https://dlang.org/spec/betterc.html In terms of the standard library, everything that is either templated or a template will very likely work, e.g. - std.algorithm (mostly) - std.range (mostly) - std.meta - std.typecons I actually have a PR in the works to add a -betterC testsuite to Phobos. - even with -betterC, the compiler sometimes require external symbols like __assert to work, so what are all the required symbols? rust-core limits them to five: memcpy, memcmp, memset, rust_begin_panic and rust_eh_personality. assert is lowered to the C runtime assert with betterC. With -betterC you should still have access to memcpy, just import core.stdc.string (see: https://dlang.org/library/core/stdc/string/memcpy.html). If you don't use the C runtime which provides assert, memcpy etc. you need to define them yourself in the minimal runtime. However, I think GDC/LDC provide intrinsics for a few of these operations. See e.g. https://github.com/JinShil/stm32f42_discovery_demo/tree/master/source/runtime Is there any way to make this project remain as a "library" with a few explicit external symbol dependencies instead of bundling a minimal d-runtime/libc stubs? Since eliminating d-runtime looks like an overkill in the most of time (almost every embedded project defines their own size_t/string/bitop/attribute, hope to see a core subset of d-runtime to prevent reinventing the wheel. Well, if you just use -betterC you still have access to all definitions in druntime (like size_t). You just need to avoid linking with the C runtime when you absolutely want to avoid it (i.e. build the executable). Here's a simple example of a D program for Linux x86_64 without any runtime that still accepts arguments , can do primitive output and uses declarations from druntime like size_t: https://gist.github.com/wilzbach/1bb812b9bdd2fed693b0ee4a6f8a2fd8 tl;dr: the declarations in druntime are still usable - you simply can't call libc functions if you plan to build an executable from your library that should be runtime free.
Re: Configuring DerelictGL3
On Thursday, 19 July 2018 at 09:41:34 UTC, Mike Parker wrote: Are you doing all of that in the main thread, or a separate one? It's all on a separate thread, but I checked every single reference I could find after posting yesterday, and the OGL context is never referenced outside of the thread which created it(I actually remember jumping through several hoops when building my display handler to ensure this). The problem hadn't cropped up before updating to the latest versions of DMD and Derelict, even when spawning 3 separate contexts for 3 separate windows when I was initially testing. (which wouldn't be causing the problem this time around either, since I'm only working with one window right now)
Re: Disabling struct destructor illegal?
On Thursday, July 19, 2018 10:04:34 RazvanN via Digitalmars-d-learn wrote: > I just don't understand why you would ever mark the destructor of > a struct with @disable. When is that useful? If it's not, why not > just forbit it? There's nothing special about destructors here. You can @disable any member function, and if you do, you get an error if you try to use it, since it's @disabled. So, code that doesn't use an @disabled function works just fine, and any code that attempts to use it gets an error. For the vast majority of functions, @disabling them really doesn't make any sense, but from what I can tell, @disable was simply implemented as a general feature rather than trying to allow specific functions to be @disabled and then have to add code for each function that we want to be able to @disable. So, the fact that you can @disable destructors is just the result of the feature being implemented in a simple, straightforward manner. But while I agree that @disabling destructors doesn't make sense, I don't see why it would actually be a problem that it's allowed. Anyone who tries it is just going to quickly get errors and have to remove @disable from the destructor. Explicitly make it illegal to mark a destructor with @disabled doesn't really add anything from what I can see. - Jonathan M Davis
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 11:35:00 UTC, Seb wrote: Well, since 2.079 it's actually possible to use D without a dependency any runtime (even libc): https://dlang.org/changelog/2.079.0.html#minimal_runtime Also with -betterC you can actually use lots of things from core that don't depend on the runtime. For example, std.algorithm/range works in betterC: https://run.dlang.io/is/38yowj Now, I assume you are asking whether there are plans for a minimal -betterC runtime? There aren't "official" plans, but AFAICT a few people are independently working on this. It might be a good idea to join efforts with them. Thank you for the clarification. I am working on a libc-free project (SAOC project: 2D rasterizer on embedded devices) and just faced some missing symbols(__assert, _memset32) from various libraries in snippets like https://run.dlang.io/is/Kme62V (more missing symbols without C runtime). I am a little bit confused at the boundary of D components: - which subset of standard library can be used under -betterC? - even with -betterC, the compiler sometimes require external symbols like __assert to work, so what are all the required symbols? rust-core limits them to five: memcpy, memcmp, memset, rust_begin_panic and rust_eh_personality. Is there any way to make this project remain as a "library" with a few explicit external symbol dependencies instead of bundling a minimal d-runtime/libc stubs? Since eliminating d-runtime looks like an overkill in the most of time (almost every embedded project defines their own size_t/string/bitop/attribute, hope to see a core subset of d-runtime to prevent reinventing the wheel.
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 11:35:00 UTC, Seb wrote:
On Thursday, 19 July 2018 at 10:27:36 UTC, Zheng (Vic) Luo
wrote:
Current implementation of d-runtime relies on a lot of symbols
from libc, librt, libpthread, which makes it hard to create a
minimal runtime used for embedded devices. Although there are
some unofficial minimal versions of d-runtime, many of them
lack maintenance and outdates rapidly. I was wondering that is
there any plan for a https://doc.rust-lang.org/core/ library
in D world, which only depends several explicitly-defined
symbols?
Well, since 2.079 it's actually possible to use D without a
dependency any runtime (even libc):
https://dlang.org/changelog/2.079.0.html#minimal_runtime
Also with -betterC you can actually use lots of things from
core that don't depend on the runtime. For example,
std.algorithm/range works in betterC:
https://run.dlang.io/is/38yowj
Now, I assume you are asking whether there are plans for a
minimal -betterC runtime?
There aren't "official" plans, but AFAICT a few people are
independently working on this. It might be a good idea to join
efforts with them.
Just tried something similar with new LDC Webassembly support [1]
and it fails to compile
---
int foo()
{
import std.algorithm, std.range;
auto r = 100.iota.stride(2).take(5);
return r.sum();
}
---
ldc2 -mtriple=wasm32-unknown-unknown-wasm -betterC
-link-internally -L-allow-undefined -release -Os wasm.d
ldc\bin\..\import\core\stdc\stdio.d(31): Error: module
`core.stdc.stdint` import intptr_t not found
ldc\bin\..\import\core\stdc\stdio.d(1149): Error: undefined
identifier FILE
This is a prime example of stuff that should just workTM on
targets like that. I would like to submit some fixes but I think
there needs to be a more systematic approach on making more core
APIs modular.
Also, CI support to make sure core API compile on such targets
and there are no regressions. Webassembly would be an excellent
target as it is both constrained and portable.
1 - https://wiki.dlang.org/Generating_WebAssembly_with_LDC
Re: taskPool.reduce vs algorithm.reduce
On Wednesday, 11 July 2018 at 10:07:33 UTC, Timoses wrote: On Wednesday, 11 July 2018 at 08:31:30 UTC, Dorian Haglund wrote: [...] As the error message says taskPool.reduce is a non-global template. It's embedded in a taskPool struct. I can't say what the reason is that a delegate cannot be used with such a template. I'd be interested in hearing what the reason is. (See Paul's reply). I'm trying to trick around it, but can't get this to work... https://run.dlang.io/is/EGbtuq You can make it all global: https://run.dlang.io/is/Kf8CLC From my own experience: Use only parallel foreach and save yourself a lot of hassle. That just works.
Re: Disabling struct destructor illegal?
On Thursday, 19 July 2018 at 10:04:34 UTC, RazvanN wrote:
I just don't understand why you would ever mark the destructor
of a struct with @disable. When is that useful? If it's not,
why not just forbit it?
struct S1 {
~this() { /* stuff */ }
}
struct S2 {
S1 s;
@disable ~this();
}
The idea would be that S1's destructor not be called when S2 goes
out of scope. Now, that's not how @disable works, but it's a
logical thought.
The way @disable does work though, isn't to remove the marked
function, but forbid it from being called.
why not make it illegal to disable the destructor if disabling
it will surely result in errors wherever the struct is used.
Because the error message when you use it clearly states what's
wrong?
It's actually possible to use a struct with a @disabled
destructor:
struct S {
int i;
@disable ~this() {}
}
struct Nodestruct(T) {
ubyte[T.sizeof] _payload;
@property
ref T value() {
return *cast(T*)_payload.ptr;
}
}
The trick is, as you can see, to never have an instance on the
stack. This gives a small advantage over @disable this(this) and
@disable this() in that it's actually impossible to have a
stack-allocated instance.
--
Simen
Re: Is there any plan for a dependency-free subset of "core" runtime?
On Thursday, 19 July 2018 at 10:27:36 UTC, Zheng (Vic) Luo wrote: Current implementation of d-runtime relies on a lot of symbols from libc, librt, libpthread, which makes it hard to create a minimal runtime used for embedded devices. Although there are some unofficial minimal versions of d-runtime, many of them lack maintenance and outdates rapidly. I was wondering that is there any plan for a https://doc.rust-lang.org/core/ library in D world, which only depends several explicitly-defined symbols? Well, since 2.079 it's actually possible to use D without a dependency any runtime (even libc): https://dlang.org/changelog/2.079.0.html#minimal_runtime Also with -betterC you can actually use lots of things from core that don't depend on the runtime. For example, std.algorithm/range works in betterC: https://run.dlang.io/is/38yowj Now, I assume you are asking whether there are plans for a minimal -betterC runtime? There aren't "official" plans, but AFAICT a few people are independently working on this. It might be a good idea to join efforts with them.
Is there any plan for a dependency-free subset of "core" runtime?
Current implementation of d-runtime relies on a lot of symbols from libc, librt, libpthread, which makes it hard to create a minimal runtime used for embedded devices. Although there are some unofficial minimal versions of d-runtime, many of them lack maintenance and outdates rapidly. I was wondering that is there any plan for a https://doc.rust-lang.org/core/ library in D world, which only depends several explicitly-defined symbols?
Re: Disabling struct destructor illegal?
On Thursday, 19 July 2018 at 09:50:32 UTC, Jim Balter wrote:
On Thursday, 19 July 2018 at 08:50:15 UTC, RazvanN wrote:
struct A
{
int a;
@disable ~this() {}
}
void main()
{
A a = A(2);
}
Currently, this code yields:
Error: destructor `A.~this` cannot be used because it is
annotated with @disable
I was expecting that disabling the destructor would make it as
if the struct does not have a destructor
Why? That's not the semantics of @disable. And why would you
want that? What are you actually trying to achieve?
I just don't understand why you would ever mark the destructor of
a struct with @disable. When is that useful? If it's not, why not
just forbit it?
Re: Disabling struct destructor illegal?
On Thursday, 19 July 2018 at 08:50:15 UTC, RazvanN wrote:
struct A
{
int a;
@disable ~this() {}
}
void main()
{
A a = A(2);
}
Currently, this code yields:
Error: destructor `A.~this` cannot be used because it is
annotated with @disable
I was expecting that disabling the destructor would make it as
if the struct does not have a destructor
Why? That's not the semantics of @disable. And why would you want
that? What are you actually trying to achieve?
, instead it makes the program not compile. I find this
behavior odd: why not make it illegal to disable the destructor
if disabling it will surely result in errors wherever the
struct is used.
Because it won't surely result in errors wherever the struct is
used ... you yourself provide an example below where it doesn't.
The only
situation where the code will compile is A is never used
directly.
Eh? You immediately give a contrary example:
To make matters even more confusing, this code compiles:
class A
{
int a;
@disable ~this() {}
}
void main()
{
A a = new A();
}
Why is that confusing? Why shouldn't it compile? The A that you
created is on the heap, so its destructor is never invoked, so
what would cause it not to compile?
So, is this a bug or am I missing something?
Yoroshiku onegaishimasu,
RazvanN
Re: Configuring DerelictGL3
On Thursday, 19 July 2018 at 00:27:58 UTC, Entity325 wrote: So I'm using the standard process: DerelictGL3.load(); glContext = SDL_GL_CreateContext(sdlWindow); GLVersion glVersion = DerelictGL3.reload(); About 1/3 of the time, the program hangs on the 3rd line and never gets past it. Currently tracking whether admittedly odd things I'm doing with threads might be the culprit. I have a growing suspicion they might be. Are you doing all of that in the main thread, or a separate one? Looking forward to the BindBC release. I assume it's more or less intended to be a drop-in replacement for Derelict, with normal allowances for version-to-version updating, but more stable. The loader is not a drop-in replacement. Different function names, different error-handling mechanism, different compile-time configuration. And it has nothing to do with stability. The Derelict packages are quite stable. The whole point of BindBC is to make the loader fully @nogc and -betterC compatible while simultaneously making maintenance more sensible than what Derelict evolved into.
Disabling struct destructor illegal?
struct A
{
int a;
@disable ~this() {}
}
void main()
{
A a = A(2);
}
Currently, this code yields:
Error: destructor `A.~this` cannot be used because it is
annotated with @disable
I was expecting that disabling the destructor would make it as if
the struct does not have a destructor, instead it makes the
program not compile. I find this behavior odd: why not make it
illegal to disable the destructor if disabling it will surely
result in errors wherever the struct is used. The only situation
where the code will compile is A is never used directly. To make
matters even more confusing, this code compiles:
class A
{
int a;
@disable ~this() {}
}
void main()
{
A a = new A();
}
So, is this a bug or am I missing something?
Yoroshiku onegaishimasu,
RazvanN
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Thursday, 19 July 2018 at 06:35:36 UTC, Simen Kjærås wrote: On Wednesday, 18 July 2018 at 11:28:54 UTC, Timoses wrote: But why is a context pointer a problem? Is it problematic because the context pointer to the main scope can not guarantee `immutable`? E.g. if I happened to use data from main in a function of the immutable struct then... well then what? The struct would still be immutable, but what would prevent a function from using non-immutable data? It's a known bug: https://issues.dlang.org/show_bug.cgi?id=18563 In the associated discussion (https://forum.dlang.org/thread/p7lp2b$1jod$1...@digitalmars.com), Steven Schveighoffer points out that an immutable struct may be passed to other threads, which would give one thread access to another thread's stack. This could be a good enough reason to prevent this kind of conversion, but a better error message would still make sense. -- Simen Thanks so much for the pointer, Simen. Interesting discussion.
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Wednesday, 18 July 2018 at 11:28:54 UTC, Timoses wrote: But why is a context pointer a problem? Is it problematic because the context pointer to the main scope can not guarantee `immutable`? E.g. if I happened to use data from main in a function of the immutable struct then... well then what? The struct would still be immutable, but what would prevent a function from using non-immutable data? It's a known bug: https://issues.dlang.org/show_bug.cgi?id=18563 In the associated discussion (https://forum.dlang.org/thread/p7lp2b$1jod$1...@digitalmars.com), Steven Schveighoffer points out that an immutable struct may be passed to other threads, which would give one thread access to another thread's stack. This could be a good enough reason to prevent this kind of conversion, but a better error message would still make sense. -- Simen
Re: New to GDC on ARM 32-bit Ubuntu
Am Tue, 17 Jul 2018 04:51:04 + schrieb Cecil Ward: > I am getting an error when I try and compile anything with the GDC > compiler which is coming up associated with source code within a D > include file which is not one of mine > > I am using a Raspberry Pi with Ubuntu 16.04 and have just done an > "apt-get install gdc". Using ldc works fine. > > The error is : > root@raspberrypi:~# gdc mac_hex.d -O3 -frelease > /usr/include/d/core/stdc/config.d:58:3: error: static if conditional > cannot be at global scope > static if( (void*).sizeof > int.sizeof ) > ^ These files in /usr/include/d probably belong to the ldc package and therefore are not compatible with gdc. gdc automatically picks up files in /usr/include/d so this folder should not contain compiler-specific files. I think this has been fixed in more recent ubuntu releases. For now you could uninstall ldc to see if this is really the problem. -- Johannes
