I tried compiling GtkD, I get the error message:
rdmd Build.d
Error: more than 32767 symbols in object file
1. How to work around this?
2. Is D still unfriendly to newbies? I am disappoint :-(
Using:
DMD 2.077
GtkD 3.7.1
gtk3-runtime_3.22.24-1, 32bit
Could someone please list some workarounds?
I am trying to compile a demo app from gtkd. I tried compiling
gtkd using dub with --build=plain option and still got that error
when compiling the demo app. Using the latest dmd.
Thanks in advance.
On Sunday, 10 December 2017 at 21:51:37 UTC, Mike Wey wrote:
On 10-12-17 16:57, user wrote:
Could someone please list some workarounds?
I am trying to compile a demo app from gtkd. I tried compiling
gtkd using dub with --build=plain option and still got that
error when compiling the demo app.
On Saturday, 14 March 2020 at 20:53:45 UTC, Abby wrote:
I would like to export some functions from my bettec dll for
dotnet core application in windows.
[...]
It is the calling convention.
I'd like to convert the following program to 2020 standards (i.e,
replace the foreach block with a one-line code). I've tried much
and I failed.
This is the code that works (1990s style)
--
import std;
void main()
{
immutable URL =
r"https://raw.githubusercontent.com/CSSEGISandData/COVID
On Friday, 26 June 2020 at 10:12:09 UTC, Jacob Carlborg wrote:
Windows:
I don't know that much of this platform.
* std.net.curl and basically all other options already
mentioned relies on OpenSSL, which is not provided by the
platform
* SChannel. As far as I know, this the the platform prov
I have to synchronize a directory. If remote file is newer I copy
to local. If local file is newer I copy it to remote server. For
some reason remote timestamp does not contain milliseconds, so
comparison (localFileTime < remoteFileTime, etc) fails. I need
help to drop milliseconds from local f
On Sunday, 12 August 2018 at 19:50:44 UTC, User wrote:
I have to synchronize a directory. If remote file is newer I
copy to local. If local file is newer I copy it to remote
server. For some reason remote timestamp does not contain
milliseconds, so comparison (localFileTime < remoteFileTime,
e
On 3/15/2018 12:39 PM, Miguel L wrote:
On Thursday, 15 March 2018 at 17:31:38 UTC, rumbu wrote:
On Thursday, 15 March 2018 at 17:18:08 UTC, Miguel L wrote:
On Thursday, 15 March 2018 at 16:31:56 UTC, Stefan Koch wrote:
On Thursday, 15 March 2018 at 15:28:16 UTC, Miguel L wrote:
[...]
intege
On 5/10/2018 1:43 PM, SrMordred wrote:
struct T
{
int x;
@property ref X(){ return x; }
@property X(int v)
{
x = v;
}
}
T t;
t.X += 10;
The setter 'x = v' are not executed because i´m returning the reference
of x.
And without the 'ref' the compiler complains
On 5/10/2018 2:50 PM, SrMordred wrote:
On Thursday, 10 May 2018 at 19:41:41 UTC, Dlang User wrote:
On 5/10/2018 1:43 PM, SrMordred wrote:
[...]
I am relatively new to D and I was under the impression that that was
a limitation of @property functions.
But, re-reading the language reference,
On 5/10/2018 3:18 PM, Ali Çehreli wrote:
On 05/10/2018 01:03 PM, Dlang User wrote:
>> this didn´t work either.
>> note that 'f.data+= 2;' don't call the write property
>
> That's odd, it works on my machine (Windows 10 with V2.079.0 DMD
compiler).
Try putting writeln expressions in the tw
On 6/1/2018 12:06 AM, vino.B wrote:
On Thursday, 24 May 2018 at 11:31:15 UTC, bauss wrote:
On Thursday, 24 May 2018 at 06:59:47 UTC, Vino wrote:
Hi All,
Request your help on how to delete a file which has the extension
.fifo (.javast.fifo) in Windows.
From,
Vino.B
What exactly is your i
I am running Debian Testing and I think I have run into the
recent fPIC issue. This is the source code for the test project
I am using:
import std.stdio;
void main()
{
writeln("Edit source/app.d to start your project.");
readln();
}
When I try to compile a project, I get the
On Thursday, 3 November 2016 at 06:11:48 UTC, rikki cattermole
wrote:
Took me a while to replicate your build environment but it
looks like a false alarm.
rikki@debian:/tmp/test$ dmd test.d
rikki@debian:/tmp/test$ file test
test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamica
On Friday, 29 December 2017 at 12:03:59 UTC, Mike Franklin wrote:
In C#, structs can inherit from and implement interfaces.
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
I think it's deliber
Any good ideas how to do that?
I couldn't figure it out in a short amount of time, but I expect
that it's possible. I'm probably missing something obvious here.
Probably because D's reflection/meta programming facilities are a
bit all over the place (and unnecessarily convoluted IMO).
Also I'm
On Saturday, 11 June 2016 at 20:30:47 UTC, Basile B. wrote:
On Saturday, 11 June 2016 at 19:45:56 UTC, Random D user wrote:
Any good ideas how to do that?
I couldn't figure it out in a short amount of time, but I
expect that it's possible. I'm probably missing something
obvious here. Probably
I can init a variable from mutable source without defining any
constructor or assignment operators, but not if the source is
const. I would imagine the behavior to be the same with mutable
and const source, since it's just reading the source and copying
it.
Is there a reason for this? Or is t
int*[] foo;
foo.length = 5;
import std.c.string;
int* baz = cast(string*)malloc(50);
import std.c.stdio;
printf("%d %d", foo.length, baz.length );
prints:
Error: no property 'length' for type 'int*'
BUT:
string*[] foo;
foo.length = 5;
import std.c.string;
string* baz = cast(string*)malloc(50
On Sunday, 12 March 2017 at 01:55:20 UTC, ketmar wrote:
Random D user wrote:
How come string* suddenly has a .length property?
due to automatic pointer dereferencing that `.` does. no, not a
bug.
Ah... right. Silly me. Of course, since string is actually
immutable(char)[].
That's bit of a
I wanted to make a 2D array like structure and support D slice
like operations,
but I had surprisingly bad experience.
I quickly copy pasted the example from the docs:
https://dlang.org/spec/operatoroverloading.html#array-ops
It's something like this:
struct Array2D(E)
{
E[] impl;
int
On Saturday, 4 May 2019 at 16:10:36 UTC, Adam D. Ruppe wrote:
On Saturday, 4 May 2019 at 15:18:58 UTC, Random D user wrote:
But array copy and setting/clearing doesn't:
int[] bar = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15 ];
foo[] = bar[];
Generally speaking, opIndex is for getti
On Saturday, 4 May 2019 at 15:36:51 UTC, Nicholas Wilson wrote:
On Saturday, 4 May 2019 at 15:18:58 UTC, Random D user wrote:
I wanted to make a 2D array like structure and support D slice
like operations,
but I had surprisingly bad experience.
The de facto multi dimensional array type in D i
or is it some obscure feature conflict?
struct Foo
{
this( float x_, float y_ )
{
// option A
//x = x_;
//y = y_;
// option B
v[0] = x_;
v[1] = y_;
}
union
{
struct
{
float x = 0;
float y
On Saturday, 12 September 2015 at 18:28:02 UTC, Random D user
wrote:
or is it some obscure feature conflict?
[...]
Oh... and I'm using win 64-bit and dmd 2.068.1, but this behavior
was present earlier than that...
I'm trying to make a base class with get property and a sub class
with corresponding set property. The value for the base class is
set via constructor.
The intuitive way doesn't seem to work and workarounds are
unnecessarily ugly (considering you'll sprinkle them all over the
codebase).
class
On Wednesday, 16 September 2015 at 03:17:05 UTC, Meta wrote:
Considering Father defines the function `int eat()` and
Daughter defines the completely different function `int
eat(int)`, it doesn't surprise me. You're not using virtual
dispatch when you do `return super.eat` or `d.Father.eat()`,
On Wednesday, 16 September 2015 at 03:54:34 UTC, Adam D. Ruppe
wrote:
On Wednesday, 16 September 2015 at 03:48:59 UTC, Random D user
Given that, normally properties are just overloaded methods in
D, it's pretty sad classes break this behavior/convention.
The D behavior for overloading is diffe
So I tried to build my project in release for the first time in a
long while. It takes like 25x longer to compile and finally the
compiler crashes. It seems to go away if I disable the optimizer.
I get:
tym = x1d
Internal error: backend\cgxmm.c 547
Does anyone have a clue what might trigger th
On Saturday, 19 September 2015 at 07:25:58 UTC, ponce wrote:
On Friday, 18 September 2015 at 22:54:43 UTC, Random D user
wrote:
So I tried to build my project in release for the first time
in a long while. It takes like 25x longer to compile and
finally the compiler crashes. It seems to go away
On Saturday, 19 September 2015 at 21:48:25 UTC, Random D user
wrote:
Assertion failure: 'type->ty != Tstruct || ((TypeStruct
*)type)->sym == this' on line 957 in file 'struct.c'
Ok managed to reduce this one to my own copy paste bug. This is
invalid code, but compiler shouldn't crash...
I'm
So I was doing some optimizations and I came up with couple basic
questions...
A)
What does assumeSafeAppend actually do?
A.1) Should I call it always if before setting length if I want
to have assumeSafeAppend semantics? (e.g. I don't know if it's
called just before the function I'm in)
A.2)
Thanks for thorough answer.
On Thursday, 15 October 2015 at 18:46:22 UTC, H. S. Teoh wrote:
It adjusts the size of the allocated block in the GC so that
subsequent appends will not reallocate.
So how does capacity affect this? I mean what is exactly a GC
block here.
Shrink to fit bit wa
Ah missed your post before replying to H.S. Teoh (I should
refresh more often).
Thanks for reply.
On Thursday, 15 October 2015 at 19:50:27 UTC, Steven
Schveighoffer wrote:
Without more context, I would say no. assumeSafeAppend is an
assumption, and therefore unsafe. If you don't know what is
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
// This also crashes. I believe crash above makes a call like
this (or similar) in the rt.
//auto h = typeid( foo ).getHash( &foo ); // Crash!
win64 & dmd 2.69.2
I kind of miss reference values on stack, so I attempted to make
one in a struct.
Pointers are pretty good (since d doesn't have ->), but it would
be nice to avoid dereferencing them explicitly on assignment.
Since reference is a pointer that you can't change afterwards.
I tried something like
On Monday, 7 December 2015 at 20:03:07 UTC, Namespace wrote:
This seems to work:
struct RefVal(T) {
private T* ptr;
this(T* val) {
ptr = val;
}
ref auto opAssign(U)(auto ref U value) {
*ptr = value;
On Tuesday, 8 December 2015 at 10:26:18 UTC, Random D user wrote:
On Monday, 7 December 2015 at 20:03:07 UTC, Namespace wrote:
This seems to work:
struct RefVal(T) {
private T* ptr;
this(T* val) {
ptr = val;
}
ref auto opAssign(U)(au
On Tuesday, 8 December 2015 at 01:23:40 UTC, Ivan Kazmenko wrote:
On Monday, 7 December 2015 at 22:03:42 UTC, Alex Parrill wrote:
On Monday, 7 December 2015 at 18:48:18 UTC, Random D user
Tested the same code with -m32 and -m64 on Windows. Works for
me, too.
I tried this again. And it seems
On Tuesday, 8 December 2015 at 11:04:49 UTC, Random D user wrote:
I need to look into this more.
Ok. This is minimal app that crashes for me. If someone could try
this:
class App
{
this()
{
}
void crash( int val )
in
{
assert( val == 1 );
}
body
{
41 matches
Mail list logo
