I can't say for sure, but there are some cases I know where you
don't get stack trace (mostly dmd bugs):
- inside module constructors `shared static this()`
- null function pointer call
On Friday, 21 September 2018 at 12:34:12 UTC, Laurent Tréguier
wrote:
I would probably go for std.utf.decode [1] to get the character
and its length in code units, capitalize it, and concatenate
the result with the rest of the string.
[1] https://dlang.org/phobos/std_utf.html#.decode
So by
How can I properly convert a character, say, first one to upper
case in a unicode correct manner?
In which code level I should be working on? Grapheme? Or maybe
code point is sufficient?
There are few phobos functions like asCapitalized() none of which
are what I want.
I was sketching some simple event-listener code and looked up
std.signals module for some inspiration. Documentation says that
it only works if the delegate used for slots are a
class/interface member function. Digging into the code it seems
like it's because _d_toObject(void*) function is
I'm trying to understand how to create some json-rest api that
would return data (in json format) related to that specific
logged in user. I see the documentation covers these but I'm
totally new to vibe.d so can't quite figure out putting these two
things together and make them work. Some
On Sunday, 14 August 2016 at 03:10:28 UTC, WhatMeWorry wrote:
On Sunday, 14 August 2016 at 01:05:33 UTC, Basile B. wrote:
On Saturday, 13 August 2016 at 21:56:49 UTC, WhatMeWorry wrote:
$ sudo chmod -v 777 *
mode of 'HelloWindow' changed from 0644 (rw-r--r--) to 0777
(rwxrwxrwx)
$ ls -al
Lack of production quality tools
Lack of good marketing
Lack of man power & corporate support
Lack of idiomatic D libraries
These are pretty much the core of all other negative
consequences. Ex: GDC is few versions behind DMD because lack of
man power.
If only we could break the vicious
On Wednesday, 27 July 2016 at 09:28:49 UTC, chmike wrote:
The reason I'm switching to Go is because
3. GC performance (no stop the world hiccups)
IIRC, there is a concurrent GC implementation used by sociomantic
but it's linux only. (It uses fork() sys call)
4. Web server && IO performance
On Sunday, 17 July 2016 at 17:52:59 UTC, solidstate1991 wrote:
Up to this day, I have to use them by dragging the source into
my project. When I tried to import imageformats, the compiler
looks up for the file imageformats.d and fails to finish the
program.
I'm not using command line for
String is an alias for 'immutable(char)[]'.
I assume you meant const(char)[] instead of 'const string'?
P.S. always use parentheses.
On Monday, 8 February 2016 at 17:51:02 UTC, Ola Fosheim Grøstad
wrote:
C++ compilers have lots of optional warnings/errors, so it is
quite possible. But I suppose those that want it would rather
use Go, C# or some other GC language than can do ahead of time
compilation.
There are several
On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote:
The GC itself may still be far from perfect but its much better
than it was, and there are more options now. I have found emsi
containers (built on top of Andrei's allocator) pretty nice
myself for my own use.
Well, GC being
On Tuesday, 9 February 2016 at 14:35:48 UTC, Ola Fosheim Grøstad
wrote:
Not incredibly high level abstraction... But I get what you
mean. It is fairly high level for a low level language.
Coming from C#, it looks amazing but probably not that incredible
when coming from C++.
So you want
On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC
implementations?
Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent
On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad
wrote:
What makes it impossible to have ref counted classes?
Nothing.
Then why do we need DIP74 ? And why documentation says RefCounted
doesn't work with classes?
So I came here to ask about things that prevent D to become
better.
What language semantics prevent precise & fast GC implementations?
What makes it impossible to have ref counted classes?
What are some other technical / design problems you encountered?
(other than poor implementation and
On Tuesday, 2 February 2016 at 03:36:25 UTC, Steven Schveighoffer
wrote:
int y() { return 1;}
No need for meta-programming hackery, mark it as @property:
int y() @property { return 1;}
On Friday, 22 January 2016 at 12:07:11 UTC, abad wrote:
Let's say I have an array like this:
int[][][] array;
And I want to generate a linear int[] based on its data. Is
there a standard library method for achieving this, or must I
iterate over the array manually?
What I'm thinking of is
Please explain.
Windows X86 64bit (x86_64-w64-mingw32)
Standard builds
Target DMDFE Runtime GCC GDC revisionBuild
Date
arm-linux-gnueabi 2.066.1 yes 5.2.0 dadb5a3784
2015-08-30
arm-linux-gnueabihf 2.066.1 yes 5.2.0 dadb5a3784
Thanks both to you for answers...
On Thursday, 1 October 2015 at 14:07:02 UTC, Johannes Pfau wrote:
Unfortunately Windows GDC builds are very unstable right now.
I'd recommend using DMD or LDC for Windows.
Well... To me it's surprising GDC is not usable on windows but I
doubt LDC is more
On Saturday, 19 September 2015 at 18:13:09 UTC, Marc Schütz wrote:
You can also do it with built-in syntax:
template AATypes(AA : K[V], K, V)
{
alias Key = K;
alias Value = V;
}
K[V] supposed to be V[K] btw...
import std.stdio;
void main()
{
Stuff!(Thing!float) s;
writeln(typeid(s.var));
writeln(typeid(s.var.varling));
writeln(typeid(s));
}
class Stuff(T)
{
T!int var;
}
class Thing(T)
{
T varling;
}
On Monday, 14 September 2015 at 16:33:23 UTC, Rikki Cattermole
wrote:
A lot of this hasn't been covered I believe.
http://dpaste.dzfl.pl/f7ab2915c3e1
I believe that should be:
foreach (query, ref value; hitlists)
Since an assignment happenin there..?
On Saturday, 12 September 2015 at 05:54:13 UTC, NX wrote:
import std.stdio : writeln, std.algorithm.mutation : remove;
Ooops, this is so wrong! Corrected version:
void main()
{
import std.stdio : writeln;
import std.algorithm.mutation : remove;
int[][string]
On Saturday, 12 September 2015 at 08:13:33 UTC, Bahman Movaqar
wrote:
Is there any or they are just simply syntactically equivalent?
Are there any official docs on this?
What if I told you, you should search the official reference
before asking such things in the forum?
I compile a simple hello world program in C and the results:
hello_world.o -> 1.5 KB
hello_world (linux executable) -> 8.5 KB
Then I compile a simple hello world program in D (using DMD) and
the results:
hello_world.o -> 9.3 KB
hello_world (linux executable) -> 575.9 KB
Then I compile a
On Saturday, 12 September 2015 at 03:44:50 UTC, Prudence wrote:
At the very least: Is T[][S] an associative array with keys of
type S and values of an array of type T or is it backwards?
Also, how to disambiguate
Thanks.
Indeed.
void main()
{
import std.stdio : writeln,
On Friday, 11 September 2015 at 13:45:03 UTC, Adam D. Ruppe wrote:
Just D's isn't preinstalled so it carries what it needs with
the executable for broadest compatibility. You could
dynamically link if you like (`-defaultlib=libphobos2.so` on
dmd linux)
So I did some testing:
# dmd
On Tuesday, 8 September 2015 at 17:22:44 UTC, NX wrote:
I have figure out
typo:
...I had to figure out...
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote:
It's called encapsulation.
Do you have any idea how much I struggled when I try to use enums
in OpenTK library because they were "encapsulated" ?
Whenever I read OpenGL tutorials I have figure out which
enum-name they used as
Typo:
*scenario
I wonder if the followings are compiler bugs:
class stuff_class
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
My project has just stopped for this reason, I
On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
No, it is by design, the idea is to keep static arrays smallish
so null references will be caught by the processor. (An overly
On Saturday, 1 August 2015 at 18:47:00 UTC, Daniel Kozak wrote:
Still same problem, You can`t allocate more then 16M on stack.
Use dynamic allocation
I don't think new MyStruct allocates on stack, actually
allocating ~16MB on stack will immediatelly crash the program
which is not the case
On Saturday, 1 August 2015 at 18:50:09 UTC, Daniel Kozak wrote:
No you don't. You still use static allocation for array
Can clarify why does that happen and I still suspect it's a
static allocation it would increase output exe if it was really
that static..?
On Saturday, 1 August 2015 at 19:33:26 UTC, Daniel Kozak wrote:
My fault It is not on stack, but still it is a static allocation
I think you're misusing static allocation and static
declaration for each other.
37 matches
Mail list logo
