Re: D's Auto Decoding and You

[Jack Stouffer via Digitalmars-d-announce]

On Wednesday, 18 May 2016 at 22:23:45 UTC, jmh530 wrote:

Is this true of all @property functions?


No, this is purely a range thing where it's legal to have your 
front be a public member variable rather than a getter function.



Should this be noted in the spec?


While somewhat supported in the language, at the end of the day 
ranges are library types, so no.



Should it be an error?


No, people's code will error if they try to call a non callable 
anyway.

Re: D's Auto Decoding and You

[Jack Stouffer via Digitalmars-d-announce]

On Wednesday, 18 May 2016 at 20:10:09 UTC, Jonathan M Davis wrote:
At this point, if anyone ever calls front with parens, they're 
doing it wrong.


$ cd ~/dlang/phobos && grep -r "\.front()" * | wc -l
3

Not bad. One is commented out and the other two look intentional.

Re: Beta D 2.071.1-b1

[Michael via Digitalmars-d-announce]

On Monday, 16 May 2016 at 20:59:41 UTC, Jack Stouffer wrote:

On Sunday, 15 May 2016 at 04:40:21 UTC, Martin Nowak wrote:

First beta for the 2.071.1 point release.
A few issues remain to be fixed before the next beta.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.071.1.html


Please report any bugs at https://issues.dlang.org

-Martin


This should probably be stalled until 
https://github.com/dlang/dmd/pull/5781 is pulled.


Agreed. A silent regression of this kind is pretty serious, and I 
think it needs to make it into the stable release as soon as 
possible.

Re: D's Auto Decoding and You

[jmh530 via Digitalmars-d-announce]

On Wednesday, 18 May 2016 at 20:10:09 UTC, Jonathan M Davis wrote:


At this point, if anyone ever calls front with parens, they're 
doing it wrong.


Is this true of all @property functions? Should this be noted in 
the spec? Should it be an error? If it shouldn't be an error, is 
it really such a bad thing?

Re: D's Auto Decoding and You

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, May 17, 2016 17:36:44 H. S. Teoh via Digitalmars-d-announce wrote:
> On Tue, May 17, 2016 at 08:19:48PM +, Vladimir Panteleev via 
Digitalmars-d-announce wrote:
> > On Tuesday, 17 May 2016 at 17:26:59 UTC, Steven Schveighoffer wrote:
> > >However, it's perfectly legal for a front function not to be tagged
> > >@property.
> >
> > BTW, where is this coming from? Is it simply an emergent property of
> > the existing implementations of isInputRange and ElementType, or is it
> > actually by design?
>
> This is very bad. The range API does not mandate that .front must be a
> function. I often write ranges where .front is an actual struct variable
> that gets updated by .popFront.  Now you're saying that my range won't
> work with some code, because they call .front() (which is a compile
> error when .front is a variable, not a function)?

At this point, if anyone ever calls front with parens, they're doing it
wrong. The range API checks that accessing front as if it were a variable
works and _not_ whether calling it as a function works. So, front can be a
variable, an enum (though that wouldn't make much sense), a function, or a
property function. All of those are legal. And properly written range-based
code will work with all of them, because it won't use parens.

The only reason to use parens on front would be if it returned a callable,
and since @property doesn't handle that correctly right now (the first set
of parens still call the function, not what it returns), it really doesn't
work correctly to have a range of callables - at least not and call them
without assigning them to a variable first.

> In the old days (i.e., 1-2 years ago), isForwardRange!R will return
> false if .save is not marked @property. I thought isInputRange!R did the
> same for .front, or am I imagining things?  Did somebody change this
> recently?

IIRC save stopped checking for that around dconf of last year, since given
that it's perfectly legit to call normal functions without parens, and there
is no strong property enforcement, it makes no sense to require that save be
a property function. But I don't think that isInputRange ever checked that
front or empty were property functions (and if it did, I don't know that it
would have worked for them to ever be variables - that would depend on how
the check for whether it was a property function was done).

Regardless, anyone who ever calls front or empty with parens is writing bad
code that will not work generically, because that's not what the range API
dictates. That's one reason why I wish that we had strict property
enforcement, but there's no way that we're getting that at this point. So,
while we do have enforcement of how ranges _can_ be used, we don't have
enforcement of how they _are_ used, and I don't expect that we'll ever get
that.

- Jonathan M Davis

Re: mago-mi: GDB/MI compatible frontend for Mago debugger

[Bruno Medeiros via Digitalmars-d-announce]

On 17/05/2016 17:56, Vadim Lopatin wrote:

On Tuesday, 17 May 2016 at 13:04:23 UTC, Bruno Medeiros wrote:

Interesting. I was about to ask what was the main advantage over GDB?
I reckon it is that Mago can debug executables with the COFF and/or
OMF formats, right? (as opposed to GDB's DWARF format)


Mago currently has the best D language support on Windows. Can debug DMD
generated executables.

Do you know any GDB version + compiler version which works ok on Windows?
Even w/o D demangling. At least able to create breakpoints, step,
continue, examining threads, stack frames, local variables. In gdb+gdc
combination I tried, gdb shows global variables instead of stack variables.

Does DDT work ok with GDB on Windows? What compiler can be used to get
GDB debugging working?



While DDT technically work oks with GDB (the GDB from mingw-w64 that 
is), you are right, there isn't a compiler on Windows that supplies 
debug info in the way GDB understands. See https://wiki.dlang.org/Debuggers.


DMD produces debug info COFF or OMF format, which GDB doesn't know 
anything about (nor ever will). LDC should in theory work with DWARF 
info, but this is broken somehow. Not because of LLVM though, since for 
example Rust on Windows works. As for GDC, it doesn't even supply 
binaries for Windows (that target Windows) -  it is not a supported 
platform.


BTW, Eclipse/DDT should in theory work with mago-mi as well, at least if 
the protocol is implemented correctly. Have you tried it? I dunno how 
complete your MI implementation is.


--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: DDT 1.0.0 released.

[Bruno Medeiros via Digitalmars-d-announce]

On 18/05/2016 16:54, E.S. Quinn wrote:

On Tuesday, 17 May 2016 at 14:04:04 UTC, Bruno Medeiros wrote:

New DDT release out: dfmt support, performance improvements to
semantic operations, more build command customization, fixes. Please
see changelog for full list:

https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0

Since DDT has generally been quite stable, and since the current
release is very close to the end-game vision I had for a D IDE - at
least as far as my free time would allow to create - I've decided to
version this as 1.0. I've been working for nearly 8 years on this
project after all (with some intermission periods), so I guess 1.0 was
a bit due... O.o'

I expect it will mainly be small updates from now on, not any major
new features (other than perhaps DCD support).


Is there any chance we'll be able to get an outline view in the project
explorer a la CDT?


Actually yes. (I haven't forgotten about 
https://github.com/DDT-IDE/DDT/issues/106 )


To be more clear what I meant is that I don't expect any major new 
*D-specific* features (other than perhaps DCD support). But DDT uses the 
same framework as the RustDT (https://github.com/RustDT/RustDT) and 
GoClipse (https://github.com/GoClipse/goclipse) IDEs, so I'm still 
planning to work on new features that work across all IDEs.


--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: dxorshift: random number generators from the extended Xorshift family

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Wednesday, 18 May 2016 at 16:12:35 UTC, jmh530 wrote:
On Sunday, 15 May 2016 at 23:34:46 UTC, Joseph Rushton Wakeling 
wrote:


Wrapper implemented here, together with documentation and 
tests:

https://github.com/WebDrake/dxorshift/pull/1

N.B. I'm sticking with the explicit wrapper, because I want to 
be really, really certain that what comes out is an input 
range whose underling RNG can _never_ be copied by value.


Thought you might find this interesting:
http://news.utexas.edu/2016/05/16/computer-science-advance-could-improve-cybersecurity

and reddit discussion:
https://www.reddit.com/r/technology/comments/4jvihm/computer_scientists_have_developed_a_new_method/


Yea, I was looking at that earlier today -- looks interesting!  
It would be good to try to implement it for D.

Re: DDT 1.0.0 released.

[Adil Baig via Digitalmars-d-announce]

Congratulations on the milestone!

I've been an admirer (and regular user!) of your work. +1 I hope we get to
version 2.

A

On Tue, May 17, 2016 at 7:34 PM, Bruno Medeiros via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> New DDT release out: dfmt support, performance improvements to semantic
> operations, more build command customization, fixes. Please see changelog
> for full list:
>
> https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0
>
> Since DDT has generally been quite stable, and since the current release
> is very close to the end-game vision I had for a D IDE - at least as far as
> my free time would allow to create - I've decided to version this as 1.0.
> I've been working for nearly 8 years on this project after all (with some
> intermission periods), so I guess 1.0 was a bit due... O.o'
>
> I expect it will mainly be small updates from now on, not any major new
> features (other than perhaps DCD support).
>
> --
> Bruno Medeiros
> https://twitter.com/brunodomedeiros
>

Re: dxorshift: random number generators from the extended Xorshift family

[Kagamin via Digitalmars-d-announce]

On Wednesday, 18 May 2016 at 16:12:35 UTC, jmh530 wrote:

Thought you might find this interesting:
http://news.utexas.edu/2016/05/16/computer-science-advance-could-improve-cybersecurity

and reddit discussion:
https://www.reddit.com/r/technology/comments/4jvihm/computer_scientists_have_developed_a_new_method/


That's more or less what random.org does.

Re: dxorshift: random number generators from the extended Xorshift family

[jmh530 via Digitalmars-d-announce]

On Sunday, 15 May 2016 at 23:34:46 UTC, Joseph Rushton Wakeling 
wrote:


Wrapper implemented here, together with documentation and tests:
https://github.com/WebDrake/dxorshift/pull/1

N.B. I'm sticking with the explicit wrapper, because I want to 
be really, really certain that what comes out is an input range 
whose underling RNG can _never_ be copied by value.


Thought you might find this interesting:
http://news.utexas.edu/2016/05/16/computer-science-advance-could-improve-cybersecurity

and reddit discussion:
https://www.reddit.com/r/technology/comments/4jvihm/computer_scientists_have_developed_a_new_method/

Re: DDT 1.0.0 released.

[E.S. Quinn via Digitalmars-d-announce]

On Tuesday, 17 May 2016 at 14:04:04 UTC, Bruno Medeiros wrote:
New DDT release out: dfmt support, performance improvements to 
semantic operations, more build command customization, fixes. 
Please see changelog for full list:


https://github.com/DDT-IDE/DDT/releases/tag/v1.0.0

Since DDT has generally been quite stable, and since the 
current release is very close to the end-game vision I had for 
a D IDE - at least as far as my free time would allow to create 
- I've decided to version this as 1.0. I've been working for 
nearly 8 years on this project after all (with some 
intermission periods), so I guess 1.0 was a bit due... O.o'


I expect it will mainly be small updates from now on, not any 
major new features (other than perhaps DCD support).


Is there any chance we'll be able to get an outline view in the 
project explorer a la CDT?

Re: Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 18/05/2016 9:01 AM, Martin Nowak wrote:


Yes, this
https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/dinterpret.d#L3418
is really ugly and complex, but you won't get rid of this inherent
complexity. The e2ir code for AssingExp looks almost the same
https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/e2ir.c#L2466.




IMO this is a different problem, that AssignExp is stupidly complex and 
needs to be split up.



You might imagine that it's easier to work with syntax trees than to
start from scratch but I'm certain that's not true. I'm pretty sure that
the simplest approach is to use the simplest possible
machine-independent bytecode that you can come up with. I had got to the
point of starting that, but I just couldn't face doing it in C++.


All I'm saying is that interpreting the AST to generate bytecode is
going to be as complex as interpreting the AST directly, but then you
still a bytecode interpreter and later might still want a JIT.


The bytecode generator and bytecode interpreter can be debugged (and 
tested!) independently.  So the total amount of code will increase but 
the components themselves will be better isolated and easier to work with.


I don't think a possible future need for a JIT is a good reason to avoid 
an bytecode interpreter.  A large part of the work of adding a new (JIT) 
backend is pinning down the semantics, and adding a bytecode interpreter 
will certainly help to do that.




Using dedicated value types during interpretation instead of recycling
the AST for that will also make the transitions clearer and get rid of
some of the lifetime complexities in the current code.



Meh, sure.  But this feels just as difficult as switching to a simple 
bytecode, without all the benefits.

Re: Beta D 2.071.1-b1

[John Colvin via Digitalmars-d-announce]

On Sunday, 15 May 2016 at 04:40:21 UTC, Martin Nowak wrote:

First beta for the 2.071.1 point release.
A few issues remain to be fixed before the next beta.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.071.1.html


Please report any bugs at https://issues.dlang.org

-Martin


Github tag / release ?

Re: My ACCU 2016 keynote video available online

[Rory McGuire via Digitalmars-d-announce]

On 18 May 2016 1:25 PM, "Bill Hicks via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, 17 May 2016 at 09:34:53 UTC, Rory McGuire wrote:
>>
>>
>> As a South African, I can only say that you are talking nonsense
regarding the horse/zebra joke. If you've been to Africa you will
understand; there really are a lot more Zebra than horses. Although I must
admit I think of horses or Monty Python when I hear hoofbeats.
>>
>> Andrei: Really good talk, thanks for sharing!
>
>
> Don't get it twisted.
>
> There are whites living in South Africa, and they are certainly not
African.  'Africans' refers to the people, the black people, and not all
Africans live in the continent of Africa, because of things like the
slavery.  The fact that Andrei referred to the people is what makes it
racist.  What's the next joke, something about Africans enjoying fried
chicken?

And then what. That the English often enjoy soccer/football?

Stop trying to alienate us. While I'm "white" (more like brown) I'm so
African even my grand parents couldn't get ancestral visas. I also happen
to be Irish so don't even start the slavery BS unless you do your history
research first.

Re: My ACCU 2016 keynote video available online

[Manu via Digitalmars-d-announce]

On 16 May 2016 at 23:46, Andrei Alexandrescu via
Digitalmars-d-announce  wrote:
> Uses D for examples, showcases Design by Introspection, and rediscovers a
> fast partition routine. It was quite well received.
> https://www.youtube.com/watch?v=AxnotgLql0k
>
> Andrei

This isn't the one you said you were going to "destroy concepts" is it?
At dconf, you mentioned a talk for release on some date I can't
remember, and I got the impression you were going to show how C++'s
concepts proposal was broken, and ideally, propose how we can nail it
in D?

Re: My ACCU 2016 keynote video available online

[Bill Hicks via Digitalmars-d-announce]

On Tuesday, 17 May 2016 at 17:31:21 UTC, Piotrek wrote:


If you want to be a troll please go to the Rust forums. They 
need you there to protect "underrepresented minorities".


Piotrek



I'm here to expose the over-represented majority.

Re: My ACCU 2016 keynote video available online

[Bill Hicks via Digitalmars-d-announce]

On Tuesday, 17 May 2016 at 09:34:53 UTC, Rory McGuire wrote:


As a South African, I can only say that you are talking 
nonsense regarding the horse/zebra joke. If you've been to 
Africa you will understand; there really are a lot more Zebra 
than horses. Although I must admit I think of horses or Monty 
Python when I hear hoofbeats.


Andrei: Really good talk, thanks for sharing!


Don't get it twisted.

There are whites living in South Africa, and they are certainly 
not African.  'Africans' refers to the people, the black people, 
and not all Africans live in the continent of Africa, because of 
things like the slavery.  The fact that Andrei referred to the 
people is what makes it racist.  What's the next joke, something 
about Africans enjoying fried chicken?

ggplotd v0.9: Added geomDensity and geomDensity2d support. Documentation improvements

[Edwin van Leeuwen via Digitalmars-d-announce]

I’d like to announce a new release of the ggplotd plotting 
library.

https://github.com/BlackEdder/ggplotd

Main changes are:

User visible change:

- geomDensity and geomDensity2D (kernel smoothed hist and hist2d)
- Browseable api documentation using harbored-mod
- Updates to documentation
- Some deprecations due to moving/renaming
- mergeRange moved to ggplotd.range
- geomHist3D renamed to geomHist2D

Other changes:

- Addition of ggplotd.stat module
- Split some geom functions into separate geom and stat part
- Many refactors




Plotcli: https://github.com/BlackEdder/plotd

A new version of plotcli has also been released, which depends on 
the new ggplotd version. As a result plotcli can now also create 
density and density2d plots (which are basically smoothed 
histograms).