D Security Team has been initiated
If you have a security-related concern or issue and feel like this shouldn't be discussed in public, please don't hesitate to contact us in private at: https://dlang.org/security
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: I've written up a short blogpost about the T.init issue. It is not very enthusiastic. https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43 Somehow, this is the type of problem, i thought point 1 in the vision document is aimed to solve https://wiki.dlang.org/Vision/2018H1 "1. Lock down the language definition: D is a powerful language but its definition is not precise enough. A number of subtleties can only be assessed only by running the compiler, not by perusing the specification. This semester we are pushing for a better, more precise, and more complete specification of the D language." ensuring that the language features are coherent together
Release D 2.081.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Glad to announce D 2.081.1. http://dlang.org/download.html This point release fixes a few issues over 2.081.0, see the changelog for more details. http://dlang.org/changelog/2.081.1.html - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAltFLvMACgkQsnOBFhK7 GTlb/w/8DNJIjsnkXHXDt/FxmS9Z9TF/rnkkjhIpGMBXiXVwPISWP5SsIsFea+Is 5ZLaV0ryqW3c3YMiNQ0b7joUtIOJeOif5Qii/aTzp8zFdCaMQu1H+9SXZ8S9cTii klNlfBVoYv69jD6hgh36xaiU5RBLKCN9QqN8s7iInexNJUthcfVo3l1Alm9HElze GY6/1CG3A7p5uDkMmpXLwStsYQ2vE7bF3NSEcELeSt635axMgyI3lTQBA2NaKXbE D7sUecLfknz9Al0RqUUe+VnXUesz7/tZcxWTohIzSytcjhlJJf/ytLlVbqNbe9AP +o0jLTnERwPXWnJoh57BSsQNQAFaT0ooQbei+xCFiZLXUTTX91ZlWm4MzdKpoF2f dKXU8F64ZWViTADOMx/x9+aJ54ahGSF4Yksl6AB7kpikolb/cYOouiYNfYaH5mPH XEJD+YNCLKUy4JuO9DprBoJdCeMNrpmzhdUuWals9lwGbcm8AgLzEgZd2ISOULVg O13TF+WQUH83vKphE8PBpEbKROo93pZw57AekIcFb9U1v93FwKWNzO7EkBt/Hw54 jPFQZ55zd2MWAmvHXmrzzslJ1q41Rwtpb1cBnYC0AyMj6um+Js0B0SukelVwK8Bt MOL+4xFVyyVVLOJOLAkJjQctk0/lCwfhxgC0vRwps3l1xYVO4ng= =/y7c -END PGP SIGNATURE-
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: I've written up a short blogpost about the T.init issue. It is not very enthusiastic. https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43 Have you tried giving your invariants a valid initial value? Change string username; into string username = "noname"; -Bastiaan
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: I've written up a short blogpost about the T.init issue. It is not very enthusiastic. https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43 Related links: https://github.com/dlang/phobos/pull/6594 problem with T.init and toString https://github.com/dlang/phobos/pull/6619 Nullable can't work with types where T.init violates invariants https://github.com/dlang/dmd/pull/8462 A somewhat sketchy PR to disable invariant on struct ~this D's contract programming features have been around since D1 and haven't really been updated to work with newer D2 features (this is no excuse IMO; these issues should have been addressed long ago). My opinion is that it's a vicious circle; D's contract programming features are underutilized, thus nobody cares enough to put effort into ironing out the bugs, thus contract programming in D is buggy and interacts poorly with other language features, thus D's contract programming features are underutilized. IMO, if you don't have the knowledge, desire, or time to fix them, the next best thing to do is write articles like these bringing some attention to the various defects of contract programming in D, and/or write DIPs to propose ways to fix it.
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Related links:
https://github.com/dlang/phobos/pull/6594 problem with T.init
and toString
https://github.com/dlang/phobos/pull/6619 Nullable can't work
with types where T.init violates invariants
https://github.com/dlang/dmd/pull/8462 A somewhat sketchy PR to
disable invariant on struct ~this
First of all I must point that I would very much like to have
seen a code actually producing an error in that article. Contrary
to what is hinted just taking the struct and putting using it
with Nullable or format() caused no error for me and worked as
expected. Taking .init explicitely was the only thing that
actually caused an error. I'm not saying you didn't experience
these issues, but if you want to demonstrate a problem then
please demonstrate it.
That said, I may be missing something obvious but what prevents
you from overloading the init field?
struct MyDomainData {
string username;
@disable this(); // don't make a MyDomainData() by
accident!
this(string username)
in(!username.empty) // only non-empty usernames please!
do { this.username = username; }
// let's formalise the restriction.
invariant { assert(!username.empty); }
string toString() { ... }
static @property MyDomainData init() {
return MyDomainData("uninitialized");
}
...
}
auto test = MyDomainData.init; // There, no error
Of course that value means nothing but .init isn't meant to
actually mean something anyway, it's just a valid value and
that's what that init is proposing, so it shouldn't cause any
more bugs than empty .init in a normal case.
Re: I have a plan.. I really DO
On Tue, Jul 10, 2018 at 05:25:11PM +, Yuxuan Shui via Digitalmars-d-announce wrote: > On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote: [...] > > Of course, for someone looking for an excuse not to use D, they will > > always find another reason why this is not sufficient. But that only > > strengthens the point that the GC is just a convenient excuse not to > > use D. > > Not a good excuse to not fix GC, though. Of course. The current GC, while decent, does leave lots of room for improvement. Unfortunately, while much talked about, not many people are willing to actually put in the work to improve it. So I'm not really interested in generating more talk, as opposed to action. > > Solve that problem, and they will just move on to the next excuse, > > because the GC is not the real reason; the real reason is probably > > non-technical. Like good ole inertia: people are lazy and set in > > their ways, and resist changing what they've grown comfortable with. > > But actually admitting this would make them look bad, so it is > > easier to find a convenient excuse like the GC (or whatever else is > > different from the status quo). > > If that's the case, then we are doom. We might just as well forget > about getting popular, and instead spend time making the language > better. I have always been skeptical of popularity. It is neither a necessary nor sufficient condition for improved language quality. That's not to say we should not invest effort in marketing D... but popularity does not imply technical superiority, and the only reason I'm here is because of D's technical superiority. > Like fixing the GC. Nobody argues *against* fixing the GC. But, who will actually do it? As opposed to the crowds who are very willing to only talk about it. > (Although I don't quite agree with you. Some people DO resist change, > that's why some decades old languages are still popular. But look at > the popularity of new languages like Go, and Rust, and the ever-change > landscape of front-end development. There're tons of people who adapt > certain technology just because it is new, why can't that happen to > D?) [...] Those who adapt technology merely because it's new, are what I call the bandwagon jumpers. They will flock to the next brand new thing, and then just as readily leave in droves once the novelty has worn off. They are unreliable customers, and I wouldn't build a business based on their continuing support. Again, popularity is orthogonal to technical excellence. T -- "I'm not childish; I'm just in touch with the child within!" - RL
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 17:44:59 UTC, Adam D. Ruppe wrote: On Tuesday, 10 July 2018 at 17:39:06 UTC, SrMordred wrote: After the GC.collect you now get 1GB of memory usage. http://dpldocs.info/experimental-docs/core.memory.GC.minimize.html yeah I was looking to this right now on the docs, thks :) But still, all this knowledge about GC and all this calls to put the memory where you want, will happen automatically most of the time with the old scoped resources/RAII(and unique_ptr/shared_ptr, that D also have). GC tradeoffs never really paid well for me. (or my mindset is very stuck in the old ways :P)
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 17:39:06 UTC, SrMordred wrote: After the GC.collect you now get 1GB of memory usage. http://dpldocs.info/experimental-docs/core.memory.GC.minimize.html
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 17:03:01 UTC, H. S. Teoh wrote: AFAIK, the current GC does not release memory back to the OS. So you won't see the memory footprint decrease. However, it does free up memory for subsequent allocations. T if you put another int[] x; x.length = 1024 * 1024 * 128; After the GC.collect you now get 1GB of memory usage. My point is, this type of control is not enough control for anyone coming from a non-GC language, so they will point out GC as a problem. And in my opinion with reason. I´m using my own lib on D with nogc container and other utilities to avoid completly the GC. Altought I know that is completly possible to use GC and have good performance, I dont think the arguments for it are enough to convince most people. I find D awesome (and probably will never look at C++ again), but for me you can remove GC completly from the language and it will continue to be aswesome. (For me, i'm hoping to compile everything that I have with -betterC in the future. Waiting for some bugs related to betterC to be solved)
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote: On Fri, Jul 06, 2018 at 08:16:36PM +, Ecstatic Coder via Digitalmars-d-announce wrote: [...] I've never said that this is something smart to do. I'm just saying that this code can perfectly be executed once in a C++ game frame without having to worry for a game freeze, because the string buffer deallocation is done once per frame too. While with many GC languages, you actually DON'T KNOW when all those unused string buffers will be claimed. [...] Of course, for someone looking for an excuse not to use D, they will always find another reason why this is not sufficient. But that only strengthens the point that the GC is just a convenient excuse not to use D. Not a good excuse to not fix GC, though. Solve that problem, and they will just move on to the next excuse, because the GC is not the real reason; the real reason is probably non-technical. Like good ole inertia: people are lazy and set in their ways, and resist changing what they've grown comfortable with. But actually admitting this would make them look bad, so it is easier to find a convenient excuse like the GC (or whatever else is different from the status quo). If that's the case, then we are doom. We might just as well forget about getting popular, and instead spend time making the language better. Like fixing the GC. (Although I don't quite agree with you. Some people DO resist change, that's why some decades old languages are still popular. But look at the popularity of new languages like Go, and Rust, and the ever-change landscape of front-end development. There're tons of people who adapt certain technology just because it is new, why can't that happen to D?) T
Re: I have a plan.. I really DO
On Tue, Jul 10, 2018 at 04:07:01PM +, SrMordred via Digitalmars-d-announce
wrote:
> > As I've already repeated twice, this is not true in D. You *can*
> > predict precisely when the GC runs a collection cycle by calling
> > GC.disable and then calling GC.collect according to *your* own
> > schedule. This is not just a theoretical thing. I have actually
> > done this in my own projects, and it does work.
>
> Sorry, can you help me with this?
>
> Eg.
> void doit()
> {
> int[] x;
> x.length = 1024 * 1024 * 128;
> }
>
> void main()
> {
> import core.memory : GC;
> import core.thread;
> GC.disable;
>
> doit; //alloc +- 500mb inside the func.
> Thread.sleep(5.seconds); //500mb still in use.
> GC.collect; //hmmm still there
> Thread.sleep(5.seconds); //same
> }
[...]
AFAIK, the current GC does not release memory back to the OS. So you
won't see the memory footprint decrease. However, it does free up
memory for subsequent allocations.
T
--
It is of the new things that men tire --- of fashions and proposals and
improvements and change. It is the old things that startle and intoxicate. It
is the old things that are young. -- G.K. Chesterton
Re: I have a plan.. I really DO
As I've already repeated twice, this is not true in D. You
*can* predict precisely when the GC runs a collection cycle by
calling GC.disable and then calling GC.collect according to
*your* own schedule. This is not just a theoretical thing. I
have actually done this in my own projects, and it does work.
Sorry, can you help me with this?
Eg.
void doit()
{
int[] x;
x.length = 1024 * 1024 * 128;
}
void main()
{
import core.memory : GC;
import core.thread;
GC.disable;
doit; //alloc +- 500mb inside the func.
Thread.sleep(5.seconds); //500mb still in use.
GC.collect; //hmmm still there
Thread.sleep(5.seconds); //same
}
D Boston Meetup - 7/26
Hi all, We are going to set up a little coding session/gathering for D in the Capital One Cafe in Back bay [1] on July 26th (Thursday) starting at 6 pm. So far it looks like Sameer, myself and Andrei will be there. Please stop by if you want to hang out, chat about our favorite language, or any other reason! We will be working on porting NLP libraries, fixing dmd bugs (have one on my radar), or working on other projects. -Steve [1] 799 Boylston St, Boston, MA 02116
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: I've written up a short blogpost about the T.init issue. I believe that whoever wrote that spec meant that the invariant WOULD not need to hold if MyDomainData.init WAS called, but that MyDomainData.init must not be called if this is the case. It definitely needs clarification if I understood it's intent right.
Blogpost about the T.init problem
I've written up a short blogpost about the T.init issue. It is not very enthusiastic. https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43 Related links: https://github.com/dlang/phobos/pull/6594 problem with T.init and toString https://github.com/dlang/phobos/pull/6619 Nullable can't work with types where T.init violates invariants https://github.com/dlang/dmd/pull/8462 A somewhat sketchy PR to disable invariant on struct ~this
Re: mir-optim v0.0.1: betterC nonlinear least squares
On Tuesday, 10 July 2018 at 02:10:56 UTC, 9il wrote: The algorigbms from https://github.com/JuliaNLSolvers are good candidates. No plans to implement them for now, but PRs are wellcome. Dlangscience has headers for the nlopt and glpk C libraries that I've used in the past. ipopt is another one that I've used, but I don't think there's a D interface. IMHO, you'd need a good reason to implement all of the functionality of a non-linear optimizer on your own. Simple linear and quadratic programming are probably a useful start, but beyond that the ability to interface with C/Fortran libraries goes a long way.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 23:27:57 UTC, RhyS wrote: Total 1336 packages found. 3359 total shards D has had a major release. Crystal has had a minor release. Total 1339 packages 3382 total shards This is a really weak point, because it doesn't show the quality of the packages. Just look at npm.
Deploy your own Dub Registry to Heroku via one click
Ever wanted to run your own Dub registry and were too lazy to set it up? It's now one click away. Simply go to the Dub Registry (https://github.com/dlang/dub-registry) and press "Deploy to Heroku". Provided you have a Heroku account, everything else will automagically work. Note that Heroku even has a nice free tier for hobby projects. At the moment the Dub registry doesn't expose the Admin interface nor supports private packages. However, it's already very useful for Heroku's GitHub PR preview pipeline, e.g. https://github.com/dlang/dub-registry/pull/278 Also now there's a auto-deployed staging server based on master for the Dub registry: https://dub-registry-staging.herokuapp.com If you don't like Heroku, you can also use Docker to deploy your private Dub registry: https://github.com/dlang/dub-registry#deploy-your-private-dub-registry-with-docker
