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: shared - i need it to be useful
I don't see any problem with this proposal as long as these points hold: - Shared <-> Unshared is never implicit, either requiring an explicit cast (both ways) or having a language support which allows the conversion gracefully. - Shared methods are called by compiler if the type is shared or if there is no unshared equivalent. - Programmer needs to guarantee that shared -> unshared cast/conversion is thread-safe by hand; such as acquiring a lock, atomic operations... - Programmer needs to guarantee that when unshared -> shared cast/conversion happens, data is not accessed through unshared reference during the lifetime of shared reference(s). Effectively this means a data needs to be treated as shared everywhere at the same time otherwise all things fall apart.
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?
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: I can download Go, C#, C, C++, Delphi, Rust and get proper working plugins for the above mentioned editors but D is always that frustrating problem child. And i can not blame the plugin authors because the issues always seem to stem from the D plugins ( dcd, dscanner, ... ). I would like to point (again) that implementing proper and intelligent code completion for D is just ridiculously hard, and by that I mean *hard*. Seriously, one requires something as complex as the compiler itself. Oh and people actually did try to use compiler but guess what? Dmd doesn't do memory management of any kind (it was still the case last time I checked) it allocates and never frees, thus it's rather unfeasible to use dmd code for all those things. Also, the compiler is not fast enough for IDE usage anyway (ctfe, template heavy code...) so there is that. Maybe things work great in a few very specific editor but in my personal experience, D its editor support is non stop frustrating. And i suspect that this complaint is not new. From experience point I can tell the easiest and smartest IDE (plugin) *was* Mono-D¹. I say was because it doesn't support latest MonoDevelop version² and not maintained these days so you need to somehow find and install MonoDevelop 5 (you can find it here²). What you need to do is basically go to add-in manager, install "D Language Binding" from gallery, go to settings and set "Import Paths". If the compiler directory is not in the PATH you need to configure those too but that's about it. It even lets you open dub.json files as projects and some other nice stuff you can read in wiki³ (there are some outdated information so beware). The reason it's no longer maintained is as you can guess: it was a one man's show. ¹ https://github.com/aBothe/Mono-D ² https://github.com/aBothe/Mono-D/issues/648 ³ https://wiki.dlang.org/Mono-D
Re: So why double to float conversion is implicit ?
On Sunday, 22 October 2017 at 02:25:44 UTC, codephantom wrote: On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote: Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors. There a few lessons here. (1) D is not Java ;-) D is not C/C++ either. I fail to see how does it help to be C++ compliant. It's absolutely trivial to tell the compiler that conversion is on purpose by explicitly casting and it immensely helps to reduce bugs (since we are humans after all). (2) Know what types are being returned from your calls, before you call them. (3) Know what the language spec says about conversions (and their order): - https://dlang.org/spec/type.html (4) If unsure, test it: - https://dlang.org/phobos/std_traits.html#isImplicitlyConvertible Only then should you start coding ;-) It never crossed my mind that D would allow such type conversion since I don't recall any language that markets itself as _modern_ allows it. oh...and... (5) Don't waste time arguing with the spec ;-) (6) Don't expect the compiler to not comply with the spec I just think spec should be reviewed at this point.
So why double to float conversion is implicit ?
I was working on some sort of math library for use in graphical computing and I wrote something like this: const float PiOver2 = (atan(1.0) * 4) / 2; Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors. I see no reason as to why would this be legal in this century, especially in D. So can someone tell me what's the argument against this? Why type conversions differ between integral and floating types? Why can't I assign a long to an int but it's fine when assigning double to float? I think this is a serious topic and needs clarification.
[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: LDC, GDC command line args
There is one for GDC[1], couldn't find anything for LDC. [1] https://wiki.dlang.org/GDC/Using_GDC
Re: 16MB static arrays again...
Maybe you can merge this: https://github.com/dlang/dmd/pull/6081
Re: Compiling DMD on Windows: A journey of mystery and madness
On Sunday, 21 August 2016 at 16:49:53 UTC, Andrei Alexandrescu wrote: On 08/21/2016 12:41 PM, NX wrote: For God's sake no place in docs say that I need DMC, which is something I figured from make error output. I reinstalled dmd and this time I checked that box which makes installer automatically download and install dmc. After making dmc available from %path%, I was able to compile phobos, that seemed too good to be true. Might be nice to contribute this tidbit to the wiki. Actually I just noticed that it *is* actually mentioned: https://wiki.dlang.org/Starting_as_a_Contributor#Windows This kind of shows how an unstructured doc can result in info-missing by people...
Compiling DMD on Windows: A journey of mystery and madness
[warning: rant ahead] I'm amazed by the lack of documentation - or to say it better, documentation that works - on how to compile DMD and eventually Phobos. Here [https://wiki.dlang.org/Starting_as_a_Contributor#Windows_2] we have awfully categorized yet promising information on how to seriously compile DMD from source. Before I compile dmd, I attempted to compile druntime & phobos and failed miserably. For God's sake no place in docs say that I need DMC, which is something I figured from make error output. I reinstalled dmd and this time I checked that box which makes installer automatically download and install dmc. After making dmc available from %path%, I was able to compile phobos, that seemed too good to be true. Then here comes the part about compiling dmd: $ make -fwin32.mak release This innocent looking command which supposed to compile dmd failed with an error message that killed my brain cells: $ run idgen $ Error: 'run' not found WTF? Are we seriously trying to execute "run"? Ohh the horror! Walking on the edge of going mad, I noticed a horrible detail in win32.mak file: # D compiler (set with env variable) #HOST_DC=dmd The fact that HOST_DC=dmd is commented out and not being defined as an environment variable is shameful to the max. After fixing make file, I was finally able to compile dmd. Now I want to sue D Language Foundation for dealing me mental damage. Thanks for reading.
Re: Why 16Mib static array size limit?
You can apply a patch if you're willing to compile dmd from source by doing the following: Find the following code in file 'mtype.d' at line 4561: bool overflow = false; if (mulu(tbn.size(loc), d2, overflow) >= 0x100 || overflow) // put a 'reasonable' limit on it goto Loverflow; And change it to: bool overflow = false; mulu(tbn.size(loc), d2, overflow); if (overflow) goto Loverflow; I would make a PR if I had the time (anyone?)...
Re: Why 16Mib static array size limit?
https://issues.dlang.org/show_bug.cgi?id=14859 This limitation is put there because of optlink (which fails to link when you have enough static data), and is actually entirely meaningless when combined with -m32mscoff & -m64 switches (since other linkers handle huge static data just fine).
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: D-Man culture
░▒░▒██░ ▓▒░░█ ▓ ░█▓ ▓ ▒▒█░░█▓░ ░█▒░▒▓▓▒▒ ▒██▒ ░██▒░▒▒ ░██▒ ██▓ ░██▓ ██▓ ░██▒ ██▓ ░██░ ▓█▓ ▒█▓ ▒█▓▓█▓██▓▓▒ ██ █▒▓▓██▓▓▓█▓▓▓███▓▒ ▒█ ▒█▒ ▓█▓█▓█▒░█▓▓██▓███ ░█░ ░██ █▓██░ ░▓▓████▒ ▓█░ ▓▓██ ▓██ ▒▒▓▓▓█ █▓ ░█▓▓▓██░ ▓ ▒ ▓▓▓█▒█▓ ▒███▓█▒███▒ ▒▒█▓ ███▓█▒ ▓██ █▓█▓█▒ ░ █▓▓█░ █▓█▓█▒ ▒█▓█▓▓▓█▒ ▓██▓▓█▒ ░█▓█▓▓▓█▓ █▓█▓▓█░ ░█▓█▓▓▓█▓ ░█▓█▓▓█ ▒███▓▓▓█▓ ▓▓█▓▓█▓ █▓██░ █▓█▓▓█ ▓██▓█ ▓▓█▓▓█░ ▓██▓█▓ ░█▓█▓█▒ ░▓██▓▓██ █▓█▓█▓ ▒▓███▓▓▓██ ▓███▓▓▓██▓███ ░█▓█▓ ▓▓▓██▓▒ ▓███▓██▓███▓▒ ▓██▓▓▓▒▒░ ▓█ ▒█ ▓█░ █ ░█ ██ ░█ ▓█ █░ ▓█ █▒ ▒▒░ ▒█▒ ██░ ▒▓▒░▒▒░▓█▒▓█ █▒ ░▓ ▒▒▒▒ ░▒▒▒
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: Andrei's list of barriers to D adoption
And this forum is impossible to use on smart phones... I gave up. You know the rest...
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 13:51:30 UTC, NX wrote: This. I think the biggest problem about D is it's trying to satisfy *everyone*. It's literally combining C++, Java, Python, and ~the like. At some point it even tries to mimic Rust! Trying to be everything at once is key po- ---int of failure. You try to be everything, then you see you're non of them. There is no clear vision what D is aiming to be. Think about it. Let's say we seamlessly combined GC + borrow semantics + manual memory management. How can you expect a library writer to decide it's way? There are way too many things to consider. And then we may write 2-3 versions of the same lib; say, one that uses GC and the other one that requires manual memory management. What a mess! D have GC. I am completely fine with GCs. But there are things that hurt rea
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 08:15:42 UTC, Russel Winder wrote: On Sun, 2016-06-05 at 19:20 -0700, Walter Bright via Digitalmars-d wrote: […] * The garbage collector eliminates probably 60% of potential users right off. And i bet over 80% of them are just saying this based on zero evidence, just prejudice. Go went with the attitude "Go has a GC, if you cannot deal with that off". Many people did exactly that and the Go community said "by". Arrogant this may have been, but Pike, Cox, et al. stuck to their guns and forged a community and a niche for the language. This then created traction. Now GC in Go is not an issue. This. I think the biggest problem about D is it's trying to satisfy *everyone*. It's literally combining C++, Java, Python, and ~the like. At some point it even tries to mimic Rust! Trying to be everything at once is key po
Re: Some questions on latest work
On Wednesday, 27 April 2016 at 20:30:56 UTC, Israel wrote: Lol, i hope youre being paid and not doing it for free. Don't feed the evil.
Re: XDG-APP and D
I will just leave it here: http://www.zdnet.com/article/linux-expert-matthew-garrett-ubuntu-16-04s-new-snap-format-is-a-security-risk/
Re: Calling .NET from D
I used this[1] code for interfacing between C# and D once. It[2] demonstrates how to use a function callback passed from C# code. C# use winapi calling convention by default which caused me hours of headache untill I figured it out. Fortunately, there is an attribute to specify it. [1] https://github.com/NightmareX1337/IDL/wiki [2] https://github.com/NightmareX1337/IDL/blob/master/IDL/IDL.d
Re: Potential GSoC project - GC improvements
On Wednesday, 9 March 2016 at 22:49:28 UTC, Jeremy DeHaan wrote: Hey all, I'm trying to think of good project ideas for this years GSoC, and one in particular I thought would be a great was working on and improving the GC. I'm not sure what the scope of this project would be like, but at the moment I am thinking writing a generational collector would be a good place to start. http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html Good luck with generational GC... I think the best possible improvement for GC is making it lock-free. Currently, GC lock cause some serious performance penalties for multithreaded code when frequent allocations take place.
Re: Parameterized Keywords
On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote: Just curious if anyone can see the use for them? I believe 'new' keyword can take advantage of this quite good. For example you can pass memory usage strategy like so: MyClass mc = new[stream] MyClass(); MyClass mc2 = new[static] MyClass(); Deja-vu? Yes the idea comes from OpenGL. Also it might come in handy for other stuff: MyClass mc3 = new[no_internal_pointers] MyClass(); MyClass mc4 = new[no_compacting] MyClass();
Re: Disappointing inflexibility of argument passing with "alias this"
On Tuesday, 23 February 2016 at 15:07:08 UTC, NX wrote: It's arguably the right design. When I say arguably I don't mean arguably :D "It's not the right design in my opinion"
Re: Disappointing inflexibility of argument passing with "alias this"
On Tuesday, 23 February 2016 at 14:35:35 UTC, Adam D. Ruppe wrote: There's no ambiguity there and no bug; it is working as defined. alias this is only ever invoked if the outer type doesn't fit. It does fit here, A is A, so no need to check alias this at all. It's arguably the right design. Conservativeness can prevent a lot of stupidity. I don't have a an example at hand though...
Re: Disappointing inflexibility of argument passing with "alias this"
On Tuesday, 23 February 2016 at 12:43:42 UTC, Kagamin wrote:
Don't we already have implicit conversions with alias this, so
what's the deal?
The deal is you can't have implicit construction like:
A a = 5; // Error
a = 5 // okay
struct A { int i; alias i this; }
void f(int i){}
void f(string s){}
void g(A a){ f(a); } //what's called?
f(int) will be called. But problem here is the opposite: try
calling g() with an int argument (like 5) and compiler won't let
you.
import std.stdio;
struct A { int i; alias i this;}
void f(int i){writeln("int");}
void f(A a){writeln("A");}
void g(A a){ f(a); }
void main()
{
g(A());
}
Above code prints "A". I would expect it to be an ambiguity
error. Not sure if I should file a bug report?
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 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 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: Downtime of gdc ftp, bugzilla, site, et. al.
On Sunday, 24 January 2016 at 20:07:47 UTC, rsw0x wrote: Where can I find GDC explorer? I believe that's it: https://d.godbolt.org
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: extern(C++, ns)
On Wednesday, 13 January 2016 at 10:53:06 UTC, Ola Fosheim
Grøstad wrote:
Next version of C++ will probably allow this:
namespace a::b::c::d::e {
...
}
Current version of D2 allow this:
module a.b.c.d.e;
Re: Error message improvement ideas
On Friday, 18 December 2015 at 18:55:29 UTC, Adam D. Ruppe wrote: [...] The biggest problem is overly templated functions. We should seriously find a way to make them error friendly. Maybe: auto find(Range : [InputRange], V)(Range haystack, V needle) Rather than: auto find(Range, V)(Range haystack, V needle) if(isInputRange!Range) But I'm sure core d devs will strike with a "we can't change semantics, it would break existing code" argument...
Re: __traits(getAttributes, ...) gets attributes for the first overload only
On Sunday, 6 December 2015 at 02:00:30 UTC, Andrei Alexandrescu wrote: Yah, error is the way to go. -- Andrei Can I ask a question?: Why we don't have a way to get an exact overload of function? Something like: void foo(int i); int foo(float f); //... int function(float) foop = ::(float);
Re: "Getting involved" on dlang.org?
On Wednesday, 2 December 2015 at 16:22:32 UTC, bachmeier wrote: Another is that there is no guide for contributing to the documentation. I didn't know lines are supposed to be no more than 80 columns. Actually there is such documentation about it but guess what? It's hidden -like many other things which should normally be reachable: Home Page > Resources > The D Style Scroll down to bottom and you will see the title saying: Additional Requirements for Phobos Lines have a soft limit of 80 characters and a hard limit of 120 characters. This means that most lines of code should be no longer than 80 characters long but that they can exceed 80 characters when appropriate. However, they can never exceed 120 characters.
Re: ARC on Objects not Class Definitions
On Thursday, 5 November 2015 at 01:42:18 UTC, Adam D. Ruppe wrote:
The object itself needs to know it because the object may pass
out references to itself.
Consider something like this:
class MyString {
private char[128] data_;
private int length_;
char[] getData() { return this.data_[0 .. length_]; }
}
How you allocate that isn't terribly important. You might
malloc it, you might gc it, you might stick it on the stack.
(This is all possible, even easy, with D today btw.)
But, when should it be freed?
char[] getString() {
MyString s = make!myString;
return s.getData();
// does s get freed here? what about the returned member
though?
}
How can class coder possibly know what's happening outside of his
implementation or how can compiler understand a reference to a
class member is being returned ? Doesn't this require full
control flow analysis ?
Enlighten me please...
Re: Example code on D homepage does not run successfully
On Saturday, 17 October 2015 at 12:57:25 UTC, Ralph Tandetzky wrote: If I understand this cryptic error message correctly, the problem is missing or inadequate input. There is no floating point number to be parsed and hence the string "" is parsed unsuccessfully which leads to an exception producing this horrible error message. I would suggest to fix the program quickly, maybe by using a string that is not given at runtime through stdin, but as a fixed string like "Pi is approximately 3.14159265." It's not because input is empty, but rather that across-web compiling is highly broken and problematic. There is an "Input" button bottom of the code area which shows what input will be given to stdin, which is actually not empty (it's written: "2.4 plus 2.4 equals 5 for sufficiently large values of 2.") Maybe one day someone will take care of improving the infrastructure...
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: 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*
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: A collection of DIPs
On Saturday, 12 September 2015 at 15:54:53 UTC, Adam D. Ruppe wrote: D programs *never* have a GC thread. Remember, the D GC isn't magic and isn't actually even that complicated, it is just an ordinary function call. That's what I was afraid of :'(
Re: A collection of DIPs
On Friday, 11 September 2015 at 19:30:56 UTC, ponce wrote: Some of us use and need @nogc all the time. The other parts of an application can use the GC: best of both worlds. Is there even a compiler switch to disable GC altogether so the program doesn't have a GC thread? No, I can't see it...
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: 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: A collection of DIPs
On Wednesday, 9 September 2015 at 21:27:02 UTC, deadalnix wrote: You can make a difference. Yes you probably don't have as much experience, but that's a great opportunity to learn. Many here would be willing to mentor you if you want. I can do it if you want to contribute to SDC. I'm sure other would on other projects they are familiar with. Generally, don't underestimate the impact you can have. Everybody think someone else will do it and is more qualified? Turns out that nobody is qualified before having done it for a while. So unless you get started, you'll never be qualified. Aaaannndd, I started reading GC theory books.
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: 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?
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 06:13:59 UTC, Dominikus Dittes Scherkl wrote: On Tuesday, 8 September 2015 at 17:07:50 UTC, NX wrote: And, can somebody show me a working example code of how to solve that friend class problem without some horrible hacktic way and agressive template/mixin stuff ? (I doubt it can solved via templates but anyway...) Why would you ever need "friend"? All functions have access to private members if they are declared within the same module, so there "friend" is not needed. And if you need access from outside the module, why do you declare them "private"? IMHO "friend" is a misconception, that is only there to compensate for the lack of modules in C++. Woah! I didn't know about private members are visible in it's module, but to me it feels much cleaner if it was achieved by something similar to what I suggested... Isn't it? never mind...
Re: A collection of DIPs
On Wednesday, 9 September 2015 at 14:00:52 UTC, Brandon Ragland wrote: It's slow, really slow, and stopping the entire world is painful, even in trivial user applications. A pause for even half a second or less on the UI makes the application looks "chunky" and broken. If you're having that much serious problems then there is only one thing I can think of: Your computer is survived from 90s The more you don't collect, the more time it takes time to collect; thus, you may want to configure GC to do it's job more often so it doesn't stop significantly, and also manually trigger collection where appropriate... If I had the time and knowledge I would spend them to make D better, but you can't expect a teenager (tip: me) to help making DMD front-end better or to implement a precise GC... I guess?
Re: A collection of DIPs
Thanks all your thoughts and criticisms... - I'm fine if DMD ever starts to support multiple `alias this`, just to see if it would be easier for compiler to use opCast for implicit casts. - Those who think ^ would cause problems as it's already used for xor must be forgetting * is widely used multiplication operator and if that's fine, ^ is fine too IMHO... (Or am I missing something?) - When I first started learning D I expected templates to have exact same syntax and struggled about it not being the same. Also, if D use ! for both, then editors can easily understand a template function is being declared so there is a point in that. - About precise GC, you guys are the ones with ultimate knowledge so I don't want to go that much deep as I still a lot to learn (because everytime I learn something, I feel even more uninformed) And, can somebody show me a working example code of how to solve that friend class problem without some horrible hacktic way and agressive template/mixin stuff ? (I doubt it can solved via templates but anyway...)
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: 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...
A collection of DIPs
https://github.com/NightmareX1337/DX Don't kill me, I'm just trying to help... You can report issues and create pull requests :) Destroy!
Re: Static arrays inside struct and class - bug?
Typo: *scenario
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.
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
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?
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 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.
