Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Monday, 11 December 2023 at 08:24:55 UTC, Bastiaan Veelo wrote: On Sunday, 10 December 2023 at 22:59:06 UTC, Nicholas Wilson wrote: Or you could use grep with `--output-ll` as noted by Johan https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied. Thanks for highlighting this, as I must have forgotten. I should be able to create a CI job that checks this as part of the release. This will give us the confidence that we need. I should note that regex will need some updating for the most recent LLVMs that have opaque pointers enabled: `ptr byval\(%[a-zA-Z_][a-zA-Z0-9_\.]*\) align`
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Monday, 11 December 2023 at 08:24:55 UTC, Bastiaan Veelo wrote: On Sunday, 10 December 2023 at 22:59:06 UTC, Nicholas Wilson wrote: Always happy to help if you're interested in looking into using dcompute. Thank you, I'll let you know! And please do get in touch with Bruce Carneal if you want some tips and insight with the practical and applied side of dcompute (also with auto-vectorisation) as he has used it a lot more than I have. Or you could use grep with `--output-ll` as noted by Johan https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied. Thanks for highlighting this, as I must have forgotten. I should be able to create a CI job that checks this as part of the release. This will give us the confidence that we need. -- Bastiaan. Cheers, I look forward to some large speed increase reports.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 16:08:45 UTC, Bastiaan Veelo wrote: On Sunday, 10 December 2023 at 15:31:55 UTC, Richard (Rikki) Andrew Cattermole wrote: It will be interesting to hear how dcompute will fare in your situation, due to it being D code it should be an incremental improvement once you're ready to move to D fully. Yes, dcompute could mean another leap forward. There are so many great things to look forward to. -- Bastiaan. Always happy to help if you're interested in looking into using dcompute. I can't remember if we've talked about it before, but if you were wanting to use it you'd need OpenCL 2.x (explicitly the 2.x version series, or make sure the 3.x implementation supports SPIRV) running on that 20 logical core box (or if it has GPUs attached to it, CUDA (any version should do) for NVidia GPUs or OpenCL 2.x (as above) on any other GPUs). With regards to the stack corruption there is https://github.com/ldc-developers/ldc/blob/master/gen/abi/x86.cpp#L260 which has been there for some time. It would be fairly simple to issue a diagnostic there (although getting source location from there might be a bit tricky) for when there is both a `byval` and an alignment specified. Or you could use grep with `--output-ll` as noted by Johan https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: ## Editions We had agreed in [the September monthly meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywm...@forum.dlang.org) the week before that we need to define what editions will look like before we start deciding which features should go in any given edition. Good My goal with this session was to establish the first point on the timeline: a deadline for the editions proposal. I also thought it would be a good opportunity for all of us to clarify what editions are (there were some different ideas about that) and discuss aspects of the concept we need to consider. Here are some points that came out of the discussion. * Editions are essentially feature sets. Each edition can add/remove/deprecate features. * Editions are entirely opt-in and only affect the source you explicitly apply them to, i.e., they are not transitive to dependencies. (see note below about packages) * Editions will most likely be implemented via an attribute on the module declaration. We haven't discussed any details about that, but for now, just imagine something like `@edition(2024) module foo;`. There are an awful lot of `version`s set by things that should be part of editions, but exactly how this is supposed to be implemented can be hashed out later. They should also be ideally settable via a (say) an attribute, on the module declaration of a package and have that apply to the whole package. That way we limit a whole lot of redundant configuration. * Features cannot be opted into individually. When you apply an edition to a module, you get the whole thing. Well that's DoA then. Why bother to implement feature sets if you can't select them? This is a particular problem from incompatible sets of features, which D has a not insignificant amount of ( betterC, basically all of the -preview flags), including things that affect safety/codegen like `-boundscheck`, `-check`, `-checkaction`, `-cov`. Selectable features would solve the problem of "a dependancy uses an option I don't want to enable" Implementing default combinations of features (editions) on top of selectable features would be reasonable. * The default edition, meaning the code you have now, should compile forever. I hope you mean "we will keep around old editions as (potentially command line) selectable options and we can update the default to be the current" * We should have a tool that automates as much as possible the migration of modules to new editions * DMD-as-a-library is a critical component for that tool and other tools in the ecosystem. We need to put a priority on working out all the implementation issues Razvan has raised. * Given that much of the D community uses code-d, we need to bring Jan Jurzitza into any discussions about DMD-as-a-library. Yes, yes, yes.
Re: A New Era for the D Community
On Wednesday, 3 May 2023 at 11:13:34 UTC, Mike Parker wrote: Yes, there have been improvements over the past few years. The quarterly DLF meetings with industry representatives, initially proposed by Nicholas Wilson, have been productive. From memory that was merely an AGM at DConf, but sure, I'll take credit for that (despite knowing next to nothing about management)!
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote: __Resolving disagreements__ Well that's disappointing. I guess DMD will just continue to bleed contributors whenever Walter decides to do something that the entire contributor base that is a very bad idea.
Re: OpenBSD DMD package
On Monday, 11 October 2021 at 15:07:59 UTC, Brian wrote: Hi all -- I am in the process of getting a DMD package shipped in the OpenBSD package repository. If you are an OpenBSD user, please test and report back (on the OpenBSD mailing list, please) how it went for you. The more users test, the faster I can commit the package :) ~Brian https://marc.info/?l=openbsd-ports=163396364901247=2 Cool, do you know anything about setting up OpenBSD CI pipelines for DMD/druntime/phobos so we don't break that accidentally?
Dcompute on OpenGL / HLSL compute
I'm happy to announce that I've managed to generate OpenGL compute shaders from the OpenCL compilation pipeline. Through the use of https://github.com/KhronosGroup/SPIRV-Cross the means that we can generate GLSL, HLSL and MSL source The setup and compilation steps is very janky at the moment but does produce legit looking GLSL/HLSL. I say looks, because I lack the means to run it at the moment. This will hopefully become less janky in the future. To produce a compute shader source you will need: ldc built with https://github.com/KhronosGroup/SPIRV-LLVM-Translator as with the regular means of producing OpenCL SPIR-V, https://github.com/google/clspv/ with https://github.com/google/clspv/pull/764 applied to convert the OpenCL SPIR-V to OpenGL compute SPIR-V and https://github.com/KhronosGroup/SPIRV-Cross to convert the resulting GL compute SPIR-V to HLSL/MSL if desired. The full compilation steps are then (I did say it was janky): ``` ldc2 --mdcompute-targets=ocl-200 -m32 ./kernel.d other_files.d -Iother_imports llvm-spirv -r kernels_ocl200_32.spv llvm-dis kernels_ocl200_32.bc clspv -x=ir kernels_ocl200_32.ll # and optionally spirv-cross --hlsl a.spv --output a.hlsl ``` 32-bit mode for ldc is required because only 32-bit OpenCL SPIR-V can be converted into OpenGL compute SPIR-V. If `-m32` doesn't work the you may have to supply an equivalent `-mtriple`
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:45:06 UTC, Rainer Schuetze wrote: On 27/02/2020 01:20, Walter Bright wrote: On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote: In all other languages with string interpolation that I'm familiar with, `a` is not passed to the `i` parameter. All rely on a garbage collected string being generated as an intermediate variable. The string buffer could also be stack allocated or manually managed with malloc/free by the string interpolation type. Don't forget LDC does GC to stack optimisations. There ought to be no need to do anything manually if you care about perf.
Re: Symmetry Autumn of Code 2019
On Monday, 1 July 2019 at 09:24:31 UTC, Mike Parker wrote: The D Language Foundation is partnering with Symmetry Investments for the second Symmetry Autumn of Code. I've written up a blog post about it [1] and updated the SAoC page [2] with the new details. Potential mentors, please be sure to contact me or announce your availability in the forums. We want to increase the odds that each applicant has a mentor lined up when they submit their application. Mentors are also getting paid this time around. I haven't shared this on reddit yet. I plan to do so later this week, so please refrain from sharing on /r/programming just yet. [1] https://dlang.org/blog/2019/07/01/get-ready-for-symmetry-autumn-of-code-2019/ [2] https://dlang.org/blog/symmetry-autumn-of-code/ Awesome! Please see also https://github.com/dlang/projects/issues/47 for the dlang/projects tracker and meta issue for all things related to SAoC projects.
dflat - v0.1
After getting waylaid by jet lag, family, health, and debugging,
I'm happy to finally announce v0.1 of dflat, a wrapping
application/library for .net dlls (e.g C#) to generate the
boilerplate needed to drive the CoreCLR (cross platform .Net
implementation).
This release features:
* cross platform support by using Mono.Cecil
* the ability to call instance methods on classes
* simplified API - no need to use classes with auto-implement
The code is still very early (and liable to break) but it should
be useable:
```c#
public class Class1
{
int a;
public Class1(int aa) { a = aa; }
public void foo() { a = 42; }
public override string ToString() { return a.ToString(); }
}
```
```d
auto a = Class1.make(314);
a.toString().fromStringz.writeln; // 314
a.foo();
a.toString().fromStringz.writeln; // 42
a.unpin(); // Objects created with make need their c# GC
references unpinned manually to avoid leaking
```
It probably easiest to build it with `dub test --
/path/tocsharpcompiler/ /path/to/cecil/bin/
/path/to/derelict-util/source [dmd|ldc2...]`, until I figure out
how to teach dub to compile c# and generate the deps.json and
runtimeconfig.json
Please don't hesitate to file bug reports or feature requests!
This work has been sponsored by Symmetry Investments.
https://github.com/thewilsonator/dflat/
https://github.com/thewilsonator/dflat/releases/tag/v0.1-alpha1
(best to use master though)
Re: Beta 2.087.0
On Sunday, 16 June 2019 at 22:47:57 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.087.0 release, ♥ to the 66 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.087.0.html As usual please report any bugs at https://issues.dlang.org -Martin Quite a few duplicate contributors: Aurelien Fredouelle Aurélien Fredouelle Ben Merritt Benjamin L. Merritt kinke Martin Kinkelin shove shove70
Re: DIP 1013--The Deprecation Process--Formal Assessment
On Wednesday, 12 June 2019 at 11:40:27 UTC, Jonathan M Davis wrote: On Wednesday, June 12, 2019 2:47:23 AM MDT Nicholas Wilson via Digitalmars- d-announce wrote: On Monday, 10 June 2019 at 13:49:27 UTC, Mike Parker wrote: > DIP 1013, "The Deprecation Process", has been accepted. > ... > https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1013.md So what is the "version" in @@@DEPRECATED_[version]@@@ supposed to be? That still seems to be ambiguous. How is it ambiguous? It says right in the same sentence that @@@DEPRECATED_[version]@@@ is mentioned. - Jonathan M Davis Wow. Note to self, don't read post and sleep all at the same time.
Re: DIP 1013--The Deprecation Process--Formal Assessment
On Monday, 10 June 2019 at 13:49:27 UTC, Mike Parker wrote: DIP 1013, "The Deprecation Process", has been accepted. ... https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1013.md So what is the "version" in @@@DEPRECATED_[version]@@@ supposed to be? That still seems to be ambiguous.
Re: Variant Graph Support to BioD
On Tuesday, 28 May 2019 at 09:41:18 UTC, Njagi Mwaniki wrote: Hello I’m Njagi Mwaniki, I am part of the 2019 Google Summer of Code under the Open Bioinformatics Foundation with a project aimed to add variation graph support to BioD under mentors George Githinji and Pjotr Prins. Awsome! can you supply some links please?
Re: Phobos is now compiled with -preview=dip1000
On Thursday, 16 May 2019 at 01:05:53 UTC, H. S. Teoh wrote:
Gah, so apparently .hashOf is a gigantic overload set of *21*
different overloads, so this is not really "truly" reduced. =-O
Anybody up for figuring out which overload(s) is/are getting
called?
https://github.com/dlang/druntime/blob/master/src/core/internal/hash.d#L393
static if (hasCallableToHash!(typeof(val))){ ... } // false
else
{
static if (__traits(hasMember, T, "toHash") &&
is(typeof(T.toHash) == function)) { ... } // false
else static if (T.tupleof.length == 0) { ... } // false
else static if ((is(T == struct) && !canBitwiseHash!T) ||
T.tupleof.length == 1)//true
{
static foreach (i, F; typeof(val.tupleof))
{
static if (__traits(isStaticArray, F)) { ... } //
false
else static if (is(F == struct) || is(F == union)) {
... } // false
else
{
// Nothing special happening.
static if (i == 0 && !isChained)
size_t h = hashOf(val.tupleof[i]);
else
h = hashOf(val.tupleof[i], h);
}
}
}
Betcha the problem is that -preview=dip1000 causes one of the
overloads to fail to compile, thus shuffling to a different
overload that isn't @safe. I hate SFINAE.
My money's on access to a private member through .tupleof.
Re: bool (was DConf 2019 AGM Livestream)
On Sunday, 12 May 2019 at 14:50:33 UTC, Andrei Alexandrescu wrote: On 5/12/19 1:34 PM, Nicholas Wilson wrote: However in this case the community consensus is that the chain of reasoning you have used to arrive at your decision is wrong. It's a simple enough matter to be understood, and reasonable to assume Walter is not missing any important facts or details. Poking holes in his explanations is, I confess, attractive, but ultimately are about debate skills rather than technical. I do agree that the way explanations on DIP decisions go could and should be improved a lot. Then let me rephrase my complaints as a question (to you, Walter and the community): At what level of egregiousness of the degree to which the unanimous community consensus believes both your decision and chain of reasoning are fundamentally wrong, do we, the community, decide to reject your position completely and implement the community consensus?
Re: bool (was DConf 2019 AGM Livestream)
On Sunday, 12 May 2019 at 10:58:49 UTC, Andrei Alexandrescu wrote: Rejected D Improvement Proposals on small matters that D language's leader thinks strongly about should allow everybody to move on to larger, better things. We are unable to, and should not be required to, provide argumentation when making a decision on a DIP that will be to the satisfaction of everybody involved. No no no, no. No. You have rejected the DIP to the annoyance of the community, That is fine. You have a decision making process. However in this case the community consensus is that the chain of reasoning you have used to arrive at your decision is wrong. Of course, pressure does exist on making the right decision and on framing it properly; Indeed, you should be making the right decisions _ for the right reasons_. I note that this is uncorrelated with wether or not we want the feature, c.f. refcounting before we had copy constructors (wanted it but couldn't have it because memory safety reasons) and opPostMove (didn't want to have to have it but e.g. couldn't interface with GCC's std::string). otherwise, one poor decision after another, we end up with a bad language that people will not want to use. Yes, but for the completely opposite reason. If the community believe the reasoning you provide for the decision you have made is wrong then we will end up with a language we not as satisfied with. [Because reasons] that all is wasted time. There's a bunch of big rocks to move. Jut because we have a bunch of other large problems does not mean that we shouldn't be fixing other problems in the language that you happen to disagree with.
Re: DDeps 1.1.1
On Saturday, 27 April 2019 at 16:16:02 UTC, lempiji wrote: Recently, I created a tool to create a module dependency graph for the D language. The tool can compare two versions and visualize the differences. I think it's useful for source reviews. Try it if you are interested. Some screenshots are included in the README. - DUB: http://code.dlang.org/packages/ddeps - GitHub: https://github.com/lempiji/ddeps Very nice! Does this respect versions? E.g. to separate unit tests importing everything else, from library code being relatively modular. This will be useful for modularising DMD.
Re: New and Unofficial OpenCV binding for D programming language
On Friday, 5 April 2019 at 15:52:42 UTC, Paolo Invernizzi wrote: Until we have copy ctors, D can't have structures with internal pointers, as they can be moved... that's something similar in C++ string, if I remember well, and that was the blocker that leaded to the copy ctors DIP... That lead to the acceptance of DIP1014 (opPostMove) not 1018. Its a move problem not a copy problem.
Re: DIP 1018--The Copy Constructor--Formal Assessment
On Sunday, 17 March 2019 at 13:17:07 UTC, Mike Parker wrote: We're considering how to balance the different perspectives on how the DIP process should work, but if any changes do come, please don't expect them before DConf. Indeed thats (part of) what the AGM is for. Please turn up and have your say. Hope to see you all there!
Re: DIP 1000--Scoped Pointers--Superseded
On Monday, 11 March 2019 at 22:57:33 UTC, Olivier FAURE wrote: On Thursday, 7 March 2019 at 14:24:29 UTC, Mike Parker wrote: The implementation supersedes the DIP. I think the question a lot of people have in mind is "Is there any plan to formally organize a discussion about the future of scoped pointers?" More specifically, are you planning a new DIP discussing the semantics of scope and return scope, ideally one that would take into account previous feedback, address concerns that DIP-1000 had originally inspired, and include an analysis of the pros and cons of -dip1000's implementation, as reported by its current users? Less formally, what I mean is that a lot of people had concerns at the time DIP-1000 was discussed; many of these concerns (including mine) weren't really addressed, and Walter's reaction gave the impression that he didn't understand them, and as a result, considered them unimportant, which led to a lot of frustration (including, if I remember correctly, Dicebot stepping down as DIP manager) and a general break in communication between Walter and the community. So, considering how important scoped pointers are to the language (betterC, webasm, video games, C++ interop, competing with Rust), I think (and I realize this is a lot to ask) that this is an area where Walter needs to bite the bullet and make a sustained effort to interact with the community and address DIP-1000's problems, whether by starting another DIP or through some other mean. If nothing else, we should probably have a "Who here uses -dip1000, and does it work for you?" thread. There will be a section of the Dlang foundation meeting at Dconf about this. I'm not very happy about the state of documentation and specification of DIP1000 and even less happy about the way it has been handled, both initially and the subsequent updates. Anyway there will be plenty of high bandwidth time to discuss this then.
Re: DIP 1018--The Copy Constructor--Formal Review
On Tuesday, 26 February 2019 at 02:51:54 UTC, Andrei Alexandrescu wrote: On 2/25/19 7:23 PM, Nicholas Wilson wrote: I've said before that that comparison is weak and not particularly useful, irrespective of its intention. That you've said it before does not make it any more correct. You're right that is does't change the facts, thats why it is an opinion. The resemblance, if any, it bears to the processes you describe is completely beside the actual point: namely that it is not _useful_. There are differences, too, of which the public discussions in this forum is the main one. Yes, thats why I think the journal submission metaphor is not apt. This is in danger of getting abused; open discussions around DIPs in this forum give the false impression that DIP authors have the authority to demand any extent of explanation and justification of a decision. Quoting myself from above: On the contrary, if we believe your reasoning to be unsound or misguided (irrespective of who is at fault) then clarification and resolution are the only appropriate courses of action. If you believe that constitutes abuse, I really don't know what to say. We do not have the capacity to do that, and it would not be anymore appropriate than journal reviewers being required to provide detailed feedback to submitters' satisfaction. I sincerely hope you don't lack the capacity, else why are you reviewing it in the first place? Time or bandwidth, sure, thats what DConf Foundation meeting is for (among many other things). This whole notion of a meeting whereby Walter is grilled by a committee on why exactly he rejected DIP 1016 is Kafkaesque. Indeed, that would serve no purpose. What I want from such a meeting is: 1) an outline of requested changes that accurately reflects the sentiments of the DIP. I am fully aware the DIP underspecified and omitted some key aspects and that there were some ambiguities present. You have provided some in that link, thank you. Although I note that some of the advice is outdated/wrong. All this back and forth cements my growing suspicion that the forum is not an appropriate place for such discussions, it severely lacks bandwidth and reciprocal latency. 2) changes to the DIP process, i.e. what to do in the event of DIP breaking behaviour/ambiguities discovered post final review, so that these misunderstandings do not happen again. You can count on me to massage the bureaucracy out of the process if that's the bottleneck. Good, but this one is stuck until DConf, the forum (as a place of communication) lacks the bandwidth for this. The most significant bit is to focus on working together toward making the proposal better, as opposed to focusing on negotiating acceptance. YES! Thats what we've been trying to do! How ever, we can't do that if the criticisms do not reflect reality (lowering to statements, which was given as an example in the DIP and wrongly characterised in the formal assessment) and the ones that are legitimate criticisms are scattered about the forum. Hence why we want the official reasons for rejection at the bottom of the DIP to be updated to reflect that. But whether the DIP keeps the number or gets another one, if the revised document is a 95% cut and paste of the existing one, the review is liable to be a 95% cut and paste of the existing one. You, of all people, should know that a proposal is not a linear function of its text. I _sincerely_ hope that your reviews aren't.
Re: DIP 1018--The Copy Constructor--Formal Review
On Tuesday, 26 February 2019 at 00:23:19 UTC, Nicholas Wilson wrote: On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu wrote: * etc. etc. etc. That is a good start, though I suspect that the list is not complete given the last item. Oh, it keeps going.
Re: DIP 1018--The Copy Constructor--Formal Review
On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote: On 2/25/19 3:23 PM, Jacob Carlborg wrote: On 2019-02-25 20:24, Mike Parker wrote: From the process document: “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.” Having it documented doesn't make it less flawed. Jacob, are there amends you need to make to the DIP? This whole reply chain sounds more like the problems lie with the DIP process not this DIP, but I'll let Jacob answer that.
Re: DIP 1018--The Copy Constructor--Formal Review
On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu wrote: On 2/25/19 1:06 AM, Nicholas Wilson wrote: On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright wrote: Your DIP, and nobody else is going to do it, so it falls to me. It will be reviewed at Dconf, please make sure you have an _accurate_ summary of your criticisms of the DIP ready for then. This seems to be a misunderstanding of protocol. A negative review is simply a signal that the submission has not been strong enough. As such, the submission, not the review, needs to be improved. I'm not suggesting that the DIP is perfect, nor that it was without ambiguities and misunderstandings, nor that is can't/doesn't need to be improved. What _is_ important is that the time spent on improving it covered that areas that actually need improvement, and given the misunderstandings on all sides, a useful starting point is the set of problems the reviewers have identified crosschecked by the authors. That is not an unreasonable request. There are similarities and differences between our DIP process and paper submission reviews at conferences and journals everywhere; one key similarity is that the submitters are on hook for providing convincing submissions, whereas reviewers are not required to defend their reviews. It's an asymmetric relationship that occasionally frustrates, but it is as such for good reason and it works. I've said before that that comparison is weak and not particularly useful, irrespective of its intention. It is not a matter of misunderstanding 1-2 sentences, but a problem of precision in specification that needs to be approached with due care. I believe it is both, which is the basis for the opinion that resubmission is not the appropriate course of action to make best use of everyone's time. * Description of the typechecking process, with examples of code that passes and code that fails; * A clarification that lowering proceeds not against all expressions, but only against rvalues; * Several places in text in which it is explained that rvalues resulted from implicit conversions are not eligible; * etc. etc. etc. That is a good start, though I suspect that the list is not complete given the last item. It is not desirable to demand reviewers to do more work on the review or to defend it. On the contrary, if we believe your reasoning to be unsound or misguided (irrespective of who is at fault) then clarification and resolution are the only appropriate courses of action. Acceptance by bullying is unlikely to create good results. I agree, but that has not happened here. The target of work is squarely the proposal itself. Our understanding after Manu asked for action items was that he would be up for the work in short order. The keyword here is "short". By suggesting that the action required is to rewrite, the order is most definitely not short. Time is a valuable resource, and a new DIP from scratch through the DIP process takes a lot of it.
Re: DIP 1018--The Copy Constructor--Formal Review
On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright wrote: Your DIP, and nobody else is going to do it, so it falls to me. It will be reviewed at Dconf, please make sure you have an _accurate_ summary of your criticisms of the DIP ready for then. BTW, everyone should expect the DIP process to be brutal. No! It should be thorough, that is a critical distinction. It has to be, we're long past the stage where we can allow misshapen stuff to get into the language. Nobody was very kind with my bottom type DIP :-) Perhaps because you responded to _precisely none_ of the feedback and wasted everybody's time? You should read the dismissal of mine and Andrei's "static if" proposal for C++! (Ironically, it was later adopted after someone else redid it, after removing one of its keystone features.) I have, it is hysterical in all senses to the word. I don't see how that relates to any of this.
Re: DIP 1018--The Copy Constructor--Formal Review
On Sunday, 24 February 2019 at 21:22:33 UTC, Walter Bright wrote: On 2/24/2019 1:02 PM, Manu wrote: I mean like, my DIP was almost violently rejected, I thought it was clear what was needed to be done with it, and I thought you were going to rewrite it. Was I mistaken? Absolutely no, no. Yes! "What needs to be done" is scattered throughout forum discussions filled with incorrect assumptions, most of which were resolved needing little change, absolutely nothing that justifies a rewrite over minor amendments (the text will be 95% the same, the sentiment will be 100% the same), neither I nor Manu plan to rewrite it. Note that none of that is reflected in the official review, most (if not all) of which is wrong (and you should update it!). What is _actually_ going to happen is this will be an item on the agenda for the Foundation meeting at dconf: you will clarify the problems you have with the DIP; those problems will be discussed, evaluated and acted upon; and the DIP process will be amended to avoid the root cause of those problems.
Re: FakeD
On Tuesday, 19 February 2019 at 10:38:22 UTC, Robert Schadek
wrote:
FakeD [2,3] is a fake data generator with support for
localisation.
It is based on faker.js [1].
See [4] for a list of available methods.
void main() {
import std.stdio;
import faked;
auto f = new Faker(/*random seed */ 1337);
writeln(f.loremText());
writeln(f.addressCity());
writeln(f.nameName());
// localized to german
f = new Faker_de(/*random seed */ 1338);
writeln(f.loremText());
writeln(f.addressCity());
writeln(f.nameName());
}
[1] https://github.com/marak/Faker.js/
[2] https://code.dlang.org/packages/faked
[3] https://github.com/kaleidicassociates/faked
[4] https://kaleidicassociates.github.io/faked/
Faker_en_au_ocker
Strewth!
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 8 February 2019 at 16:00:58 UTC, bitwise wrote: On Monday, 4 February 2019 at 20:08:39 UTC, Paul Backus wrote: On Monday, 4 February 2019 at 18:35:37 UTC, bitwise wrote: [...] It's actually fine to leave the `return` there unconditionally--you're allowed to return an expression of type `void` from a function. Example: https://run.dlang.io/is/tnSGN4 Even better ;) No one else seems particularly excited about the rewrite though - what am I missing? I suppose a lambda cost significantly more, but I don't think the lambda should make it through the optimizer for this case though. Immediately called lamdas are always inlined.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 31 January 2019 at 02:10:05 UTC, Manu wrote: On Wed, Jan 30, 2019 at 1:05 PM Andrei Alexandrescu via fun(my_short); // implicit type conversions (ie, short->int promotion) Oh I see. fun(short(10)); // implicit type conversions (ie, short->int promotion) I did not intend for this DIP to apply to anything other than rvalues. I can totally see how that's not clear. `my_short` should be an rvalue of some form, like the rest. Is that the only such line? I think so. Presumably my_short is a variable of type short. Is that correct? It is not. It should be an rvalue like everything else. Perhaps it's an enum... but I should write `short(10)`, that would be clear. It would. * DIP 1016 proposes a hole in the language one could drive a truck through. I still can't see a truck-sized hole. * The problem goes undetected in community review. I don't know how I could have influenced this outcome. * Its own author seems to not have an understanding of what the DIP proposes. More classy comments. I can't get enough of the way you belittle people. I made a 1-word error, where I should have written `short(10)` to be clear. 1-word error feels amendment-worthy, and not a call for "let's start over from scratch". You should just PR it back to review with that fix and a note about how it lowers to statements (incl. an example of lambdification for if/while/for/switch statements (see https://forum.dlang.org/post/qysmnatmjquuhylaq...@forum.dlang.org ))
Re: DIP 1016 should use expression lowering, not statement lowering
On Thursday, 31 January 2019 at 02:29:47 UTC, Steven Schveighoffer wrote: I came up with this idea based on tempCString, but it doesn't work: So I don't get why it doesn't work. But if that was fixed, could be a potential workaround without requiring a DIP. Thats nice! But it doesn't fix the problem that in generic code you don't know without checking if you need to do that. Also the template bloat.
Re: DIP 1016 should use expression lowering, not statement lowering
On Tuesday, 29 January 2019 at 11:52:40 UTC, Andrei Alexandrescu
wrote:
While writing this example:
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
if (alloc.reallocate(a, 200 * int.sizeof))
{
assert(a.length == 200);
}
=>
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
void[] __temp0 = a;
if (alloc.reallocate(__temp0, 200 * int.sizeof)
{
assert(a.length == 200);
}
I noticed a problem - the lowering as informally described in
DIP 1016 makes it difficult to figure how function calls
present in control statements like if, while, etc. should
behave. Where should the temporary go? An expression-based
lowering clarifies everything. A statement-based lowering would
need to work on a case basis for all statements involving
expressions.
On the contrary, an expression lowering cannot inject temporary
declarations and is impossible.
The correct lowering in the case for `if` & friends follows the
form of C++ initialiser conditions(?) i.e:
if (auto val = expr(); val) { ... },
or the slightly more ugly valid D:
if ((){return expr(); }()) { ... }
this lambdification will work for just about anything: if, while,
assert...
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Tuesday, 29 January 2019 at 08:35:11 UTC, Manu wrote: 4. "Under DIP 1016, a call with any T[] will silently "succeed" by converting the slice to void[]" <-- Do you mean "... with any T[] rvalue ..."? What would be the aim of that call? Can you suggest a particularly sinister construction? I _think_ what is meant is: void[] allocate(size_t size); bool reallocate(ref void[] b, size_t s); void deallocate(ref void[]); T[] arr = allocate(42); arr.reallocate(8192); // reallocates a temporary as T[] is cast to void arr.deallocate(); // double free
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 25 January 2019 at 12:03:36 UTC, Nicholas Wilson wrote: On Friday, 25 January 2019 at 11:56:58 UTC, Walter Bright wrote: It should never have gotten this far without giving a precise explanation of how exception safety is achieved when faced with multiple parameters. The pot calling the kettle black. DIP1000? DIP1017? Or DIP1008: https://issues.dlang.org/show_bug.cgi?id=19463
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 25 January 2019 at 11:56:58 UTC, Walter Bright wrote: It should never have gotten this far without giving a precise explanation of how exception safety is achieved when faced with multiple parameters. The pot calling the kettle black. DIP1000? DIP1017? Again, all that requires is a minor revision. It is not DIP breaking.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 25 January 2019 at 07:33:02 UTC, Walter Bright wrote: No, it is not rejected in principle. Good. Finding serious errors in it on the eve of approval is disappointing, and is not auspicious for being in a hurry to approve it. Praytell, what serious errors? Also you should heed your own advice DIP1017 and send it back to draft. Rvalue references are not a simple problem (although they appear to be). Please, do enlighten us.. The statement thing is a "do what I meant, not what I wrote" example, _You_ removed the semicolons. The DIP applying to statements was at worst implied by their use, and frankly quite obvious, how else could they transcend multiple expressions? You're leaving him to design where the temporaries go, where the gates go, and ensure everything is properly exception safe. You could have at least had the decency to notify Manu. As noted elsewhere this problem is nowhere even close to DIP breaking, and I'm certain he could have resolved that.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 25 January 2019 at 07:02:47 UTC, Walter Bright wrote: On 1/24/2019 4:21 PM, Elie Morisse wrote: I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection. On the contrary. It is good to find conceptual errors before implementing it. You mean the conceptual errors you made when reviewing it? Like: That the conflation of pass by reference to avoid copying and mutation is not only deliberate but also mitigated by @disable. That the DIP applies to statements, not expressions. That the construction order issue is trivially fixable, by specifying the same behaviour as the non ref case modulo ref.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Friday, 25 January 2019 at 00:31:50 UTC, 12345swordy wrote: On Thursday, 24 January 2019 at 23:43:21 UTC, Walter Bright wrote: It's no problem if you want to rework the existing text, just submit it as a new DIP. And wait for another 180+ days for a fix? Come on dude, can you understand the frustration being display here? This will be discussed at DConf at the DLF meeting, which is only 75ish days, along with all other DIPs that are not yet implemented, under review (incl. draft) or recently rejected and a whole host of other topics, so that we can finally get some process direction and vision happening.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 23:59:30 UTC, Walter Bright wrote: On 1/24/2019 1:03 PM, kinke wrote: (bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true , f(__pfx, __pfy); There must be an individual gate for each of __pfx and pfy. With the rewrite above, if b() throws then _pfx won't be destructed. (All this rigamarole is part of why exception handling isn't free, even in the happy case.) Indeed, and thats why it should be have exactly the same as if there were no `ref` involved, except for the not copying stuff. Behaving and differently is, a) wrong and, b) going to cause a lot of confusion.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 21:03:29 UTC, kinke wrote: Describing this stuff in detail (rewritten expression?!), isn't trivial and requires knowledge about how calls and construction/destruction of argument expressions works. E.g., the f() call in the code above is lowered to (-vcg-ast): (bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true , f(__pfx, __pfy); Here, (only seemingly unused) temporary `__gate` is used to control the destruction of temporaries with dtors (here just the `__pfx` arg, as `__pfy` is a special case [no potentially throwing later argument expressions...]) at the caller side (false => destruct; true => skip destruction, as it has been moved successfully to the callee, which destructed it). The dtor expressions of these temporaries (e.g., `__gate || __pfx.~this()` for `__pfx`) aren't visible with `-vg-ast`. With this DIP, *all* rvalues passed by ref must be lowered to temporaries. In case they require destruction, the only difference wrt. the by-value case is that they are *always* destructed by the caller (after the call, or if an exception is thrown while they are in scope), i.e., their destruction isn't controlled by `__gate`. Exactly, doing something that could result in a different outcome would be a disaster.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote: On Thu, Jan 24, 2019 at 1:25 AM Nicholas Wilson via We discussed and concluded that one mechanism to mitigate this issue was already readily available, and it's just that 'out' gains a much greater sense of identity (which is actually a positive side-effect if you ask me!). You have a stronger motivation to use 'out' appropriately, because it can issue compile errors if you accidentally supply an rvalue. True I forgot about that. That doesn't address the specific `atomicIncrement` case here, but now we're in VERY niche territory; we analysed a lot of cases, and concluded that such cases were relatively few, and other choices exist to mitigate those cases. There are cases that want to do mutation to rvalues (like in pipeline functions), and then most cases can use 'out' instead. Remaining cases are quite hard to find, and in this particular case, I'd suggest that `atomicIncrement`, a very low-level implementation-detail function, should just receive a pointer. Probably. Oh well, I'll add this to the long list of things to make sure is covered at dconf by the foundation.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote: Walter and Andrei have declined to accept DIP 1016, "ref T accepts r-values", on the grounds that it has two fundamental flaws that would open holes in the language. They are not opposed to the feature in principle and suggested that a proposal that closes those holes and covers all the bases will have a higher chance of getting accepted. You can read a summary of the Formal Assessment at the bottom of the document: https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md [Reasons]. As such, they suggest that a new DIP be drafted from scratch, and that a stronger proposal would have a better chance of acceptance. Given the simplicity of the fixes for the problems identified I really don't think thats the best way forward. One round of forum review + formal reassessment ought to be enough.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
Walter and Andrei have declined to accept DIP 1016, "ref T
accepts r-values", on the grounds that it has two fundamental
flaws that would open holes in the language. They are not
opposed to the feature in principle and suggested that a
proposal that closes those holes and covers all the bases will
have a higher chance of getting accepted.
You can read a summary of the Formal Assessment at the bottom
of the document:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
The second problem is the use of := (which the DIP Author
defines as representing "the initial construction, and not a
copy operation as would be expected if this code were written
with an = expression"). This approach shows its deficiencies in
the multiple arguments case; if the first constructor throws an
exception, all remaining values will be destroyed in the void
state as they never have the chance to become initialized.
Although not specified by the DIP, I think this could be easily
remedied by saying that the order of construction is the same as
if the temporaries were not bound to ref, i.e.
---
struct A {~this();} struct B{ ~this();}
A a();
B b();
void f(A a, B b);
void g(ref A a, ref B b);
f(a(),b()); //(1)
g(a(),b()); //(2)
---
and a() or b() may throw (and are pure), that (1) and (2) exhibit
the same exception/destructor semantics.
Which is what I would expect to happen under no given
specification (although specifying it is a good idea!). To put it
another way, they should be constructed in place in the order
they are used, and given they are a temporary, they can only be
used once.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
Walter and Andrei have declined to accept DIP 1016, "ref T
accepts r-values", on the grounds that it has two fundamental
flaws that would open holes in the language. They are not
opposed to the feature in principle and suggested that a
proposal that closes those holes and covers all the bases will
have a higher chance of getting accepted.
You can read a summary of the Formal Assessment at the bottom
of the document:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
fun(10)
==>
{
T __temp0 = void;
fun(__temp0 := 10);
}
The first problem the Language Maintainers identified with this
approach is that the rewrite is from an expression to a
statement, rendering it invalid.
The expression should be rewritten as an expression to clarify
how it behaves in larger expressions.
But it does, or at least gives an example of:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md#function-calls-as-arguments
The statement the expression is part of is "enscoped" and the
temporaries live in the scope of that statement.
Re: My Meeting C++ Keynote video is now available
On Wednesday, 16 January 2019 at 05:32:51 UTC, Walter Bright
wrote:
On 1/15/2019 10:39 AM, Jacob Carlborg wrote:
Perhaps we shouldn't support user defined types or functions
either ;)
You deliberately wrote that, and I'm confident you'd never try
to pass that off as good work.
With macros, however, programmers are convinced they are
creating models of clarity. I've seen programmers truly believe:
#define BEGIN {
#define END }
improves their C code. Fortunately, that was ridiculed out of
existence in the 1980s, but the more subtle abuses persist with
their ardent defenders. I used to use a lot of macros in my C
code, and a few years back made an effort to remove them all
from the dmd source code. The result was very satisfactory.
I've seen entire code bases abandoned because of macros after
the original developer left.
I'm pretty sure Jacob is talking about a completely different
type of macro (i.e. not textual substitution), AST macros.
I'd be interested to see how close we could get if we allowed
mixin template to contain expression as well as declarations
(obviously these could only be instantiated in function
contexts). Anyway something to play around with at DConf.
Re: The New Fundraising Campaign
On Monday, 7 January 2019 at 13:35:31 UTC, H. S. Teoh wrote: [string mixins make] it hard to debug (esp. if the codegen isn't your own code) - (4) any compile errors are by necessity obscure because there isn't a concrete file and line number to refer to; to get to the locus of the problem further effort is required to extract the generated code string (after figuring out which string is the relevant one!) and then dereference the line number. This is no longer (as) true, try using -mixin=filename. It was made exactly for this sort of thing.
Re: DConf 2019: Shepherd's Pie Edition
On Tuesday, 25 December 2018 at 18:54:25 UTC, Joakim wrote: Simply repeating over and over again that you're not "convinced" is not an argument, nor do your own personal reasons above argue for one format over another. I don't mean to stoke the flames on this anymore, but I do: I've been to past conferences and now that I'm not a poor student anymore I'd pay to go to them. I happen to still have plenty of free time so watching pre-recorded talks, while not a problem for me a) does not apply to everyone and b) loses interactivity. I asked for a rationale above and got none from Mike and a very weak, confused one from Walter. It's fairly obvious that there was never any real deliberation on the DConf format, and that you guys have dug in and decided to cut off your nose to spite your face. I can't speak for other but the rationale or deliberation of not doing what you have suggested is the it has worked well in the past, and I see no reason for that to cease to be the case. Fine with me, your loss. On the contrary, I think it will (continue to be) a massive success. I see, so you're arguing that DConf shouldn't be doing in-person talks because it's larger than most D meetups? Don't answer that, scale as a reason makes no sense and there's no way you can make it. You have that backwards again, As Iain said, watching one pre-recorded talk takes an hour, which I'm sure many enthusiasts will be able and wiling to spend, scale that up to 20 and they may not be able to even if they are willing. To do something very different from a "traditional" conference would be a significant risk when what we have works well. I see no "risk" whatsoever in change when the status quo is dying, and what you're already doing isn't having much impact. and that comes down to an apparently fundament disagreement that the status quo is not good enough, In our experience the current format work very well. I hope you agree that a major change to the way things are done will likely have a major impact on the quality of the conference: if you think it is bad enough that changing it can only improve it then you would, rightly, come to the conclusion that the expected value (in the statistical sense) of changing the format is positive. However, if you think that the change may cause the quality to degrade then the expected value of the change of format drops significantly... As noted previously your opinions would carry more weight if you had actually attended a past DConf. Heh, this is the dumbest possible argument anyone can put forth and you guys repeatedly make it: "I have no arguments so 'Magic! You had to be there!'" ...and the change becomes much more risky. The argument of "your opinions would carry more weight if you had actually attended a past DConf" stems from the fact that we have experienced the conference as a positive well worthwhile to attend event and we see the potential for this to get worse in the face of change.
Re: DConf 2019: Shepherd's Pie Edition
On Tuesday, 25 December 2018 at 05:01:43 UTC, Joakim wrote: On Monday, 24 December 2018 at 22:22:08 UTC, Steven Schveighoffer wrote: The 0.1% of the community that attend seem to like it, the vast majority don't, or at least don't care. You think we have 200k users? More to the point you neglect the benefit of development and progress is shared by all users. I, for one, will not be donating to the foundation as long as they continue to waste money this way, just as others have said they won't donate as long as it doesn't put out a Vision document anymore or otherwise communicate what it's doing with their money. I agree this does need to happen, the foundation will be having a another meeting in Feb to set the vision, which I hope will be a little more planned and productive than the last one. Nobody is asking for your money for this conference (unless you want to attend), and if you feel this way, that's totally your choice. I'm not talking about the registration fee, I'm talking about contributing anything to the foundation, which Walter indicates above covers some of the expenses for DConf. Some additional transparency would help, Mike? I like the results that come from the conferences, I've been to all of them since 2013, on my dime for 3, and with assistance for 3. I felt it was 100% worth it for all. Yet you cannot give a single reason _why_ you felt it was worth it, or why my suggestions wouldn't make it better. I'll give my reasons: I got a job out of it. I got useful insight into various bits of the compiler. I got connections for collaboration with stuff that I'm interested. If you're making a bad decision, it _should_ be questioned. Indeed, but none of us think DConf is a bad idea or that the format doesn't work for us. Almost nothing that has been decided so far would stop most of my three suggestions from still being implemented. You haven't managed to convince us that that would be an improvement. As for how they feel about it, I don't care. The reason most projects and companies fail is because the decision-making process stops being about putting out a good product but about "feelings" and various people "saving face," especially when higher up the hierarchy, ie politics. And don't make up some nonsense that I'm saying that it's okay if everybody starts cursing each other out like Linus did: we're talking about _questioning a decision_. That is the whole point of having a community. The day this community starts being more about saving face is the day I leave it, as that's the beginning of the end, and I don't want to be around for that end. I totally agree, but again, you haven't convinced us that it is an improvement. Not at all, the whole reason I'm willing to debate is that other worthwhile perspectives may be out there. I think the evidence and arguments strongly favor the suggestions I'm putting forward, but I'm perfectly willing to consider other arguments. That is the same stance they should have, but don't appear to. My problem with this "debate" is that nobody was able to defend the current DConf format at all. That reasoning is backwards: in our experience DConf, as done in the past, works, and it works well. The onus is on you to convince us that it would work better the way you describe. Consider some of Walter's silly arguments above: at one point he says he wants "successful instantiations of your theories," implying that these are all things I'm just talking about and nobody's doing them, though it's not clear which aspects he thinks that of since I've presented evidence for much of it. But at another point, he says that other D meetups are already doing something I suggest (I pointed out that he's wrong about that one, but let's assume he believes it), so there's no reason for DConf to do it. First of all, 95+% of D meetups appear to follow the DConf format of having a single speaker lecture to a room, so why isn't that an argument against doing that yet again at DConf? What works at one scale doesn't necessarily work at another. To do something very different from a "traditional" conference would be a significant risk when what we have works well. As noted previously your opinions would carry more weight if you had actually attended a past DConf. Secondly and more importantly, he's speaking out of both sides of his mouth: do you want to do something that nobody else's doing or that somebody has done? You can't argue _both_ that you don't want to do what others are doing and what nobody else is doing. And why wouldn't the former apply much more to the outdated DConf format? I don't knowhow many times we have to say it: we do not feel the conference format is outdated. It's not just because of this, this is merely the final straw. I have felt that the talks were mostly not worth my time at the last couple Dconfs, that is the main reason. I see a lot of
Re: DConf 2019: Shepherd's Pie Edition
On Sunday, 23 December 2018 at 10:59:32 UTC, Joakim wrote: You say that like some superior technology exists to replace the conference. It does, read the first link I gave in my first post above. You mean the one that says "I don’t know how to fix conferences"? Yes, DConf may benefit from tutorials, workshops, BoFs, whatever, but the value it brings to the community is very real. It may bring some value, but that's not the question: the question is whether we could get more value out of the alternatives, particularly at a cheaper cost? The fact that you and others keep avoiding this question suggests you know the answer. That really depends on the objective function you mean by "more value". "social networks, Slack groups, podcasts, and YouTube" are all well and good but they cannot compare (as in apples to oranges) to high-bandwidth low latency personal communication with all the people that have an interest (business, technical, whatever) and technical expertise in the subject at hand. Hardly. IME there are two kinds of conferences (or maybe they form a spectrum, whatever) academic and industrial. Academic is going nowhere, research needs presenting, organisation of collaboration needs to happen. Research conferences are irrelevant. I don't pay attention to them and the fact that the Haskell link Atila gave above says their conferences are for presenting research is one big reason why almost nobody uses that PL in industry. I concede that I find PL theory useless, but not all academic conferences are PL theory, and I don't think that the potential scope for more academic talks of DConf is limited to PL theory. Novel applications of D in anything from physics to bioinformatics to optimisations based on immutability to DSELs enabled by D's meta programming are all possible in an academic setting. Industrial, there is project coordination, employment prospectus, business opportunities, why do you think companies sponsor conferences? They get their moneys worth out of it. Clearly not in the iOS community, and according to a commenter in my second link above, the Javascript community in his country, as the number of tech conferences is going down a lot. It is my impression that this is true across the board for pretty much every tech community, but I presented that iOS link because he actually tallies the evidence. I don't doubt those numbers and perhaps the other forms of communication do lessen the need for multiple conferences per year, but there is a large difference from many to one compared to one to zero, in person communication cannot be easily replaced. Industrial sponsorship is definitely real, take a look at the side column of http://llvm.org/devmtg/2018-10/ which I went to and talked to the authors of https://github.com/wsmoses/Tapir-LLVM for potentially targeting OpenMP and other parallel runtimes with dcompute, talked to the people developing the SPIR-V target of LLVM, the list goes on. I'm going to EuroLLVM (Brussels) to continue those conversations, followed straight away by ACCU (Bristol) to give a talk about meta programming with D in the context of developing and using DCompute. Then a few weeks later I'll be going to DConf for many reasons but principally to coordinate development, deal with the gripes that have accumulated. I'll probably return home via Boston for IWOCL (OpenCL). Perhaps you as an individual believe that they are not cost effective for you, fine. As I keep repeating, this is not about me. I'm pointing out trends for _most_ devs, DConf has been growing in size every year it has been held, as have IWOCL and the LLVM conferences. I'm sure some topics for some conferences are declining, it may well even be an industry wide trend, but I'd bet good money that the new equilibrium will have conferences as a staple. my own preferences are irrelevant. I certainly hope not. But consider that the foundation reimburses speakers and I personally would be very interested to hear what you have been doing with Andoird/ARM and I'm sure many others would as well, the question becomes: is it worth your time? I don't understand what's so special about "speakers" that it couldn't simply reimburse non-speakers that the foundation wants at one of the decentralized locations instead. It seems like the talk is a made-up excuse to pay for some members of the core team to come, when the real reason is to collaborate with them. Why not dispense with that subterfuge? The talks together with the topic of the conference are what draw people to the conference and make it economically viable. It is a perfectly rational decision. If I was running a conference trying to turn a profit I'd probably get more applications for the available speaker slots => better quality speakers => more attendees => $$$. DCompute would not exist were it not for that reimbursement, as a poor student that made the
Re: DConf 2019: Shepherd's Pie Edition
On Sunday, 23 December 2018 at 08:08:59 UTC, Joakim wrote: On Sunday, 23 December 2018 at 06:54:26 UTC, Russel Winder wrote: Others have cited Rust and Go. I shall cite Python, Ruby, Groovy, Java, Kotlin, Clojure, Haskell, all of which have thriving programming language oriented conferences all over the world. Then there are the Linux conferences, GStreamer conferences, conference all about specific technologies rather than programming languages. And of course there is ACCU. There is much more evidence that the more or less traditional conference format serves a purpose for people, and are remaining very successful. Many of these conferences make good profits, so are commercially viable. That's all well and good, but none of this addresses the key points of whether there are less tech conferences being done and whether they make sense in this day and age. There are still people riding in horse and carriage, that doesn't mean it's still a good idea. :) You say that like some superior technology exists to replace the conference. Yes, DConf may benefit from tutorials, workshops, BoFs, whatever, but the value it brings to the community is very real. Thus I reject the fundamental premise of your position that the conference format is dying off. It isn't. The proof is there. Yes, the proof is there: the conference is dying. Hardly. IME there are two kinds of conferences (or maybe they form a spectrum, whatever) academic and industrial. Academic is going nowhere, research needs presenting, organisation of collaboration needs to happen. Industrial, there is project coordination, employment prospectus, business opportunities, why do you think companies sponsor conferences? They get their moneys worth out of it. Perhaps you as an individual believe that they are not cost effective for you, fine. But consider that the foundation reimburses speakers and I personally would be very interested to hear what you have been doing with Andoird/ARM and I'm sure many others would as well, the question becomes: is it worth your time?
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Nice! I like the eponymous templates idea, though it might get confusing with doubly nested eponymous templates and with mixin templates injecting constructors ( https://run.dlang.io/is/UYakit ) We really do need to figure out what to do with @property Returning a reference Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw Variables can’t be ref not _quite true, foreach variables can be.
Re: Interview with Liran Zvibel of WekaIO
On Wednesday, 5 December 2018 at 08:02:21 UTC, M.M. wrote: On Tuesday, 4 December 2018 at 14:21:02 UTC, Mike Parker wrote: Joakim interviewed Liran for the D Blog about their file system, Matrix, and their use of D. Thanks to Joakim for putting it together, and to Liran for taking the time to participate! Blog: https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-wekaio/ Reddit: https://www.reddit.com/r/programming/comments/a3106x/interview_liran_zvibel_of_wekaio/ Interesting read. I am new to dlang, and after reading the post, I asked myself: the company liked the language, but tweaked the compiler. Could the company now switch to one of the official compilers? If not, why? LDC _is_ an official compiler, they just use a slightly modified version of LDC (with LTO & PGO'd against their codebase). I
Re: The New Fundraising Campaign
On Tuesday, 4 December 2018 at 10:20:10 UTC, Martin Tschierschke wrote: p.s. And still: Please put the campaign logo/button beside the general donation logo/button at: https://dlang.org/foundation/donate.html You could do a PR to https://github.com/dlang/dlang.org/blob/master/foundation/donate.dd You've probably got a better Idea of what to do for that than I do (also I can't approve my own PRs)
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 28 November 2018 at 12:48:46 UTC, Laeeth Isharc wrote: I think that there are different strategies - decent appeal to a broad market and having a very high appeal to a small market (but there has better be something good about your potential customer base ie 'D, if you find VBA too difficult' is probably not a good strategy!). And you probably don't get to pick which situation you are in, and then one had better realise it and play the game you're in. The particular kind of market will shape what works - in my business you approach a retail client base differently from regular institutional investors and then the worlds' largest pools of money involved something else again. D isn't really marketed and it's definitely not sold. That's an implicit strategy in itself. But one doesn't decide to have no strategy (at least if they any common sense!), one simply has no strategy. Unfortunately I think D falls into the latter, certainly not more than "Build it and they will come", irrespective of it effectiveness. Actually no less than 3 programmer friends came to (I'm the weirdo-using-D and people are _always_ in disbelief and invent all sorts of reasons not to try) saying they saw an article on D on HN, with "D compilation is slow", and on further examination they didn't read or at best the first paragraph. But they did remember the title. They may rationally think their opinion of D hasn't changed: aren't we highly capable people? I hope so! It doesn't matter what most people think. It matters what people who are on the fence or using D already a bit think. Or people who have a lot of problems to which D is in part a solution only they didn't know about or think of D yet. Then we should try to subtly (for some value of subtlety) make ourselves noticed.
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 11:58:25 UTC, Vladimir Panteleev wrote: Have we tried disabling -unittest for modules that aren't on the compiler's command line yet (or, in case of -i, not excluded)? Not that I know of, thats a great idea! Maybe this hack could be developed further into a more generic "compiler server" idea. Wasn't that Robert's Masters thesis (Dconf 2013(?) presentation)? ;)
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 08:07:52 UTC, Vladimir Panteleev wrote: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ This is #2 on HN at the moment.
Re: D compilation is too slow and I am forking the compiler
On Wednesday, 21 November 2018 at 08:07:52 UTC, Vladimir Panteleev wrote: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ You gave me a fright there with the title there for a moment. Awesome stuff though. Not sure how easy it will be to upstream considering this needs to not wreck Windows and needs to work with LDC/GDC (at least we have inlining in the backend).
Re: Profiling DMD's Compilation Time with dmdprof
On Sunday, 18 November 2018 at 04:38:57 UTC, Basile B. wrote: Damn, you're right. Actually i didn't try your stuff at all and instead used callgrind intuitively. Bad advice was here: https://github.com/dlang/dmd/pull/8945#issuecomment-439388332. Also along the thread there was discussion about building DMD and one saying that DMD had not been profiled for ages. My bad.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Wednesday, 14 November 2018 at 06:56:12 UTC, aliak wrote:
On Tuesday, 13 November 2018 at 09:17:51 UTC, Walter Bright
wrote:
[...]
Ok, thanks!
[...]
Bummer. At least if this enum : int case is fixed that doesn't
seem like it's hard to work out in my head at least - but I
guess I'm missing some edge case maybe, but I can't figure it
out.
Pus, it seems to work as "expected" with alias this. So I kinda
wonder what reasons there could be to not make it work as
expected for other scenarios.
struct B {
enum A : int { a }
alias b = A.a;
alias b this;
}
void f(short) {}
void f(int) {}
f(B()); // does what anyone would expect
Hahaha! That is hilarious! for the curious
https://run.dlang.io/is/fqlllS
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Wednesday, 14 November 2018 at 04:33:23 UTC, Isaac S. wrote: On Wednesday, 14 November 2018 at 04:27:05 UTC, Walter Bright wrote: There have been various attempts over the years to "fix" various things in the D matching system by adding "just one more" match level. I've rejected all of them, because things that look simple and obvious with trivial examples tend to sink in a swamp with the dirty reality of the rather vast number of types and conversions that D supports. This happens in C++, and what people tend to do is just throw up their hands and hackishly add in more overloads until they get the result they want. The thing is, this isn't a new match level. Rather than the enum implicitly casting to its literal (I'm hoping I'm using the correct word here) I'm proposing it implicitly cast to its typed literal (Instead of A.a implicitly converting to 0, it converts to int(0)). This would mean it would match the int since its a direct match. The water is already somewhat murky here, the magic enums `__c_long` & friends already do some of this, but array of them don't (which I'm going to fix in https://github.com/dlang/dmd/pull/8950 as its needed to make __c_wchar_t actually useful). Extending this to all enums would probably do the trick. enum implicitly casting to its literal memory type is what the compiler calls it.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Wednesday, 14 November 2018 at 04:24:20 UTC, Jonathan M Davis wrote: Given how strong the negative response is to this and how incomprenhensible a number of us find the reasoning behind how bool functions in some scenarios, Walter probably does need to sit back and think about this, but using words like asinine is pretty much always uncalled for in a professional discussion. I can very much understand Isaac's frustration, but making statements like that really is the sort of thing that comes across as attacking the poster and is going to tend to result in folks not listening to your arguments anymore, even if they're well-reasoned and logical. It's already hard enough to convince people when your arguments are solid without getting anything into the mix that could come across as insulting. - Jonathan M Davis asinine, adjective: extremely stupid or foolish. Is there some additional connotation I am missing on this living (comparatively) in the middle of nowhere? (Genuine question.)
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Wednesday, 14 November 2018 at 03:02:48 UTC, Walter Bright wrote: On 11/13/2018 3:50 PM, Isaac S. wrote: is asinine and ignorant. Some friendly advice - nobody is going to pay serious attention to articles that sum up with such unprofessional statements. Continuing the practice will just result in the moderators removing them. I read the first adjective as a statement of opinion about your reasoning for rejection and the second about the way you have dismissed the opinions of others, neither of which are uncalled for and certainly not unprofessional. You would do well to think about that before you post further.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 10:05:09 UTC, Jonathan M Davis wrote: I was hoping that this DIP was convincing enough, and its failure is certainly disappointing. Indeed.
Re: The New Fundraising Campaign
On Sunday, 11 November 2018 at 11:29:03 UTC, Andre Pany wrote: On Saturday, 10 November 2018 at 16:09:12 UTC, Mike Parker wrote: I've just published a new blog post describing our new fundraising campaign. TL;DR: We want to pay a Pull Request Manager to thin out the pull request queues and coordinate between relevant parties on newer pull requests so they don't go stale. We've launched a three-month campaign, and Nicholas Wilson has agreed to do the work. We have high hopes that this will help reduce frustration for current and future contributors. And we will be grateful for your support in making it happen. Please read the blog post for more details: https://dlang.org/blog/2018/11/10/the-new-fundraising-campaign/ For the impatient: https://www.flipcause.com/secure/cause_pdetails/NDUwNTY= This is really great news. Will all dlang repositories monitored? Or more specific, does this also includes the dub repository? The pull request list is really hot here. Kind regards Andre My current focus is DMD > druntime > phobos > dlang.org Unfortunately I don't have a lot of experience with the dub codebase (or access right for that matter) though I agree it could really benefit. Looks like I've got some source-diving to do.
Re: Release D 2.083.0
On Friday, 2 November 2018 at 00:12:29 UTC, Martin Nowak wrote: Glad to announce D 2.083.0, ♥ to the 51 contributors. This release comes with betterC support in dub, new CppRuntime_* version identifiers, an isZeroInit trait, and an exported environment variable DUB_PACKAGE_VERSION during dub build steps. http://dlang.org/download.html http://dlang.org/changelog/2.083.0.html - -Martin I got mentioned twice in contributors list.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 05:00:12 UTC, myCodeDontSmell wrote: I did find it confusing however, that you discuss leaky abstractions, and putting your public interface at the beginning of your code (and all the other crap below it)... but then, in D, once your write your abstraction, say a class, with it's public interface, all the code below it can do whatever it likes to that class, making it a leaky abstraction. That's sure sound like code smell to me. i.e. A class (perhaps one of the most important abstractions in programming) within a module, is *always* a leaky abstraction (within the module), because of the way the code further down can just ignore the interface. In fact, there is no way at all to ensure code below the class uses that interface. So I can't help but see contradictions everywhere, in D. That is by design, because in D the unit of abstraction is the module, not the class. Running into such problems is a sign that your module is too large, and should become a package.
Re: BindBC -- The successor to Derelict
On Tuesday, 30 October 2018 at 12:35:15 UTC, Mike Parker wrote: Thanks! Yes, I'll port all of those over. I implemented most of bindbc-al the other day. I plan to sit down and finish it up later this week. Be forewarned though, my plans too frequently have a mind of their own. Mike could you add those of us who are members of derelict to BindBC? I'll take a look at porting CUDA and OpenCL over to BindBC. Thanks Nic
Re: Beta 2.082.0
On Wednesday, 17 October 2018 at 15:18:43 UTC, Vladimir Panteleev wrote: On Wednesday, 17 October 2018 at 12:14:55 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.083.0 release, ♥ to the 48 contributors for this release. Thanks! CppRuntime_* version identifiers - https://dlang.org/changelog/2.083.0.html#cppVersions When is this different from the corresponding CRuntime version? CppRuntime is per compiler, CRuntime is per system. An example: on linux linking with Clang's C++ lib, the CppRuntime is CppRuntime_Clang and the CRuntime is CRuntime_Glibc.
Re: Wed Oct 7 - Avoiding Code Smells by Walter Bright
On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote: I'm giving a presentation at: http://nwcpp.org/ See you there! Where'd you get your time machine from? I want one!
Re: Release D 2.082.1
On Thursday, 11 October 2018 at 23:02:19 UTC, Martin Nowak wrote: Glad to announce D 2.082.1. http://dlang.org/download.html This point release fixes a few issues over 2.082.1 Ummm... Anyway, thanks for the release!
Re: Copy Constructor DIP and implementation
On Monday, 8 October 2018 at 10:27:47 UTC, RazvanN wrote: Both the DIP and the implementation still lack a -dip10xx switch. After discussing with Walter and Andrei we came to the conclusion that a flag is not necessary in this case. Please elaborate on the reasoning. Immediately after the DIP is accepted, the postblit will be deprecated. Its not about the deprecation process, its about the transitional process, i.e what to do when there is both a postblit and a copy constructor are defined. Whatever the default is, if there is no way to control it, it is impossible to transition smoothly.
Re: Copy Constructor DIP and implementation
On Monday, 8 October 2018 at 10:14:51 UTC, RazvanN wrote: On Tuesday, 2 October 2018 at 09:26:34 UTC, RazvanN wrote: Hi all, I just pushed another version of the DIP in which the major modifications among otthers are removing implicit and use copy constructor calls in all situations where a copy is made. For more details, please visit [1] and if you have the time, please offer some feedback, Thank you, RazvanN [1] https://github.com/dlang/DIPs/pull/129/ I've made all the changes in the code that the DIP includes[1] and the tests seem to be all green. I still need to add more tests; if you have any tests that you want to make sure the implementation takes into account please post them. Cheers, RazvanN [1] https://github.com/dlang/dmd/pull/8688 Both the DIP and the implementation still lack a -dip10xx switch.
Re: Aedi dependency injection framework 1.0.0
On Sunday, 7 October 2018 at 10:14:08 UTC, Alexandru Ermicioi wrote: Hi Dlang community, I'm announcing version 1.0.0 of Aedi dependency injection framework. [...] Link?
Re: Aurora DirectX Bindings 12.1
On Saturday, 6 October 2018 at 00:02:36 UTC, Adam Wilson wrote: So for now I definitely think the package route is a better option. Indeed. But if you do end up using these bindings on DCompute please let me know! I've made sure that all the Shader interfaces exist, but if you find anything missing I will gladly except PR's. Will do. It really depends on a) what happens at the LLVM Dev meeting in a week and a half and b) what Blizzard want out of it, both if it happens at all, and how much, if any (i.e. anything more than codegen), of the API will need to be usable from D.
Re: Aurora DirectX Bindings 12.1
On Thursday, 4 October 2018 at 04:03:27 UTC, rikki cattermole wrote: On 04/10/2018 2:06 PM, Adam Wilson wrote: The Aurora DirectX bindings have been updated to support Windows 10 1809. Also the D2D Effect Authoring SDK has been added. GitHub: https://github.com/auroragraphics/directx DUB: http://code.dlang.org/packages/aurora-directx Please send PR's if you find any bugs! It would be nice to get DirectX bindings into druntime. Just need 9/10 (some are floating about) after these mature a bit. I don't think thats wise, nor is it ever like to happen. Druntime is D's runtime, the only reason there are bindings to the C and and C++ standard library is because of their ubiquity. This is much better suited to a dub package. Side note, its possible that I might end up adding a DX12 backend to LDC/DCompute (which I'm going to have to rename if I do) based on https://github.com/Microsoft/DirectXShaderCompiler/ even more likely if MS (Hi Adam) upstream it to LLVM.
Re: Silicon Valley D Meetup - September 27, 2018 - "Introduction to the D Programming Language and Q"
On Wednesday, 26 September 2018 at 22:57:47 UTC, Ali Çehreli wrote: Link at Meetup: https://www.meetup.com/D-Lang-Silicon-Valley/events/slbvflyxmbkc/ Ali Ah rats, this one is two weeks too early and the next one is a week too late for me to go to while I'm in town for a conference.
Re: Copy Constructor DIP and implementation
On Tuesday, 25 September 2018 at 12:33:30 UTC, RazvanN wrote: After discussing with Walter and Andrei we have decided that we are going to drop @implicit for now as it may cause bugs (as Jonathan has highlighted) and consider constructors that have the form this(ref $q1 S rhs) $q2 as copy constructors. I will update the DIP with more information. Also, regarding the cohabitation between postblit and copy constructor: in order to make the transition smoother, whenever a postblit and a copy constructor are found togheter in a struct, the former is used and the latter is ignored (even if it is a field postblit). Once the postblit is going to be deprecated we can do the opposite and use the copy constructor and ignore the postblit. If @implicit is going to be introduced then that is going to be a DIP on its own. Thanks! I still think a -dip10xx flag to control which to prefer is worth doing, since a) it won't be hard to do and will make the transition smoother still , and b) IIRC the motivating factor for this is memory safety. Delaying memory safety while waiting for a deprecation period to expire ( O(years) ) for code that wants to remain backwards compatible with older compiler versions is not something we should be encouraging. In the deprecation period if no flag is given prefer postblit to copy if both are defined, if flag is given prefer copy over postblit. Nic
Re: Copy Constructor DIP and implementation
On Monday, 24 September 2018 at 23:22:13 UTC, Jonathan M Davis wrote: @implicit on copy constructors is outright bad. It would just be a source of bugs. Every time that someone forgets to use it (which plenty of programmers will forget, just like they forget to use @safe, pure, nothrow, etc.), they're going to have a bug in their program. However, unlike, with attributes like @safe or pure, they're not going to get a compiler error in their program; they're going to get a logic error. They may or may not find that bug quickly, but the compiler isn't going to point it out to them. I think this is the most important reason. In C++, where everything is implicit by default (which is bad) and (I think) you are encouraged to use explicit where possible, you should never use it for the copy constructor because the compiler always calls it implicitly for you and is the whole point of having: Foo a; Foo b = a; do something useful. Putting explicit on the copy ctor means that no longer works, one can then only use it with Foo a; Foo b(a); Having `Foo a; Foo b = a;` do something completely different by the addition or removal of one attribute is a serious problem just waiting to happen.
Re: Copy Constructor DIP and implementation
On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis wrote: On Saturday, September 22, 2018 6:13:25 PM MDT Adam D. Ruppe via Digitalmars-d-announce wrote: [...] Yeah, the problem has to do with how much you have to mark up your code. Whether you have @foo @bar @baz or foo bar baz is pretty irrelevant. And keywords eat up identifiers, so they're actually worse. In addition, most of the complaints about @implicit have to do with the fact that it doesn't even add anything. It's annoying that we have @nogc, @safe, pure, etc. but at least each of those adds something. @implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist. - Jonathan M Davis It appears that @implicit has been removed from the implementation [1], but not yet from the DIP. https://github.com/dlang/dmd/commit/cdd8100
Re: Copy Constructor DIP and implementation
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis
wrote:
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via
Digitalmars-d- announce wrote:
This will break compilation of current code that has an
explicit copy constructor, and the fix is simply to add the
attribute @implicit.
In that case, why not just use a transitional compiler switch?
Why force everyone to mark their copy constructors with
@implicit forever? The whole point of adding the attribute was
to avoid breaking existing code.
- Jonathan M Davis
Apparently because extending copy constructors are intended to be
extended to types other than typeof(this), which would also be
implicit, and then @implicit is to make sure that you actually
want this(ref SomethingElse){ ... } to be implicitly called when
A a;
B b;
...
b = a;
which I think is a bad idea, not the least of which is because
thats what opAssign is for.
See https://github.com/dlang/DIPs/pull/129#discussion_r218006614
Re: Copy Constructor DIP and implementation
On Monday, 17 September 2018 at 23:14:28 UTC, tide wrote:
From what I've read, the copy constructor can be used with
different types:
struct B
{
}
struct A
{
@implicit this(ref B b)
{
}
}
B foo();
A a;
a = foo(); // ok because of @implicit
a = A(foo()); // ok without @implicit
That's why it exists, otherwise I wouldn't want two types to be
implicitly convertible unless i explicitly tell it to be
implicit.
This DIP does not allow this, but apparently it is on the
horizon[1],
it will be easier to extend the feature to copy construct
from any type to any type
Is this a thing we are even considering?
Yes.
I don't agree with it.
[1]: https://github.com/dlang/DIPs/pull/129#discussion_r218006614
Re: D kernel for Jupyter notebook
On Saturday, 15 September 2018 at 08:12:37 UTC, Peter Alexander wrote: On Sunday, 19 August 2018 at 23:49:21 UTC, Nicholas Wilson wrote: On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: [...] Note that the D repl will only work on platforms where drepl works i.e. platform with shared library support. It will _build_ on OSX due to https://github.com/kaleidicassociates/jupyterd/blob/master/source/jupyterd/kernel.d#L393 but it won't work. The drepl README on github says it works for OSX. Is that not correct? "Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD)." https://github.com/dlang/druntime/blob/master/src/rt/sections_elf_shared.d#L534 vs. https://github.com/dlang/druntime/blob/master/src/rt/sections_osx_x86_64.d ^F rt_loadLibrary Not found. As a result it fails to link. Probably not hard to fix, though.
Re: Copy Constructor DIP and implementation
On Wednesday, 12 September 2018 at 23:55:05 UTC, Nicholas Wilson wrote: The bog-standard way of dealing with avoidable breakage with DIPs is a -dip-10xx flag. In this case, if set, would prefer to call copy constructors over blit + postblit. Also adding @implicit is a backwards incompatible change to a codebase that wants to use it as it will cause it to fail on older compilers. Even if one does : static if (__VERSION__ < 2085) // or whenever it gets implemented enum implicit; all over the place, It is illegal to declare a copy constructor for a struct that has a postblit defined and vice versa: Hmm, I suppose one could static if (__VERSION__ < 2085) // use a postblit else // use a copy ctor.
Re: Copy Constructor DIP and implementation
On Wednesday, 12 September 2018 at 23:36:11 UTC, Jonathan M Davis wrote: On Wednesday, September 12, 2018 5:17:44 PM MDT Nicholas Wilson via Digitalmars-d-announce wrote: it seems that even if we were to want to have @implicit as an opposite of C++'s explicit it would _always_ be present on copy-constructors which means that @implicit for copy constructors should itself be implicit. Oh, yes. The whole reason it's there is the fear that not requiring it would break code that currently declares a constructor that would be a copy constructor if we didn't require @implicit. So, if the DIP is accepted, you _could_ declare a constructor that should be a copy constructor but isn't, because it wasn't marked with @implicit (just like you can right now). If code breakage were not a concern, then there's pretty much no way that @implicit would be part of the DIP. Personally, I don't think that the risk of breakage is high enough for it to be worth requiring an attribute for what should be the normal behavior (especially when such a constructor almost certainly was intended to act like a copy constructor, albeit an explicit one), but Andrei doesn't agree. The bog-standard way of dealing with avoidable breakage with DIPs is a -dip-10xx flag. In this case, if set, would prefer to call copy constructors over blit + postblit. Also adding @implicit is a backwards incompatible change to a codebase that wants to use it as it will cause it to fail on older compilers. Even if one does : static if (__VERSION__ < 2085) // or whenever it gets implemented enum implicit; all over the place, It is illegal to declare a copy constructor for a struct that has a postblit defined and vice versa:
Re: Copy Constructor DIP and implementation
On Wednesday, 12 September 2018 at 22:11:20 UTC, Manu wrote:
On Wed, 12 Sep 2018 at 04:40, Dejan Lekic via
Digitalmars-d-announce
wrote:
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?
>
> @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);
I could not agree more. @implicit can mean many things, while
@copy is much more specific... For what is worth I vote for
@copy ! :)
@implicit may be attributed to any constructor allowing it to
be invoked implicitly. It's the inverse of C++'s `explicit`
keyword. As such, @implicit is overwhelmingly useful in its own
right.
This will address my single biggest usability complaint of D as
compared to C++. @implicit is super awesome, and we must
embrace it.
https://stackoverflow.com/a/11480555/1112970
I have no idea why you would want to declare a copy-constructor
as explicit
it seems that even if we were to want to have @implicit as an
opposite of C++'s explicit it would _always_ be present on
copy-constructors which means that @implicit for copy
constructors should itself be implicit.
From what I understand of explicit in C++, if we were to have
@implicit construction it would be used for things like
struct Foo
{
@implicit this(int) {}
}
void useFoo(Foo f) { ... }
void main()
{
useFoo(0); // Fine, implicitly construct auto tmp = Foo(0);
useFoo(tmp);
}
If at some point in the future we decide that we do want to add
@implicit construction, then we can make the copy constructor
always @implicit. Until that point I see no need for this,
because it is replacing postblit which is always called
implicitly.
@\all please remember to leave feedback on the actual draft
review on the DIP PR.
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 17:44:28 UTC, Jonathan M Davis wrote: Of course, what further complicates things here is that the author is Walter, and ultimately, it's Walter and Andrei who make the decision on their own. And if Walter doesn't respond to any of the feedback or address it in the DIP, it all comes across as if the DIP itself is just a formality. The fact that he wrote a DIP and presented it for feedback is definitely better than him simply implementing it, since it does give him the chance to get feedback on the plan and improve upon it, but if he then doesn't change anything or even respond to any of the review comments, then it makes it seem kind of pointless that he bothered with a DIP. At that point, it just serves as documentation of his intentions. This is all in stark contrast to the case where someone other than Walter or Andrei wrote the DIP, and the author doesn't bother to even respond to the feedback let alone incorporate it, since they then at least still have to get the DIP past Walter and Andrei, and if the DIP has not taken any of the feedback into account, then presumably, it stands a much worse chance of making it through. On the other hand, if the DIP comes from Walter or Andrei, they only have the other person to convince, and that makes it at least seem like there's a decent chance that it's just going to be rubber-stamped when the DIP author doesn't even respond to feedback. I think that it's great for Walter and Andrei to need to put big changes through the DIP process just like the rest of us do, but given that they're the only ones deciding what's accepted, it makes the whole thing rather weird when a DIP comes from them. - Jonathan M Davis If Walter had tried to implement this w/o a DIP, that would have been among the first reviews received, so it is good that he's has done it as a DIP. But not using it for improving the design is almost as bad. I view this DIP like DIP1000 but worse: at least with DIP1000 there was clear motivation, and despite any breakage and poor documentation of continued changes due to unforeseen requirements, it solves a real problem and has bought real value. It could have been handled much better, but is a net positive IMO. DIP1017 OTOH has flawed/unsubstantiated motivation, will break lots of code, and solves a problem that is already solved by GDC/LDC where the only benefit other that documentation is faster code and could be solved in the same way as GDC/LDC with none of the breakage and complications. Any marginal benefits in speed of compiled code for DMD _only_ (which is not why one uses DMD) comes at the cost of: opportunity cost of development/review and ongoing implementation fixes; unknown but probably very large code breakages; slower compile times for all three compilers; increased complexity in the type system and for new users; and all the other reasons listed in the draft and community review. IMO, a very much net negative I now understand why Mihails left over DIP1000...
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 10:49:55 UTC, Mike Parker wrote: I always ask DIP authors about unaddressed feedback before moving from one stage to the other, and I did so with DIP 1017 when moving out of Draft Review. It's entirely up to the author whether or not to address it and there is no requirement for DIP authors to respond to any feedback. I would prefer it if they did, especially in the Post-Community stage and later as it helps me with my review summaries, but 1017 is not the first DIP where feedback went unaddressed and I'm sure it won't be the last. I can understand not requiring authors to respond to all the feedback, but not requiring them to respond to _any_ is just wasting everyone's time, since _all_ of the previous points will be bought up again and the next stage will be a repeat of the previous.
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 09:41:39 UTC, Dukc wrote: I disagree. Reviews are mainly for giving feedback, not for deciding the fate of the DIP -that's what the formal assesment is for. For the draft review yes, but the points against the DIP were raised in draft and it proceeded to community review unchanged without any correspondence on the part of the author, except to state that a reason to extend the DIP to extern(C++) function wouldn't work. IMO, it's enough that the author reads the review and addresses the points in the DIP before the next phase. I agree, but see previous point. And not every point has to be blindly addressed, No, but I expect a fraction greater then zero to be addressed. the reviewers may be just as wrong as the author. Yes but the reviewers outnumber the author by a lot, and in aggregate are less likely to be. That's why there are multiple reviewers. The reviews are still mentioned in the DIPs so they can be considered in the formal assesment, addressed by the author or not. And of course it's always better if the author interactively participates at the review, but it should not be required IMO. Put it this way: DIP1017 should not go to formal without change, as it did from draft to community (which I don't think should have happened without at least some acknowledgement or refutation of the points raised in draft).
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 05:25:11 UTC, Mike Parker wrote: I've got three DIPs in the Post-Community stage right now [2]. DIP 1015 will move to Final Review before yours if its author is ready when I am, then yours will go before 1017. I'm a bit worried about 1017 going in to final, given the large, unresolved criticisms in both draft and community review rounds. IMO the DIP author should at least participate in the community review if they expect their DIP to have _any_ chance of success.
Re: DIP Draft Reviews
On Thursday, 6 September 2018 at 03:19:33 UTC, Mike Parker wrote: I'm not going to start another Community Review until I get some space in the latter end of the queue. But soon I'll be asking for Draft Review feedback on the next candidate. Right now that's likely to be 'Named arguments lite', but it be Rikki's. https://github.com/dlang/DIPs/pull/123 Did you a word? Anyway good to know that things are still moving forward.
Re: DIP Draft Reviews
On Monday, 20 August 2018 at 14:54:24 UTC, Mike Parker wrote: I'm getting ready to start prepping one of the DIPs in the PR queue for community review. It proposes adding an `in` operator for arrays. I haven't gone through it in detail yet, so I invite anyone with time on their hands to provide feedback on the Draft so we can more speedily get in shape to kick off the big-league reviews. https://github.com/dlang/DIPs/pull/101 While you're at it, feel free to poke around and leave some feedback on other drafts in the queue. pull/101 was closed. What's happening now?
Re: D kernel for Jupyter notebook
On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: Proof of concept works, but it requires some further development to be useful to do work in. https://github.com/kaleidicassociates/jupyterd It uses D repl currently - this was written for a console interface and probably you will encounter difficulties running it in a notebook environment. I guess one would like to treat all functions defined in a single notebook as part of the same session and to execute immediate statements as part of a main specific to that cell. The kernel is a bit flakey - takes time to come on line and you might need to reconnect to it sometimes. To Do: 1.Add HTML and markdown table output to display arrays of structs or of dicts in a useful manner 2.Integrate with mir and other numeric libraries 3.Integrate with charting 4.Consider adding to Dlang tour and run.dlang.io when stable 5.Integrate with dpp 6.Integrate with dub 1 and 3 should be quite simple. One wouldn't want to write a large program in Jupyter, but it's helpful for exploratory data analysis and programming where the code that does the work is already in D. Note that the D repl will only work on platforms where drepl works i.e. platform with shared library support. It will _build_ on OSX due to https://github.com/kaleidicassociates/jupyterd/blob/master/source/jupyterd/kernel.d#L393 but it won't work.
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Monday, 6 August 2018 at 00:47:12 UTC, Nicholas Wilson wrote: Sure https://github.com/thewilsonator/jupyterd The echo interpreter now works, and the dmd one is there. I've got no idea if it works because I'm on OSX (yay no shared library support) if someone wants to test it that would be great.
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Sunday, 5 August 2018 at 20:01:22 UTC, Nikos wrote: Thank you very much for your feedback. Unfortunately, none of the above worked. By the way, the reason I'm trying all this is to create a Jupyter notebook. I've already made a simple version of it some time ago (https://github.com/nikoskaragiannakis/d-jupyter-kernel). Since you are also working on a D kernel, maybe we could work together? Sure https://github.com/thewilsonator/jupyterd There are 5 main objects: Channel, an abstraction over raw ZMQ sockets. Interpreter, abstracted for debugging and also other kernels (I work for Laeeth and they have an internal language they wan't to use from this.) Kernel, does the higher level network logic and calls the interpreter. Message and Wire message are high and low level representation of the packet layout. I'm currently trying to figure out why the message signing is bjorked (I swear it did use to work!), the IOPub channel fails intermittently (the worst kind) and the Shell/Control fails all of the time. Any effort pointing out where I done something stupid is much appreciated (and I do mean something stupid, the last major hurdle was trying to figure out why the packets were going nowhere: turns out I was missing the routing prefix). Are you on slack?
Re: Dpp on run.dlang.io
On Sunday, 5 August 2018 at 22:43:42 UTC, Laeeth Isharc wrote: One benefit of D is as a better glue language that integrates well with other languages and ecosystems. Many people who know a bit about D have no idea that interop can work so easily or well. So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for: Python (via autowrap:python and pyd) C (via dpp) C++ (extern(C++) for now) R (via embedr) Julia (via C interface, including julia.h via dpp) Lua (if LuaD stable enough) with just screenshot for: Excel (via autowrap excel / excel-d) C# via Binderoo Jupyter via pydmagic and just link for web assembly. Obviously a lot of work, but if you think a good idea we could work away at over time. "Here's something I prepared earlier." https://github.com/thewilsonator/interop This is currently to house [1] to try to show Walter why https://github.com/dlang/dmd/pull/8120 is a good idea. Unfortunately he remains unconvinced so I think I'm going to have to do it as a DIP [3]. [1]: https://github.com/thewilsonator/interop/blob/master/c%2B%2B/dslice.h [2]: https://github.com/dlang/dmd/pull/8120 [3]: https://github.com/thewilsonator/DIPs/blob/extern(C++)-array/DIPs/DIP1xxx.md
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Sunday, 29 July 2018 at 18:14:31 UTC, Nikos wrote:
But when I try to export the whole dmdEngine
export:
auto engine(char[] txt) {
return interpreter(dmdEngine());
}
Can you export an instance of `interpreter(dmdEngine())`?
e.g.
__gshared auto dmdi = interpreter(dmdEngine());
export ref dmd()
{
return dmdi;
}
or if that doesn't work, proxy it
__gshared auto dmdi = interpreter(dmdEngine());
struct Dmd
{
mixin Proxy!dmdi;
}
export auto dmd()
{
Dmd d;
return d;
}
That is pretty much required if you want to maintain state across.
Also I'm working on a D kernel for Jupyter notebook which should
be done soon.
Re: Write in D with Coedit 3.6.11
On Saturday, 28 April 2018 at 14:30:14 UTC, Basile B. wrote: New release of the strange D IDE not written in D and without dark theme: https://github.com/BBasile/Coedit/releases Real change log is here: https://github.com/BBasile/Coedit/releases/tag/v3.6.10 Every time you post a release I think " I should check this out!" then I (re)discover that there are no OSX releases and that it's not in D so I'm not set up to build it myself.
Re: Pre-DConf Meetup on May 1
On Wednesday, 25 April 2018 at 15:00:18 UTC, SimonN wrote: On Wednesday, 25 April 2018 at 14:13:55 UTC, Seb wrote: Our next D Munich Meetup will coincide with DConf to give our For those of you who stay at the hotel, we will be at the NH München Messe hotel at 18:00 and lead you towards the venue. Awesome, I'll attend! I'm posting here for lack of a meetup account. -- Simon Ditto, look forward to seeing you all there! Nic
Re: Beta 2.079.0
On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 contributors for this release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.079.0.html As usual please report any bugs at https://issues.dlang.org - This is probably the most feature-laden 2 month release ever. Highlights: https://dlang.org/changelog/2.079.0.html#lazy-gc-init https://dlang.org/changelog/2.079.0.html#includeimports https://dlang.org/changelog/2.079.0.html#minimal_runtime https://dlang.org/changelog/2.079.0.html#toString There is experimental `@nogc` exception throwing `-dip1008` (still missing changelog). Windows got a new experimental toolchain based on the lld linker and MinGW import libraries. This will hopefully replace OMF in the long-term without requiring heavy VC installations. Of course VC will remain the primary toolchain on Windows. (still missing changelog) A few remaining private symbols leaks have been fixed. https://dlang.org/changelog/2.079.0.html#private https://dlang.org/changelog/2.079.0.html#fix17630 https://dlang.org/changelog/2.079.0.html#fix18219 Some small syntax goodies: https://dlang.org/changelog/2.079.0.html#multi_module_selective_imports https://dlang.org/changelog/2.079.0.html#default_after_variadic Some noteworthy deprecations: https://dlang.org/changelog/2.079.0.html#deprecate_delete https://dlang.org/changelog/2.079.0.html#hexstrings - -Martin Awesome. A typo. Lambda comparison using __traits(isSame, ...) ... Whenver ...
