Re: how to compile D programs without console window
On Sunday, 15 July 2018 at 01:20:25 UTC, evilrat wrote: ... "lflags": [ "/SUBSYSTEM:windows" ], ... didn't know that, thank you
Re: mir-optim v0.0.1: betterC nonlinear least squares
On Friday, 13 July 2018 at 16:20:30 UTC, jmh530 wrote: On Tuesday, 10 July 2018 at 02:10:56 UTC, 9il wrote: The algorigbms from https://github.com/JuliaNLSolvers are good candidates. No plans to implement them for now, but PRs are wellcome. Another type of functionality that would be useful: https://www.mathworks.com/help/matlab/ref/fzero.html This can be done with a non-linear least squares, but I don't think that's the most efficient method. D's findRoot probably is the world's most efficient and robust implementation. For single initial point fzero we can be implemented as IEEE set binary search of second initial point x1 such that sign(f(x0)) != sign(f(x1)) plus D's findRoot.
Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On 7/13/18 4:47 PM, Patrick Schluter wrote: On Friday, 13 July 2018 at 20:12:36 UTC, Steven Schveighoffer wrote: On 7/13/18 3:53 PM, Paolo Invernizzi wrote: On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer wrote: On 7/13/18 8:55 AM, Adam D. Ruppe wrote: [...] But it doesn't scale if you use OS processes, it's too heavyweight. Of course, it depends on the application. If you only need 100 concurrent connections, processes might be OK. Came on, Steve... 100 concurrent connections? Huh? What'd I say? orders of magnitudes too small. 100 concurrent connections you can handle with a sleeping arduino... :-) Meh, I admit I don't know the specifics. I just know that there is a reason async i/o is used for web services. Let's say there is a number N concurrent connections that processes are OK to use. Then you can scale to 100xN if you use something better. -Steve
Re: @safe - why does this compile?
On 7/14/18 2:50 AM, Timoses wrote: On Friday, 13 July 2018 at 22:17:59 UTC, Dukc wrote: On Friday, 13 July 2018 at 13:52:27 UTC, Timoses wrote: I suppose this is another good example of how casting can be dangerous? E.g. also: immutable int i = 3; int* j = cast(int*) assert(i == 3); *j = 4; assert(j == ); // data occupies same address space assert(i == 3 && *j == 4); // yet the values differ No, casting classes to their subclasses is not dangerous to program integrity, because it is checked. It is just a regular bug that terminates the program when encountered. But casting away immutable can break program integrity as your example demonstrates. For that reason the compiler won't let you do that if you wrap that code in @safe, unlike the class cast. Thanks for the explanation. Only read the function safety chapter in depth after posting this : D. Still, is `cast`ing seen as something "dangerous" or as something that should only be done as a last resort? Should std.conv : to be prioritized? Well, std.conv.to is going to throw if it doesn't dynamically convert. So it depends on the behavior you want. But yeah, if you know it's going to work, you probably want to do std.conv.to, it's safer. Just FYI, it's kind of bad that you have to use cast here, because cast isn't going to distinguish between dynamic casting and const casting. It's kind of a problem in D in general. We don't have C++ niceties like const_cast etc. -Steve
Re: how to compile D programs without console window
On Saturday, 14 July 2018 at 09:43:48 UTC, Flaze07 wrote: On Saturday, 14 July 2018 at 09:39:21 UTC, rikki cattermole wrote: If you're using dub, throw them into lflags and remove the -L. https://forum.dlang.org/post/gmcsxgfsfnwllploo...@forum.dlang.org hmm, for some unknown reason it says that it is unable to find SUBSYSTEM:windows.lib / (slash) is the part of a linker switch, /SUBSYSTEM:windows so in dub.json it will look like ... "lflags": [ "/SUBSYSTEM:windows" ], ...
Re: Weird bugs in DMD 2.81.0
Well, it seems I fixed the AA issue by removing a totally unrelated thing (an undoable event chain system, that got "deprecated"), but now I got another weird issue. Sometimes setting a dynamic array's length causes an access violation. Still only on WindowMaker, and nothing in PixelPerfectEditor. Does somebody have a foolproof method for designing window layouts without an editor? I starting to give up on this piece of crap software, however before that it took me a whole day to figure out where the elements should fall, then another day to debug issues with the layout. My current solution at this point is to type in stuff instead of relying on generated code.
Is there any tool that will auto publish my changes.
I am writing a simple vibe.d app. The following is what I do right now. - I make changes. - build - Restart the server. Is there any tool that will auto publish my changes as I save them ? I am using Visual Studio Code. Thanks Venkat
Re: Find out druntime/import and phobos folder on Linux
On Saturday, 14 July 2018 at 19:04:01 UTC, Andre Pany wrote: Somehow also the DMD executable needs to know which Phobos/DRuntime it should use. How does DMD is working here? Maybe I can do the same... DMD determines default import and library paths from the dmd.conf file typically at /etc/dmd.conf. Mike
Re: Weird bugs in DMD 2.81.0
On Saturday, 14 July 2018 at 07:01:59 UTC, Seb wrote: Any chance you can make a minimal, reproducible example of this? Would be great because then it can be put on bugzilla and other people can have a look at it too. I might try, but first I'll look at the functions to see if I can fix some of it by myself, fixing pointer overflows. I suspect that the drawing functions overflow due to small typos, once I mixed up the x and y coordinates of something then it resulted in a corrupted image.
What determines if an algorithm goes in std.algorithm or std.range
Alo, I'm wondering how phobos devs view or determine what goes in to std.algorithm and what goes in to std.range. To me some of them are quite obvious - well, most things can arguably be an algorithm. But for example "refRange" is clearly a range specific thing, but "transpose" is not. And things that create ranges from nothing also may "clearly" belong in the range module? (e.g. iota, generate and recurrence) Also curious, are there any github PRs in phobos where certain algorithms were discussed as going in to where and what the reasonings were? cheers - Ali
Re: Find out druntime/import and phobos folder on Linux
On Saturday, 14 July 2018 at 17:19:20 UTC, Andre Pany wrote:
Is there a way to find out both paths based on the dmd
executable folder?
What I found out so far, these paths are not always correct:
/usr/include/dmd/druntime/import
/usr/include/dmd/phobos
Arch Linux and derivatives keep them under
/usr/include/dlang/{dmd,gdc,ldc}/*
You may have to hardcode some common paths and try them in each
in turn. I'm happy to be proven wrong here though.
Re: Find out druntime/import and phobos folder on Linux
On Saturday, 14 July 2018 at 19:00:56 UTC, Anonymouse wrote:
On Saturday, 14 July 2018 at 17:19:20 UTC, Andre Pany wrote:
Is there a way to find out both paths based on the dmd
executable folder?
What I found out so far, these paths are not always correct:
/usr/include/dmd/druntime/import
/usr/include/dmd/phobos
Arch Linux and derivatives keep them under
/usr/include/dlang/{dmd,gdc,ldc}/*
You may have to hardcode some common paths and try them in each
in turn. I'm happy to be proven wrong here though.
Somehow also the DMD executable needs to know which
Phobos/DRuntime it should use.
How does DMD is working here? Maybe I can do the same...
Kind regards
André
Re: Check whether a range is empty
First, please show us code that demonstrates the issue.
On 07/14/2018 07:47 AM, vino.B wrote:
>The reason it never prints the text "Empty" is that the out of the
> "r" is just an empty array.
>
> OUTPUT:
> []
> []
If that's the output of r, then r is not empty but has two elements and
those elements are likely arrays. If they are in fact arrays, them being
empty does not change r: it still has two elements.
If you want to treat the range as empty when all its elements are empty,
then perhaps your problem needs std.algorithm.joiner. The following
program demonstrates your issue with the first assert and the fix with
the second assert:
import std.algorithm;
import std.range;
void main() {
int[][] r = [ [], [] ];
assert(!r.empty);
auto joined_r = r.joiner;
assert(joined_r.empty);
}
joiner joins elements that are ranges themselves. For example, joiner([
[1], [2] ]) is equal to [ 1, 2 ].
Ali
Find out druntime/import and phobos folder on Linux
Hi, The IntelliJ D Language plugin has support for D-scanner and DCD. Both tools needs to know the paths to druntime/import and Phobos source folder. In IntelliJ you set the path to the folder where dmd binary is located. Based on this information on Windows and MacOS it is possible to determine the paths. The code can be found here https://github.com/intellij-dlanguage/intellij-dlanguage/blob/develop/src/main/java/io/github/intellij/dlanguage/codeinsight/dcd/DCDCompletionServer.java#L180 I want to provide a fix that the paths are also automatically determined on Linux correctly but I do not have much Linux experience. Is there a way to find out both paths based on the dmd executable folder? What I found out so far, these paths are not always correct: /usr/include/dmd/druntime/import /usr/include/dmd/phobos Kind regards Andre
Re: Funding code-d
On Friday, 13 July 2018 at 14:20:19 UTC, Mike Parker wrote: As promised in my tweet of June 30 (and to the handful of people who emailed me), the cloud of mystery surrounding the use of the money raised for code-d and its supporting tools has now been (partially) lifted! In this post, I lay out the details of how the first $1000 will be paid out to project maintainer Jan Jurzitza, a.k.a Webfreak001, and explain what we hope to achieve with this ecosystem fundraising initiative going forward. This time around, it all came together in the background of prepping for DConf with little forethought beyond activating an Open Collective goal and then working with Jan to determine the details. Lessons were learned. Later this year, you'll see the result when we announce the next of what we hope to be an ongoing series of funding targets. In the meantime: The blog https://dlang.org/blog/2018/07/13/funding-code-d/ Reddit https://www.reddit.com/r/d_language/comments/8yka7b/funding_coded_the_d_blog/ Nice explication of the plan, really needed. Why github never rolled out such a bounty program for OSS and other public projects has to be one of the head-scratching moves of all time, no wonder they were about to run out of money before they sold. A good way to decide on future projects would be to let prospective donors stake money on various proposals, to see how much backing they might receive, sort of like how kickstarter and other crowdfunding sites work.
Re: Copy Constructor DIP
On Friday, 13 July 2018 at 01:18:48 UTC, Andrei Alexandrescu
wrote:
On 7/12/18 2:30 PM, ag0aep6g wrote:
You're still potentially changing the semantics of existing
code. `@implicit` can be a UDA today:
enum implicit = 0;
struct C
{
@implicit this(ref C another) {}
}
Today, that's a normal constructor. With the DIP, it becomes a
copy constructor.
That is correct and a liability of the current DIP. That should
be mentioned in it.
That's easily fixed by implementing a compiler recognized UDA.
That would mean that it would only be a copy constructor if
"implicit" is defined in core.attribute. This would also avoid
any special syntax in the parser. The already existing @selector
is implemented like this.
--
/Jacob Carlborg
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 13:57:12 UTC, Laeeth Isharc wrote: On Saturday, 14 July 2018 at 07:30:26 UTC, Joakim wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ "join us" for "submit an application" -> apply (confusing otherwise) Maybe sum up and make clear that each student can earn between $3000-4000, instead of capped at $1k. Why limit it to students? If the goal is to have a youth injection, just use an age limit- say 18-25- I see no reason for the stupid college bias. Hi Joakim. Thanks for suggestions. Sure, thanks for funding this worthwhile initiative. I don't know what legal aspects there are relating to targeting age in different countries. We are definitely targeting people earlier in their careers. I agree with you that talent isn't only found amongst students, and I've in the past hired someone that didn't even finish high school and has gone on to do good work for the D community. So as far as Symmetry goes we are very open to unusual talent. A degree is just one piece of interesting information. Yes, but the current requirements exclude, for example, recent college grads who may not be employed yet and might do much better work than a harried college student. I don't know the legal risks in detail, but I can't imagine the risk/reward to opening it up would favor the current limitation.
Re: Check whether a range is empty
On Saturday, 14 July 2018 at 14:28:52 UTC, vino.B wrote:
On Friday, 13 July 2018 at 19:45:03 UTC, Steven Schveighoffer
wrote:
On 7/13/18 3:29 PM, vino.B wrote:
[...]
Well, empty is how you detect whether any range is empty, and
as far as ranges are concerned, your code is correctly
checking for empty.
A couple comments:
1. Why are you using chain with a single parameter? That just
returns its parameter.
2. You may want to try grabbing the range ONCE. i.e.:
auto r = PFresult.toRange;
if(!r.empty)
{
foreach(i; r) ...
}
I'm not familiar with how taskPool works, so I don't know the
real answer.
-Steve
Hi Steve,
i Tried your method no luck, it just prints blank lines.
From,
Vino.B
Hi Steve,
The reason it never prints the text "Empty" is that the out of
the "r" is just an empty array.
OUTPUT:
[]
[]
From,
Vino.B
Re: dpp now compiles julia.h headers
On Friday, 13 July 2018 at 22:22:25 UTC, Meta wrote: On Friday, 13 July 2018 at 19:02:56 UTC, Laeeth Isharc wrote: Atila Neves' d++ now compiles julia.h. Modulo bugs this makes it possible to embed Julia in D (and probably the other way around, but I have not tried). https://github.com/kaleidicassociates/juliad Very cool. It's awesome to be able to directly #include C++ headers. C++ headers with all basic features are not yet there. Atila thought it might be a couple of months work full-time to be able to do #include It's not out of the question to make that investment, but we need to hire a few more programmers locally first.
Re: Check whether a range is empty
On Friday, 13 July 2018 at 19:45:03 UTC, Steven Schveighoffer
wrote:
On 7/13/18 3:29 PM, vino.B wrote:
[...]
Well, empty is how you detect whether any range is empty, and
as far as ranges are concerned, your code is correctly checking
for empty.
A couple comments:
1. Why are you using chain with a single parameter? That just
returns its parameter.
2. You may want to try grabbing the range ONCE. i.e.:
auto r = PFresult.toRange;
if(!r.empty)
{
foreach(i; r) ...
}
I'm not familiar with how taskPool works, so I don't know the
real answer.
-Steve
Hi Steve,
i Tried your method no luck, it just prints blank lines.
From,
Vino.B
Re: DIP 1014--Hooking D's struct move semantics--Final Review
On 14/07/18 15:56, Johan Engelen wrote: First off: I am trying to wear a strict language lawyer hat. D spec is already very much ill specced which is _very_ problematic for language and compiler development. I am not attacking the proposal in order to kill it. I am merely commenting on points that I feel should be improved. Wouldn't these comments be better suited for the language spec's PR, then? I'm asking seriously. There is nothing in this DIP (or just about any other one) that can go, unmodified, into the specs. If that's the DIP's purpose, then so be it. If not, then I don't see the value. OK, so make _that_ explicit. I think there is value in prescribing the precise order of moves (like for construction of members), such that reasoning about code becomes easier. I disagree. The member variables at the point of the move are all: 1. Fully initialized. 2. Either move agnostic or know how to handle their own move 3. Oblivious to one another Obviously, you might wish to spite me by creating a case where any one of the above is not true, but the compiler has every right to assume all three points above are true. In your hypothetical spite case, your best course of action is to leave the members with no opPostMove at all, and handle their move in the containing struct's opPostMove, in which case you are fully defined. Assuming all three are correct, the order in which they are moved makes no difference. If you want the same semantic effect (as I wrote above), then the text should say that the ordering is relaxed. I have no objection to explicitly stating that exact move order of members is undefined. Why "SHOULD" and not "MUST"? Precisely for the reason you stated above. So that if you want to do something else, you may. Why is that freedom needed? Because compiler implementers might have a good reason to do something besides this. For example, a compiler writer might choose to place the actual moving code inside __move_post_blt, and I don't think we should stop her. The freedom is already provided by user-defined opPostMove? Different audiences. opPostMove serves the D programmer, __move_post_blt serves the compiler. I think the language spec doesn't say when a "move" is performed? I think Walter sees that as an advantage, but I'm not sure. Either way, the current language spec says structs must have semantics that remain correct even if the struct suddenly changes the memory address it resides in. The specs + DIP 1014 say that the above is true, or the struct must supply an opPostMove that fixes the semantics post-move. In both cases, *when* the move takes place is irrelevant. Or is it enough to define what a "move" is ? (didn't check but I guess the DIP already explains that) Only implicitly. (D's "move" is different from C++'s right? Yes. D's move after exiting a struct's constructor doesn't lead to a destructor call, but D's std.algorithm.mutation.move _does_ call the destructor of the moved source object.) Depends on which version of move you're referring to. For example, moveEmplace does not. I think the correct way to phrase this is to say that D's move *never* calls a destructor, but if the move's destination had a valid object in it, that one gets destructed. In a way, C++'s move is the same, except the actual moving of the data from the source location to the destination one is up to the programmer, and accordingly, so is destructing. Since, logically, a C++ move operator always copies, it also has to destruct the source. Technically, however, it doesn't always. A move assignment operator typically just swaps the content of the structs (i.e. - moves the source to the destination and the destination to the source), and lets the usual rvalue elimination code destruct it. Shachar
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 07:09:21 UTC, Timoses wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Typos "D programming lagnauge" (looks a bit french) : D "accept yor offer." Thanks for corrections. Great! Wish I was a student still : D. Me too ! Kidding aside, if you would be interested in a job programming mostly or partly in D please see our website. Lots of roles we haven't yet had time to post.
Re: Call method with Variant array as parameters
On Saturday, 14 July 2018 at 11:37:20 UTC, Timoses wrote:
On Saturday, 14 July 2018 at 11:08:21
How about this?
import std.variant: Variant;
import std.traits : isCallable;
class Foo
{
void bar(string s, long l)
{
import std.stdio : writeln;
writeln(s); writeln(l);
}
}
void call(T)(T fun, in Variant[] args)
if (isCallable!fun)
{
import std.traits : Parameters;
alias Params = Parameters!fun;
Params params;
static foreach(i, param; params)
{
if (auto p = args[i].peek!(Params[i]))
{
param = *p;
}
// perhaps create a warning if peeking was
unsuccessful...
}
fun(params);
}
unittest
{
Foo foo = new Foo();
Variant[] args = [Variant("Hello"), Variant(42L)];
call(, args);
}
Thank you so much!
Kind regards
Andre
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 07:30:26 UTC, Joakim wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ "join us" for "submit an application" -> apply (confusing otherwise) Maybe sum up and make clear that each student can earn between $3000-4000, instead of capped at $1k. Why limit it to students? If the goal is to have a youth injection, just use an age limit- say 18-25- I see no reason for the stupid college bias. Hi Joakim. Thanks for suggestions. I don't know what legal aspects there are relating to targeting age in different countries. We are definitely targeting people earlier in their careers. I agree with you that talent isn't only found amongst students, and I've in the past hired someone that didn't even finish high school and has gone on to do good work for the D community. So as far as Symmetry goes we are very open to unusual talent. A degree is just one piece of interesting information. https://symmetryinvestments.com/careers/ There's quite a lot of work involved in organising something like this, and I'm very grateful to the D Foundation for doing such an excellent job. We can refine this for next year, but I wanted to make a start. Laeeth
Re: DIP 1014--Hooking D's struct move semantics--Final Review
On Thursday, 12 July 2018 at 10:22:33 UTC, Shachar Shemesh wrote:
On 11/07/18 20:04, Johan Engelen wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready
for final review.
after quick read:
(would be much easier to do inline commenting, but it appears
that's not supported)
### Section "Code emitted by the compiler on move"
Dangerous to talk about what "code is emitted" by the
compiler. I think this DIP doesn't need that, and semantics is
enough. "the compiler MUST call " should be reworded, because
an _actual_ call to the function should not be mandatory,
because it would limit the optimizer in eliding it or inlining
it (note that it will be hard to _prevent_ the optimizer from
eliding/inlining the call as currently specified by the DIP).
I don't draw the same conclusions from the text as you.
I'm perfectly fine with specifying that nothing here is
mandatory if the compiler ensures that *the end effect* is as
if it happened.
AFAIK, C++ has a standing order to that effect, and it greatly
simplifies documenting what you want to do.
First off: I am trying to wear a strict language lawyer hat. D
spec is already very much ill specced which is _very_ problematic
for language and compiler development. I am not attacking the
proposal in order to kill it. I am merely commenting on points
that I feel should be improved.
My point was to remove things like "compiler" and "emitted code"
from the DIP / spec. In this case, the simple rewording can be:
"When moving a struct's instance, an implicit call to
__move_post_blt is inserted with both new and old instances'
addresses as arguments."
### "__move_post_blt SHOULD be defined in a manner that is
compatible"
What does "compatible" mean?
"Has the same effect as".
It's a little as if you're complaining about something not
being explicit in one section, and again about that same thing
being explicit in the next. Precisely why such standing order
would be a good idea.
Being explicit about generated machine is not good in a language
spec. Being explicit about the semantic meaning of something
_is_. ;-)
"compatible" is very vague. It may mean that just the function
signature should match.
"has the same semantic effect" would be a much better description
of what you want.
Some things should be made more explicit, such as the order of
calls for compound structs.
I don't think it makes sense to specify the order, except to
say that member's opPostMove must be called before the
instance's opPostMove (which the code already says).
OK, so make _that_ explicit. I think there is value in
prescribing the precise order of moves (like for construction of
members), such that reasoning about code becomes easier.
If you want the same semantic effect (as I wrote above), then the
text should say that the ordering is relaxed.
Why "SHOULD" and not "MUST"?
Precisely for the reason you stated above. So that if you want
to do something else, you may.
Why is that freedom needed? The freedom is already provided by
user-defined opPostMove? I think the implicit call to
__move_post_blt is a MUST, like calls to dtors.
### "This MUST return true iff a struct or any of its members
have an opPostMove defined."
Doesn't cover struct A containing struct B containing struct C
with opPostMove. Reword e.g. into: "hasElaborateMove!S MUST
return true iff `S` has an `opPostMove` defined or if
hasElaborateMove!X is true for any member of S of type X.
Yes, I'm sorry. I worded the spec for humans.
Please don't ;-)
I can suggest a recursive definition:
hasElaborateMove for a struct MUST return true iff at least one
of the following is true:
* The struct has opPostMove defined
* hasElaborateMove returns true for at least one of the
struct's members.
Great.
### What is lacking is a clear list of exactly in which cases
`opPostMove` will be called (needed for user-facing
documentation of the function).
I don't think I understand this point. Can you suggest what
that list might contain?
I think the language spec doesn't say when a "move" is performed?
So I don't know when exactly the opPostMove is called. Things
that come to mind:
* exiting from struct ctor
* std.algorithm.mutation.move
Or is it enough to define what a "move" is ? (didn't check but I
guess the DIP already explains that)
(D's "move" is different from C++'s right? D's move after exiting
a struct's constructor doesn't lead to a destructor call, but D's
std.algorithm.mutation.move _does_ call the destructor of the
moved source object.)
I now realize that the DIP is a mix between language semantic
changes (opPostMove) and implementation suggestions/details
("__move_post_blt"). I think it would have been clearer to split
the two in the DIP (it's valuable to have implementation
suggestions in addition to spec changes), but by now that's too
late. Part of my comments
[Issue 19083] make target doc compile error: mach_header conflicts with other
https://issues.dlang.org/show_bug.cgi?id=19083 Seb changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment #1 from Seb --- Have you tried building the docs from dlang.org? The individual doc targets have been deprecated for a very long time already. --
[Issue 19082] Cannot inline "...Slides.numberOfFullFrames", "...Slides.gap"
https://issues.dlang.org/show_bug.cgi?id=19082 Seb changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment #1 from Seb --- We would need a minimal reproducible example to help you :/ --
Re: Copy Constructor DIP
On 14/07/2018 11:49 PM, Johan Engelen wrote: On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote: I now deeply regret ever telling Razvan to mention future possible directions. This DIP must do implicit copy constructors and do it well, nothing less and nothing more. Strongly agree with this. In my review on Github I had a few sentences about this, but I removed them because I thought it may be perceived wrong. I find it almost completely irrelevant to add a "future directions" discussion to a DIP. If a DIP is incomplete, then finish it. Other than that, a DIP should stand completely on its own, regardless of speculation on future directions. -Johan Really any mention of the "future" in a DIP section wise, should be fairly concrete. I.e. this is already a good design, BUT it may come to pass that this use case is indeed important to support (an acknowledgement to its existence) so here is an idea on how to support it. It doesn't need to be entirely thought out, it just needs to be pretty well thought out and with clear added complexity as to why it isn't part of the original DIP. The example I'll use is my named arguments DIP[0], where I show a feature that could be added to allow renaming of args. However, because I'm unconvinced that such a complex feature is even needed, I don't support it. [0] https://github.com/rikkimax/DIPs/blob/named_args/DIPs/DIP1xxx-RC.md#future-proposals
Re: Copy Constructor DIP
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote: I now deeply regret ever telling Razvan to mention future possible directions. This DIP must do implicit copy constructors and do it well, nothing less and nothing more. Strongly agree with this. In my review on Github I had a few sentences about this, but I removed them because I thought it may be perceived wrong. I find it almost completely irrelevant to add a "future directions" discussion to a DIP. If a DIP is incomplete, then finish it. Other than that, a DIP should stand completely on its own, regardless of speculation on future directions. -Johan
Re: Call method with Variant array as parameters
On Saturday, 14 July 2018 at 11:08:21 UTC, Andre Pany wrote:
Hi,
I have a class with methods and I want to call a method by
using a variant array.
The length of the array and the types exactly fits the method
signature.
In the last line of main you see the coding which should be
generated.
I need some coding which looks at the signature of bar and uses
this information
to create "(args[0].get!string, args[1].get!long)".
I think it is possible with string mixins, but is there some
better way?
Maybe a staticMap?
class Foo
{
void bar(string s, long l) {}
}
void main()
{
import std.variant: Variant;
Foo foo = new Foo();
Variant[] args = [Variant("Hello"), Variant(42)];
__traits(getMember, foo, "bar")(args[0].get!string,
args[1].get!long);
}
Kind regards
André
How about this?
import std.variant: Variant;
import std.traits : isCallable;
class Foo
{
void bar(string s, long l)
{
import std.stdio : writeln;
writeln(s); writeln(l);
}
}
void call(T)(T fun, in Variant[] args)
if (isCallable!fun)
{
import std.traits : Parameters;
alias Params = Parameters!fun;
Params params;
static foreach(i, param; params)
{
if (auto p = args[i].peek!(Params[i]))
{
param = *p;
}
// perhaps create a warning if peeking was unsuccessful...
}
fun(params);
}
unittest
{
Foo foo = new Foo();
Variant[] args = [Variant("Hello"), Variant(42L)];
call(, args);
}
[Issue 19087] New: `final switch` cannot be used in -betterC
https://issues.dlang.org/show_bug.cgi?id=19087
Issue ID: 19087
Summary: `final switch` cannot be used in -betterC
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: slavo5...@yahoo.com
void test(int p)
{
final switch (p)
{
case 42:
break;
}
}
void main()
{
test(0);
}
dmd -betterC test.d
/dlang/dmd/linux/bin64/../../src/druntime/import/core/exception.d(584): Error:
Cannot use throw statements with -betterC
/dlang/dmd/linux/bin64/../../src/druntime/import/object.d(4180): Error:
template instance `core.exception.__switch_errorT!()` error instantiating
This is caused by a `throw` statement in the implementation of
`__switch_errorT` in druntime. It should probably be an `assert`.
--
Call method with Variant array as parameters
Hi,
I have a class with methods and I want to call a method by using
a variant array.
The length of the array and the types exactly fits the method
signature.
In the last line of main you see the coding which should be
generated.
I need some coding which looks at the signature of bar and uses
this information
to create "(args[0].get!string, args[1].get!long)".
I think it is possible with string mixins, but is there some
better way?
Maybe a staticMap?
class Foo
{
void bar(string s, long l) {}
}
void main()
{
import std.variant: Variant;
Foo foo = new Foo();
Variant[] args = [Variant("Hello"), Variant(42)];
__traits(getMember, foo, "bar")(args[0].get!string,
args[1].get!long);
}
Kind regards
André
Re: Copy Constructor DIP
On 7/14/18 5:03 AM, Luís Marques wrote: If there is "no other meaning of @implicit" (other than the intersection of those two properties) why don't you just call it something like @copyctor? I'm totally cool with giving the attribute a more obscure name such as @copyctor or anything people want really. (What follows is a personal opinion. I think it's better to choose a more general attribute name with reduced initial applicability. Then application of said attribute can be extended to other functions with ease. In contrast, an obscure attribute name is sure to be followed by more obscure attribute names. And don't get me started about inventing new syntax. Regarding the hand-wringing over generality: we have an exceedingly poor record of paralysis of analysis, whereby we'd worry that every design decision potentially locks us out from all other as-of-yet-unchosen design decisions. If history is any indication, this sudden worry about vaguely-promising green pastures of the future is a sign of malady. We want copy construction. Conflating this with a very general schemata for implicit conversion would not be a wise decision in my opinion. I now deeply regret ever telling Razvan to mention future possible directions. This DIP must do implicit copy constructors and do it well, nothing less and nothing more.) Andrei
Re: how to compile D programs without console window
On Saturday, 14 July 2018 at 09:39:21 UTC, rikki cattermole wrote: If you're using dub, throw them into lflags and remove the -L. https://forum.dlang.org/post/gmcsxgfsfnwllploo...@forum.dlang.org hmm, for some unknown reason it says that it is unable to find SUBSYSTEM:windows.lib
Re: how to compile D programs without console window
On 14/07/2018 9:32 PM, Flaze07 wrote: how do you compile a D programs without a console window ? I found this link https://wiki.dlang.org/D_for_Win32 I know that you need .def file, but how do you link to .def ? WinAPI: FreeConsole(); Optlink linker (default for 32bit): -L/SUBSYSTEM:windows MSVC linker: -L/SUBSYSTEM:windows -L/ENTRY:mainCRTStartup If you're using dub, throw them into lflags and remove the -L. https://forum.dlang.org/post/gmcsxgfsfnwllploo...@forum.dlang.org
how to compile D programs without console window
how do you compile a D programs without a console window ? I found this link https://wiki.dlang.org/D_for_Win32 I know that you need .def file, but how do you link to .def ?
Re: Copy Constructor DIP
On Sat., 14 Jul. 2018, 2:00 am rikki cattermole via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On 14/07/2018 1:04 PM, Manu wrote: > > Determining that requires at least a cursory exploration. > > Given how many of us are objecting to the syntax, I'm going to place > this requirement upon a 'yes' answer by me. That an attempt is made for > an alternative syntax discussion. It's a fair request I think. > I just want to reiterate again, I'm not seeking alternative syntax, I just want to know that proposed syntax can work broadly, or if there are any challenges or problems that would restrict it from broad application. >
Re: Copy Constructor DIP
On Saturday, 14 July 2018 at 00:41:37 UTC, Andrei Alexandrescu
wrote:
The specification of @implicit is in the DIP in full: a
constructor that takes by reference a qualified typeof(this)
and has the @implicit attribute will be callable implicitly by
the compiler. There is no other meaning of @implicit. That
completes the spec of @implicit.
That is the problem: you are using a very generic name
("implicit") to signify both:
1) something very general ("will be callable implicitly by the
compiler") and
2) something very specific ("a constructor that takes by
reference a qualified typeof(this)")
If there is "no other meaning of @implicit" (other than the
intersection of those two properties) why don't you just call it
something like @copyctor?
On the other hand, if the name is chosen with the hope that the
meaning will be generalized in the future ("callable implicitly
by the compiler"), why don't you want to at least briefly discuss
that more general meaning?
What happens if you later conclude that a generic "callable
implicitly by the compiler" annotation has semantics that don't
quite align with those of this ctor annotation? Do you need to
introduce @implicitconv?
Surely we want the language constructs to be composable and
generalizable, and not just quirky one offs that you have to
memorize. This seems like a missed opportunity to make sure of
that.
Re: Copy Constructor DIP
On 14/07/2018 1:04 PM, Manu wrote: Determining that requires at least a cursory exploration. Given how many of us are objecting to the syntax, I'm going to place this requirement upon a 'yes' answer by me. That an attempt is made for an alternative syntax discussion. It's a fair request I think.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ "join us" for "submit an application" -> apply (confusing otherwise) Maybe sum up and make clear that each student can earn between $3000-4000, instead of capped at $1k. Why limit it to students? If the goal is to have a youth injection, just use an age limit- say 18-25- I see no reason for the stupid college bias.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Great! Wish I was a student still : D. Typos "D programming lagnauge" (looks a bit french) : D "accept yor offer."
Re: Weird bugs in DMD 2.81.0
On Saturday, 14 July 2018 at 01:27:03 UTC, solidstate1991 wrote: On Saturday, 14 July 2018 at 00:58:08 UTC, solidstate1991 wrote: I found a temporary workaround. Basically I just save the content of the AA, then reapply it after the application's constructor finished, before that it always generated an exception when I tried to check its content e.g. via printing it to the screen. The program still crashes when I close it, and it seems like it's something GC related, which will be extremely hard to reproduce. I'm going to make a commit soon to Github (maybe even an alpha release), so people can check it out for themselves. The AA issue still happens when I disable the GC. What happens if I accidentally write into the memory space of an AA? Might be a pointer-overflow related issue I messed up, which will be a hell of a ride to find. Any chance you can make a minimal, reproducible example of this? Would be great because then it can be put on bugzilla and other people can have a look at it too.
Re: @safe - why does this compile?
On Friday, 13 July 2018 at 22:17:59 UTC, Dukc wrote: On Friday, 13 July 2018 at 13:52:27 UTC, Timoses wrote: I suppose this is another good example of how casting can be dangerous? E.g. also: immutable int i = 3; int* j = cast(int*) assert(i == 3); *j = 4; assert(j == ); // data occupies same address space assert(i == 3 && *j == 4); // yet the values differ No, casting classes to their subclasses is not dangerous to program integrity, because it is checked. It is just a regular bug that terminates the program when encountered. But casting away immutable can break program integrity as your example demonstrates. For that reason the compiler won't let you do that if you wrap that code in @safe, unlike the class cast. Thanks for the explanation. Only read the function safety chapter in depth after posting this : D. Still, is `cast`ing seen as something "dangerous" or as something that should only be done as a last resort? Should std.conv : to be prioritized?
Re: Orange not working?
On Friday, 13 July 2018 at 21:38:18 UTC, JN wrote: I'm curious, are the tests in any way OS specific? I see the tests are passing, but trying the latest DMD on Windows and orange v2.0.0, when I add "@nonSerialized" to a struct member, I get this: C:\Users\jacek\Desktop\test_orange>dub run Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86. orange 2.0.0: target for configuration "" is up to date. test_orange ~master: building configuration "application"... ..\..\AppData\Local\dub\packages\orange-2.0.0\orange\orange\serialization\Serializer.d(1504,13): Warning: statement is not reachable ..\..\AppData\Local\dub\packages\orange-2.0.0\orange\orange\serialization\Serializer.d(1510,17): Warning: statement is not reachable ..\..\AppData\Local\dub\packages\orange-2.0.0\orange\orange\serialization\Serializer.d(1512,13): Warning: statement is not reachable ..\..\AppData\Local\dub\packages\orange-2.0.0\orange\orange\serialization\Serializer.d(1514,13): Warning: statement is not reachable C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. Wasn't aware of the `buildRequirements "silenceWarnings"` switch in dub.sdl. Now there should hopefully be no more warnings with below PR. https://github.com/jacob-carlborg/orange/pull/51 Could perhaps bump it to 2.0.1 ? @Jacob
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ Reddit: https://www.reddit.com/r/programming/comments/8yram3/symmetry_autumn_of_code/
Re: Guido van Rossum has resigned
On 07/12/2018 05:16 PM, Walter Bright wrote: as Python's BDFL. https://mail.python.org/pipermail/python-committers/2018-July/005664.html Interesting. My takeaway after reading his post: Despite his obvious and understandable frustration, it must be immensely satisfying to create a tool, and build it up to the point where you can release it back into to its own ecosystem for its own continued future. I may not be a Python fan, but seriously - kudos to Guido!
Symmetry Autumn of Code
Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/
