Re: crashing with no stack trace, why?
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
Re: Converting a character to upper case in string
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 this I assume it is sufficient to work with dchars rather than graphemes?
Converting a character to upper case in string
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.
How to understand context type of a delegate?
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 used by passing "ptr" variable of the delegate to it. If there was a way to distinguish context types of delegates this would not be a problem. Is there a way to know what kind of context a delegate has either in compile time or runtime? Also is there any way to check whether a pointer legitimately points to an Object instance?
[vibe.d] How to create authentication system via REST interface?
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 easy to follow sample would be incredibly helpful, though any help is appreciated.
Re: DUB saying my Linux exe file is "not an executable file" even though DUB built it
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 total 3016 drwxr-xr-x 2 generic generic4096 Aug 13 16:48 . drwxr-xr-x 7 generic generic4096 Aug 12 23:14 .. -rw-r--r-- 1 generic generic 3080080 Aug 13 16:48 HelloWindow Now I'm really gobsmacked. Can you post the result of $file HelloWindow ? Certainly. $file * HelloWindow: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=1ee19ed1fe36d068ad24f1a16f9990b6b7ff4438, not stripped I'm running Ubuntu (actually Xubuntu) 16.04.1 LTS And I've got the very latest dmd and dub general releases. I might be doing something unusual that may not even be allowed. I've got a USB flash drive that I'm trying to share between two physical machines: one Windows and the other Linux. The dub project, bin, source code etc. is on the flash drive. I compiled my little HelloWorld in dub to create a HelloWorld.exe on my Windows machine. This compiled and ran fine. I then moved the USB flash drive over to the Linux machine and reran dub build/run to create the executable HelloWorld that is now causing the trouble. Should I not be trying to share a flash drive like this? This is the actual problem that cause trouble. Your flash drive is probably Fat32 or NTFS formatted rather than ext4. Since those file systems do not support "executable attribute", Linux will silently fail to give files the attribute which results in these sort of surprises. You may wonder why the same thing doesn't happen on NTFS formatted partition of your hard drive. I guess this is because Linux assumes internal hard drive is trustable, thus all files have executable attribute by default (that's what happens on my pc).
Re: Why D isn't the next "big thing" already
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 circle...
Re: Why D isn't the next "big thing" already
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 (see: https://www.techempower.com/benchmarks or https://github.com/nanoant/WebFrameworkBenchmark). Please, these are terribly outdated benchmarks. There was a recent bug causing Vibe.D to not scale to multiple cores at all which has been fixed.
Re: Using external libraries the correct way
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 compiling, I use Xamarin with mono-D instead. Menu > Project > Project Options > Compiling > Libraries Something like this: http://i51.photobucket.com/albums/f358/NightmareX1337/project-options_zpsbmvgtr3b.png Or you can choose the pragma(lib) way: http://dlang.org/spec/pragma.html#lib
Re: Passing a sting as 'in char[]' yields "immutable is not callable using argument types ()"
String is an alias for 'immutable(char)[]'. I assume you meant const(char)[] instead of 'const string'? P.S. always use parentheses.
Re: Things that keep D from evolving?
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 this to be worked on (as D has a horribly slow one)? I would want it to be solved rather than being worked on... which requires design change which is probably not going to happen. There is still room for improvement though. Doesn't C# work just as well as D (or better) with most platforms? There are differences, but yeah I shouldn't have said that ~ cross-platform thingy is not a valid argument against C# anymore.
Re: Things that keep D from evolving?
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 reasons I want to use D rather than C# / Go / something else: - Interfacing with native API without jumping through hoops - Incredibly high abstraction and meta-programming possibilities with relatively easier syntax + semantics. - It's harder to reverse engineer native code than byte code equivalent. - Trading off anything according to your needs. - Expressiveness and purity, immutablity concepts. - Having GC (but not a horribly slow one) - Syntactic sugars (associtive arrays, powerful foreach, slices...) - Compile times - Not bound to a specific platform (unlike C#, easier to do cross-platform work in many cases) I wish D could be better. I really want it with all of my heart...
Re: Things that keep D from evolving?
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 better than it used to be doesn't change the fact it's still the worst of it's kind. I don't know if this[1] work actually got released or merged but looks like it's abandoned. Pretty sad as it seemed very promising. Anyway, I was expecting a lot more people to tell their specific problems, like "bla bla design desicion makes ARC incredibly dangerous and we can't properly interface with Objective-C without that" or like "bla bla D feature overlaps with some other stuff and requires redesign to be solved" or maybe "being unsafe (@system) by default breaks the deal"... GC is just one of the hundreds of problems with D and it was an example rather than the main point in this thread but thanks for anyone who replied. [1] http://forum.dlang.org/thread/mailman.655.1399956110.2907.digitalmar...@puremagic.com
Re: Things that keep D from evolving?
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 fast (generational and/or concurrent) GC. Some more detailed explanations here: http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html I see... By any chance, can we solve this issue with GC managed pointers? AFAIK, this is what C++/CLR does: There are 2 different pointer types, (*) and (^). (*) is the famous raw pointer, second one is GC managed pointer. A GC pointer has write barrier (unlike raw pointer) so we can have both raw C performance (if we want) and fast generational GC or concurrent GC (which are a magnitude better than a mark and sweep GC). As you realized, there is a major problem with this: classes. The desicion of making classes reference-type is actually fine (+simplicity), but it doesn't really help with the current situation, I expect D to be pragmatic and let me decide. Maybe in future... Who knows...
Re: Things that keep D from evolving?
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?
Things that keep D from evolving?
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 lack of resources) Enlighten! :)
Re: Determine type of property
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;}
Re: Collapsing n-dimensional array to linear (1 dimensional)
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 something like this: int[] onedim = std.array.collapse(array); It's not the thing you want but I would suggest using one dimensional array like N dimensional array like this: int d1 = 10, d2 = 10, d3 = 10; int[] arr = new int[d1 * d2 * d3]; for(int i = 0; i < d1; i++) for(int j = 0; j < d2; j++) for(int k = 0; k < d3; k++) write(arr[(i * d1 * d2) + (j * d2) + (k)]); This will lead to cache friendly code in most cases as you ensure data is packed. It's elements can be iterated with a single foreach loop and easier to use in some (many?) cases like when using functions that works with one dimensional array. And if you seriously need multi dimensional array then it's too easier to do it yourself: int[][][] a = new int[][][](d1, d2, d3); int[] collapsed = new int[d1 * d2 * d3]; foreach(i, q; a) foreach(j, w; q) foreach(k, e; w) collapsed[(i * d1 * d2) + (j * d2) + (k)] = e;
Regression vs Bug
Please explain.
Re: Which GDC to download?
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 stable. Sad... *Cries in Turkish*
Which GDC to download?
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 2015-08-30 x86_64-w64-mingw32 2.066.1 yes 5.2.0 dadb5a3784 2015-08-30 I'm totally confused about what does these mean: 1) Why there is a download targeting arm-linux-gnueabi(hf) and what exactly it means? Is this a cross-compiler which will produce obj files containing ARM instructions or what? If so, will linking just work? and how? 2) Is what I understand from "cross-compiler" correct? (a compiler that can target different architectures than the host architecture it's compiled for) 3) Which one to choose if I just want to write & compile windows programs? 4) x86_64-w64-mingw32 is commented as "Unsupported alpha build. SEH"? is that means windows-targeting version of the compiler is highly unstable/not ready yet? What's "SEH"?
Re: Get AA key and value type
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...
What kind of sorcery is that?
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;
}
Re: Speeding up text file parser (BLAST tabular format)
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..?
Re: Difference between back (`) and double (") quoted strings
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? http://dlang.org/lex.html#WysiwygString Wysiwyg: What you see is what you get writeln(`\asd"fg"hj hmph'`); \asd"fg"hj haha'
Re: Multidimension AA's and remove
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] heh = [ "heh":[ 0, 10, 15, 20 ] ];
heh["heh"][0] = 5;
writeln(heh); // ["heh":[5, 10, 15, 20]]
heh["heh"] = remove!(c => (c == 15))(heh["heh"]);
writeln(heh); // ["heh":[5, 10, 20]]
}
Re: Multidimension AA's and remove
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, std.algorithm.mutation : remove;
int[][string] heh = [ "hah":[ 0, 10, 15, 20 ] ];
heh["hah"][0] = 5;
foreach(var; heh["hah"])
writeln(var);
writeln();
heh["hah"] = remove!(c => (c == 15))(heh["hah"]);
foreach(var; heh["hah"])
writeln(var);
}
Giving me:
5
10
15
20
5
10
20
Re: Huge output size for simple programs
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 -defaultlib=libphobos2.so "app.d"
Source:
void main()
{
main();
}
Result:
app.o -> 5.3 KB
app (exe) -> 9.4 KB
# dmd -defaultlib=libphobos2.so "app.d"
Source:
import std.stdio, std.conv, core.stdc.stdlib, std.typecons,
std.parallelism;
void main()
{
main();
}
Result:
app.o -> 6 KB
app (exe) -> 13.7 KB
Just because I imported some stuff from a dynamically linked
library makes output weirdly big. Try it yourself, change the
number of imported modules and output size will significantly
change.
One question: Why?
Huge output size for simple programs
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 simple hello world program in D (using GDC) and the results: hello_world.o -> 24.6 KB hello_world (linux executable) -> 13 MB !!! What's the reason for that? What makes D applications so much bloated? Is this because whole GC implementation code is injected into executable or maybe libphobos.a being statically linked or is this because TypeInfo* ModuleInfo* stuff?
Re: Windows Header consts
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 container...
Re: Windows Header consts
On Tuesday, 8 September 2015 at 17:22:44 UTC, NX wrote: I have figure out typo: ...I had to figure out...
Re: Static arrays inside struct and class - bug?
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.
Re: Static arrays inside struct and class - bug?
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..?
Re: Static arrays inside struct and class - bug?
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 with NewExpression.
Re: Static arrays inside struct and class - bug?
Typo: *scenario
Re: Static arrays inside struct and class - bug?
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
large static array could allow indexing it through a null
pointer to potentially reach another object.)
The easiest workaround is to just dynamically allocate such
huge arrays:
byte[] arr = new byte[](1024*1024*16);
ReadProcessMemory(Proc, 0xdeadbeef, arr.ptr, arr.length, null);
The arr.ptr and arr.length are the key arguments there.
Sorry, I can't see _the_ point in that. I understand that could
be a problem if it was a "global" array but this scenery is
completely wrong in my view. I'm already going to dynamically
allocate it and my problem is actually a lot complex than what I
showed there, I not even allowed to do this:
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
//...
stuff* data = new stuff;
ReadProcessMemory(Proc, (void*)0xA970F4, data, stuff.sizeof,
null);
Here
(https://gist.github.com/NightmareX1337/6408287d7823c8a4ba20) is
the real issue if anyone want to see the real-world problem with
long lines of code
Static arrays inside struct and class - bug?
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 was trying to hack
into another process memory with something similar to this:
stuff data;
ReadProcessMemory(Proc, (void*)0xA970F4, &data, stuff.sizeof,
null);
Target program is written in C++ and because of this limitation
I'm not able to write equivalent code and here I'm stuck.
