Re: Searching for Dgame Maintainer
On Monday, 25 November 2019 at 10:16:47 UTC, Vijay Nayar wrote: On Sunday, 24 November 2019 at 16:34:35 UTC, Dgame wrote: Maybe some of you know Dgame (https://github.com/Dgame/Dgame), it was my biggest project using D and was a lot of fun at that time. But since I don't use D anymore, I have neither the time nor the desire and even less the knowledge to take care of it anymore. So, if anyone wants to keep it going, I am open for offers. I have never used Dgame before, but what immediately stands out is that it's pretty well organized. Your website also does a great job at explaining how to use the library and the tutorials are well done. There is even a style guide for contributors. It really seems that quite a bit of work and care went into making this. Thanks. Yes, it was my favorite project at that time and I was really into it. I am curious to know why you are no longer using D? Is it more that personal and professional life has taken up your free time, or have you found something else where you would prefer to invest your time and energy? Or was it something about the D language or community that initiated the change? A little bit of everything you said. D was a very welcome experience before C++11 came, but there are more modern approaches now, for me it's Rust: rich ocosystem, easy to install and update, easy to install packages, almost no bugs (at least I haven't experienced any so far in the last ~4 years) great IDE support and no GC! That why I'm doing almost everything today in Rust. I've even convinced my coworkers that we should use Rust. It has so many tutorials and works out of the box. That sums it up, I have no reason to use D anymore. :)
Searching for Dgame Maintainer
Maybe some of you know Dgame (https://github.com/Dgame/Dgame), it was my biggest project using D and was a lot of fun at that time. But since I don't use D anymore, I have neither the time nor the desire and even less the knowledge to take care of it anymore. So, if anyone wants to keep it going, I am open for offers.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
fun(10)
==>
{
T __temp0 = void;
fun(__temp0 := 10);
}
The first problem the Language Maintainers identified with this
approach is that the rewrite is from an expression to a
statement, rendering it invalid.
The expression should be rewritten as an expression to clarify
how it behaves in larger expressions.
Couldn't that just be rewritten as something like
fun(tuple(10).expand);
?
Re: Creating fixed array on stack
On Friday, 11 January 2019 at 14:46:36 UTC, Andrey wrote:
Hi,
In C++ you can create a fixed array on stack:
int count = getCount();
int myarray[count];
In D the "count" is part of type and must be known at CT but in
example it is RT.
How to do such thing in D? Without using of heap.
You could try alloca:
import core.stdc.stdlib: alloca;
pragma(inline, true) auto stack(T, alias len)(void* p =
alloca(T.sizeof * len)) {
return (cast(T*) p)[0 .. len] = T.init;
}
void main() {
import std.stdio: writeln;
int size = 42;
auto a = stack!(int, size);
writeln(a);
a[] = 2;
writeln(a);
}
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
wrote:
The attribute spam is almost longer than the function itself.
I often wished for something like
module foo.bar;
default(@safe, pure);
function foo() { } // is annotated with @safe & pure
@deny(pure) // or pure(false) as I suggested a long time ago
function bar() { } // is annotated only with @safe
That would IMO lighten the burden.
Re: Friends don't let friends use inout with scope and -dip1000
On Monday, 20 August 2018 at 15:55:54 UTC, Kagamin wrote:
On Monday, 20 August 2018 at 13:02:23 UTC, Atila Neves wrote:
On Monday, 20 August 2018 at 12:56:42 UTC, Kagamin wrote:
You need `return` attribute there, not `scope`:
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size);
}
~this() @trusted { free(ints); }
inout(int)* ptr() return inout { return ints; }
}
I need `return` for what exactly? Your code still compiles,
and my point is it shouldn't. It sure isn't memory safe.
@safe:
struct MyStruct
{
import core.stdc.stdlib;
int* ints;
this(int size) @trusted { ints = cast(int*) malloc(size); }
~this() @trusted { free(ints); }
inout(int)* ptr() return inout { return ints; }
}
int* gInt;
void f()
{
auto s=MyStruct(10);
gInt=s.ptr;
}
Error: address of variable s assigned to gInt with longer
lifetime
Looks safe to me.
Is that safe as well?
void f()
{
auto s = MyStruct(10);
gInt = (() => s.ptr)();
}
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 10:31:48 UTC, Seb wrote:
On Friday, 20 July 2018 at 10:08:03 UTC, Dgame wrote:
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack temporary
(*very* bad), or allocates with no way to deallocate (bad).
What about something like this?
import std.stdio;
ref T byRef(T)(T value) {
static T _val = void;
_val = value;
return _val;
}
void foo(ref int a) {
writeln("A = ", a);
}
void main() {
foo(42.byRef);
foo(23.byRef);
}
That can't work, consider e.g.:
foo(10.byRef, 20.byRef); // calls foo with (20, 20)
https://run.dlang.io/is/lazeu2
True.. But this could work (but is way more uglier):
https://run.dlang.io/is/rKs2yQ
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack temporary
(*very* bad), or allocates with no way to deallocate (bad).
What about something like this?
import std.stdio;
ref T byRef(T)(T value) {
static T _val = void;
_val = value;
return _val;
}
void foo(ref int a) {
writeln("A = ", a);
}
void main() {
foo(42.byRef);
foo(23.byRef);
}
Re: D'ish similar_text?
On Thursday, 10 May 2018 at 20:38:12 UTC, Vladimir Panteleev wrote: On Thursday, 10 May 2018 at 20:32:11 UTC, Dgame wrote: immutable size_t len = s1.length + s2.length; percent = (len - distance) * 100.0 / len; Note that this formula will give you only 50% similarity for "abc" and "def", i.e. two completely different strings. I suggest to divide by max(s1.length, s2.length) instead. Hm, that does not work either. ABC and AZB have a different outcome with both. How can I calculate the percentage with levenshtein? It's rather simple with similar_text since it returns the amount of similar chars.
Re: D'ish similar_text?
On Thursday, 10 May 2018 at 20:13:49 UTC, Vladimir Panteleev
wrote:
On Thursday, 10 May 2018 at 20:08:04 UTC, Dgame wrote:
void similar_text_similar_str(char* txt1, size_t len1, char*
That looks like an implementation of Levenshtein distance. We
have one in Phobos:
https://dlang.org/library/std/algorithm/comparison/levenshtein_distance.html
Oh, that could to work, thank you. I've just tested it quickly,
but that code seems to produce the same results:
size_t similar_text2(in string s1, in string s2, out double
percent) {
import std.algorithm: levenshteinDistance;
immutable size_t distance = s1.levenshteinDistance(s2);
immutable size_t len = s1.length + s2.length;
percent = (len - distance) * 100.0 / len;
return distance;
}
D'ish similar_text?
I'm in need for some sort of string similarity comparision. I've
found soundex but that didn't solved my needs. After some search
I found a C implementation of similar_text, but that is quite
ugly... I was able to let it work in D but it's still somewhat
messy. Is there any D implementation of similar_text? Here's my
current code which makes heavy use of pointer-arithmetic which
makes it hard to understand.
void similar_text_similar_str(char* txt1, size_t len1, char*
txt2, size_t len2, size_t* pos1, size_t* pos2, size_t* max) {
char* p, q;
char* end1 = txt1 + len1;
char* end2 = txt2 + len2;
size_t l;
*max = 0;
for (p = txt1; p < end1; p++) {
for (q = txt2; q < end2; q++) {
for (l = 0; (p + l < end1) && (q + l < end2) && (p[l]
== q[l]); l++) { }
if (l > *max) {
*max = l;
*pos1 = p - txt1;
*pos2 = q - txt2;
}
}
}
}
size_t similar_text_similar_char(char* txt1, size_t len1, char*
txt2, size_t len2) {
size_t sum;
size_t pos1, pos2, max;
similar_text_similar_str(txt1, len1, txt2, len2, ,
, );
if ((sum = max) != 0) {
if (pos1 && pos2) {
sum += similar_text_similar_char(txt1, pos1, txt2,
pos2);
}
if ((pos1 + max < len1) && (pos2 + max < len2)) {
sum += similar_text_similar_char(txt1 + pos1 + max,
len1 - pos1 - max,
txt2 + pos2 + max, len2 - pos2 - max);
}
}
return sum;
}
size_t similar_text(in string s1, in string s2, out double
percent) {
immutable size_t sim = similar_text_similar_char(s1.dup.ptr,
s1.length, s2.dup.ptr, s2.length);
percent = sim * 200.0 / (s1.length + s2.length);
return sim;
}
Re: auto: useful, annoying or bad practice?
On Wednesday, 2 May 2018 at 00:01:42 UTC, Nick Sabalausky wrote: Now, all that said, using auto for a function signature's return type shouldn't usually be done, except in very careful, specific "voldemort type" kinds of situations (and even then, I dont see a real big point). I do it all the time because of attribute inference. D has way to many attributes, so I'm willing to automatically let the Compiler interfere which are appropriate, he knows it better anyway.
Re: Tilix 1.7.9 Released
On Sunday, 29 April 2018 at 14:01:10 UTC, Gerald wrote: A new version of tilix has been released. For those not familiar with it, Tilix is a terminal emulator for Linux written in D using GTK. The list of changes is available here: https://gnunn1.github.io/tilix-web/2018/04/28/release-1-7-9 As always, I'm always looking for people who are interested in contributing, PRs welcome. Finally a big thank you to Mike Wey who has continued to work on and evolve GtkD. Working on libraries is often behind the scenes work that doesn't get the appreciation it deserves. I was struck by a recent reddit post on the gnome shell memory leak which involved C and javascript, it mentioned how difficult it is to merge two different memory models. Mike has managed this with aplomb in terms of integrating the Gtk reference counting into D's GC. So thanks Mike, your efforts are much appreciated! Since I'm on Windows I sadly can't use it, but I suggested it to my colleagues - which are using Ubuntu - half a year ago and they use it since then and still love it. So keep up the good work! :)
Re: Static Array with negative index results in a strange error-message
It's really fun playing around: char[int.max - 1] c; results in Internal error: dmd/backend/cgcod.c 634 with DMD 2.079. Guess I or somebody else should report this.
Re: Static Array with negative index results in a strange error-message
On Monday, 23 April 2018 at 13:48:07 UTC, Steven Schveighoffer wrote: On 4/23/18 9:32 AM, Dgame wrote: char[-1] c; results in Error: char[18446744073709551615LU] size 1 * 18446744073709551615 exceeds 0x7fff size limit for static array Should we fix that? A negative index should be IMO detected sooner/with a cleaner error message. Hm.. at least it's detected. I actually don't think the message is wrong: -1 is a valid size_t literal, and results in that number. if you did: enum size_t x = -1; char[x] c; You would get the same result, and I don't know how we would fix that. -Steve C's error message is error: 'c' declared as an array with a negative size char c[-1]; That is more understandable.
Static Array with negative index results in a strange error-message
char[-1] c; results in Error: char[18446744073709551615LU] size 1 * 18446744073709551615 exceeds 0x7fff size limit for static array Should we fix that? A negative index should be IMO detected sooner/with a cleaner error message.
Re: Assoc. Array and struct with immutable member
On Tuesday, 17 April 2018 at 11:38:17 UTC, Jonathan M Davis wrote:
On Sunday, April 15, 2018 17:59:01 Dgame via
Digitalmars-d-learn wrote:
How am I supposed to insert a struct with immutable members
into an assoc. array?
Reduced example:
struct A {
immutable string name;
}
A[string] as;
as["a"] = A("a"); // Does not work
I would point out that in general, having const or immutable
fields in a struct is a terrible idea. It causes all kinds of
problems because stuff like assignment doesn't work. If you
want the field to be read-only, you'll have far fewer problems
if you simply use a function to access it instead of making the
member public. e.g.
struct A
{
public:
@property string name() { return _name; }
private:
string _name;
}
The problem you're having here is just one example of the list
of things that don't work if you have a struct with immutable
members. It looks like the AA probably is doing something like
initializing the entry with A.init and then assigning it the
new value, and that's not going to work if the struct has
immutable members - which is exactly what the error message
says.
- Jonathan M Davis
That's how I solved it. But it is troublesome and annoying
because it increases the amount of manually work I have to do.
Re: Ldc on Windows
On Tuesday, 17 April 2018 at 11:01:21 UTC, Nicholas Wilson wrote: On Tuesday, 17 April 2018 at 10:17:56 UTC, Dgame wrote: Ah, I found the msvcEnv.bat and I told me that I have to VSC installation. Solved! You should also be able to use -link-internally /LLMV's lld if you don't want to install MSVC What would be "/LLMV's lld" in this case?
Re: Ldc on Windows
On Tuesday, 17 April 2018 at 09:42:01 UTC, Dgame wrote: I'm trying to use Ldc on Windows, but I get these linker errors: OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 9: Unknown Option : OUT OPTLINK : Warning 9: Unknown Option : LIBPATH OPTLINK : Warning 9: Unknown Option : D OPTLINK : Warning 9: Unknown Option : LDC OPTLINK : Warning 9: Unknown Option : .. OPTLINK : Warning 9: Unknown Option : LIB :REF.obj Error 2: File Not Found :REF.obj Error: D:\D\dmd2\windows\bin\link.exe failed with status: 1 How can I solve this? Ah, I found the msvcEnv.bat and I told me that I have to VSC installation. Solved!
Ldc on Windows
I'm trying to use Ldc on Windows, but I get these linker errors: OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 9: Unknown Option : OUT OPTLINK : Warning 9: Unknown Option : LIBPATH OPTLINK : Warning 9: Unknown Option : D OPTLINK : Warning 9: Unknown Option : LDC OPTLINK : Warning 9: Unknown Option : .. OPTLINK : Warning 9: Unknown Option : LIB :REF.obj Error 2: File Not Found :REF.obj Error: D:\D\dmd2\windows\bin\link.exe failed with status: 1 How can I solve this?
Assoc. Array and struct with immutable member
How am I supposed to insert a struct with immutable members into
an assoc. array?
Reduced example:
struct A {
immutable string name;
}
A[string] as;
as["a"] = A("a"); // Does not work
Re: rvalues -> ref (yup... again!)
On Thursday, 29 March 2018 at 20:05:48 UTC, Rubn wrote:
On Thursday, 29 March 2018 at 19:11:30 UTC, Dgame wrote:
Just to be sure it does not got los: You know that you can
avoid the temp/copy if you add one method to your struct, yes?
import std.stdio;
struct Big {
string name;
float[1000] values;
this(string name) {
this.name = name;
}
@disable
this(this);
ref auto byRef() inout {
return this;
}
}
void foo(ref const Big b) {
writeln(b.name);
}
void main() {
Big b = Big("#1");
foo(b);
foo(Big("#2").byRef);
}
That works like a charm and avoids any need for rvalue
references. Just add it as mixin template in Phobos or
something like that.
Doesn't work with built-in types like float.
Why would you want to use a float as a rvalue reference?
Just adds bloat for operators like opBinary if you want that to
be ref.
foo((a.byRef + b.byRef * c.byRef).byRef)
// vs
foo(a + b * c);
It's kind of funny all this talk about allowing temporaries to
bind to refs being messy, yet you can already bind a temporary
to a ref in a messy way using that.
Yeah, it is a bit messy. It is not perfect, but is does avoid any
temp var!
Let's look at a Vector2f example with the following opBinary:
auto opBinary(string op)(ref const Vector2f v) {
return Vector2f(mixin("this.x" ~ op ~ "v.x"), mixin("this.y"
~ op ~ "v.y"));
}
void foo(ref const Vector2f v) {
writeln(v.x, ':', v.y);
}
foo((Vector2f(2, 4).byRef + Vector2f(4, 6).byRef).byRef);
Since opBinary needs to be a template, you can combine my
solution with auto ref:
auto opBinary(string op)(auto ref const Vector2f v) {
return Vector2f(mixin("this.x" ~ op ~ "v.x"), mixin("this.y"
~ op ~ "v.y"));
}
void foo(ref const Vector2f v) {
writeln(v.x, ':', v.y);
}
foo((Vector2f(2, 4) + Vector2f(4, 6)).byRef);
That is cleaner. :)
Re: rvalues -> ref (yup... again!)
Just to be sure it does not got los: You know that you can avoid
the temp/copy if you add one method to your struct, yes?
import std.stdio;
struct Big {
string name;
float[1000] values;
this(string name) {
this.name = name;
}
@disable
this(this);
ref auto byRef() inout {
return this;
}
}
void foo(ref const Big b) {
writeln(b.name);
}
void main() {
Big b = Big("#1");
foo(b);
foo(Big("#2").byRef);
}
That works like a charm and avoids any need for rvalue
references. Just add it as mixin template in Phobos or something
like that.
Re: Binding rvalues to ref parameters
On Sunday, 25 March 2018 at 19:24:00 UTC, Rubn wrote: On Sunday, 25 March 2018 at 14:28:30 UTC, Andrei Alexandrescu wrote: On 3/25/18 9:40 AM, Rubn wrote: On Saturday, 24 March 2018 at 12:51:07 UTC, Andrei Alexandrescu wrote: Filing a DIP is like filing a police report: once it's in the system, we're obligated to work on it. There's a guarantee of a response. https://wiki.dlang.org/DIP36 The DIP system has changed extensively since Mike Parker took it over. This "old format" DIP would need to be submitted to https://github.com/dlang/DIPs. That's not the issue... That DIP was already labelled as rejected. Wasn't able to find an explanation anywhere as to why either. No point changing the format for a DIP that was already rejected. There is one: https://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=9
Re: rvalues -> ref (yup... again!)
Here is what I've used if I had to: https://p0nce.github.io/d-idioms/#Rvalue-references:-Understanding-auto-ref-and-then-not-using-it
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Monday, 5 February 2018 at 00:56:20 UTC, welkam wrote: On Sunday, 4 February 2018 at 22:05:45 UTC, Dgame wrote: I want to use a language and if I see problems which are ignored I move on. That is how it is, no offense. So you see a problem and do not work on fixing it then complain that other people do the same. Ok. Nice try in twisting someones words. As I already said, you are one of those guys I spoke about. :) Keep going!
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Sunday, 4 February 2018 at 12:02:25 UTC, psychoticRabbit wrote: On Sunday, 4 February 2018 at 10:31:17 UTC, Dgame wrote: On Sunday, 4 February 2018 at 01:46:34 UTC, psychoticRabbit wrote: Your suggestions are welcome. Just don't tell people that if they don't listen to them, then their community is bad. That's not how an open source community works. I've never said that the community is bad. :) ok.. I stand corrected. In any case, the problem is not with the community, but your expectations of the community. Once you realise this, you can change your expectations.. and then you'll have a much happier time :) No, I have no expectations, I simply stated the facts about what I've seen so far. I do not want to live a happy live in a community, why should I? I want to use a language and if I see problems which are ignored I move on. That is how it is, no offense.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Sunday, 4 February 2018 at 01:46:34 UTC, psychoticRabbit wrote: Your suggestions are welcome. Just don't tell people that if they don't listen to them, then their community is bad. That's not how an open source community works. I've never said that the community is bad. :)
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Saturday, 3 February 2018 at 23:45:21 UTC, bachmeier wrote: On Saturday, 3 February 2018 at 23:39:00 UTC, Dgame wrote: On Saturday, 3 February 2018 at 23:29:58 UTC, Christof Schardt wrote: On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote: I congratulate you on your decision. I also changed to another language and I've never regretted it. Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book) First back to C++11/14/17. Since 2017 I'm mostly using Rust. Then why are you posting here? Your post was 100% troll. It was not, your posts shows exactly what I meant. :)
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Saturday, 3 February 2018 at 23:25:09 UTC, welkam wrote: On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote: This could be used to improve D So when will you start working on issues he described? And when will you? I already tried in the past as you can see.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Saturday, 3 February 2018 at 23:29:58 UTC, Christof Schardt wrote: On Saturday, 3 February 2018 at 22:59:06 UTC, Dgame wrote: I congratulate you on your decision. I also changed to another language and I've never regretted it. Which is...? (just out of curiousity, btw I'm currently watching nim, after long years monitoring D and buying every book) First back to C++11/14/17. Since 2017 I'm mostly using Rust.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
This is a nice, refreshing post. You state problems and why you switched to Go. You give a ton of informations (here and in your prior posts) why you did what you did and what problems you've seen. This could be used to improve D. But the regular reply you will get if you criticize D even a little is "You are wrong! D is great!" or "You have a point, but ...". You can watch these discussions regularly, it's really hilarious. It always ends in the same way: Criticism is being hunted down and after Page 3 you can only read how great D is and why. I congratulate you on your decision. I also changed to another language and I've never regretted it. Sadly the D community will never learn from those excelent posts which only wants to help D to become better than it is. It's really sad... I bet this post will also torn apart to bash any sign of criticism.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 17:55:06 UTC, H. S. Teoh wrote: On 1/26/18 5:50 PM, Dgame wrote: [...] > My impression so far is that most of the D users love to > program in a tiny editor without the features which modern > IDE's gives you. That's impressive, but outdated and even a > bit silly if the project is bigger. In any company I've > been so far we've used IDE's, because their feature-set and > tools take so much work away from you - I don't want to miss > them anymore. Nowadays, the majority of programmers who are > willing to try new/others programming languages, think so > too. I'm somewhat sure that this unneccessary hurdle is one > of D's biggest mistakes. [...] Not to negate the fact that we *do* need to improve IDE support, but the claim that IDEs are "required" for large projects is false, and so is the claim that non-IDE editors are "tiny". At my day job, I work with a very large codebase (50,000+ source files, and yes, I mean 50 *thousand*, not hundred), and vim has more than sufficed for the past 10 years. And vim does a *lot* more than what some people tend to falsely believe that it's "just" another "tiny" text editor on the order of NotePad. This doesn't excuse our poor IDE support, of course, we do need to improve our IDE support. But it's tiresome to keep reading these unfounded claims that IDE's are somehow inherently superior to powerful editors like vim, which is not necessarily the case. T It's nice that this works for you, but I strongly believe that most of the programmers who are willing to try something new are younger and I also think that most of them don't use VIM/Emacs on a daily basis. It's impressive that you can do it and I'm sure it works for you pretty well, but I doubt that younger programmers do the same - the hurdle to work with those tools is way to high at the start. One of our programmers use VIM too, but on a regular basis he has problems like finding/renaming files/variables or optimize imports or code formatting. I bet you can do that with the right tools and a lot of time as good as an IDE can do it, but the IDE can do that out of the box without consuming your time. It's like I said - if you mainly used VIM/Emacs you think everything is fine and would not try an IDE - but that's not what nowadays happens to new programmers. And to make D appealing to them, D has to offer good IDE support or it will remain as a hobby language with very few exceptions.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote: On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain. My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc). So, lets install Visual Studio Code: * Code-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... So lets try the next plugin: * Serve-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Frustration level increasing. Lets try the next one: * D-Language Plugin: - Syntax highlight *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do not properly work or some other issue. Then lets try IntelliJ Community Edition. After a long time getting all the dependancies and compiling them... Dscanner - DCD ( client and server ) - Dfix ... * D Language Plugin: - Syntax highlight *check* - Way too many items like writefln, import etc all being marked as unknown. Clearly wrong. - ... and nothing else... - Socket error (std.socket.xxx) on closing IntelliJ Conclusion is that it feels like the whole D infrastructure is very, very poorly supported. Other issues like delays that some of the D plugins seem to introduce: * Like "loading ..." popups that do nothing but always show up ( Visual Studio Code ) * Like pressing "dot" expecting a response, waiting 2 seconds and then finally something happening ( IntelliJ plugin ) but simply dumping every possible name and variable ( zero intelligent code support ) I assume that this is again broken DCD or Dscanner. And no, no errors in the console of VSC or anything like that. Let me summarize my personal D editor experience in the last 1+ year. * Attempts at getting D editor support going: 6 or 7. * Amount of times things worked out of the box. One! And this was limited to about a few minutes and after that all suggestions broke again. * Amount of times dscanner or dcd or other plugins broke because of DMD newest version broke: 4 * Tested on different machines: 4! They all have one thing in common: Windows 10 * Tested on different Windows installations: 3 * Tested on different "version" of Windows 10: 3 * Amount of times complaining to the plugin authors: Too many to count. * Time spend on these tests / issues: Easily 50 hours or more. * Frustration level: Again, like each time before EXTREME! Please do not give me the company line that i need to report issues. I did so many times. It is tiring playing guinea pig, complaining and reporting, waiting for things to get fixed and still seeing things break again or simply not working properly. 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, ... ). Like dscanner changing its binary location between builds from folder root to /bin folder, breaking the plugin authors there system as it expected it in the folder root. 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. Clearly there is infrastructure in place for automated testing the compiler but it feels like there is a total lack of infrastructure for everything that surround it. Beyond maybe a few editors that the core team uses? My personal opinion: Too much in the D landscape is so individualist and not properly cross platform tested, that it results in pure frustration for the end developer. You are not alone. The existing D-Tools are either really bad or do not work propely/not out of the box. And I have more important things to do than trying to setup the tools. Maybe someone likes that, but not me. But I have to say that I've used more or less successfully Visual-D and Mono-D a few years ago. But neither of the tools can keep up in any way with Tools for Rust/C++/C#/Java/PHP. The existence of a good IDE which works out of the box without annoying setup procedures is crucial for the success of a language nowadays. That's one of the reason why I've moved on. I went back to C++ and nowadays to Rust. C++ is not that clean as D but the Tool support is crucial for anyone who wants to use the language for other than some hobby stuff.
Re: Rvalue references
On Wednesday, 10 January 2018 at 14:41:21 UTC, Steven Schveighoffer wrote: On 1/10/18 3:08 AM, Dgame wrote: On Wednesday, 10 January 2018 at 01:56:02 UTC, Steven Schveighoffer wrote: But current auto ref is what we have, so I would recommend using it. I would recommend to ignore auto ref for rvalue references. It generates 2^N functions where N is the amount of auto ref parameters. That the most awful template bloat I've ever seen. It only generates 2^N functions if you call it 2^N different ways. Most of the time you call it the same way. -Steve If that would be true we wouldn't need auto ref at all.
Re: Rvalue references
On Wednesday, 10 January 2018 at 01:56:02 UTC, Steven Schveighoffer wrote: But current auto ref is what we have, so I would recommend using it. I would recommend to ignore auto ref for rvalue references. It generates 2^N functions where N is the amount of auto ref parameters. That the most awful template bloat I've ever seen.
Re: Maybe D is right about GC after all !
On Thursday, 4 January 2018 at 11:04:51 UTC, Ola Fosheim Grøstad wrote: On Thursday, 4 January 2018 at 10:49:49 UTC, Dgame wrote: On Thursday, 4 January 2018 at 10:40:33 UTC, Ola Fosheim Grøstad wrote: However, Rust won't fare well in a head-to-head comparison either, because of the issues with back-pointers. Could you explain this? You often want back-pointers for performance reasons, but Rust default pointer model isn't as accepting to cycles. So you either have to change your design or loose the benefits that the compiler provides, at which point C++ is more convenient, but it depends on what you try to do. As far as I remember you can use pointers as you normally do if you use them in unsafe blocks. Not that I ever tried.
Re: Maybe D is right about GC after all !
On Thursday, 4 January 2018 at 10:40:33 UTC, Ola Fosheim Grøstad wrote: However, Rust won't fare well in a head-to-head comparison either, because of the issues with back-pointers. Could you explain this?
Re: Maybe D is right about GC after all !
On Friday, 22 December 2017 at 16:17:33 UTC, Dan Partelly wrote: Why should we settle for this ? D code (efortless) is easier to read then Rust. Such statement is highly controversial, since it can be said about C/C++, D and most other languages as well.
Re: Maybe D is right about GC after all !
On Wednesday, 20 December 2017 at 17:05:41 UTC, Tony wrote: I have heard with regard to reference counting as is done in Python, that if two objects each have a reference to the other, that they will never be deleted, even if neither is used elsewhere in the program. Garbage collection is not supposed to have that issue, although I don't know how a garbage collector determines that there usage is just via each other and that they can be deleted. Here's how PHP does it: http://php.net/manual/de/features.gc.collecting-cycles.php
Re: How do I pass a type as parameter in this method?
On Tuesday, 19 December 2017 at 15:19:53 UTC, Marc wrote:
On Tuesday, 19 December 2017 at 00:01:00 UTC, Ali Çehreli wrote:
On 12/18/2017 03:54 PM, Ali Çehreli wrote:
On 12/18/2017 02:58 PM, Marc wrote:
Here's another experiment:
template FirstOf(T...) {
template otherwise(D) {
static if (T.length == 0) {
enum otherwise = D.init;
} else {
enum otherwise = T[0];
}
}
}
void main() {
static assert (FirstOf!(1.5, "hello").otherwise!int ==
1.5);
static assert (FirstOf!("world", [1]).otherwise!int ==
"world");
static assert (FirstOf!().otherwise!int == 0);
}
Ali
Thanks four answer. I'll be using this one. I was messing
around and getting multiple arguments to template function too.
I like the naming too, it made code clear, imo.
It's possible to have overload where one take a type name and
the other a variable (constant value actually)? something like
this (also imaginary code):
template FirstOf(TP...) {
template otherwise(D) {
static if(TP.length > 0) {
enum otherwise = TP[0];
} else {
enum otherwise = D.init;
}
}
template otherwise(D value) {
static if(TP.length > 0) {
enum otherwise = TP[0];
} else {
enum otherwise = value;
}
}
}
So I can use like this:
int index = FirstOf!(myTuple).otherwise!int;
int value = FirstOf(myTuple2).otherwise!(10);
with my limited template knowledge, I know I can write it like
this:
template otherwise(D, D value) {
static if(TP.length > 0) {
enum otherwise = TP[0];
} else {
enum otherwise = value;
}
}
So the call would go like this:
int value = FirstOf(myTuple2).otherwise!(int, 10);
But for simplicity I'd like to infer the type from constant
value passed in parameter, in that case, the integer value of
10.
template FirstOf(T...) {
template otherwise(D) {
static if (T.length == 0) {
enum otherwise = D.init;
} else {
enum otherwise = T[0];
}
}
template otherwise(alias value) {
static if (T.length == 0) {
enum otherwise = value;
} else {
enum otherwise = T[0];
}
}
}
void main() {
static assert (FirstOf!(1.5, "hello").otherwise!int == 1.5);
static assert (FirstOf!("world", [1]).otherwise!int ==
"world");
static assert (FirstOf!().otherwise!int == 0);
static assert (FirstOf!(1.5, "hello").otherwise!23 == 1.5);
static assert (FirstOf!().otherwise!42 == 42);
}
Re: classes by value
On Friday, 15 December 2017 at 12:56:41 UTC, Jonathan M Davis wrote: On Friday, December 15, 2017 11:10:42 Dgame via Digitalmars-d wrote: On Friday, 15 December 2017 at 09:18:23 UTC, Seb wrote: > [...] Since scope was revived with DIP-1000 we will see about that. I doubt that the deprecation will stay. DIP 1000 is half killing it. DIP 1000 is using scope for something very different, and it has nothing to do with putting classes on the stack. However, as an optimization, it may put a class on the stack if it determines that the the class object is unique. Anyone who wants to guarantee it should be using std.typecons.scoped. - Jonathan M Davis Since scope is used inside dmd I'm sure it will stay the way it is or the way you've described, yes.
Re: classes by value
On Friday, 15 December 2017 at 09:18:23 UTC, Seb wrote: On Thursday, 14 December 2017 at 16:40:33 UTC, Petar Kirov [ZombineDev] wrote: ``` scope foo = new Foo(); ``` That's about to be deprecated in favor of scoped!Foo: https://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack Since scope was revived with DIP-1000 we will see about that. I doubt that the deprecation will stay.
Re: classes by value
On Thursday, 14 December 2017 at 16:40:33 UTC, Petar Kirov [ZombineDev] wrote: On Thursday, 14 December 2017 at 16:10:17 UTC, Jonathan Marler wrote: On Thursday, 14 December 2017 at 14:45:51 UTC, Dgame wrote: Strongly reminds me of scoped Declaring a variable as `scoped` prevents that variable from escaping the scope it is declared in. This restriction allows the compiler certain optimizations, such as allocating classes on the stack, i.e. ``` scoped foo = new Foo(); ``` this optimization is well-known to D programmers so class allocation on the stack is strongly associated with the "scoped" modifier which is probably why this "class by value" snippet reminds you of "scoped". Even though "classes by value" can be implied in certain usages of "scoped", "scoped" carries with it extra semantics that "classes by value" on it's own does not. This snippet allows "classes by value" on it's own, which enables different ways of using classes (for example, creating an array of classes by value `Value!MyClass[]`). I think what Dgame meant was: https://dlang.org/phobos-prerelease/std_typecons#scoped. For the built-in scoped classes, the keyword is 'scope', not 'scoped': https://dlang.org/spec/class.html#auto. Yes, that's what I meant.
Re: classes by value
On Thursday, 14 December 2017 at 14:31:33 UTC, Jonathan Marler
wrote:
Thought I would share this little nugget. It's a simple module
to enable "classes by value". A good demonstration of the
power of "alias this". I had originally implemented this using
"opDispatch" and only after I was done did I realize I could
have made my life much simpler if I had gone with "alias this"
in the first place :)
https://run.dlang.io/gist/marler8997/799286523e139c65c6de1b37b6729a72?compiler=dmd=-unittest%20-main
/**
Value is a template that represents a class object value. This
is in contrast to a
normal class object which is a pointer to a class object value.
---
void foo(Value!SomeClass value)
{
// ... use value
}
---
*/
struct Value(T) if (is(T == class))
{
@disable this();
private void[__traits(classInstanceSize, T)] classdata
= void;
@property pragma(inline) T classptr()
{
return cast(T)
}
alias classptr this;
}
/**
Initializes a class value
*/
void initClassValue(T, Args...)(Value!T* classValue, Args args)
if (is(T == class))
{
import std.conv : emplace;
emplace(classValue.classptr, args);
}
/**
Use to create a class object value.
---
auto classValue = createClasValue!SomeClass;
---
*/
Value!T createClassValue(T, Args...)(Args args) if (is(T ==
class))
{
import std.conv : emplace;
Value!T value = void;
emplace(value.classptr, args);
return value;
}
/**
Creates a Value!T class from class T.
---
Foo foo; // foo is a class
Value!Foo fooValue1 = void;
copyClassValue(, classObject);
auto foo2 = foo.copyClassValue();
---
*/
void copyClassValue(T)(Value!T* classValue, T classObject) if
(is(T == class))
{
classValue.classdata[0 .. __traits(classInstanceSize,
T)] =
(cast(ubyte*) classObject)[0 ..
__traits(classInstanceSize, T)];
}
/// ditto
Value!T copyClassValue(T)(T classObject) if (is(T == class))
{
Value!T value = void;
copyClassValue(, classObject);
return value;
}
unittest
{
static class Foo
{
int x;
this(int x)
{
this.x = x;
}
void assertValue(int expected)
{
assert(x == expected);
}
void doNothing()
{
}
}
static void testValueClassArg(Value!Foo foo, int
valueToAssert)
{
foo.assertValue(valueToAssert);
}
{
auto foo = createClassValue!Foo(946);
assert(foo.x == 946);
foo.assertValue(946);
testValueClassArg(foo, 946);
initClassValue(, 391);
assert(foo.x == 391);
foo.assertValue(391);
testValueClassArg(foo, 391);
}
{
auto foo = new Foo(1234);
assert(foo.x == 1234);
foo.assertValue(1234);
Value!Foo fooValue = void;
copyClassValue(, foo);
assert(fooValue.x == 1234);
fooValue.assertValue(1234);
testValueClassArg(fooValue, 1234);
auto fooValue2 = foo.copyClassValue();
assert(fooValue2.x == 1234);
fooValue2.assertValue(1234);
testValueClassArg(fooValue2, 1234);
testValueClassArg(foo.copyClassValue(), 1234);
}
}
Strongly reminds me of scoped
Re: Sort characters in string
On Wednesday, 6 December 2017 at 09:25:20 UTC, Biotronic wrote:
On Wednesday, 6 December 2017 at 08:59:09 UTC, Fredrik Boulund
wrote:
string word = "longword";
writeln(sort(word));
But that doesn't work because I guess a string is not the type
of range required for sort?
Yeah, narrow (non-UTF-32) strings are not random-access, since
characters like take up more than one code unit, and so
""[0] returns an invalid piece of a character instead of a
full character.
In addition, sort does in-place sorting, so the input range is
changed. Since D strings are immutable(char)[], changing the
elements is disallowed. So in total, you'll need to convert
from a string (immutable(char)[]) to a dchar[]. std.conv.to to
the rescue:
import std.stdio : writeln;
import std.conv : to;
import std.algorithm.sorting : sort;
string word = "longword";
writeln(sort(word.to!(dchar[]))); // dglnoorw
--
Biotronic
Or you simply do
writeln("longword".array.sort);
Re: Temporary objects as function parameters or when-is-this-shit-going-to-end?
On Friday, 13 October 2017 at 12:08:00 UTC, Jack Applegame wrote: On Friday, 13 October 2017 at 12:03:55 UTC, Dgame wrote: Interesting. If you remove the CTor in Foo it works again. If you remove DTor it works again too. :) That's one of these times where it would be helpful to see the generated AST.
Re: Temporary objects as function parameters or when-is-this-shit-going-to-end?
On Friday, 13 October 2017 at 10:35:56 UTC, Jack Applegame wrote: If you don't want to get the great PITA, never create temporary objects in function parameters. I recently spent a whole day digging through my reference counted containers library. But nasty bug was not there, but in the compiler. Look at this: https://glot.io/snippets/eui2l8ov0r Result: Bar.this(int): 7FFD3D60CD38 fun: 7FFD3D60CD20 Bar.~this(): 7FFD3D60CD20 Compiler creates struct on the stack and silently (without postblitting and destruction old object) moves it to another address. Is it normal? I don't think so. But that's not the most fun. Look at this: https://glot.io/snippets/eui2pjrwvi Result: Bar.this(int): 7FFF87DD2D31 fun: 7FFF87DD2CE0 Bar.~this(): 7FFF87DD2CE0 Bar.~this(): 7FFF87DD2D31 WAT??? Compiler creates struct on the stack copies it without postblitting and destructs both objects. But if you create the structure before calling the function, then all will be well: https://glot.io/snippets/eui2vn2bu1 All this greatly angered me because there are several issues related wrong struct construction and destruction in the bugtracker. Because of these bugs my low level libraries full of strange hacks. I want to ask. How you guys are going to create a reliable RC library, if such fundamental bugs hang in the issue tracker for months and years. And instead of fixing them, you develop new minor bells and whistles. See: https://issues.dlang.org/buglist.cgi?quicksearch=destructor Since I myself can't fix such bugs (my knowledge in this area are extremely small), I have a question to Andrei Alexandrescu: Can I donate to the D Foundation and that my donations would be aimed at fixing exactly these bugs? Interesting. If you remove the CTor in Foo it works again.
Re: static array with inferred size
On Wednesday, 20 September 2017 at 14:15:30 UTC, Steven
Schveighoffer wrote:
On 9/20/17 3:12 AM, Dgame wrote:
http://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits
This is plain stack corruption, you should fix that. The s
template seems useful, but still I can't get my use case to
work with it:
T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc
@safe
{
return array;
}
void main()
{
char[5] x1 = "hello"; // works.
auto x2 = s("hello"); // oops, type is immutable(char[5]);
auto x3 = s!char("hello"); // template s cannot deduce
function from argument types !(char)(string)
}
-Steve
Works:
char[5] b = "hallo".s;
Otherwise you could simply use Unqual:
Unqual!T[n] s(T, size_t n)(T[n] arr)
{
return arr;
}
auto a = "hallo".s;
writeln(typeof(a).stringof); // char[5]
Re: static array with inferred size
On Wednesday, 20 September 2017 at 08:33:34 UTC, Nordlöw wrote:
On Wednesday, 20 September 2017 at 07:38:00 UTC, Jonathan M
Davis wrote:
T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc
@safe
{
return array;
}
What about adding `s` to std.array in the meanwhile? I wonder
what Walter says about the static array to slice assignment.
Isn't it memory-safe?
Maybe even in object.d so that [1, 2, 3].s is possible without
any import. Then it would look like a built-in feature.
Re: static array with inferred size
On Wednesday, 20 September 2017 at 05:36:43 UTC, Andrei Alexandrescu wrote: On 9/19/17 8:47 PM, Steven Schveighoffer wrote: This needs to happen. e.g.: char[$] arr = "hello"; // syntax up for debate, but I like this. I can't think of a correct way to do this that doesn't heap-allocate and is DRY. D is so powerful, it's a huge shame it can't figure this one out. issue: https://issues.dlang.org/show_bug.cgi?id=481 Fix that was merged: https://github.com/dlang/dmd/pull/3615 And then reverted: https://github.com/dlang/dmd/pull/4373 Maybe there was an issue with the implementation? Can it be redone? -Steve The argument was it can be done trivially with a library solution. -- Andrei http://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits
Re: Dynamic array leak?
On Saturday, 12 August 2017 at 17:25:36 UTC, bitwise wrote:
On Saturday, 12 August 2017 at 08:16:56 UTC, Temtaime wrote:
Collect - is a hint to the GC, not an order. It can ignore
this request.
If this is the case, then D's GC should have an option to force
collection like C#'s GC:
https://msdn.microsoft.com/en-us/library/bb495757(v=vs.110).aspx
Also do not rely on the gc calling a dtor - it is not safe and
can be called totally randomed, so use RC instead or expicit
destroy()
RC is not applicable. I'm doing unit tests for a non-GC
container and trying to make sure all destructors are called
properly.
Example:
unittest {
auto a = List!int([S(0), S(1), S(2)]);
a.popBack();
assert(equal(a[], [S(0), S(1)]));
}
// lots of similar unittests
unittest {
import std.stdio;
GC.collect();
assert(S.count == 0);
}
So if all goes well, S.count should be zero, but the arrays I'm
testing against are being allocated on the heap. Given the
conditions of the tests, it seems like GC.collect should be
able to reclaim those arrays after the unit tests have exited,
and in most cases does.
The ideal solution though, would be to allocate those arrays on
the stack and avoid the problem altogether. There doesn't seem
to be any reasonable way to do it though.
// won't this allocate anyways?
S[2] b = [S(0), S(1)];
assert(equal(a[], b[]));
// why can't I just declare a static array inline?
assert(equal(a[], int[2]{ S(0), S(1) }));
auto s(T, size_t n)(T[n] values)
{
return values;
}
assert(equal(a[], [S(0), S(1)].s));
Re: Is there a cleaner way of doing this?
On Monday, 7 August 2017 at 08:01:26 UTC, Shachar Shemesh wrote:
It is often desired to have a struct with an extra parameter.
The common way to do this is like so:
struct S(T) {
T param;
void initialize(T param) {
this.param = param;
// Other stuff
}
}
The problem is what happens when the param is optional. The
common way to do this is to set T to void. This results in the
following code:
struct S(T) {
enum HasParam = !is(T == void);
static if( HasParam ) {
T param;
}
static if( HasParam ) {
void initialize(T param) {
this.param = param;
// Other stuff
}
} else {
void initialize() {
// Same other stuff as above!
}
}
}
This is both tedious and error prone. Is there a cleaner way of
doing this?
Just as an unrealistic fantasy, if the following code was
legal, the problem would be resolved on its own:
void func(void p) {
void param;
param = p;
return param;
}
Of course, that code has its own set of problems, and I'm not
really suggesting that change.
Shachar
Why don't you use a factory method?
struct S(T)
{
T p;
static make(T p)
{
S s;
s.p = p;
return s;
}
static make()
{
return S();
}
}
void main()
{
auto s1 = S!int.make;
auto s2 = S!string.make;
}
Re: Destructors vs. Finalizers
Consider reference counting with cycles. The proposal from Walter/Andrei is to do reference counting to clean up everything but cycles. For cycles, the GC will take care of it. That is the PHP way to do things. :) It's neat but I still think the only real thing to deal with resources is built-in ownership like Rust does it. But that's a bit out of question for D2 I suppose. What's the state of the RC approach?
Re: Destructors vs. Finalizers
On Wednesday, 26 July 2017 at 20:02:02 UTC, Moritz Maxeiner wrote: On Wednesday, 26 July 2017 at 19:18:48 UTC, Dgame wrote: Alright, thanks for the clarification. I've briefly hoped for some sort of miracle such as deterministic object lifetime without manual interaction. :) I'm not sure what scheme you are trying to describe here, could you give a code example of what you hoped for? Built-in Ownership/RC for objects.
Re: Destructors vs. Finalizers
On Wednesday, 26 July 2017 at 18:33:58 UTC, Moritz Maxeiner wrote: On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote: I don't get it. The GC collects the objects which aren't in use anymore. The order in which this is currently happening is not specified. So, how are the destructors supposed to be called in the right order? Manually? ARC? After the split: Destructors are only for deterministic end of object lifetime, so yes, they are to be called by any scheme (such as manual management via destroy and reference counting - which is likely also implemented as calling destroy) that is deterministic. Finalizers are for nondeterministic schemes such as the GC. The GC *never* calls destructors directly, only finalizers. A finalizer might manually call a destructor, but a destructor may never call a finalizer. Alright, thanks for the clarification. I've briefly hoped for some sort of miracle such as deterministic object lifetime without manual interaction. :)
Re: Destructors vs. Finalizers
I don't get it. The GC collects the objects which aren't in use anymore. The order in which this is currently happening is not specified. So, how are the destructors supposed to be called in the right order? Manually? ARC? As far as I understand it, the GC can't do it, otherwise we wouldn't have the "random" order in which the finalizer are called in the first place.
Re: No polymorphism?
On Monday, 24 July 2017 at 18:15:20 UTC, Steven Schveighoffer wrote: On 7/24/17 1:29 PM, Dgame wrote: Why isn't the compiler able to deduce S[] => I[]? Or is it just me? I've tried dmd 2.075 I know you got the explanation already, but just in case you actually need to call something like test1 but only have an S[]: test1(ss.map!((I i) => i).array) -Steve Thanks.
Re: No polymorphism?
On Monday, 24 July 2017 at 17:33:48 UTC, Adam D. Ruppe wrote:
On Monday, 24 July 2017 at 17:29:55 UTC, Dgame wrote:
S[] ss = [new S()];
test1(ss); // Fails
Why isn't the compiler able to deduce S[] => I[]? Or is it
just me?
This is exactly because of polymorphism. Consider the following:
```
S[] ss = [new S()];
I[] i = ss; // pass it to the function or whatever for implicit
conversion
class OtherDerived : I {}
i[0] = new OtherDerived(); // looks OK, otherDerived is also
interface I
```
But now, ss[0], the same array as i, no longer points to an S!
You broke the type system.
So, tired it is. Thanks a lot.
No polymorphism?
I may be just tired, but could somebody explain this behaviour to
me? It seems odd to me:
interface I
{
}
class S : I
{
}
void test1(I[])
{
}
void test2(I)
{
}
void main()
{
test1([new S()]); // Works
test2(new S()); // Works
I i = new S();
test2(i); // Works
S s = new S();
test2(s); // Works
I[] si = [new S()];
test1(si); // Works
S[] ss = [new S()];
test1(ss); // Fails
}
Compiler output: test.d(32): Error: function test1 (I[] _param_0)
is not callable using argument types (S[])
Why isn't the compiler able to deduce S[] => I[]? Or is it just
me?
I've tried dmd 2.075
Re: Static array with parameter based size?
On Tuesday, 11 July 2017 at 08:23:02 UTC, Miguel L wrote:
I need to create a non-dynamic array like this
void f(int x)
{
int[x] my_array;
...
this does not compile as x value needs to be known at compile
time. The closest to this I can get is:
void f(int x)
{
int[] my_array;
my_array.length=x;
but I don't really need a dynamic array as length is not going
to change inside f.
What is the best way to do this?
Thanks in advance
Another approach would be to use a template function:
void f(int x)()
{
int[x] array;
}
void main()
{
f!42;
}
Re: Master thesis
On Saturday, 1 July 2017 at 21:00:14 UTC, Ecstatic Coder wrote: Whatever the object oriented language you use, you can keep exactly the same global game architecture, using more or less the same classes for your game subsystems and gameplay elements. Therefore, as an old game industry veteran, I confirm what you already know, which is that it's all about memory allocation, access and deallocation when comparing a game made in C++, D or Rust. I'm not saying that other matters are not important, but many game development directors apply Bertrand Meyer's architectural advices (design by contract with pre/post condition assertions, etc) since the early nineties, so there is not much difference between a C++ game and a D/Rust game in this area. So all that remains in the end are just concurrency and memory-related features, like immutable data, array memory slicing, automatic array bound and null pointer checking, object destruction and deallocation through variable scope and garbage collection, etc. This of course includes interfacing with C/C++, i.e. managing the memory and lifecycle of C/C++ structs/objects from D or Rust. With D, my biggest concern was about avoiding the application thread to freeze during a GC, while C++ and Rust can completely ignore this problem. IMHO just these last points could already explain why Rust and C++ still remain preferred to D for game development... That's a good statement which I found very often recently. Maybe I should change my main focus from architecture to software-engineering per se... Maybe an comparison between different software-products (one in an insecure and one in a secure programming language) to show the difference and potential vulnerabilities.
Re: Master thesis
On Saturday, 1 July 2017 at 14:40:36 UTC, ketmar wrote:
Dgame wrote:
Which impact would have D on the software-architecture, if it
would be choosen for a 2D game instead of C/C++?
i can actually finish 'em. most of the time when i'm working
with D, i feel that compiler tries to help me. EVERY TIME i'm
working with C/C++, i know for sure that compiler silently
setting traps for me ('cause it is absolutely impossible to
write safe and secure C/C++ code
Do you have examples (code and/or personal experience) about that?
-- tnx to standard committee and compiler implementers,
anything can turn into UB unexpectedly, and writing UB-free
code is tedious and it will have UB anyway).
Is that described somewhere? Or do you have examples or both?
otherwise, i hate writing articles: writing code is way more
fun. ;-)
Same here. :D
Re: Master thesis
If you haven't watched it yet, Walter's dconf keynote this year is a good place to start as are the discussion on dip1000 and the dip itself. Thanks, that's a good hint, I'll definitely watch it. :) But as Rikki said the fact that all arrays carry they length means that we have array bounds checking, which rules out one class of very common bugs you would get in C. Yes, that's what I call "security oriented software technology concept" or "vulnerability avoiding concept". It's one of the many things D did right and which I want to mention (there are so many!), but it's not a concrete impact on software architecture. That's what I mainly seek. It's not that easy to find concrete impacts IMO. I'm about to hand in my Honours thesis on Monday after doing it for a year, I don't think I could do one in six months, so best of luck! If I could, I would also happily wrote a year or more, since there is so much to write about, but we only have six months for our master thesis.
Master thesis
Hi there. I hope that is the right place for this topic. I'm currently writing my master thesis and just like in my bachelor thesis, D will play a significant role in my master thesis. My thesis will discuss the impact of software engineering concepts of security-oriented programming languages on software development with a focus on the effects on software design / design patterns and specifically software architecture. As said, D will be one of the few secure programming languages which I will present. Others will be Rust & Ada and on the other side C/C++ will be one example of the many unsecure programming languages. That as a short introduction of the purpose of my master thesis and what I intend to do in the next six months. Currently, I'm collecting links, literature and other stuff on that topic. But I thought that maybe some of you know more about that and can give me hints, links or maybe even real live experience/examples. That would be really kind of you. :) For example: Which impact would have D on the software-architecture, if it would be choosen for a 2D game instead of C/C++? The 2D game is my choosen case example since I programmed small games on gamejams in C/C++ and D, until two years ago. Of course, any architecture regarding that topic is of interest. Have you already made such experience or do you know people who have and maybe even wrote articles about? Many thanks in advance!
Re: D Meetup in Hamburg?
On Tuesday, 6 September 2016 at 09:42:12 UTC, Martin Tschierschke wrote: Hi All, anybody interested to meet in Hamburg, Germany? Time and location will be found! Regards mt. Yes, I would be interested.
