Vibe.d - very low performance
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=plaintext C++, Java and Go frameworks have very high performance. Vibe.d is supposed to have similar performance, but in fact vibe.d performance is very low. Why?
Foreach loops on static arrays error message
I stumbled upon https://issues.dlang.org/show_bug.cgi?id=12685
In essence:
ubyte[256] data;
foreach (ubyte i, x; data) {}
Error: index type 'ubyte' cannot cover index range 0..256
`ubyte` can clearly hold a value from 0 to 255 so it should be
ok. No need for 256 ?!
So I decided to fix it https://github.com/dlang/dmd/pull/6973
Unfortunately when you think about how foreach is lowered it
makes sense - but the error message is misleading.
The previous code is lowered to:
ubyte[256] data;
for (ubyte i = 0 ; i < 256 ; ++i) {
ubyte x = data[i]
}
`i < 256` is always true, this would loop forever.
Questions:
- What would be a better error message?
- How about a different lowering in this case?
From the programmer's point of view the original code makes sense.
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
...
if(i==255) break;
}
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet wrote: I stumbled upon https://issues.dlang.org/show_bug.cgi?id=12685 In essence: [...] `ubyte` can clearly hold a value from 0 to 255 so it should be ok. No need for 256 ?! So I decided to fix it https://github.com/dlang/dmd/pull/6973 Unfortunately when you think about how foreach is lowered it makes sense - but the error message is misleading. The previous code is lowered to: [...] `i < 256` is always true, this would loop forever. Questions: - What would be a better error message? - How about a different lowering in this case? From the programmer's point of view the original code makes sense. A correct lowering would be: [...] I'd say this is not often encoutered. One should avoid using a different type then size_t for the index, as it can have negative performance implications.
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 08:49:33 UTC, Stefan Koch wrote: On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet wrote: [...] I'd say this is not often encoutered. One should avoid using a different type then size_t for the index, as it can have negative performance implications. Interesting. What would be the example of negative performance implication? I'm guilty of using the int on occasions.
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
From the programmer's point of view the original code makes
sense.
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
...
if(i==255) break;
}
or:
ubyte[256] data;
foreach(ubyte i; 0..256) {
ubyte x = data[i];
}
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 08:57:42 UTC, Nemanja Boric wrote: On Thursday, 6 July 2017 at 08:49:33 UTC, Stefan Koch wrote: On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet wrote: [...] I'd say this is not often encoutered. One should avoid using a different type then size_t for the index, as it can have negative performance implications. Interesting. What would be the example of negative performance implication? I'm guilty of using the int on occasions. on 64bit a downcast can cause the compiler to emit a cqo instruction when the index is used as an index. it's relatively expensive in some circumstances when it messed up predictions.
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 09:00:47 UTC, Andrea Fontana wrote:
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
From the programmer's point of view the original code makes
sense.
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
...
if(i==255) break;
}
or:
ubyte[256] data;
foreach(ubyte i; 0..256) {
ubyte x = data[i];
}
Yes. Much better. What's the rewrite in this case? Using a size_t
internally and casting to ubyte?
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet
wrote:
A correct lowering would be:
ubyte[256] data;
for(ubyte i = 0;;++i) {
ubyte x = data[i];
...
if(i==255) break;
}
That could lead to two branches in machine language, try to think
about it in terms of if and do-while loops to mirror typical
machine language. The correct lowering is:
ubyte[256] data;
if (data.length > 0) {
ubyte i = 0;
do {
writeln(i);
} while ((++i) != cast(ubyte)data.length);
}
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 09:11:44 UTC, Ola Fosheim Grøstad
wrote:
ubyte[256] data;
if (data.length > 0) {
ubyte i = 0;
do {
writeln(i);
} while ((++i) != cast(ubyte)data.length);
}
You also need to add an assert before the if to check that the
last index can be represented as an ubyte. So probably not worth
it.
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 09:11:44 UTC, Ola Fosheim Grøstad
wrote:
ubyte[256] data;
if (data.length > 0) {
ubyte i = 0;
do {
writeln(i);
} while ((++i) != cast(ubyte)data.length);
}
Here is another version that will work ok on CPUs that can issue
many instructions in parallel if there are no dependencies
between them as you avoid an explicit comparison on the counter
(zero tests tend be be free):
ubyte[N] data;
size_t _counter = data.length;
if( _counter !=0){
ubyte i = 0;
do {
writeln(i);
i++;
} while (--_counter);
}
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 09:06:18 UTC, Guillaume Chatelet
wrote:
ubyte[256] data;
foreach(ubyte i; 0..256) {
ubyte x = data[i];
}
Yes. Much better. What's the rewrite in this case? Using a
size_t internally and casting to ubyte?
I was just wondering
Re: Foreach loops on static arrays error message
On Thursday, 6 July 2017 at 08:49:33 UTC, Stefan Koch wrote: I'd say this is not often encoutered. One should avoid using a different type then size_t for the index, as it can have negative performance implications. I thought size_t was what it lowered down to using if you used something else. What should I use instead?
Re: DCompute development
Am 05.07.2017 um 11:41 schrieb Nicholas Wilson: Hi all, Now that I've (finally) finished my honours thesis, I've got time to start working on dcompute again. I'd like to invite anyone interested in helping to develop and/or document (or just interested in general) the drivers for OpenCL/CUDA, the device standard library and other stuff. Please post here or on the MIR gitter (https://gitter.im/libmir/public) if you would like to contribute. (...) P.S: Thanks so much for Vibe, Sönke! Being able to use D made the writing if the server for my thesis so much less painful. You're welcome and congratulations on finishing your thesis! I'm sure I can say the same once I'll finally be ready to start using DCompute, I would have had to invest lots of work into an inferior system otherwise!
Re: Vibe.d - very low performance
Am 06.07.2017 um 09:27 schrieb Marek: https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=plaintext C++, Java and Go frameworks have very high performance. Vibe.d is supposed to have similar performance, but in fact vibe.d performance is very low. Why? This is a scalability issue, which should hopefully be fixed with 0.8.0. I'll open a PR once that is out. Basically with the version that was used in the last benchmark round, it didn't scale at all, and they use a server with many cores (40 + hyperthreading).
Re: Checked vs unchecked exceptions
On Thursday, 6 July 2017 at 01:31:44 UTC, Moritz Maxeiner wrote:
---
void foo() throws AException throws BException { ... }
vod bar() { foo(); }
---
works and bar's exception is inferred by the compiler to
contain AException and BException.
But to be clear (and the title and description of any DIP
addressing this should reflect this):
These are not checked exceptions, because checked exceptions
would require bar to declare its exception set manually.
Not checked in sense of Java, but Java has no deductible
exceptions. If compiler will fail on `void bar() { foo(); }
throws AException;` we still can call it 'checked', I think. In
sense of D.
Re: Checked vs unchecked exceptions
Am Thu, 06 Jul 2017 01:31:44 + schrieb Moritz Maxeiner : > But to be clear (and the title and description of any DIP > addressing this should reflect this): > These are not checked exceptions, because checked exceptions > would require bar to declare its exception set manually. Yep, absolutely clear. Just like "auto a = 1" does not declare a variable as we all know declarations start with a type. Instead of defining checked exceptions how it bests fits all your posts in this thread, why not say "Checked exceptions as implemented in Java were a good idea, had they allowed the compiler to infer them where possible." Of course we can still call those inferred checked exceptions something else. ;o) -- Marco
Re: Compilation times and idiomatic D code
On 2017-07-05 22:12, H. S. Teoh via Digitalmars-d wrote: Over time, what is considered "idiomatic D" has changed, and nowadays it seems to be leaning heavily towards range-based code with UFCS chains using std.algorithm and similar reusable pieces of code. It's not UFCS per say that causes the problem. If you're using the traditional calling syntax it would generate the same symbols. D (well, DMD specifically) is famed for its lightning speed compilation times. So this left me wondering why my latest D project, a smallish codebase with only ~5000 lines of code, a good part of which are comments, takes about 11 seconds to compile. Yeah, it's usually all these D specific compile time features that is slowing down compilation. DWT and Tango are two good examples of large code bases where very few of these features are used, they're written in a more traditional style. They're at least 200k lines of code each and, IIRC, takes around 10 seconds (or less) to compile, for a full build. -- /Jacob Carlborg
Re: Checked vs unchecked exceptions
On Thursday, 6 July 2017 at 11:01:26 UTC, Marco Leise wrote:
Am Thu, 06 Jul 2017 01:31:44 +
schrieb Moritz Maxeiner :
But to be clear (and the title and description of any DIP
addressing this should reflect this):
These are not checked exceptions, because checked exceptions
would require bar to declare its exception set manually.
Yep, absolutely clear. Just like "auto a = 1" does not declare
a variable as we all know declarations start with a type.
Red herring.
Checked exceptions are well defined - not just implemented - (by
Java as the de facto authority for the term) as requiring the
declaration of all exceptions (that aren't inherited from some
special class, in Java's case `RuntimeException`, in D's it would
be `Error`) that may be thrown by a function as a result of its
body being executed [1]. If even a single function is allowed to
have its exception set defined by inference (instead of
declaration), you are not implementing checked exceptions.
---
void foo() throws AExp throws BExc { ... }
void bar1() { foo(); } // Checked exceptions require this to
result in a compilation error
void bar2() throws AExc throws BExc { foo(); } // this must be
used for checked exceptions
---
Instead of defining checked exceptions how it bests fits all
your posts in this thread, why not say "Checked exceptions as
implemented in Java were a good idea, had they allowed the
compiler to infer them where possible."
Invalid premise. The definition of checked exceptions is de facto
fixed by Java [1], because it not only coined the term but
remains the only major PL to use them.
Of course we can still call those inferred checked exceptions
something else. ;o)
The java compiler does infer an exception set for every function
based on its body.
This is then checked against the function's exception set as
declared in its signature.
"inferred checked exceptions" is thus an oxymoron, because it
would mean checking the inferred exception set against itself.
[1]
https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html
Re: Compilation times and idiomatic D code
On Thursday, 6 July 2017 at 12:00:29 UTC, Jacob Carlborg wrote: On 2017-07-05 22:12, H. S. Teoh via Digitalmars-d wrote: [...] It's not UFCS per say that causes the problem. If you're using the traditional calling syntax it would generate the same symbols. [...] Yeah, it's usually all these D specific compile time features that is slowing down compilation. DWT and Tango are two good examples of large code bases where very few of these features are used, they're written in a more traditional style. They're at least 200k lines of code each and, IIRC, takes around 10 seconds (or less) to compile, for a full build. IIRC building Tango per package instead of all-at-once got the build time down to less than a second. Atila
Experience with https://www.patreon.com
Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei
Re: Experience with https://www.patreon.com
On Thursday, 6 July 2017 at 13:53:08 UTC, Andrei Alexandrescu wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei I support several creators on there. I think it works great.
Re: Checked vs unchecked exceptions
On Wednesday, 5 July 2017 at 21:05:04 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 5 July 2017 at 15:48:33 UTC, Crayo List wrote: What happens to the 3000 direct and indirect calls to open() ? Notice how the 'interface' has not changed, only the implementation. No, the exception spec is part of the interface whether it is in the function declaration or not. I disagree! Once an interface is defined you should be able to alter the implementation all you want without impacting client code! Such a change could be fatal in any system. No idea what you mean here. What you should do is to specify what Exceptions are thrown across module borders. That means you should recast the internal exceptions into module-level exceptions. I don't need to do anything since I don't have a problem. I don't understand what are you helping me with. I pointed out how checked exceptions 'leak' internal implementation, that was all.
Webassembly?
Is there a future where we can see WebAssembly as part of D? Seeing Rusts backbone already producing wasm is impressive. WebAssembly currently does not support a GC ...so it fair the assume that this will be the main issue for LDC? I see the move towards one language for back and front-end as the future.
Re: Experience with https://www.patreon.com
On Thursday, 6 July 2017 at 13:53:08 UTC, Andrei Alexandrescu wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei It works well for supporting artists. I support many people with it. However, if you're thinking of an application for the D foundation, I don't know if that's the right avenue. It would certainly work, but Patreon is more built for people who release discrete pieces of content, not necessarily charities who have less concrete results.
Re: DCompute development
On Wednesday, 5 July 2017 at 09:41:40 UTC, Nicholas Wilson wrote: @Mike Parker, what kind of things do you want me to write for the blog? Anything you can expand on beyond your DConf talk. Add a link to the talk video & slides in the introductory paragraph, touch on one or two points you talked about, then expand on them. Or even branch off into info not in the talk. This helps keep the DConf talks in the public awareness (for the subset of the public we care about anyway), alerts people who haven't seen the video what it's about, and gives new information for those who already have. I'd like to get as many such posts as I can from DConf speakers between now and DConf 2018. Email me if you'd like to brainstorm.
Re: VSCode plugins
On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: I've been using code-d for a while, and it generally works well. I've also noticed there's another plugin available, which at the time I first looked, appeared to be older and less-featured than code-d. I've recently had a couple of colleagues ask me which plugin to install, and I noticed that both seem to be up-to-date these days, and this leads to confusion. Looking at the feature list, it appears that both plugins do mostly the same stuff. My feeling is, having 2 very similar plugins is confusing to potential users, and it undermines user confidence. Ie, users have the feeling that they're competing hacky things maintained by some guy, rather than something that's more 'official' with consolidated community support. I also tend to presume in these situations that the 'proper' one is the one with the most users/installs, but that's not clear either in this case. I know this has nothing to do with the truth, but it's about perception and first impressions. Little things matter. If authors of both plugins are active here, I ask; why have 2 separate plugins? I can't imagine any reason for divergence. I would be a lot more comfortable if there was only one with multiple contributors. Projects with many contributors always inspire a lot more confidence than multiple overlapping projects with one contributor each... So, is there a reason not to merge the projects beyond ego? hi, code-d author here. I personally think a merge of all of our features into one plugin would be a great idea but the problem is that the plugins work a lot differently in the code level. My plugin uses workspace-d to abstract dfmt, dcd and dscanner so the extension doesn't need to know about it and dlang-vscode simply uses the extensions directly. I am also planning on further abstracting code-d using serve-d and Microsoft's Language Server Protocol for a wider adoption and better support across editors, but that also means that the extension code will be mostly thrown out and converted to D. While this isn't such a big problem for me because most code was already in workspace-d, I think if we implemented all the features from dlang-vscode it would be a lot of work not to break things. And doing it the other way around (merging my code into dlang-vscode) would mean that all the abstraction goes away and that it would be a vscode only plugin. code-d is basically the same as the one for atom or sublime text, just with all the features implemented instead of just a subset. While I didn't really support atom or sublime text for a while, I still think it's a good idea to keep these projects around for anyone who wants to implement workspace-d or serve-d into their extension as example reference how to implement them. But if the authors of dlang-vscode could contact me on IRC for example (WebFreak on #d on freenode) we might be able to find a solution to improve the situation and either merge into one plugin or share some code and ideas.
Re: Compilation times and idiomatic D code
On Thu, Jul 06, 2017 at 01:32:04PM +, Atila Neves via Digitalmars-d wrote: > On Thursday, 6 July 2017 at 12:00:29 UTC, Jacob Carlborg wrote: [...] > > Yeah, it's usually all these D specific compile time features that > > is slowing down compilation. > > > > DWT and Tango are two good examples of large code bases where very > > few of these features are used, they're written in a more > > traditional style. They're at least 200k lines of code each and, > > IIRC, takes around 10 seconds (or less) to compile, for a full > > build. > > IIRC building Tango per package instead of all-at-once got the build > time down to less than a second. [...] Well, obviously D's famed compilation speed must still be applicable *somewhere*, otherwise we'd be hearing loud complaints. :-D My point was that D's compile-time features, which are a big draw to me personally, and also becoming a selling point of D, need improvement in this area. I'm very happy to be pointed to Rainer's PR that implements symbol backreferencing compression. Apparently it has successfully compressed the largest symbol generated by Phobos unittests from 30KB (or something like that) down to about 1100 characters, which, though still on the large side, is much more reasonable than the present situation. I hope this PR will get merged in the near future. T -- Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright
Re: Webassembly?
On Thursday, 6 July 2017 at 15:34:08 UTC, Wulfklaue wrote: Is there a future where we can see WebAssembly as part of D? Seeing Rusts backbone already producing wasm is impressive. WebAssembly currently does not support a GC ...so it fair the assume that this will be the main issue for LDC? I see the move towards one language for back and front-end as the future. I'm just curious how it doesn't support GC? Like if you can allocate and free memory then you can have a GC.
Re: Compilation times and idiomatic D code
On Wednesday, 5 July 2017 at 20:32:08 UTC, Stefan Koch wrote: On Wednesday, 5 July 2017 at 20:12:40 UTC, H. S. Teoh wrote: I vaguely remember there was talk about compressing symbols when they get too long... is there any hope of seeing this realized in the near future? Yes there is. Rainer Schuetze is quite close to a solution. Which reduces the symbol-name bloat significantly. See https://github.com/dlang/dmd/pull/5855 There is still a problem with the template system as a whole. Which I am working on in my spare time. And which will become my focus after newCTFE is done. Please give consent for the D Foundation to clone you.
Strange -cov bug
Recently I discovered a strange bug in dmd -cov, that I finally got some time today to reduce to a smallish test case. However, I can't seem to get rid of the dependency on std.stdio; anybody has any idea how to reduce this code further? https://issues.dlang.org/show_bug.cgi?id=17613 This is a very strange bug where decreasing code coverage actually increases the reported coverage percentage. :-P T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: Webassembly?
On Thursday, 6 July 2017 at 17:19:34 UTC, bauss wrote: I'm just curious how it doesn't support GC? Like if you can allocate and free memory then you can have a GC. Currently there is no native GC build into WebAssembly. This is planned for the future. If your language is designed around allocating and freeing memory manually, you have no issue with WebAssembly. C/C++/Rust ... But you can not program in D fashion ( where the GC takes care of things ). It means you need to write the allocation and freeing all the time for any code that targets WebAssembly. hat also means no std library etc ... Think of it as writing pure @nogc code ( what currently breaks like half the standard library ). WebAssembly has plans for a native GC build into the design for the next version so that languages that have there own GC, can target this and not run into the issue of manually allocating and freeing. Think C#, Go, ... The other option is for the language to have there own GC included that targets WebAssembly into the compiled wasm file but that adds overhead. And is more work for the language to support. That is why a lot of languages that have GCs are on the fence and are waiting for the default GC. GC are nice and well but at times having a pure no-gc language does have its advantages ;)
auto*
Create an auto pointer, handy in some cases and fits in the language as a natural generalization.
Re: auto*
On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d wrote: > Create an auto pointer, handy in some cases and fits in the language > as a natural generalization. What's an auto pointer? T -- Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson
Re: Webassembly?
On Thursday, 6 July 2017 at 17:19:34 UTC, bauss wrote: On Thursday, 6 July 2017 at 15:34:08 UTC, Wulfklaue wrote: Is there a future where we can see WebAssembly as part of D? Seeing Rusts backbone already producing wasm is impressive. WebAssembly currently does not support a GC ...so it fair the assume that this will be the main issue for LDC? I see the move towards one language for back and front-end as the future. I'm just curious how it doesn't support GC? Like if you can allocate and free memory then you can have a GC. People usually point to this design doc: https://github.com/WebAssembly/design/blob/master/GC.md I don't know much about GC or their IR, but I get the impression it's more about integrating with the browser's GC, so you can seamlessly pass objects to javascript. I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same.
Re: Strange -cov bug
On 07/06/2017 10:58 AM, H. S. Teoh via Digitalmars-d wrote: Recently I discovered a strange bug in dmd -cov, that I finally got some time today to reduce to a smallish test case. However, I can't seem to get rid of the dependency on std.stdio; anybody has any idea how to reduce this code further? https://issues.dlang.org/show_bug.cgi?id=17613 This is a very strange bug where decreasing code coverage actually increases the reported coverage percentage. :-P T Sorry, not helping but rambling below... Yep, not surprising that conditional expression has such issues. The last time I checked Python code for coverage, they were missing uncovered branch of the conditional expression. [And saying this without testing.] Additionally, what about lazily evaluated sub-expressions like function arguments? So, per-line coverage is not sufficient anyway. Ali
Re: Experience with https://www.patreon.com
On Thursday, 6 July 2017 at 16:00:05 UTC, Jack Stouffer wrote: On Thursday, 6 July 2017 at 13:53:08 UTC, Andrei Alexandrescu wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei It works well for supporting artists. I support many people with it. However, if you're thinking of an application for the D foundation, I don't know if that's the right avenue. It would certainly work, but Patreon is more built for people who release discrete pieces of content, not necessarily charities who have less concrete results. Pippin from GIMP uses it pretty successfully for general work mostly related to GIMP https://www.patreon.com/pippin
Re: gdc is in
Am Wed, 21 Jun 2017 15:11:39 + schrieb Joakim : > the gcc tree: > > https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html > > Congratulations to Iain and the gdc team. :) > > I found out because it's on the front page of HN right now, where > commenters are asking questions about D. I missed this thread. So the persistence payed off in the end. Congratulations from me, too. Frankly, I wasn't sure if this day would ever come. -- Marco
Re: auto*
On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d wrote: Create an auto pointer, handy in some cases and fits in the language as a natural generalization. What's an auto pointer? T is it not obvious? auto x = ... auto* x = ... auto* is the pointerized version of auto. e.g., int x = ... int* x = ... typeof(x) y = ... typeof(x)* y = ... obviously the rhs must be congruent with the type. auto p = &foo; // a pointer auto* p = &foo; // a double pointer to foo. When having the need to require a pointer to a pointer, it avoids having to specify the type in a verbose way. i.e., the second line above is not valid, but to do it we must either cast to void** or use typeof and such to get the correct type and make a pointer out of it. auto* simplifies all that.
Re: auto*
On Thu, Jul 06, 2017 at 08:24:24PM +, FoxyBrown via Digitalmars-d wrote: [...] > auto x = ... > > auto* x = ... > > auto* is the pointerized version of auto. > > > e.g., > > int x = ... > > int* x = ... > > typeof(x) y = ... > typeof(x)* y = ... > > > obviously the rhs must be congruent with the type. > > auto p = &foo; // a pointer > auto* p = &foo; // a double pointer to foo. > > When having the need to require a pointer to a pointer, it avoids > having to specify the type in a verbose way. > > i.e., the second line above is not valid, but to do it we must either > cast to void** or use typeof and such to get the correct type and make > a pointer out of it. auto* simplifies all that. Huh? How is it even remotely valid to cast a single pointer to a double pointer implicitly? If foo is a non-pointer object, `auto p = &foo;` already gives you a pointer. If foo itself is also a pointer, `auto p = &foo;` will already give you a double pointer. There is no need to "specify the type in a verbose way" at all. You can't get a double pointer out of a single pointer without saving the single pointer in an addressable variable, e.g.: auto p = &foo; // takes address of foo (single pointer) auto pp = &p; // takes address of p (double pointer) It's invalid to take the address of an rvalue, because an rvalue has no location. I.e., `&(&foo)` is illegal because &foo is an rvalue. Before you can make a double pointer to it, you have to designate some location where it is to be stored, so that the double pointer can point to that location. T -- The two rules of success: 1. Don't tell everything you know. -- YHL
Re: auto*
On 07/06/2017 01:24 PM, FoxyBrown wrote:
> On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote:
>> On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d
>> wrote:
>>> Create an auto pointer, handy in some cases and fits in the language
>>> as a natural generalization.
>>
>> What's an auto pointer?
>>
>>
>> T
>
> is it not obvious?
It wasn't obvious at all. :) (I even suspected C++'s std::auto_ptr but
dropped the thought.)
> auto p = &foo; // a pointer
> auto* p = &foo; // a double pointer to foo.
>
> When having the need to require a pointer to a pointer, it avoids having
> to specify the type in a verbose way.
>
> i.e., the second line above is not valid, but to do it we must either
> cast to void** or use typeof and such to get the correct type and make a
> pointer out of it. auto* simplifies all that.
Let's say foo is type Foo...
Staying with that example and assuming that p has type Foo**, what would
*p provide? We have the object (foo), we have the pointer to pointer
(p), but where does the pointer itself live? Only the programmer knows
where that intermediate pointer is. For example:
struct Foo {
}
void main() {
auto foo = Foo();
auto x = &foo;// A local variable here
auto p = &x;
}
It seems to work cleanly to me. If you have something else in mind
please show the troubling line with complete code. :)
Ali
Re: Experience with https://www.patreon.com
On Thursday, 6 July 2017 at 13:53:08 UTC, Andrei Alexandrescu wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei I support someone who is a pure intellectual now, and can no longer survive in the university system, with his radical ideas of economics. He provides various content at different subscription points. What do you have in mind? Nick
Re: Experience with https://www.patreon.com
On 7/6/17 6:53 AM, Andrei Alexandrescu via Digitalmars-d wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei I have experience as both. Feel free to grab me off-list to talk in more detail.
Re: Experience with https://www.patreon.com
On Thursday, 6 July 2017 at 16:00:05 UTC, Jack Stouffer wrote: On Thursday, 6 July 2017 at 13:53:08 UTC, Andrei Alexandrescu wrote: Does anyone have experience with https://www.patreon.com either as a patron or creator? Thanks! -- Andrei It works well for supporting artists. I support many people with it. However, if you're thinking of an application for the D foundation, I don't know if that's the right avenue. It would certainly work, but Patreon is more built for people who release discrete pieces of content, not necessarily charities who have less concrete results. There's also an option to make regular monthly donations.
Re: Webassembly?
On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote: On Thursday, 6 July 2017 at 17:19:34 UTC, bauss wrote: On Thursday, 6 July 2017 at 15:34:08 UTC, Wulfklaue wrote: Is there a future where we can see WebAssembly as part of D? Seeing Rusts backbone already producing wasm is impressive. WebAssembly currently does not support a GC ...so it fair the assume that this will be the main issue for LDC? I see the move towards one language for back and front-end as the future. I'm just curious how it doesn't support GC? Like if you can allocate and free memory then you can have a GC. People usually point to this design doc: https://github.com/WebAssembly/design/blob/master/GC.md I don't know much about GC or their IR, but I get the impression it's more about integrating with the browser's GC, so you can seamlessly pass objects to javascript. I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same. Wow, quite an opportunity for D I'd say. A D frontend able to interop with the myriads of existing Javascript libraries, using the browser's GC and its DOM as GUI toolkit. Coupled with a vibe.d backend. Frontend and backend sharing D files describing their common interface.
Re: auto*
On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: Create an auto pointer, handy in some cases and fits in the language as a natural generalization. It's been suggested before (as well as more powerful generalization for slices and associative arrays), but Andrei vetoed it so it probably won't be added even if somebody created a formal proposal for it.
Re: auto*
On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via Digitalmars-d wrote: > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > > Create an auto pointer, handy in some cases and fits in the language > > as a natural generalization. > > It's been suggested before (as well as more powerful generalization > for slices and associative arrays), but Andrei vetoed it so it > probably won't be added even if somebody created a formal proposal for > it. I'm curious, what exactly was proposed? Because I have a hard time understanding what's intended from the OP's description. T -- Obviously, some things aren't very obvious.
Re: auto*
On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via Digitalmars-d wrote: On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > Create an auto pointer, handy in some cases and fits in the > language as a natural generalization. It's been suggested before (as well as more powerful generalization for slices and associative arrays), but Andrei vetoed it so it probably won't be added even if somebody created a formal proposal for it. I'm curious, what exactly was proposed? Because I have a hard time understanding what's intended from the OP's description. T Partial type inference. `auto*` declares a point to a type that is inferred from inspecting the RHS's type. The previous proposal was for doing `auto[] a = [0, 1, 2]` (a's type is inferred as int[]).
Re: Webassembly?
On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote: so you can seamlessly pass objects to javascript. I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same. You would have to emulate the stack...
Re: auto*
On Thu, Jul 06, 2017 at 10:31:10PM +, Meta via Digitalmars-d wrote: > On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote: > > On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via Digitalmars-d wrote: > > > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > > > > Create an auto pointer, handy in some cases and fits in the > > > > language as a natural generalization. > > > > > > It's been suggested before (as well as more powerful > > > generalization for slices and associative arrays), but Andrei > > > vetoed it so it probably won't be added even if somebody created a > > > formal proposal for it. > > > > I'm curious, what exactly was proposed? Because I have a hard time > > understanding what's intended from the OP's description. > > > > > > T > > Partial type inference. `auto*` declares a point to a type that is > inferred from inspecting the RHS's type. The previous proposal was for > doing `auto[] a = [0, 1, 2]` (a's type is inferred as int[]). But doesn't `auto a = [0, 1, 2];` *already* infer typeof(a) as int[]? What does `auto[]` add over what `auto` already does? T -- "Real programmers can write assembly code in any language. :-)" -- Larry Wall
Re: auto*
On Thursday, 6 July 2017 at 23:12:03 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 10:31:10PM +, Meta via Digitalmars-d wrote: On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote: > On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via > Digitalmars-d wrote: > > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > > > Create an auto pointer, handy in some cases and fits in > > > the language as a natural generalization. > > > > It's been suggested before (as well as more powerful > > generalization for slices and associative arrays), but > > Andrei vetoed it so it probably won't be added even if > > somebody created a formal proposal for it. > > I'm curious, what exactly was proposed? Because I have a > hard time understanding what's intended from the OP's > description. > > > T Partial type inference. `auto*` declares a point to a type that is inferred from inspecting the RHS's type. The previous proposal was for doing `auto[] a = [0, 1, 2]` (a's type is inferred as int[]). But doesn't `auto a = [0, 1, 2];` *already* infer typeof(a) as int[]? What does `auto[]` add over what `auto` already does? T It does, but I think it's more a thing of knowing what exactly the auto is. Let's say you have. auto a = foo(); You have no idea what auto actually is in that case, but auto* a = foo(); You know auto is a pointer of whatever foo returns.
Re: auto*
On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via Digitalmars-d wrote: [...] > Let's say you have. > > auto a = foo(); > > You have no idea what auto actually is in that case, but > > auto* a = foo(); > > You know auto is a pointer of whatever foo returns. Ah, I see. So if foo() doesn't return a pointer it will be a compile error? So it's basically a kind of self-documentation? T -- INTEL = Only half of "intelligence".
Re: auto*
On Thursday, 6 July 2017 at 23:51:13 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via Digitalmars-d wrote: [...] Let's say you have. auto a = foo(); You have no idea what auto actually is in that case, but auto* a = foo(); You know auto is a pointer of whatever foo returns. Ah, I see. So if foo() doesn't return a pointer it will be a compile error? So it's basically a kind of self-documentation? T That's my understanding yeah.
Re: auto*
On Thursday, 6 July 2017 at 23:51:13 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 11:50:24PM +, bauss via Digitalmars-d wrote: [...] Let's say you have. auto a = foo(); You have no idea what auto actually is in that case, but auto* a = foo(); You know auto is a pointer of whatever foo returns. Ah, I see. So if foo() doesn't return a pointer it will be a compile error? So it's basically a kind of self-documentation? T Kenji also extended the inference to some very interesting cases. // static array type int[$] a1 = [1,2];// int[2] auto[$] a2 = [3,4,5]; // int[3] const[$] a3 = [6,7,8]; // const(int[3]) // dynamic array type immutable[] a4 = [1,2];// immutable(int)[] shared[]a5 = [3,4,5]; // shared(int)[] // partially specified part is unqualified. // pointer type auto* p1 = new int(3); // int* const* p2 = new int(3); // const(int)* // mixing auto[][$] x1 = [[1,2,3],[4,5]]; // int[][2] shared*[$] x2 = [new int(1), new int(2)]; // shared(int)*[2] (https://github.com/dlang/dmd/pull/3615) Of course this could also get confusing pretty fast. I wish we at least had the `int[$]` syntax but it's not a huge loss.
Re: auto*
On Friday, 7 July 2017 at 00:39:32 UTC, Meta wrote: (https://github.com/dlang/dmd/pull/3615) Of course this could also get confusing pretty fast. I wish we at least had the `int[$]` syntax but it's not a huge loss. Thanks for posting the link. Made for interesting reading. This was another link on the same topic: http://forum.dlang.org/post/bewroetnschakoqjz...@forum.dlang.org
Re: auto*
On Friday, 7 July 2017 at 00:58:57 UTC, jmh530 wrote: On Friday, 7 July 2017 at 00:39:32 UTC, Meta wrote: (https://github.com/dlang/dmd/pull/3615) Of course this could also get confusing pretty fast. I wish we at least had the `int[$]` syntax but it's not a huge loss. Thanks for posting the link. Made for interesting reading. This was another link on the same topic: http://forum.dlang.org/post/bewroetnschakoqjz...@forum.dlang.org Yeah, it's one of those features that seemed very nice and I, at the very least, was disappointed that it didn't get in (of course Bearophile was as well). I don't really agree with Andrei's reason for vetoing the feature (the part about adding this feature being a slippery slope, not the power to complexity ratio), but looking back on it there are a few peculiarities with this syntax. For example, `immutable[] i = [0]` has the type `immutable(int)[]`, but to get `immutable(int[])` you have to do `immutable i = [0]`. I'd say that a beginner looking at this code would assume the opposite (although it's a very easy rule to learn). It's one of the problems D has with this syntax as opposed to C++, which has the ability to declare head-const arrays/pointers.
Re: Webassembly?
On Thursday, 6 July 2017 at 22:58:36 UTC, Ola Fosheim Grostad wrote: On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote: so you can seamlessly pass objects to javascript. I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same. You would have to emulate the stack... WebAssembly has linear memory that you can scan just like normal memory. C programs use it for those values on the stack that it needs a pointer to. For other values they are put on the safe stack, you can only read the value not the memory backing it. So there is a problem of pointers going on the safe stack so you need to make sure to not optimise those pointers to the safe stack. But in short, the D GC will work just fine, just need to be a bit carefull with pointers on the stack. Cheers, Jakob.
Re: auto*
On Thursday, 6 July 2017 at 20:24:24 UTC, FoxyBrown wrote: On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 06:10:57PM +, FoxyBrown via Digitalmars-d wrote: Create an auto pointer, handy in some cases and fits in the language as a natural generalization. What's an auto pointer? T is it not obvious? auto x = ... auto* x = ... auto* is the pointerized version of auto. e.g., int x = ... int* x = ... typeof(x) y = ... typeof(x)* y = ... obviously the rhs must be congruent with the type. auto p = &foo; // a pointer auto* p = &foo; // a double pointer to foo. When having the need to require a pointer to a pointer, it avoids having to specify the type in a verbose way. i.e., the second line above is not valid, but to do it we must either cast to void** or use typeof and such to get the correct type and make a pointer out of it. auto* simplifies all that. Just one thing. auto in D is not a type, it's a storage class. It inherited that from C. This means auto* doesn't make any sense as the * is part of a type. So your expression lack a proper type. Type deduction works by using the type of the rhs of the expression and applying to it the storage class of the lhs. This means that auto x = ..; works but also static x = ..; works D does not implemented C's register storage class, but if it did register x = .. would also work. When you understand that you will understand why your proposition does not make sense.
Re: auto*
On Thursday, 6 July 2017 at 23:50:24 UTC, bauss wrote: On Thursday, 6 July 2017 at 23:12:03 UTC, H. S. Teoh wrote: On Thu, Jul 06, 2017 at 10:31:10PM +, Meta via Digitalmars-d wrote: On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote: > On Thu, Jul 06, 2017 at 09:42:22PM +, Meta via > Digitalmars-d wrote: > > On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote: > > > Create an auto pointer, handy in some cases and fits in > > > the language as a natural generalization. > > > > It's been suggested before (as well as more powerful > > generalization for slices and associative arrays), but > > Andrei vetoed it so it probably won't be added even if > > somebody created a formal proposal for it. > > I'm curious, what exactly was proposed? Because I have a > hard time understanding what's intended from the OP's > description. > > > T Partial type inference. `auto*` declares a point to a type that is inferred from inspecting the RHS's type. The previous proposal was for doing `auto[] a = [0, 1, 2]` (a's type is inferred as int[]). But doesn't `auto a = [0, 1, 2];` *already* infer typeof(a) as int[]? What does `auto[]` add over what `auto` already does? T It does, but I think it's more a thing of knowing what exactly the auto is. Let's say you have. auto a = foo(); You have no idea what auto actually is in that case, but auto* a = foo(); You know auto is a pointer of whatever foo returns. If you want to document the type returned, then use an explicit type. Type deduction is imho a thing to avoid redundancy in an expression, not to transform D into python (and to make templates possible). If the type of an expression becomes difficult to deduce, it is a good idea imo to explicitely write out the type. This adds a simple constraint, i.e. adds a way for the compiler to exploit the type system to make the program more secure.
Re: Compile without generating code
On Wednesday, 5 July 2017 at 22:05:53 UTC, Stefan Koch wrote: On Wednesday, 5 July 2017 at 21:58:45 UTC, Lewis wrote: I was reading https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.html, which mentioned that the Rust compiler now has a mode to go through the motions of compiling and show errors, but without generating any code. This way you can do a much faster build while iterating until you have no compile errors, then do a single build with code generation once everything looks good. [...] We already have it. use -o- and it'll disable codegen. Well there you go, D is already ahead of the game. Thanks!
