Re: extern(C++, ns) is wrong
On Tuesday, September 11, 2018 9:59:30 PM MDT Danni Coy via Digitalmars-d
wrote:
> So my understanding is that the main issue with extern(C++,"ns") is
> functions that have different C++ name-spaces overriding each other in
> unexpected ways.
> How feasible is to simply disallow functions/variables/objects/... with
> the same name but a different "ns" being in the same module?
If we had extern(C++, "NS"), then all it would affect would be mangling and
all of the normal rules for conflicting symbols would be in force. So, if
you tried to put two symbols with the same name but from different
namespaces in the same module, you'd get an error just like if they were D
functions that conflicted. Disallowing it wouldn't be the problem. The
problem would be if you were trying to match the C++ header file and thus
have the two namespaces in the same file without a conflict, and that
wouldn't work unless you could do something like put the symbol inside a
struct or template to effectively namespace it - or if the current
extern(C++, NS) mechanism were left in place in addition to adding
extern(C++, "NS").
But for the most part, this is a non-issue, because the sane thing to do
would be to just put different namespaces in different modules even if they
were in the same header file in C++ - maybe pkg.headerfile.namespace instead
of pkg.headerfile like you might do if everything in the header file were in
the same namespace. It might be more of a problem with something that
generated the bindings automatically, but mostly, the issue seems to be that
Walter wants to be able to completely follow the C++ header scheme when you
create the bindings, whereas most of the rest of us don't really care about
being that exact about it if the header file did something like have
multiple namespaces with symbols that would conflict if they were in the
same namespace. Since the current scheme effectively creates namespaces
inside of the module instead of just affecting the name mangling, you can
stick as many namespaces in the module as you want without worrying about
conflicts, but you then get other fun problems like having to declare
everything in the namespace sequentially and having to refer everything in
the namespace with the namespace unless you alias it all.
So really, the most flexible solution would probably to have
extern(C++, "NS") which only affects the mangling and then make sure that it
works to do something like
struct Namespace
{
extern(C++, "Namespace") static void foo(int bar);
}
thereby allowing you to have symbols from multiple namespaces in the same
module even if they have conflicting names. In most cases, people would then
just do
extern(C++, "Namespace") void foo(int bar);
and it's nice and simple, whereas if they really wanted to put conflicting
symbols in the same module instead of just putting them in separate module
like you would with D symbols, they could then explicitly namespace them.
But given what we already have in the language, the simplest alternative
would be to just add
extern(C++, "Namespace")
and leave
extern(C++, Namespace)
so that most code could use extern(C++, "Namespace"), and those rare cases
where you really don't want to put conflicting symbols in separate modules,
you use the current scheme of extern(C++, Namespace). The main downside is
that having both constructs risks being confusing. Really though, there
isn't much of a downside to the extern(C++, "Namespace") solution even if it
were the only one.
- Jonathan M Davis
Re: extern(C++, ns) is wrong
On Wednesday, 12 September 2018 at 03:59:30 UTC, Danni Coy wrote: So my understanding is that the main issue with extern(C++,"ns") is functions that have different C++ name-spaces overriding each other in unexpected ways. How feasible is to simply disallow functions/variables/objects/... with the same name but a different "ns" being in the same module? Very. The compiler would do it automatically because they would cause name collisions.
Re: silly is released - new test runner for the D programming language
On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Hello, I'm glad to announce that silly v0.0.1 is released. Silly is a brand-new test runner with simplicity in mind. It's developed to be as simple as possible and contain no useless features. Another important goal is to provide flexible tool which can be easily integrated into existing environments. In my local version I've modified the test name to be colorized. Could you add this feature? it really helps the readability in my opinion. Either way, I really love silly! Thanks a lot!
Re: extern(C++, ns) is wrong
So my understanding is that the main issue with extern(C++,"ns") is functions that have different C++ name-spaces overriding each other in unexpected ways. How feasible is to simply disallow functions/variables/objects/... with the same name but a different "ns" being in the same module?
Re: rund users welcome
On Tuesday, 11 September 2018 at 19:55:33 UTC, Andre Pany wrote: On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: I've rewritten rdmd into a new tool called "rund" and have been using it for about 4 months. It runs about twice as fast making my workflow much "snappier". It also introduces a new feature called "source directives" where you can add special comments to the beginning of your D code to set various compiler options like import paths, versions, environment variable etc. Feel free to use it, test it, provide feedback, contribute. https://github.com/marler8997/rund It would be great if you could create a pull request for rdmd to add the missing -i enhancement. Kind regards Andre I did :) https://github.com/dlang/tools/pull/292 I spent quite a bit of time on it but in the end the bulk of my time was spent on what seemed to be endless debate rather than writing good code. After I decided to try forking rdmd my life got much better :) Now I spend my time writing great code, making good tests and having nice tools. I'm much happier working than I am arguing with people. What took me months to do with rdmd took me less than a day with my rund. So...if you have requests for rund features or issues by all means let me know, but I don't control rdmd and I've learned that time contributing to it is mostly time wasted.
Canadian companies using D?
Hi All, I wonder if you guys are aware of any Canadian companies using D, I want to do some research about what they're using D for and eventually follow some of them. I was browsing https://dlang.org/orgs-using-d.html but I didn't find any there yet. Cheers.
Re: Copy Constructor DIP and implementation
On 9/11/2018 8:08 AM, RazvanN wrote: [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688 Thank you, RazvanN!
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 07:23:53 UTC, Joakim wrote: I agree with a lot of what you say here, but I'm not sure what you mean by "first class support for mobile." What exactly do you believe D needs to reach that level? Natural-feeling bindings to platform libraries that are not incredibly slow and that are well-maintained. What does it matter that you can run a webserver from your phone if you can't write a "hello world" GUI program, set an alarm, or enqueue a download?
Fwd: Copy Constructor DIP and implementation
This should probably have been posted here. -- Andrei Forwarded Message Subject: Copy Constructor DIP and implementation Date: Tue, 11 Sep 2018 15:08:33 + From: RazvanN Organization: Digital Mars Newsgroups: digitalmars.D.announce Hello everyone, I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it! Thanks, RazvanN [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688
Re: rund users welcome
On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: I've rewritten rdmd into a new tool called "rund" and have been using it for about 4 months. It runs about twice as fast making my workflow much "snappier". It also introduces a new feature called "source directives" where you can add special comments to the beginning of your D code to set various compiler options like import paths, versions, environment variable etc. Feel free to use it, test it, provide feedback, contribute. https://github.com/marler8997/rund It would be great if you could create a pull request for rdmd to add the missing -i enhancement. Kind regards Andre
Re: @safe pointer value modification
On Saturday, September 8, 2018 11:06:20 AM MDT Neia Neutuladh via
Digitalmars-d wrote:
> On Saturday, 8 September 2018 at 17:01:33 UTC, Jacob Shtokolov
>
> wrote:
> > So, modification of pointer values is prohibited (if I
> > understand this sentence correctly).
>
> @safe code can't manipulate the pointer itself, in order to avoid
> memory corruption.
>
> So this is forbidden:
>
> void main() @safe
> {
>int* p = malloc(512);
>p++;
> }
>
> But in @safe code, the compiler assumes that all pointers you
> receive are valid. And the null pointer is also valid --
> dereferencing it results in a segmentation fault rather than
> memory corruption.
Also, mutating the data that a pointer points to is not mutating the
pointer. So,
*foo = 42;
is not mutating a pointer, whereas
++foo;
would be. So, the first is allowed in @safe code, whereas the second is not.
BTW, if you have questions about D, please ask them in D.Learn. This
newsgroup / mailing list / forum is intended for general discussion on D,
not for answering questions about how the language works.
- Jonathan M Davis
Re: rund users welcome
On Tuesday, 11 September 2018 at 17:36:09 UTC, Kagamin wrote: On Tuesday, 11 September 2018 at 15:20:51 UTC, Jonathan Marler wrote: The Posix/Windows 10 cases seem fine, but Windows <10 is not great. MSDN says symbolic links are supported since Vista. Yeah but I think you need Admin privileges to make them.
Re: rund users welcome
On Tuesday, 11 September 2018 at 15:20:51 UTC, Jonathan Marler wrote: The Posix/Windows 10 cases seem fine, but Windows <10 is not great. MSDN says symbolic links are supported since Vista.
Re: Process in parallel and output result to stdout theread-safely
On Monday, 10 September 2018 at 20:30:52 UTC, Dr.No wrote:
On Saturday, 8 September 2018 at 14:26:45 UTC, ag0aep6g wrote:
[...]
Yes, it does only happens at line breaks. I hadn't realized
that until you mentioned. It does gets in place of \r and \n,
that's why there's all in one line when this happens. Thankfor
for the notice.
[...]
I noticied this happens with everything I print in the loop, even
using C's printf:
__gshared Mutex m;
m = new Mutex();
foreach(string fn; parallel(files))
{
try
{
auto res = f(fn);
synchronized(m)
{
import std.c.stdio :
printf;
printf("hello!\n");
}
[...]
Output:
https://imgur.com/a/Mq9X4c3
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: LDC recently added a linux/AArch64 CI for both its main branches and 64-bit ARM, ie AArch64, builds have been put out for both linux and Android. It does not seem that many are paying attention to this sea change that is going on with computing though, so let me lay out some evidence. ... I mostly agree with you, Joakim. I own a very nice (but now old) ODROID U2 (check the ODROID XU4 or C2!) so ARM support is important for me... Also, check this: https://www.hardkernel.com/main/products/prdt_info.php?g_code=G152875062626 HOWEVER, I think Iain is right - PPC64 and RISC-V are becoming more and more popular nowadays and may become more popular than ARM in the future but that future is unclear.
Re: How to use listener.d example?
On Friday, 7 September 2018 at 17:00:21 UTC, Marcin wrote: I get it working in linux environment. I don't know why vibe-d get linker errors on win10. And I get it to work on windos dub --build=release
Re: Copy Constructor DIP and implementation
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole wrote: Here is a question (that I don't think has been asked) why not @copy? It's not wrong to call this an implicit constructor since it's called implicitly. It also means that, if we get implicit constructors in general, we can keep the same syntax and annotations, and it will be consistent. Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other); That would be possible, but it would be inconsistent with super constructors in general.
Re: rund users welcome
On Tuesday, 11 September 2018 at 08:53:46 UTC, Kagamin wrote: On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: https://github.com/marler8997/rund I have an idea how to push shebang to userland and make it crossplatform: if, say, `rund -install prog.d` would copy/link itself into current folder under name "prog" and when run would work with file args[0]~".d", this will work the same on all platforms without shebang. So your idea is that you could run `rund -install prog.d` which would create some sort of file that allows you to run `./prog` (on POSIX) or `prog` (on WINDOWS). So something like this: /path/prog.d Posix: /path/prog -> /usr/bin/rund Windows 10 (It supports symbolic links) /path/prog.exe -> C:\Programs\rund.exe Windows <10 /path/prog.exe (a copy of rund.exe) Then this would allow you to run "/path/prog" and which would invoke rund and like you said we could take "argv[0]" and assume that's the main source file. The Posix/Windows 10 cases seem fine, but Windows <10 is not great. In this case it has to keep an entire copy of rund around (currently 1.8M). I think we can do better. Instead, `rund -install prog.d` could generate a little "wrapper program" that forwards any calls to rund. You could make this wrapper program with a small D program, or with this BATCH script: --- /path/prog.bat @rund %~dp0prog.d %* You get the same result. When you run "\path\prog" it will invoke rund with the given args for prog.d. Thoughts?
Re: Copy Constructor DIP and implementation
On 12/09/2018 3:08 AM, RazvanN wrote:
Hello everyone,
I have finished writing the last details of the copy constructor DIP[1]
and also I have published the first implementation [2]. As I wrongfully
made a PR for the DIP queue in the early stages of the development of
the DIP, I want to announce this way that the DIP is ready for the draft
review now. Those who are familiar with the compiler, please take a look
at the implementation and help me improve it!
Thanks,
RazvanN
[1] https://github.com/dlang/DIPs/pull/129
[2] https://github.com/dlang/dmd/pull/8688
Here is a question (that I don't think has been asked) why not @copy?
@copy this(ref Foo other) { }
It can be read as copy constructor, which would be excellent for helping
people learn what it is doing (spec lookup).
Also can we really not come up with an alternative bit of code than the
tupleof to copying wholesale? E.g. super(other);
Copy Constructor DIP and implementation
Hello everyone, I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it! Thanks, RazvanN [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688
Re: More fun with autodecoding
On Tuesday, 11 September 2018 at 02:00:29 UTC, Nicholas Wilson wrote: [snip] https://github.com/dlang/DIPs/pull/131 will help narrow down the cause. I like it, but I worry people would find multiple ifs confusing. The first line of the comment is about using static asserts and in contracts, but it looks like static asserts are allowed in in contracts for functions [1]. You can do the same thing in structs/classes with invariant blocks (but in contracts are not allowed). So basically, the same behavior for if can be reduced to in contracts with static asserts already. Multiple ifs would just be a slightly less verbose way to accomplish the same thing. I suppose one issue might be that contracts are not compiled in during release mode, but I think release only impacts normal asserts, not static asserts. Is there any reason why this is not sufficient? [1] https://run.dlang.io/is/lu6nQ0
Re: This is why I don't use D.
On Tuesday, 11 September 2018 at 13:48:36 UTC, 0xEAB wrote: By the way, thanks for all your explanations :) No problem! If it's inscrutable, it's not very useful.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 20:36:44 UTC, Neia Neutuladh wrote: On Monday, 10 September 2018 at 19:19:56 UTC, 0xEAB wrote: Moreover, a future feature could be build logs, so one could check why something failed to build. I'm hesitant to do much in this regard because I don't want people to treat this as a CI system. It would certainly be useful for finding bugs in the tester, though. A possible solution to this problem could be not testing updated packages for a compiler version they have already been tested with. This comes with some downsides, though - but it prevents abusing your service as CI. By the way, thanks for all your explanations :)
enforce with return type RegexMatch!string
I've got the folling function which returns a RegexMatch!string:
auto extract_list(const string entry)
{
// check if entry is valid
return matchAll(entry, some_regex);
}
I call this function using enforce(extract_list(some_argument)).
I think, that enforce is quite useless in this version. But I'd
like to add a check, if entry is valid in the
extract_list-function, something like:
if (!matchFirst(entry, other_regex)) return null;
That doesn't work, because I cannot cast null to
RegexMatch!string (I don't understand why). What works is to
create a string[] from the result of matchAll (using map and
array) and use that array instead of the range. Now I can return
null too.
Is there a way to accomplish this?
Re: More fun with autodecoding
On Tuesday, 11 September 2018 at 13:08:46 UTC, Steven Schveighoffer wrote: On 9/10/18 7:00 PM, Nicholas Wilson wrote: On Monday, 10 September 2018 at 20:44:46 UTC, Andrei Alexandrescu wrote: On 9/10/18 12:46 PM, Steven Schveighoffer wrote: On 9/10/18 8:58 AM, Steven Schveighoffer wrote: I'll have to figure out why my specialized range doesn't allow splitting based on " ". And the answer is: I'm an idiot. Forgot to define empty :) Also my slicing operator accepted ints and not size_t. I guess a better error message would be in order. https://github.com/dlang/DIPs/pull/131 will help narrow down the cause. While this would help eventually, I'd prefer something that just transforms all the existing code into useful error messages. See my response to Andrei. -Steve Please tell me where to get one of those! But yeah, that DIP will tell you that has slicing is you problem straight away. Extracting useful information to present to the user on why hasSlicing!R is false is much trickier for the same reason that providing useful information in the current template constraint format is hard: it is a bunch of potentially unstructured logic that has already been const-folded in order to evaluate it in the first place, so you can't re-evaluate it without flushing the template cache. That's not to say that the situation can't be improved beyond what the DIP specifies, but I haven't had any brilliant ideas (and the Idea for that DIP was stolen from someone else anyway).
Re: Small @nogc experience report
On Monday, 10 September 2018 at 09:11:38 UTC, Kagamin wrote: On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote: There is no other choice when the runtime is disabled but to have @nogc. It's a fantastic peace of mind for high-performance to be able to _enforce_ something will not allocate. You can't have a working GC allocation with disabled runtime, can you? Indeed and that's why you must ensure at compile-time that you have no `new` else you have a runtime crash, and one that might be difficult to test unless you have perfect coverage.
Re: More fun with autodecoding
On 9/10/18 7:00 PM, Nicholas Wilson wrote: On Monday, 10 September 2018 at 20:44:46 UTC, Andrei Alexandrescu wrote: On 9/10/18 12:46 PM, Steven Schveighoffer wrote: On 9/10/18 8:58 AM, Steven Schveighoffer wrote: I'll have to figure out why my specialized range doesn't allow splitting based on " ". And the answer is: I'm an idiot. Forgot to define empty :) Also my slicing operator accepted ints and not size_t. I guess a better error message would be in order. https://github.com/dlang/DIPs/pull/131 will help narrow down the cause. While this would help eventually, I'd prefer something that just transforms all the existing code into useful error messages. See my response to Andrei. -Steve
Re: More fun with autodecoding
On 9/10/18 1:44 PM, Andrei Alexandrescu wrote:
On 9/10/18 12:46 PM, Steven Schveighoffer wrote:
On 9/10/18 8:58 AM, Steven Schveighoffer wrote:
I'll have to figure out why my specialized range doesn't allow
splitting based on " ".
And the answer is: I'm an idiot. Forgot to define empty :) Also my
slicing operator accepted ints and not size_t.
I guess a better error message would be in order.
A better error message would help prevent the painful diagnosis that I
had to do to actually find the issue.
So the error I got was this:
source/bufref.d(346,36): Error: template
std.algorithm.iteration.splitter cannot deduce function from argument
types !()(Result, string), candidates are:
/Users/steves/.dvm/compilers/dmd-2.081.0/osx/bin/../../src/phobos/std/algorithm/iteration.d(3792,6):
std.algorithm.iteration.splitter(alias pred = "a == b", Range,
Separator)(Range r, Separator s) if (is(typeof(binaryFun!pred(r.front,
s)) : bool) && (hasSlicing!Range && hasLength!Range ||
isNarrowString!Range))
/Users/steves/.dvm/compilers/dmd-2.081.0/osx/bin/../../src/phobos/std/algorithm/iteration.d(4163,6):
std.algorithm.iteration.splitter(alias pred = "a == b", Range,
Separator)(Range r, Separator s) if (is(typeof(binaryFun!pred(r.front,
s.front)) : bool) && (hasSlicing!Range || isNarrowString!Range) &&
isForwardRange!Separator && (hasLength!Separator ||
isNarrowString!Separator))
/Users/steves/.dvm/compilers/dmd-2.081.0/osx/bin/../../src/phobos/std/algorithm/iteration.d(4350,6):
std.algorithm.iteration.splitter(alias isTerminator,
Range)(Range r) if (isForwardRange!Range &&
is(typeof(unaryFun!isTerminator(r.front
/Users/steves/.dvm/compilers/dmd-2.081.0/osx/bin/../../src/phobos/std/algorithm/iteration.d(4573,6):
std.algorithm.iteration.splitter(C)(C[] s) if (isSomeChar!C)
This means I had to look at each line, figure out which overload I'm
calling, and then copy all the constraints locally, seeing which ones
were true and which ones false.
But it didn't stop there. The problem was hasSlicing!Range. If you look
at hasSlicing, it looks like this:
enum bool hasSlicing(R) = isForwardRange!R
&& !isNarrowString!R
&& is(ReturnType!((R r) => r[1 .. 1].length) == size_t)
&& (is(typeof(lvalueOf!R[1 .. 1]) == R) || isInfinite!R)
&& (!is(typeof(lvalueOf!R[0 .. $])) || is(typeof(lvalueOf!R[0 ..
$]) == R))
&& (!is(typeof(lvalueOf!R[0 .. $])) || isInfinite!R
|| is(typeof(lvalueOf!R[0 .. $ - 1]) == R))
&& is(typeof((ref R r)
{
static assert(isForwardRange!(typeof(r[1 .. 2])));
}));
Now I had to instrument a whole slew of items. I pasted this whole thing
this into my code, added an alias to my range type for R, and then
changed the big boolean expression to a bunch of static asserts.
Then I found the true culprit was isForwardRange!R. This led me to
requestion my sanity, and finally realized I forgot the empty function.
A fabulous fantastic mechanism that would have saved me some time is
simply coloring the clauses of the template constraint that failed red,
the ones that passed green, and the ones that weren't evaluated grey.
Furthermore, it would be good to either recursively continue this for
red clauses like `hasSlicing` which have so much underneath. Either that
or a way to trigger the colored evaluation on demand.
If I were a dmd guru, I'd look at doing this myself. I may still try and
hack it in just to see if I can do it.
--
Finally, there is a possible bug in the definition of hasSlicing: it
doesn't require the slice parameters be size_t, but there are places
(e.g. inside std.algorithm.searching.find) that pass in range.length ..
range.length for slicing the range. In my implementation I had used ints
as the parameters for opSlice. So I started seeing errors deep inside
std.algorithm saying there was no overload for slicing. Again the sanity
was questioned, and I figured out the error and now it's actually working.
-Steve
Re: Is it's correct to say that ALL types that can grow are place on heap?
11.09.2018 13:11, Timoses пишет: Is this why it is said that passing parameters by value can be more efficient? Cause for a ref parameter it would require passing the address which would require to be allocated? Aww, I really would love some insights into function parameter passing. Why is it said that passing by value can be more efficient at times? Since it is also said that passing large structs by value can be expensive, why then would it not be cheaper to ALWAYS pass everything by reference? What mechanism is behind the scene that follows one to reason that sometimes passing by value is less expensive? I get that passing an int by reference would cause indirections which need to be resolved whereas passing the int by value is just one copy (I guess). This topic kinda seemed fit for my question that I was carrying around for some time. If data size is less or equal to total size of available registers (that can be used to pass values) than passing by value is more efficient. Passing data with size less than register size by reference isn't efficient because you pass pointer (that has register size) and access memory using it.
Re: "immutable string" vs "const string*"
On Sunday, 9 September 2018 at 08:41:37 UTC, Christian Mayer wrote: On Sunday, 9 September 2018 at 08:14:41 UTC, rikki cattermole wrote: Are you aware that a string is just an alias of immutable(char)[]? Yes, I'm aware of that. But it's the same, for example, with just one char. "immutable char" vs "const char*". Or int, or any other data type. As of my current understanding "char" will create a new variable and copy the content of the original to the new variable. "char*" will just use the pointer. And "const char*" is good for when not modifying. But I also can achieve the same using "immutable char". But I'm not sure when better using "immutable char". In C I would rather use a const pointer. But since I just started learing D I'm not so sure because there are so many ways. Since strings are slices (immutable(char)[]) it could also be worth reading into slices [1]. Assigning an existing slice to another slice will not copy the content but only the slice struct (length and pointer to data). [1] https://dlang.org/articles/d-array-article.html
Re: Is it's correct to say that ALL types that can grow are place on heap?
On Saturday, 8 September 2018 at 22:51:17 UTC, Ali Çehreli wrote: On 09/08/2018 02:19 AM, Suliman wrote: > Is it's correct to say that ALL types that can grow are place on heap > and types that not growing (int, char, pointer) are place on stack? The question is not that simple. :) First, there is also the area used for objects that are static and object that are defined at module scope. That is different from both the call stack and the heap. Let's ignore them... There are automatic objects like local variables inside a function and function parameters. They normally live on the stack. (However, the compiler may pass some parameters in CPU registers without allocating any memory at all.) Is this why it is said that passing parameters by value can be more efficient? Cause for a ref parameter it would require passing the address which would require to be allocated? Aww, I really would love some insights into function parameter passing. Why is it said that passing by value can be more efficient at times? Since it is also said that passing large structs by value can be expensive, why then would it not be cheaper to ALWAYS pass everything by reference? What mechanism is behind the scene that follows one to reason that sometimes passing by value is less expensive? I get that passing an int by reference would cause indirections which need to be resolved whereas passing the int by value is just one copy (I guess). This topic kinda seemed fit for my question that I was carrying around for some time.
Re: libmir: recent updates
On Monday, 10 September 2018 at 20:22:08 UTC, jmh530 wrote: On Monday, 10 September 2018 at 17:42:16 UTC, jmh530 wrote: [snip] mir-algorithm and lubeck do not interact well right now on run.dlang.org as lubeck depends on the earlier API. The maintainer of that might consider adding an older version of mir-algorithm until the situation is resolved. Hmm, it looks like all you have to do just change the dependency to whatever works with lubeck and it works fine. Maybe it can be temporarily adjusted so that adding lubeck as a dependency adds the correct version of mir algorithm by default? Thanks for the report. Lubeck has been tagged to release. Plus tour update https://github.com/dlang-tour/english/pull/269 (requires mir v2.0.2)
Re: traits getOverload of a template method
On Thursday, 6 February 2014 at 23:06:03 UTC, QAston wrote:
How do i get aliases to overloads of a template method like
Class A
{
int a(T)(T tq,T tw);
int a(T)(T tq);
}
__traits(getOverloads, A, "a(int)")doesnt work
Support for template in the getOverloads trait has been added
recently.
You have to set an optional trailing parameter to `true`:
```
class A
{
int a(T)(T,T){}
int a(T)(T){}
}
enum include_templates = true;
static foreach (overload; __traits(getOverloads, A, "a",
include_templates))
pragma(msg, overload.stringof);
```
a(T)(T, T)
a(T)(T)
specs: https://dlang.org/spec/traits.html#getOverloads
[Issue 19241] New: Broken value of auto ref argument for closure
https://issues.dlang.org/show_bug.cgi?id=19241
Issue ID: 19241
Summary: Broken value of auto ref argument for closure
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: zan77...@nifty.com
This code doesn't work:
---
auto ref run(F, Args...)(F dg, auto ref Args args)
{
return dg(args);
}
auto makeClosure(alias func, Args...)(auto ref Args args)
{
auto fptr = args[0].funcptr;
return {
// ! Assertion failure !
assert(args[0].funcptr is fptr);
return func(args);
};
}
auto test(F, Args...)(F dg, auto ref Args args)
{
return makeClosure!run(dg, args);
}
void main()
{
auto t = test( delegate ()=> 10 );
assert(t() == 10);
}
---
dmd -debug -g -run main.d
---
core.exception.AssertError@main.d(9): Assertion failure
0x004029B3 in _d_assertp at ...\src\core\exception.d(436)
0x0040225B in _Dmain at main.d(20)
--
[Issue 19240] New: std.typecons.Tuple should check for reserved identifiers
https://issues.dlang.org/show_bug.cgi?id=19240 Issue ID: 19240 Summary: std.typecons.Tuple should check for reserved identifiers Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com e.g. import std.typecons : Tuple; Tuple!(int, "function") a; /dlang/dmd/linux/bin64/../../src/phobos/std/typecons.d-mixin-613(613): Error: basic type expected, not function /dlang/dmd/linux/bin64/../../src/phobos/std/typecons.d-mixin-613(613): Error: found = when expecting ( /dlang/dmd/linux/bin64/../../src/phobos/std/typecons.d-mixin-613(613): Error: found ; when expecting ) /dlang/dmd/linux/bin64/../../src/phobos/std/typecons.d-mixin-613(613): Error: no identifier for declarator _error_ function(_0LU) /dlang/dmd/linux/bin64/../../src/phobos/std/typecons.d-mixin-613(613): Error: semicolon expected to close alias declaration onlineapp.d(3): Error: template instance `std.typecons.Tuple!(int, "function")` error instantiating Not the best error message --
Re: rund users welcome
On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: https://github.com/marler8997/rund I have an idea how to push shebang to userland and make it crossplatform: if, say, `rund -install prog.d` would copy/link itself into current folder under name "prog" and when run would work with file args[0]~".d", this will work the same on all platforms without shebang.
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 07:23:53 UTC, Joakim wrote: I agree with a lot of what you say here, but I'm not sure what you mean by "first class support for mobile." What exactly do you believe D needs to reach that level? Basically the things you describe. I was thinking of a stable and easy build system, e.g. $ dub init android [iOS] $ dub --arch=arm64 And and of course check which language features work (or don't work!) on ARM and write a documentation. Cf. https://kotlinlang.org/docs/reference/native-overview.html The thing is that D already has a lot of useful stuff like C/C++ and Objective-C interop. It would be a pity if we didn't use it. I think most of the heavy lifting with core language and stdlib support is done. What remains is polish and integration for the build process and possibly IDEs and of course, making sure there are D libraries to make mobile dev easier. I will be sporadically polishing the build process over the coming months, by getting much more building through dub. I won't be doing anything with IDEs, as I don't use them. As for libraries, that all depends on what you're doing and how much others in the D community want that too. It might be a good idea to set up a funding target to get the iOS port back up to speed again. I don't use Apple products so it won't be me picking up that porting work, but maybe Dan could be enticed to finish it as a paid project, since he did most of the voluntary work so far. I'm purely speculating, no idea if money changes the equation for him, just know that he's been too busy to work on it for the last couple years. That'd be part of the first class support. That a dedicated team works on it. Volunteers are not enough. Once it's polished it will still need loads of maintenance.
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 07:42:38 UTC, passenger wrote: On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: [...] Is it possible to develop versus a NVidia Jetson, CUDA included? I think so, but I doubt anyone has ever actually tried it: https://www.nvidia.com/en-us/autonomous-machines/embedded-systems-dev-kits-modules/ As for CUDA, Nicholas Wilson said recently that he could do something with it for his DCompute project with ldc, but no idea what the current status is: https://forum.dlang.org/post/slijjptlxdrfgvoya...@forum.dlang.org
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: LDC recently added a linux/AArch64 CI for both its main branches and 64-bit ARM, ie AArch64, builds have been put out for both linux and Android. It does not seem that many are paying attention to this sea change that is going on with computing though, so let me lay out some evidence. At my workplace six years ago, the developers were all allocated a core i5 ultrabook- likely with 4 GBs of RAM and a 128 GB SSD, though I don't remember those specs- and a 27" 2560X1440 display with which to get our work done. I was pretty happy with the display, the best I'd ever used to that point. I'm guessing the setup cost my employer a couple thousand dollars per developer. I picked up an Android/AArch64 smartphone earlier this year, with 6 GBs of RAM, 128 GBs of flash, a Snapdragon 835 octa-core CPU, and a 5.5" 2560X1440 display. This is the fastest computer I've ever owned, and it fits in 6 cubic inches and weighs a little more than a third of a pound. It cost me approximately $700. That is a stunning change in mobile capabilities in just six years, where what used to be a mobile developer workstation now comes packed into a smartphone at a fraction of the cost. If you think the phone doesn't actually perform, I borrowed a 2015-model Macbook Air with a core i5 and 4 GBs of RAM and built the last pure C++ version of ldc, 0.17, using both cores with `-ninja -j5`. It took two minutes with clang from Homebrew, the same amount of time it takes me to build the same source on my smartphone with clang by running `ninja -j9`. This phone has been my development hardware since early this year, by pairing it with a $30 bluetooth keyboard and a $5 stand to hold it up. I'm typing this long forum post up on it now. Tech companies are starting to realize this and going after the desktop/laptop PC markets with various 64-bit ARM products: https://www.engadget.com/2018/08/09/samsung-galaxy-note-9-dex/ https://arstechnica.com/gadgets/2018/08/samsungs-tab-s4-is-both-an-android-tablet-and-a-desktop-computer/ https://youtube.com/watch?v=uLvIAskVSUM https://www.anandtech.com/show/13309/lenovo-yoga-c630-snapdragon-850-windows That last link notes 25 hours of battery life with a Windows/AArch64 laptop, one of the key benefits of ARM, which is why even Microsoft has come around. Yes, I know, these devices won't replace your quad-core Xeon workstation with 32-64 GBs of RAM anytime soon, but most people don't need anywhere near that level of compute. That's why PC sales keep dropping while mobile sales are now 6-7X that per year: https://www.businessinsider.com/PC-sales-are-continuing-to-slump-fewer-are-sold-now-than-when-the-iPhone-launched/articleshow/62547330.cms https://www.androidauthority.com/smartphone-sales-idc-2018-871363/ Most of those mobile devices running iOS have AArch64 CPUs, and google said last December that "over 40% of Android devices coming online have 64-bit support," which is why they're requiring apps with native libraries to support it by next fall: https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html D now has mostly working AArch64 support, with the ldc 1.11 release last month: https://github.com/ldc-developers/ldc/releases/tag/v1.11.0 That is the result of years of intermittent AArch64 patches added by the core teams of ldc and gdc- David, Iain, Kai, Johannes, Dan, and others- to which I recently added some Android patches. You too can pitch in with the few remaining issues or try out the AArch64 support with your own D code. This company provides a free linux/AArch64 CI for OSS projects, LDC uses it: http://blog.shippable.com/shippable-arm-packet-deliver-native-ci-cd-for-arm-architecture Despite all this, D may never do very well on mobile or AArch64, even though I think it's well-suited for that market. But at the very least, you should be looking at mobile and AArch64, as they're taking over the computing market. Is it possible to develop versus a NVidia Jetson, CUDA included?
Re: dlang download stat should be updated
On Sunday, 9 September 2018 at 09:05:33 UTC, Suliman wrote: Last update was long time ago http://erdani.com/d/downloads.daily.png UP
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 06:42:26 UTC, Chris wrote:
On Monday, 10 September 2018 at 19:28:01 UTC, aberba wrote:
On Monday, 10 September 2018 at 16:09:41 UTC, rjframe wrote:
That's exactly whats happening in Africa. The continent is
leapfrogging from nothing to a smart phone thanks to China.
Many don'[t know how to even use a PC. Especially the young
and upcoming generation.
The smart phone market is really significant.
That's why I'm trying to draw attention to first class ARM
support by the D Foundation (not just some voluntary efforts,
much as they are appreciated). ARM in dmd wouldn't be a bad
idea perhaps, as Manu suggested. It's become more than obvious
over the last couple of years that mobile devices have become
very important and that people often use them instead of PCs or
laptops. Fewer and fewer developers can "escape" development
for mobile ("we want an app too"), and if a language doesn't
offer first class support for mobile, then devs won't bother
with it. A lot of other (new) languages are directing their
efforts towards mobile for a reason.
I agree with a lot of what you say here, but I'm not sure what
you mean by "first class support for mobile." What exactly do you
believe D needs to reach that level?
I think most of the heavy lifting with core language and stdlib
support is done. What remains is polish and integration for the
build process and possibly IDEs and of course, making sure there
are D libraries to make mobile dev easier.
I will be sporadically polishing the build process over the
coming months, by getting much more building through dub. I won't
be doing anything with IDEs, as I don't use them.
As for libraries, that all depends on what you're doing and how
much others in the D community want that too.
It might be a good idea to set up a funding target to get the iOS
port back up to speed again. I don't use Apple products so it
won't be me picking up that porting work, but maybe Dan could be
enticed to finish it as a paid project, since he did most of the
voluntary work so far. I'm purely speculating, no idea if money
changes the equation for him, just know that he's been too busy
to work on it for the last couple years.
Re: Small @nogc experience report
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote: Not Weka but we are happy with @nogc and without @nogc our job would be impossible. There is one way to code without garbage collector somewhat practically without annotating @nogc, the way I use: Compile manually only those parts of runtime you need and have linker to link in only needed symbols (so there is no need to go stubbing the whole runtime). If you accidently allocate, you get linker errors. Still, @nogc helps because it will tell right away where I called something I should not. I wonder if having an option to compile DRuntime without support for thearding would simplify portability. I once read the implementation and got the impression that theards are by far the most platform-dependant part of it.
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 19:28:01 UTC, aberba wrote:
On Monday, 10 September 2018 at 16:09:41 UTC, rjframe wrote:
That's exactly whats happening in Africa. The continent is
leapfrogging from nothing to a smart phone thanks to China.
Many don'[t know how to even use a PC. Especially the young and
upcoming generation.
The smart phone market is really significant.
That's why I'm trying to draw attention to first class ARM
support by the D Foundation (not just some voluntary efforts,
much as they are appreciated). ARM in dmd wouldn't be a bad idea
perhaps, as Manu suggested. It's become more than obvious over
the last couple of years that mobile devices have become very
important and that people often use them instead of PCs or
laptops. Fewer and fewer developers can "escape" development for
mobile ("we want an app too"), and if a language doesn't offer
first class support for mobile, then devs won't bother with it. A
lot of other (new) languages are directing their efforts towards
mobile for a reason.
