Re: Using D for Raspberry Pi expirements
On Sunday, 29 September 2019 at 11:36:00 UTC, aberba wrote: I have no idea how to do that from D. Any help/resources on that? You should be able to use the techniques at https://dlang.org/spec/interfaceToC.html to declare the C functions that you wish to use in your *.d source files, and then, when you compile, pass `-lpigpiod_if2` to the linker. Mike
Re: Using D for Raspberry Pi expirements
On Wednesday, 25 September 2019 at 23:56:45 UTC, aberba wrote: I'm looking for resources on using D for basic Raspberry Pi programming...stuff like turning on and off an LED light. I believe it requires being able to call the Raspberry OS core APIs from D as available in Python. Anyone here tried something like that using D? I haven't tried with D yet, but I use C# and mono calling into the pigpio C library (http://abyz.me.uk/rpi/pigpio/pdif2.html) and it workes great. You should be able to do the same with D. Mike
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote: There's probably at least one bug report on it, but as I understand it, it's not a bug in the sense that the implementation is currently expected to handle such a case. It's an area where betterC should be improved upon, but it would be an enhancement, not a bug fix. Yes. The point is that libraries have to be written with betterC and compile-time evaluation in mind. If they aren't the code is likely not going to work in those use cases. Much of the code in Phobos was written long before betterC was introduced. There are probably changes that could be made to Phobos so the OP could get a build, but that requires someone with enough interest in the issue to volunteer their time and talent to improve the implementation for betterC and compile-time use cases. We have a GSoC student making changes the druntime to help with this matter and I have been picking away at it too. It will take time and could use more contributors. Mike
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 12:01:40 UTC, Oleg B wrote:
Hello everyone!
I try build this code with betterC
import core.stdc.stdio;
import std.format : format;
extern(C) int main()
{
mixin(format!`enum str = "%s\0";`("hello"));
fprintf(stderr, "%s\n", str.ptr);
return 0;
}
but compilation fails
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6278):
Error: Cannot use try-catch statements with -betterC
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6308):
Error: template instance
`std.format.checkFormatException!("enum str = \"%s\\0\";",
string)` error instantiating
onlineapp.d(6):instantiated from here: format!("enum
str = \"%s\\0\";", string)
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6311):
while evaluating: static assert(!e)
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3204):
Error: TypeInfo cannot be used with -betterC
Is this a bug?
https://run.dlang.io/is/TG1uhg
If you read the documentation for betterC
(https://dlang.org/spec/betterc.html#consequences) you'll see
that there are features of the D language which are not
supported. Therefore, libraries that use such features (e.g.
std.format, std.array) are also not supported, and that is why
you are encountering such errors.
There are some features of Phobos which can be used in betterC
builds, but you're going to find that it's hit-and-miss.
Mike
Re: Stack-based @nogc dynamic array
On Thursday, 16 May 2019 at 12:16:26 UTC, Marco de Wild wrote:
Or are there any tips to roll my own implementation?
I took a stab at it:
---
@nogc:
nothrow:
pure:
struct NoGcArray(size_t maxSize, T)
{
private T[maxSize] _buffer;
private T[] _slice;
private size_t _frontIndex;
size_t length() const
{
return _slice.length;
}
void opOpAssign(string op)(T element)
{
static if(op == "~")
{
_buffer[_frontIndex + length] = element;
_slice = _buffer[_frontIndex..(length + 1)];
}
else
{
static assert(false, "Only concatenation supported");
}
}
T opIndex(size_t index) const
{
return _slice[index];
}
T front() const
{
return _slice[0];
}
void popFront()
{
_frontIndex++;
_slice = _slice[1..$];
}
bool empty() const
{
return _slice.length == 0;
}
}
void main()
{
import std.algorithm : sum, map;
NoGcArray!(4, int) array;
array ~= 420;
array ~= 42;
assert(array.map!(x => x*2).sum == 924);
}
---
Mike
Re: Do @property attributes not allow postincrement operators
On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote:
Do @property attributes not allow postincrement operators?
import std.stdio;
struct Foo {
@property bar() { return 10; }
@property bar(int x) { writeln(x); }
}
void main()
{
Foo foo;
writeln(foo.bar); // actually calls foo.bar();
foo.bar = 10; // calls foo.bar(10);
// following doesn't work
foo.bar++; // would expect this to call foo.bar(foo.bar() +
1);
// have to use:
foo.bar = foo.bar + 1;
writeln(foo.bar);
}
It's a long standing issue (going on 7 years old)
https://issues.dlang.org/show_bug.cgi?id=8006
There's an implementation at
https://github.com/dlang/dmd/pull/7079
It requires a DIP, which you can find at
https://github.com/dlang/DIPs/pull/97
However, in preparing that DIP other issues were discovered with
@property, so we need to create a DIP to fix those issues first.
I plan on getting to it, but there are other pressing things I'm
trying to get out of the way.
Mike
Re: Where is GDC being developed?
On Thursday, 21 March 2019 at 22:51:21 UTC, James Blachly wrote: Thanks -- I also tried to figure out how to install GDC just yesterday and gave up. All wiki links and google top results seemed dead ends. I'm also a little puzzled by how GDC is structured, but I have learned a few things with the help of some of the GDC developers, and I'll share my understanding below (though be aware that my assumptions may be wrong). GDC is in a weird state right now where it needs to boostrap itself. The bootstrap compiler has a front-end written in C++, but the lastest GDC on GitHub has a front-end written in D. My understanding is that this bootstrap compiler with the front-end written in C++ is what is being released with GCC 9. Since GCC always needs to be able to be built with a prior version of GCC, GCC 10 will be the first release with the latest D frontend. So, to build your own GDC compiler, you need to first build the bootstrap compiler. I have a script for that at https://github.com/JinShil/native-gdc Then, using the bootstrap compiler, you can build the latest GDC with the D frontend from GitHub. I have a script for that too, but it is only for building an ARM cross-compiler. See https://github.com/JinShil/arm-none-eabi-gdc Mike
Re: Where to start with SafeD?
On Wednesday, 13 February 2019 at 22:29:18 UTC, solidstate1991 wrote: When I tried to apply to a position at Symmetry, I've got a criticism from Atila Neves that some of my code relied too much on memcpy, thus making it unsafe. After digging into std.array, I found some function that could possibly replace it to emulate writing in the middle of a file, but at least for VFile, I need some type agnostic solution. I don't understand your use case, but for me, I try not to escape the type system. Instead of using void*, I recommend templating. That is the approach I took here: https://github.com/JinShil/memcpyD It still does explicit casts to prevent code bloat, which is still escaping the type system, but at least it avoids pointer arithmetic. I'm not sure if that's helpful, but regardless, there it is. Mike
Re: is this a betterC bug ?
On Wednesday, 15 August 2018 at 08:14:53 UTC, Petar Kirov
[ZombineDev] wrote:
It's not a bug, it's all about how the type system is set up.
The type of an array literal expression like `[1, 2, 3]` is
`int[]` (a slice of an array of ints), so no matter if you do:
auto readonly(T)(const(T)[] x) { return x; }
auto arr1 = [1, 2, 3];
auto arr2 = [1, 2, 3].readonly;
constarr3 = [1, 2, 3];
enum arr4 = [1, 2, 3];
static immutable arr5 = [1, 2, 3];
scopearr6 = [1, 2, 3];
In all instances the type will be `int[]` modulo type
qualifiers.
Static arrays are completely different types, that just happen
to accept
assignments from slices. Their two defining properties are:
1. Their length is fixed at compile-time, meaning that you can
do:
import std.array, std.meta;
auto x = [1, 2, 3, 4, 5].staticArray;
enum length = x.length;
pragma (msg, length);
alias seq = AliasSeq!(0, 42, length);
static foreach (i; 0 .. length) { }
static foreach (i; seq) { }
2. Where slices are reference types, static arrays are value
types which means that each assignment will copy an entire
array.
Basically they behave like a `struct { int _arr_0 = 0, _arr_1 =
1, _arr_2 = 2; }`.
https://run.dlang.io/is/iD9ydu
Thanks for the detailed explanation; it make sense now.
Mike
Re: is this a betterC bug ?
On Tuesday, 14 August 2018 at 17:22:42 UTC, Seb wrote: FYI: staticArray will be part of 2.082, it already works with dmd-nightly: That just seems wrong. Isn't the fact that `staticArray` is needed a bug in the compiler? I think the compiler could have lowered to something like that automatically to avoid the library workaround. Mike
Re: Concat enum of strings into one string
On Tuesday, 14 August 2018 at 13:42:04 UTC, Andrey wrote:
Hello,
I have a enum:
enum Type : string
{
One = "Q1",
Two = "W2",
Three = "R3"
}
I want to concat it in compile-time:
enum result = doConcat!Type();
And get this result:
writeln(result); // output: "Q1 W2 R3"
Delimiter here is space symbol.
How do do it?
I think you just need to use the concatenation operator `~`.
enum Type : string
{
One = "Q1",
Two = "W2",
Three = "R3"
}
enum concatenation = Type.One ~ " " ~ Type.Two ~ " " ~ Type.Three;
void main()
{
import std.stdio: writeln;
writeln(concatenation);
}
Mike
Re: Where is TypeInfo_Class.m_init set
On Monday, 30 July 2018 at 22:40:21 UTC, Hakan Aras wrote: I'm trying to use extern(C++) classes with -betterC and I would like to initialize their members properly. I would also like to be able to use `extern(C++)` classes without the runtime, but I haven't been able to allocate any time to it yet. If you're trying to use `extern(C++)` classes with betterC, and the compiler is complaining about `TypeInfo` give me an example illustrating the problem, and I might be able to submit a fix to the compiler. Mike
Re: Where is TypeInfo_Class.m_init set
On Tuesday, 31 July 2018 at 00:29:45 UTC, Mike Franklin wrote: I'm not sure if this is right, but check https://github.com/dlang/dmd/blob/792fe5379af310cbd9348eca910cd5f8889d57ac/src/dmd/toobj.d#L368 Actually, this looks more like what you're looking for: https://github.com/dlang/dmd/blob/792fe5379af310cbd9348eca910cd5f8889d57ac/src/dmd/toobj.d#L1202 Mike
Re: Where is TypeInfo_Class.m_init set
On Monday, 30 July 2018 at 22:40:21 UTC, Hakan Aras wrote: Sorry if this is the wrong category. Where in the druntime is m_init of TypeInfo_Class set? I'm trying to use extern(C++) classes with -betterC and I would like to initialize their members properly. I don't think it is set in druntime, but rather directly emitted to the binary by the compiler as part of the object code generation. I'm not sure if this is right, but check https://github.com/dlang/dmd/blob/792fe5379af310cbd9348eca910cd5f8889d57ac/src/dmd/toobj.d#L368 Afterall, the initializer is static data, so there's no need to expend resources setting it at runtime. Mike
Re: Windows 7 x64. Prevent appearing of console with GUI application
On Tuesday, 24 July 2018 at 08:09:33 UTC, ANtlord wrote:
So... how prevent appearing of console on the startup of the
application?
Here's my test
---
module HelloMsg;
import core.runtime;
import std.utf;
import core.sys.windows.windows;
auto toUTF16z(S)(S s)
{
return toUTFz!(const(wchar)*)(s);
}
extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize();
result = myWinMain(hInstance, hPrevInstance, lpCmdLine,
iCmdShow);
Runtime.terminate();
}
catch (Throwable o)
{
MessageBox(null, o.toString().toUTF16z, "Error", MB_OK |
MB_ICONEXCLAMATION);
result = 0;
}
return result;
}
int myWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
MessageBox(NULL, "Hello, Windows!", "Your Application", 0);
return 0;
}
---
dmd -L/SUBSYSTEM:WINDOWS main.d
main.obj : error LNK2019: unresolved external symbol MessageBoxW
referenced in function WinMain
dmd -L/SUBSYSTEM:WINDOWS main.d User32.lib
Success!
Executing from PowerShell: no console
Executing from Command Prompt: no console
Double-clicking in Explorer: no console
Windows 10 64-bit
Mike
Re: Find out druntime/import and phobos folder on Linux
On Saturday, 14 July 2018 at 19:04:01 UTC, Andre Pany wrote: Somehow also the DMD executable needs to know which Phobos/DRuntime it should use. How does DMD is working here? Maybe I can do the same... DMD determines default import and library paths from the dmd.conf file typically at /etc/dmd.conf. Mike
Re: scope(success) lowered to try-catch ?
On Sunday, 17 June 2018 at 10:58:29 UTC, Cauterite wrote:
---
// main.d
void main() {
scope(success) {}
}
dmd -betterC main.d
Error: Cannot use try-catch statements with -betterC
---
You can see what the compiler is doing at
https://run.dlang.io/is/5BZOQV and clicking on the "AST" button.
It produces the following:
import object;
void main()
{
bool __os2 = false;
try
{
}
catch(Throwable __o3)
{
__os2 = true;
throw __o3;
}
if (!__os2)
{
}
return 0;
}
The compiler could probably lower that to something more
intelligent so it could be used in -betterC. I rule it a bug.
Mike
Re: implicit or module-wide @nogc
On Wednesday, 13 June 2018 at 07:19:24 UTC, Gokhhy wrote:
Nevermind, it doesn't affect functions inside classes and
structs.
Yeah, that's kindof unfortunate isn't it. Just do the same thing
within the class/struct scope.
class C {
@nogc:
void nogcMethod1() {}
void nogcMehtod2() {}
}
I would be interested in what influenced the design decision to
make opting out of garbage collection so difficult.
Because D is more evolution then intelligent design,
unfortunately.
Mike
Re: implicit or module-wide @nogc
On Wednesday, 13 June 2018 at 06:45:27 UTC, Gokhhy wrote:
Is there a way to define an entire module as @nogc or otherwise
make it so I don't have to qualify every single function as
@nogc?
You can put attributes at the top of a module followed by a ":"
to have them apply to everything below them.
module mymodule;
@nogc:
void nogcFunction1() { }
void nogcFunction2() { }
Mike
Re: Using stdin/out in a windows application bugs only when compiled to 64bit.
On Thursday, 7 June 2018 at 19:19:55 UTC, realhet wrote:
Hi,
The following narrow test program works fine when compiled with
DMD to 32bit target:
import std.stdio, core.sys.windows.windows, core.runtime;
extern(Windows) int WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR lpCmdLine, int iCmdShow)
{
Runtime.initialize;
writeln("Hello");
stdout.flush; //exception
readln; //exception
return 0;
}
It shows the console window and waits for user input at readln.
If I try to compile this to 64bit target or with LDC (both 32
and 64) it gets privileged instruction exception at
stdout.flush. If I comment out flush then it fails at readln.
Is there a way to fix this? I don't wanna lose the console
window even on 64bit.
Thanks!
You might be running into this issue:
https://issues.dlang.org/show_bug.cgi?id=6880
I recall similar issues with a project I was working on, but I
don't remember all the details now. Anyway, I ended up with this
in the end.
https://github.com/JinShil/Dsus2/blob/b08c66c6a6efb46134c409aac9f1c600d62f99fa/Dsus2/main.d#L300-L331
Mike
Re: Conditionally set nothrow: for a block of code.
On Thursday, 24 May 2018 at 18:51:31 UTC, Mike Franklin wrote:
I'm trying to find a way to declare a block of code `nothrow:`
when compiling with -betterC, but not `nothrow` when not
compiling with -betterC.
The solution is needed for this PR:
https://github.com/dlang/druntime/pull/2184/files#r188627707
Walter came up with a solution to this; put the code that is
conditionally `nothrow` in a template and mix it in in the
appropriate branch.
void test() { }
mixin template code()
{
extern(C) void main()
{
test(); // This should throw an error in -betterC
because `main` is
// `nothrow` but `test` isn't. It doesn't work
}
}
version(D_BetterC)
{
nothrow:
mixin code;
}
else
{
mixin code;
}
Thanks, Walter.
Mike
Re: Getter an lvalue and cannot be modified
On Sunday, 27 May 2018 at 23:21:05 UTC, IntegratedDimensions wrote: I came across a few posts mentioning this after the fact. It's been this way since at least 2012 so... It's now may so not sure how much longer we'll have to wait. That pull seems to have stalled. So close but so far away ;/ It's currently on me to finish the DIP, but I'd rather find a way to implement this in the library, so we can deprecate @property altogether favoring fewer, more powerful language features. The more I think about it though, that's probably not feasible. Anyway, after I finish the DIP it will have to go through the review process, and given the current rate of review, that's going to take a very long time, unfortunately. Mike
Re: Getter an lvalue and cannot be modified
On Sunday, 27 May 2018 at 09:23:09 UTC, IntegratedDimensions
wrote:
C[] c;
@property C[] get() { return c; }
get ~= something;
errors out, yet
auto q = get;
q ~= something;
is fine.
Why is D thinking that ~= is being applied to get, the
function, rather than what it returns?
Also
When I converted a field in to a property, an AA, it is
returning null rather than being initialized by default. Seems
like properties are broke. I'd expect a property getter to
behave, for all intents and purposes as if it were field. I
shouldn't have to have a temp variable to be able to use it as
such.
You'll probably get your answer and more by reading this:
https://github.com/dlang/DIPs/pull/97
TL;DR: return `ref C[]`
Mike
Conditionally set nothrow: for a block of code.
I'm trying to find a way to declare a block of code `nothrow:`
when compiling with -betterC, but not `nothrow` when not
compiling with -betterC.
The solution is needed for this PR:
https://github.com/dlang/druntime/pull/2184/files#r188627707
Attempt #1
--
void test() { }
version(D_BetterC)
{
nothrow:
}
extern(C) void main()
{
test(); // This should throw an error in -betterC because
`main` is
// `nothrow` but `test` isn't. It doesn't work
}
Attempt #2
--
version(D_BetterC)
{
enum isNoThrow = true;
}
else
{
enum isNoThrow = false;
}
void test() { }
static if (isNoThrow)
{
nothrow:
}
extern(C) void main()
{
test(); // This should throw an error in -betterC because
`main` is
// `nothrow` but `test` isn't. It doesn't work
}
Attempt #3
--
version(D_BetterC)
{
enum nothrowValue = "nothrow:";
}
else
{
enum nothrowValue = "";
}
void test() { }
mixin(nothrowValue);
extern(C) void main()
{
test(); // This should throw an error in -betterC because
`main` is
// `nothrow` but `test` isn't. It doesn't work
}
Given that the PR above is for object.d, I can't turn the entire
object.d source file into a string and conditionally mix that in.
Does anyone have a solution to this?
Thanks,
Mike
Re: property += operator
On Thursday, 10 May 2018 at 21:16:12 UTC, Jonathan M Davis wrote: IIRC, there's a DIP for trying to make += work with just getters and setters, but I don't know if we're ever going to see anything like it in the language. Yes, the DIP is here: https://github.com/dlang/DIPs/pull/97 It's currently stalled while I elaborate on the merits, or lack thereof, of a library solution. The best library implementation I've seen is https://forum.dlang.org/post/mqveusvzkmkshrzws...@forum.dlang.org I'm exploring the idea of continuing with the DIP, or adding features (or removing limitations of the language) to make a library implementation more appealing. IMO, it'd be great if we could add more composable primitives to the language, and get rid of quirky features like @property. Mike
Re: `this` and nested structs
On Thursday, 10 May 2018 at 06:22:37 UTC, Jonathan M Davis wrote: Structs don't have that. Should they?
`this` and nested structs
Consider the following code:
---
struct S
{
// intentionally not `static`
struct SS
{
int y() { return x; } // Error: need `this` for `x` of
type `int`
}
int x;
SS ss;
}
void main()
{
S s;
s.ss.y();
}
---
If I change `return x;` to `return this.x;` then of course it
emits the following error:
Error: no property `x` for type `SS`
My understanding is that `SS` should have a context pointer to an
instance of `S`, but how do I navigate the members of `S` and
`SS`. Is this a bug?
Thanks,
Mike
My understanding is that nested structs have an implicit context
pointer to their containing scope.
Re: Warning on self assignment
On Wednesday, 25 April 2018 at 01:20:13 UTC, Mike Franklin wrote: It appears a bug has already been filed (https://issues.dlang.org/show_bug.cgi?id=11970). I'll see if I can fix it. https://github.com/dlang/dmd/pull/8208 We'll see what happens.
Re: Warning on self assignment
On Wednesday, 25 April 2018 at 01:08:46 UTC, Arun Chandrasekaran
wrote:
So I was telling my colleague that D would warn on self
assignment, but found that I was wrong.
https://run.dlang.io/is/HLhtek
```
module a;
import std.stdio;
void main() {
string a;
a = a; // Can the compiler warn at this line that
there is no effect?
writeln(a);
return;
}
```
Are people using self assignment of structs as a way of
force-running the postblit? Is there a valid use case for that?
Mike
Re: Warning on self assignment
On Wednesday, 25 April 2018 at 01:08:46 UTC, Arun Chandrasekaran
wrote:
So I was telling my colleague that D would warn on self
assignment, but found that I was wrong.
https://run.dlang.io/is/HLhtek
```
module a;
import std.stdio;
void main() {
string a;
a = a; // Can the compiler warn at this line that
there is no effect?
writeln(a);
return;
}
```
It appears a bug has already been filed
(https://issues.dlang.org/show_bug.cgi?id=11970). I'll see if I
can fix it.
Mike
Re: dynamically allocating on the stack
On Sunday, 22 April 2018 at 00:41:34 UTC, Nicholas Wilson wrote: You're not using the C library version of it, the compiler does the stack space reservation inline for you. There is no way around this. I'm not convinced. I did some no-runtime testing and eventually found the implementation in druntime here: https://github.com/dlang/druntime/blob/master/src/rt/alloca.d Mike
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote: alloca is an intrinsic, and part of the language technically -- it has to be. From what I can tell `alloca` is only available in the platform's C standard library (actually for Linux it appears be part of libgcc as `__builtin_alloca`; `alloca` is just and alias for it). Of course I can use 3rd party libraries like C to do this, but it seems like something useful to have in the language for certain use case and optimizations. Also, my immediate use case if for bare metal microcontroller programming where I'm intentionally avoid C and looking for a way to do this in idiomatic D. Mike
Re: dynamically allocating on the stack
On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
Does D have some way to dynamically allocate on the stack? I'm
looking for something roughly equivalent to the following C
code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
https://issues.dlang.org/show_bug.cgi?id=18788
dynamically allocating on the stack
Does D have some way to dynamically allocate on the stack? I'm
looking for something roughly equivalent to the following C code.
int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}
Thanks,
Mike
Inner Classes vs. Inner Structs
This works:
```
class S {
int n, m;
int sum() { return n + m; }
Inner!(sum) a;
class Inner(alias f){
auto get() {
return f();
}
}
}
```
This doesn't:
```
struct S {
int n, m;
int sum() { return n + m; }
Inner!(sum) a;
struct Inner(alias f){
auto get() {
return f(); // Error: this for sum needs to be type S
not type Inner!(sum)
}
}
}
```
The only difference between the two is one one uses classes, the
other uses structs. My question is, under the current semantics
of D, shouldn't the two work the same? That is, shouldn't the
inner struct in the second example have an implicit context
reference to the outer struct? Is this a bug?
Thanks for the help,
Mike
Re: LDC / BetterC / _d_run_main
On Saturday, 10 March 2018 at 02:25:38 UTC, Richard wrote:
Hi,
I've been trying to see if I can get an mbed project to work
with Dlang
basically compiling D code for use on a Cortex-M Proccessor
You might be interested in the following, if you're not already
aware:
* https://github.com/JinShil/stm32f42_discovery_demo
* https://bitbucket.org/timosi/minlibd
The STM32 demo only supports GDC right now, but I'll be updating
it to support LDC when 2.079.0 lands there. 2.079.0 removes some
coupling of the compiler to the runtime, so I should be able to
avoid the following bugs:
https://github.com/ldc-developers/ldc/issues/created_by/JinShil
so I tried this instead
```
extern (C) int _d_run_main(int argc, char **argv, void*
mainFunc) {
MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}
```
but nope that didn't seem to work ether, compiles okay but the
code in main() (D space) isn't called
I'd imagine this should be a simple thing, anyone got any ideas?
The following worked fine for me on my x64 Linux desktop with LDC
version 1.8.0 (DMD v2.078.3, LLVM 5.0.1)
``` main.d
import core.stdc.stdio;
private alias extern(C) int function(char[][] args) MainFuncType;
extern (C) int _d_run_main(int argc, char **argv, void* mainFunc)
{
MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}
void main()
{
printf("Hello, World!\n");
}
```
Compile with: ldc2 -defaultlib= -debuglib= -betterC main.d
Mike
Re: Generic Property Implementation
On Friday, 9 March 2018 at 14:46:04 UTC, Simen Kjærås wrote:
This is the best I've come up with in the current language:
struct S {
int n;
mixin property!("field", "get => this.n", "set => this.n =
set");
}
Not bad. Not good, but not bad either.
Sadly, there are issues:
1) Wrong return type:
unittest {
S s;
auto a = s.field;
// Fails - typeof(a) is Property!((get) => this.n, (set) =>
this.n = set)
assert(is(typeof(a) == int));
}
This looks like a related issue:
https://issues.dlang.org/show_bug.cgi?id=16657. That's is a
deal-breaker for me, but I think it could be fixed.
2) Noisy syntax:
If I had my druthers, mixin templates would be mixin'd
automatically, and eponymous mixin templates would be a thing.
Yes, this would be nice, but I don't think it's a deal-breaker.
3) Stringy functions:
The string literal functions are an eyesore, but would require
some compiler work to fix. This fails:
struct S {
int n;
mixin property!("field", get => this.n, set => this.n =
set);
}
The reason is there's no 'this' at the point of instantiation,
since we're in the context of the type, not a function where
'this' makes sense. It seems to me this should be fixable, but
I have no idea how much work would be required.
Yeah, that's quite unfortunate; writing code in strings stinks.
I actually prefer the DIP for this issue alone.
4) 'this' in function bodies
It should be possible to write "get => this.n" as "get => n".
There's no ambiguity as to which 'n' I'm referring to. Filed a
bug:
https://issues.dlang.org/show_bug.cgi?id=18584
Thanks for filing the issue. I just might be able to fix it;
I'll try.
Implementation:
https://gist.github.com/Biotronic/5849af011cbe9c7ea05515011d5995bf
You've done some great work here. I spent about an hour on this
yesterday, and my implementation started to require more and more
mixing strings to get it to work.
If all of the issues you've identified were addressed, you'd end
up with something like this (formatted in a C# way).
struct S {
int n;
property!
(
get =>
{
n
},
set =>
{
n = set
}
) field;
}
That's actually pretty darn good. It makes me wonder if I should
work on fixing those issues or continue with the DIP.
If you don't have any objections I'd like to incorporate this
implementation and your analysis into the DIP.
Thank you again for doing this; you've saved me a awful lot of
time, and have done more than I probably could have.
Mike
Re: Generic Property Implementation
On Friday, 9 March 2018 at 01:22:15 UTC, Mike Franklin wrote: I would like to know if this can be improved to support the following: * binary assignment operators (e.g. +=) * unary assignment operators (e.g. ++) * @safe, @nogc, and -betterC compatible * at least as good code generation as that proposed in the DIP when optimizations are enabled. * And should be scalable to data that isn't addressable (e.g. bitfields). See https://issues.dlang.org/show_bug.cgi?id=16187
Re: Generic Property Implementation
On Tuesday, 20 February 2018 at 14:34:53 UTC, bauss wrote: Would there be a reason why this wouldn't be a good implementation? If so what and how could it be improved? Are there flaws in an implementation like this? [... snip ...] I am very interested in this as a potential alternative to the binary assignment operators for properties DIP (https://github.com/JinShil/DIPs/blob/master/DIPs/DIP1xxx-mvf.md) I would like to know if this can be improved to support the following: * binary assignment operators (e.g. +=) * unary assignment operators (e.g. ++) * @safe, @nogc, and -betterC compatible * at least as good code generation as that proposed in the DIP when optimizations are enabled. D has the philosophy that the language should strive to provide composable primitives, and delegate syntactic sugar to libraries. I like that philosophy and I think it would prevent an expense of limited resources if we could find a good library implementation for this. Mike
Re: VsCode tutorial
On Wednesday, 7 March 2018 at 21:39:09 UTC, Apocalypto wrote: Are there any tutorials about D in vscode? No that I know of. Which are the minimal plugins to install to have code completion, syntax highlighting and code formatting? I've been getting by with https://marketplace.visualstudio.com/items?itemName=webfreak.code-d-beta Are there any app templates that i can invoke to not start every project from scratch? See the usage of `dub init` here: https://code.dlang.org/getting_started How can I debug my app? See https://marketplace.visualstudio.com/items?itemName=webfreak.debug Mike
Re: Game and GC
On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote: Hi, I'm new to language and games. Many people say that GC is bad and can slow down your project in some moments. What can happen if I create a game using D without worrying with memory management? (using full GC) Don't let the GC prevent you from writing a game in D. D is the most flexible language I have ever used; you just need to learn how to deal with the GC in your game. Jonathan M. Davis gave you some good advice and explained the fundamental problem with the GC in real time games (the potential for pauses during reclamation). You can avoid that in a number of ways like temporarily disabling the GC during the real-time part of your game, just to name one. More can be found in the resources below. https://wiki.dlang.org/Memory_Management http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread automem (https://github.com/atilaneves/automem) also gives you reference counting in D (C++ style), if that will work better for your use case. Mike
Re: Tuts/Aritcles: Incrementasl C++-to-D conversion?
On Thursday, 22 February 2018 at 04:16:44 UTC, Nick Sabalausky (Abscissa) wrote: Are there any tutorials or articles out there for "getting started with converting a C++ codebase to D one module at a time?" Or at the very least: tips, tricks, lessions learned, from those who have come before. These are the resources I'm aware of: https://dlang.org/articles/cpptod.html https://wiki.dlang.org/Programming_in_D_for_C%2B%2B_Programmers Mike
Re: -transition=safe and DIP1000
On Sunday, 21 January 2018 at 10:04:36 UTC, Mike Franklin wrote: What is/was `transition=safe`? I can't find any documentation on it. Well, I found http://forum.dlang.org/post/gquxgusfhyigirfpe...@forum.dlang.org But, didn't really clear much up for me.
-transition=safe and DIP1000
I found the following statement in the DIP1000 document (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md) NB: this DIP is out of sync with -transition=safe implementation available in dmd and pending a rewrite. Most key points still apply though. What is/was `transition=safe`? I can't find any documentation on it. And what does "NB" mean? Thanks, Mike
Re: Implicit conversion
On Wednesday, 17 January 2018 at 23:15:33 UTC, Jiyan wrote:
I want to convert from ints implicit to a struct type, so for
example:
I'm not sure what your actual use case is, but based on the
example, you can just template `useV`.
import std.stdio;
struct use
{
int x;
int toInt()
{
return x;
}
use fromInt(int v)
{
return use(v);
}
alias toInt this; // implicit conversion to int value
this(int v)
{x = v;}
}
void useP(int v)
{
v.writeln;
}
void useV(T)(T v)
{
v.writeln;
}
void main(string[] args)
{
use a = use(2);
//useP(a);
useV(2); // how can i let this work?
}
https://run.dlang.io/is/pJhQJh
Mike
Re: -L--demangle=dlang doesn't work
On Saturday, 6 January 2018 at 05:44:28 UTC, Venkat wrote: Why does gcc say "unknown demangling style `dlang'" ? Do I need GDC for demangling to work ? Check your version of binutils with `ld --version`. It looks like it was added in v2.25: http://forum.dlang.org/post/rvoqllpimfskvlabp...@forum.dlang.org I tested with 2.29.1 and it worked fine for me. Mike
Re: structs inheriting from and implementing interfaces
On Friday, 29 December 2017 at 12:11:46 UTC, rikki cattermole wrote: Structs are structs, classes are classes. I'm talking about interfaces, which are neither structs nor classes. C++ had the mixed model similar to what you suggested, we got it right and kept it nice and separate. This was done on purpose. I'm comparing with C#, not C++. And structs implementing interfaces does not blur the two concepts, as C# eloquently demonstrates. Mike
Re: Adding Toc for the "longish" spec pages.
On Friday, 29 December 2017 at 12:06:12 UTC, tipdbmp wrote: It seems to me that some of the language reference/spec pages that are somewhat long, could provide a Toc (Table of contents) which should help users see an overview of what's there and improve the searchability and the navigation of the content. The 'Functions' page has a Toc already. If you have a suggestion for improving the documentation, please file an issue at https://issues.dlang.org/ Occasionally contributors go fishing for easy issues like that in the issues list and will submit pull requests. Even better, you may want to file a pull request yourself at https://github.com/dlang/dlang.org Mike
structs inheriting from and implementing interfaces
In C#, structs can inherit from and implement interfaces.
using System;
interface IPrint
{
void Print();
}
struct MyStruct : IPrint
{
public void Print()
{
Console.WriteLine(ToString());
}
}
public class Program
{
public static void Main()
{
MyStruct s = new MyStruct();
s.Print();
}
}
https://dotnetfiddle.net/lpXR1O
But in D it doesn't appear possible.
import std.stdio;
interface IPrint
{
void print();
}
// Error: base classes are not allowed for struct, did you mean ;?
struct MyStruct : IPrint // Error: base classes are not allowed
for struct, did you mean ;?
{
void print()
{
writeln("MyStruct");
}
}
void main()
{
MyStruct s;
s.Print();
}
https://run.dlang.io/is/j4xwla
Is that simply because it hasn't been implemented or suggested
yet for D, or was there a deliberate design decision?
Thanks for your insight,
Mike
Re: What is 'scope' in function parameter?
On Monday, 25 December 2017 at 10:42:55 UTC, Sobaya wrote:
```
import std.stdio;
int[] x;
void func(scope int[] a) {
x = a;
}
void main() {
func([0,1,2]);
writeln(x);
}
```
This code was successfully compiled and printed '[0, 1, 2]'.
But according to https://dlang.org/spec/function.html, above
code must cause a compile error.
After a few hours trying to figure out why the compiler didn't
catch this, I finally figured it out. You have to add `@safe`.
import std.stdio;
int[] x;
void func(scope int[] a) @safe
{
x = a;
}
void main() @safe {
func([0,1,2]);
writeln(x);
}
This is one of the things really ticks me off about D; it has all
the wrong defaults.
At a minimum, the documentation needs clarification. I encourage
you to file a bug report against the documentation at
http://issues.dlang.org/
Mike
Re: What is 'scope' in function parameter?
On Monday, 25 December 2017 at 11:09:25 UTC, Jonathan M Davis
wrote:
```
import std.stdio;
int[] x;
void func(scope int[] a) {
x = a;
}
void main() {
func([0,1,2]);
writeln(x);
}
```
This code was successfully compiled and printed '[0, 1, 2]'.
But according to https://dlang.org/spec/function.html, above
code must cause a compile error.
Could you give me any advice?
Walter has been working on DIP 1000, which broadens scope so
that it affects a lot more types, and that can be triggered
with the -dip1000 compiler flag, but it's very much a work in
progress, and I wouldn't advise using it at this point. Without
it, scope has zero effect on something like a dynamic array.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
But we need people to use -dip25 and -dip1000 and provide
feedback, submit bug reports, etc.. so we can move the
implementation forward.
Based on your assessment, is Sobaya's test case an indication of
a bug in -dip1000's implementation?
Mike
Re: Finding equivalent of C++ feature in D documentation.
On Saturday, 23 December 2017 at 15:04:30 UTC, kerdemdemir wrote: Is there any better way for me to search C/C++ equivalent features? As a humble suggestion would it make sense to make a table with feature names and corresponding name of the same feature in other languages ? Try this: https://wiki.dlang.org/Programming_in_D_for_C%2B%2B_Programmers ... and potentially this: https://wiki.dlang.org/Coming_From Those resources are community maintained. When I was first learning D, if I encountered a problem and struggled to a solution, I would make an attempt to documented it on the D wiki to try and save others from having to go through the same difficulty. I encourage you to do the same. Mike
Re: Don't expect class destructors to be called at all by the GC
On Thursday, 21 December 2017 at 19:43:16 UTC, Steven Schveighoffer wrote: The gist is, you cannot expect that destructors will be run in a timely manner, or at all. They may be called, and most of the time they are. But the language nor the current implementation makes a guarantee that they will be called. I understand that we can't deterministically predict when a destructor will be called, but if we can't deterministically predict if a destructor will be called, that seems asinine. What condition(s) would cause a destructor for an object that is managed by the GC to potentially not be called? Thanks, Mike
Re: GC in D and synadard library.
On Thursday, 21 December 2017 at 10:49:46 UTC, Dan Partelly wrote: I started to look into D very recently. I would like to know the following, if you guys are so nice to help me: 1. What is the performance of D's GC, what trade-offs where done in design , and if a in-deep primer on efficient usage and gotchas of the current implementation exists. I've never independently measured it myself, so I can't say. 2. GC is never good enough. What are the current plans in this area for D. The -betterC feature come to mind. Walter is trying to convert the DMD compiler's backend to D (It's still written in C-like C++; only the frontend is in D). For reasons I don't quite understand, he wants to use -betterC and RAII: https://github.com/dlang/dmd/pull/7421#issuecomment-350874126 But the GC isn't required. D is an extraordinarily powerful language with which you can work around just about any limitation. https://wiki.dlang.org/Memory_Management https://p0nce.github.io/d-idioms/#The-impossible-real-time-thread In general, please point me to the place where current work on D is done. Work on the D programming language is done primarily in 3 different repositories: DMD (reference compiler) - https://github.com/dlang/dmd DRuntime (language runtime library) - https://github.com/dlang/druntime Phobos (standard library) - https://github.com/dlang/phobos 3. I need to be able to run with GC totally disabled sometimes. In the light of this: - are there any features of core language which depend on garbage collection ? (i.e unbound arrays, strings ..) Yes, Exceptions, classes, dynamic arrays, and associative arrays come to mind. But, keep in mind that there are always ways to word around this. - are there any features from standard library which depend on active garbage collection? I'm not a big user of the standard library, but I believe most features of the standard library require the GC. - Please point me to a list where there is an exhaustive enumeration of which language features *and* library features requires GC active. Looking at standard library docs I did not seen markings which identify clearly and unequivocally what requires GC active and what not. I don't think such a list exists. You can compile code with the @nogc attribute and the compiler emit errors if you attempt to use the GC. The -vgc compiler option will also tell you where you have GC allocations. 4. Is Andrei Alexandrescu's book from 2009 on D still actual, or the language evolution made it obsolete ? I think there is still great information in that book, and Andrei is always a fun author to read. However, "Programming in D" is probably the best place to start - http://ddili.org/ders/d.en/index.html Some D books are currently on sale for $5 at Packt Publishing: http://forum.dlang.org/post/mbczecvrworfwacmz...@forum.dlang.org Mike
Don't expect class destructors to be called at all by the GC
"Don't expect class destructors to be called at all by the GC" I was a bit shocked to read that here: https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors The document tries to clarify with: "The garbage collector is not guaranteed to run the destructors for all unreferenced objects." Unfortunately, that doesn't really shed much light on this oddity. So, specifically, under what circumstances are destructors not called? Thanks, Mike
Re: Alias example should supposedly be illegal, but runs fine
On Tuesday, 19 December 2017 at 10:37:05 UTC, Michael wrote: On Tuesday, 19 December 2017 at 02:12:29 UTC, Mike Franklin wrote: On Tuesday, 19 December 2017 at 02:04:34 UTC, codephantom wrote: writeln(S.j); // Error: Instance symbols cannot be used through types. I don't understand why you would say that is a bug. I meant that the example is wrong, and a bug report should be filed to fix the example. Mike Hmm.. but the example is explicitly dealing with when it is valid to create an alias for a non-static struct member. Should it still not be int? Even if you cannot change it via that alias? I don't quite understand what you mean. `s.i` refers to a symbol in the compiler's symbol table. Therefore, I don't see any reason it can't be aliased. `alias a = b + c;` would be a better example to demonstrate that expressions cannot be aliased. Mike
Re: Alias example should supposedly be illegal, but runs fine
On Tuesday, 19 December 2017 at 02:04:34 UTC, codephantom wrote: writeln(S.j); // Error: Instance symbols cannot be used through types. I don't understand why you would say that is a bug. I meant that the example is wrong, and a bug report should be filed to fix the example. Mike
Re: Alias example should supposedly be illegal, but runs fine
On Monday, 18 December 2017 at 23:44:46 UTC, Michael wrote:
I have been looking at the following example found right at the
end of the section here:
https://dlang.org/spec/declaration.html#alias
struct S { static int i; }
S s;
alias a = s.i; // illegal, s.i is an expression
alias b = S.i; // ok
b = 4; // sets S.i to 4
and it runs fine to me, including if I add:
I think the example is wrong. Consider this:
import std.stdio;
struct S
{
static int i;
int j;
}
S s;
void main()
{
s.i = 1;
s.j = 2;
writeln(s.i); // OK: Static symbols can be used through
instances
writeln(S.i); // OK: Static symbols can be used through types
writeln(s.j); // OK: Instance symbols can be used through
instances
//writeln(S.j); // Error: Instance symbols cannot be used
through types.
}
https://run.dlang.io/is/eppwuf
Please file a bug report at http://issues.dlang.org/
Mike
Re: No line numbers in stack trace (again)
On Tuesday, 5 December 2017 at 13:43:38 UTC, Nordlöw wrote: If I get the following stack trace ___without line numbers___ (instead ??:?) what's missing? and using DMD 2.077.1 https://issues.dlang.org/show_bug.cgi?id=18068
Re: Temporary objects as function parameters or when-is-this-shit-going-to-end?
On Tuesday, 17 October 2017 at 19:00:38 UTC, Steven Schveighoffer wrote: In this case, an extra destructor call is made without a corresponding postblit or constructor. -Steve https://issues.dlang.org/show_bug.cgi?id=18050
Does __gshared have shared semantics?
In other words, is 'shared __gshared' redundant?
HeadUnshared in core.atomic
Hello,
I was recently exposed to this template in core.atomic:
private
{
template HeadUnshared(T)
{
static if( is( T U : shared(U*) ) )
alias shared(U)* HeadUnshared;
else
alias T HeadUnshared;
}
}
Could someone please explain/elaborate on what this is doing, and
why it's necessary and used so often in core.atomic?
Thanks,
Mike
