Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 05:43:58 UTC, KingJoffrey wrote:


Also, having a C++ like spec, written by the elite, for the 
elite, and then everyone else has to wait until some kind 
person explains the spec, is really not a great model.


It's equivalent to the elitist view of trickle down economics - 
which is not working in my country.


oh, and btw, even the elite don't truly understand the tool. 
they, they like all people, understand bit and pieces of this and 
that, some bits more than others, some less than others.


Please find me the number of C++ programmers who understand C++.

https://www.youtube.com/watch?v=YAP_xTsapW0

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 04:25:40 UTC, Jonathan M Davis wrote:
I think that really what you want is something that's geared 
more towards teaching the language. The ways that the language 
spec needs to be improved really revolve around making it a 
proper spec, which means making it far more precise, not making 
it more amenable to folks reading it in order to learn the 
language. But unfortunately, what we have right now is kind of 
in the middle. It's not precise enough to really be a proper 
spec, and it's generally terse enough that it's harder to use 
it as a learning resource (though it usually has the necessary 
information in it).


- Jonathan M Davis


Also, having a C++ like spec, written by the elite, for the 
elite, and then everyone else has to wait until some kind person 
explains the spec, is really not a great model.


It's equivalent to the elitist view of trickle down economics - 
which is not working in my country.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 04:25:40 UTC, Jonathan M Davis wrote:
The ways that the language spec needs to be improved really 
revolve around making it a proper spec, which means making it 
far more precise, not making it more amenable to folks reading 
it in order to learn the language.


I love it. I'll add that to my list of 'D forum qoutes'.

Re: Sealed classes - would you want them in D?

[dlang user via Digitalmars-d]

On 05/15/2018 04:05 PM, Jonathan M Davis wrote:

On Tuesday, May 15, 2018 12:21:23 Dlang User via Digitalmars-d wrote:

On 5/15/2018 10:17 AM, aliak wrote:

On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:

The way you use the word "leak" make is sounds that this is
unintentional, while in reality it is intentional by design. That why
reading the specification is important!

Alexander


Ya I guess you be right - but a leak is what it is to people who expect
private to mean private. Which is not a small number of people ;)

And while I agree reading a spec is important. Language specs are not
known for being trivial to go through and it's not really something you
read but more of something you refer to, and that also probably for more
advanced developers. This is not something you can expect newcomers or
even intermediate level devs to go through. And the less you need to
refer to a spec the better (i.e. more intuitive) a language is.


I concur with that.  When I first started learning D (coming from a C#
background), I figured that I already knew all of the OOP stuff and
didn't dig too deeply into it, figuring that it worked pretty close to
the same as C#.  It did catch me off guard when I first realized how it
really worked in D.  But the work around (putting it in its own module),
seemed pretty trivial and is what I typically do in C# anyways, so it
didn't bother me too much.


I think that if there's an actual problem here, it's the fact that how
private works in D is surprising to folks coming from languages like C++,
C#, or Java. IMHO, D's approach works extremely well, but if you don't
understand what it is, you risk problems, just like with any other feature
that you don't understand properly. And to better deal with that, we
probably need more in the way of documentation geared towards teaching
newbies. The "spec" is pretty poor in that it's not precise enough to be a
spec, meaning that it doesn't really do its job in that respect, but it's
also not really written with the idea that it's teaching someone, so it
doesn't do a great job teaching the language either. There's a lot of great
information there, but it's ultimately not all that accessible for many
folks.

Though if someone expects to be able to just jump into any language and use
it without reading up on how it works, they're just shooting themselves in
the foot. And surprisingly often, that seems to be how many folks operate.

Ultimately, if newcomers don't want to be tripped up on stuff like this,
their best bet is probably to read books like Andrei's "The D Programming
Language" and Ali's "Programming in D."

https://wiki.dlang.org/Books

- Jonathan M Davis



To clarify myself a little bit, the main points that I was agreeing with 
were:


1. I think there are significant number of people coming from other 
languages that are going to get tripped up by D's module level 
encapsulation, mainly because it happened to me.


2. The spec is hard to use as a training resource, because I tried to 
use it and didn't have a good experience with it.


I ended up reading all of the free material that I could find (including 
the Programming in D book).


I also wasn't trying say anything about D's encapsulation being right or 
wrong, just that it tripped me up initially, and that now that I know 
how it works, it isn't a big deal for me.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 03:52:43 UTC, Uknown wrote:


One is expected to know the tool they are using. There is 
nothing elitist about that.




That is a pathetic, and yet another elitist view.

If programmers never programmed until they 'understood the tool', 
there would not be 20+ million programmers in the world.


How many C++ programmers understand C++ (let alone have read the 
spec).


The same can be asked for pretty much any other language.

Learning is still a gradual process - except for elitists it 
seems, who expect you to know everything up front.


There is no if. You know what the stop sign means because 
someone told you what it means. private means it is only 
available to the module. It is entirely the fault of the user 
for not reading the docs.




Another elitist view.



Its actively being improved, but in this case it was more than 
adequate. The spec was pretty clear that private applies to 
modules.


I disagree.

Re: Sealed classes - would you want them in D?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, May 16, 2018 03:36:39 KingJoffrey via Digitalmars-d wrote:
> On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis wrote:
> > It specifies what private does quite accurately. If you want
> > something that's trying to point out how you might
> > misunderstand the spec or what problems you might run into,
> > you'll need to read something like Ali's book. The spec is
> > telling you how the language works, not trying to tell you how
> > you might misunderstand it or what misakes you might make. And
> > the information it gives there is quite accurate and complete.
> > Honestly, I would have thought that knowing that private is
> > private to the module would be plenty to understand what that
> > then means for structs or classes, but everyone thinks
> > differently and absorbs or misses different pieces of
> > information. But ultimately, anyone who doesn't understand
> > something is free to ask in places like D.Learn or
> > stackoverflow.
> >
> > - Jonathan M Davis
>
> To suggest that "Symbols with private visibility can only be
> accessed from within the same module" - is all you need to know
> (if you're lucky to find the needle in the haystack), is kinda
> elitist.
>
> People expect norms to be the norm. That's entirely reasonable.
>
> If I see a STOP sign while I'm driving, I expect it means STOP,
> not 'STOP..if.."
>
> If I see private, I expect it means private, not 'private..if'.

I don't see why it would be elitist to expect folks to read the spec and
assume that it means what it says. It's always a risk that someone is going
to assume that a language that they're learning works the same way as a
language that they know even if it doesn't, but anyone learning a new
language needs to take into account the fact that every language works
differently, and you need to read up on how the language you're learning
actually works if you want to avoid misunderstanding stuff. private is far
from the only feature in D that doesn't work quite like it does in other
languages.

> The language reference could, and should do better.

I think that really what you want is something that's geared more towards
teaching the language. The ways that the language spec needs to be improved
really revolve around making it a proper spec, which means making it far
more precise, not making it more amenable to folks reading it in order to
learn the language. But unfortunately, what we have right now is kind of in
the middle. It's not precise enough to really be a proper spec, and it's
generally terse enough that it's harder to use it as a learning resource
(though it usually has the necessary information in it).

- Jonathan M Davis

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Wednesday, 16 May 2018 at 03:36:39 UTC, KingJoffrey wrote:
On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis 
wrote:


[...]
- Jonathan M Davis


To suggest that "Symbols with private visibility can only be 
accessed from within the same module" - is all you need to know 
(if you're lucky to find the needle in the haystack), is kinda 
elitist.


One is expected to know the tool they are using. There is nothing 
elitist about that.



People expect norms to be the norm. That's entirely reasonable.

If I see a STOP sign while I'm driving, I expect it means STOP, 
not 'STOP..if.."


If I see private, I expect it means private, not 'private..if'.


There is no if. You know what the stop sign means because someone 
told you what it means. private means it is only available to the 
module. It is entirely the fault of the user for not reading the 
docs.



The language reference could, and should do better.


Its actively being improved, but in this case it was more than 
adequate. The spec was pretty clear that private applies to 
modules.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis wrote:


It specifies what private does quite accurately. If you want 
something that's trying to point out how you might 
misunderstand the spec or what problems you might run into, 
you'll need to read something like Ali's book. The spec is 
telling you how the language works, not trying to tell you how 
you might misunderstand it or what misakes you might make. And 
the information it gives there is quite accurate and complete. 
Honestly, I would have thought that knowing that private is 
private to the module would be plenty to understand what that 
then means for structs or classes, but everyone thinks 
differently and absorbs or misses different pieces of 
information. But ultimately, anyone who doesn't understand 
something is free to ask in places like D.Learn or 
stackoverflow.


- Jonathan M Davis


To suggest that "Symbols with private visibility can only be 
accessed from within the same module" - is all you need to know 
(if you're lucky to find the needle in the haystack), is kinda 
elitist.


People expect norms to be the norm. That's entirely reasonable.

If I see a STOP sign while I'm driving, I expect it means STOP, 
not 'STOP..if.."


If I see private, I expect it means private, not 'private..if'.

The language reference could, and should do better.

Re: Sealed classes - would you want them in D?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, May 16, 2018 02:39:22 KingJoffrey via Digitalmars-d wrote:
> On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:
> > Though if someone expects to be able to just jump into any
> > language and use it without reading up on how it works, they're
> > just shooting themselves in the foot. And surprisingly often,
> > that seems to be how many folks operate.
>
> And that comment is a little unfair don't you think?

Is it? How many programmers just start trying to program in D without
actually reading much of anything about it? We not only have the spec but
multiple books on the language - some of which are available for free - and
yet plenty of programmers (regardless of the language) seem to think that
they can just start programming in a language and only look up stuff when
they run into a problem and yet expect to have that work well without
running into serious problems. Anyone taking that approach is just begging
for trouble. Obviously, not everyone does that, but a suprisingly large
number of programmers seem to. We try to help such folks when they do ask
questions, but plenty of questions that get asked clearly show that the
person asking the question has not studied the language much at all.

> The best clarification I can find, regarding how D treat's
> private, is from this tiny little sentence (from which, I assume,
> the programmer is now meant to understand it's full implications):
>
> "Symbols with private visibility can only be accessed from within
> the same module"
>
> https://dlang.org/spec/attribute.html#visibility_attributes

It specifies what private does quite accurately. If you want something
that's trying to point out how you might misunderstand the spec or what
problems you might run into, you'll need to read something like Ali's book.
The spec is telling you how the language works, not trying to tell you how
you might misunderstand it or what misakes you might make. And the
information it gives there is quite accurate and complete. Honestly, I would
have thought that knowing that private is private to the module would be
plenty to understand what that then means for structs or classes, but
everyone thinks differently and absorbs or misses different pieces of
information. But ultimately, anyone who doesn't understand something is free
to ask in places like D.Learn or stackoverflow.

- Jonathan M Davis

Re: Splitting up large dirty file

[Jon Degenhardt via Digitalmars-d-learn]

On Tuesday, 15 May 2018 at 20:36:21 UTC, Dennis wrote:

I have a file with two problems:
- It's too big to fit in memory (apparently, I thought 1.5 Gb 
would fit but I get an out of memory error when using 
std.file.read)
- It is dirty (contains invalid Unicode characters, null bytes 
in the middle of lines)


I want to write a program that splits it up into multiple 
files, with the splits happening every n lines. I keep 
encountering roadblocks though:


- You can't give Yes.useReplacementChar to `byLine` and 
`byLine` (or `readln`) throws an Exception upon encountering an 
invalid character.


Can you show the program you are using that throws when using 
byLine? I tried a very simple program that reads and outputs 
line-by-line, then fed it a file that contained invalid utf-8. I 
did not see an exception. The invalid utf-8 was created by taking 
part of this file: 
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt (a 
commonly used file with utf-8 edge cases), plus adding a number 
of random hex characters, including null. I don't see exceptions 
thrown.


The program I used:

int main(string[] args)
{
import std.stdio;
import std.conv : to;
try
{
auto inputStream = (args.length < 2 || args[1] == "-") ? 
stdin : args[1].File;
foreach (line; inputStream.byLine(KeepTerminator.yes)) 
write(line);

}
catch (Exception e)
{
stderr.writefln("Error [%s]: %s", args[0], e.msg);
return 1;
}
return 0;
}

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 19:56:58 UTC, Patrick Schluter wrote:

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:

On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:

[...]


If 'getting a module to respect the enscapsulation 
boundaries the programmer puts in place would change the 
language so 'fundamentally', then the language 'already' 
presents big problems for large complex application 
development.



Evidence for this claim please.


- Object independence
- Do not violate encapsulation
- Respect the interface

All large software projects are done in (or moving toward) 
languages that respect these idioms.


Those that don't, are the ones we typically have problems with.

Isn't that evidence enough?


That's not evidence, that's pure opinion. There's not a shred 
of data in that list.


Actually, that is the history of the evolution of programming 
large, complex systems, that have to be to correct, safe, and 
amenable to change.


What other approach would work?

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:


Though if someone expects to be able to just jump into any 
language and use it without reading up on how it works, they're 
just shooting themselves in the foot. And surprisingly often, 
that seems to be how many folks operate.




And that comment is a little unfair don't you think?

The best clarification I can find, regarding how D treat's 
private, is from this tiny little sentence (from which, I assume, 
the programmer is now meant to understand it's full implications):


"Symbols with private visibility can only be accessed from within 
the same module"


https://dlang.org/spec/attribute.html#visibility_attributes

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Wednesday, 16 May 2018 at 02:15:45 UTC, KingJoffrey wrote:


"The unit of object encapsulation in D is the class." - page 
175, The D Programming Language, 2010, Andrei Alexandrescu.


What it really should have included, locally, within that same 
section, is the implications of this 'encapsulation' with 
regards to how 'facebook like friendship' is a core design 
component of the D module.


i.e, on the next line, Andrei could have continued..

"However, if your class is contained within a module, then this 
encapsulation barrier kinda breaks down, because everything in 
the module becomes a friend of that class, whether you like it 
or not. You have no say in the matter. If you don't like it, 
fine, but that's how D does things, so just be careful what you 
put in a module".


Although, to be fair to Andrei, once you get to page 200 (25 
pages after the above comment about class encapsulation), you do, 
finally, get some clarification:


"In all contexts, private has the same power: it restricts symbol 
access to the current module (file). This behavior is unlike that 
in other languages, which limit access to private symbols to the 
current class only. ...  If class-level protection is needed, 
simply put the class in its own file."

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:


Ultimately, if newcomers don't want to be tripped up on stuff 
like this, their best bet is probably to read books like 
Andrei's "The D Programming Language" and Ali's "Programming in 
D."




"The unit of object encapsulation in D is the class." - page 175, 
The D Programming Language, 2010, Andrei Alexandrescu.


What it really should have included, locally, within that same 
section, is the implications of this 'encapsulation' with regards 
to how 'facebook like friendship' is a core design component of 
the D module.


i.e, on the next line, Andrei could have continued..

"However, if your class is contained within a module, then this 
encapsulation barrier kinda breaks down, because everything in 
the module becomes a friend of that class, whether you like it or 
not. You have no say in the matter. If you don't like it, fine, 
but that's how D does things, so just be careful what you put in 
a module".

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 15:19:33 UTC, Jesse Phillips wrote:

On Tuesday, 15 May 2018 at 10:19:58 UTC, KingJoffrey wrote:
My own code in D had bugs, cause I didn't realise all my 
private parts were not just visible, but accessible by all the 
so called 'friends' around me. They could reach in a do 
whatever they want! Without my consent!


You've peaked my interest, could you give some details on one 
or more of these bugs?


It's simple.

Write a non-member function, contained in the same module as a 
class, and accidently use a private class member instead of the 
public getter/setter defined by the interface of that class.


It's human error, that will occur time and time again, but will 
*never* get picked up in D, except through a debugging session, 
because D does not consider this an error.


How can it, if private is not really private?

Now the burden is back on the programmer again.

Be careful what you put into a module.

[Issue 18821] DMD segfault when doing unsafe operation outside of any function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18821

--- Comment #7 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8251

--

[Issue 18821] DMD segfault when doing unsafe operation outside of any function

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18821

Walter Bright  changed:

   What|Removed |Added

Summary|DMD segfault 2.080  |DMD segfault when doing
   ||unsafe operation outside of
   ||any function

--

[Issue 18821] DMD segfault 2.080

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18821

Walter Bright  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

Re: DIP 1011 library alternative

[Jonathan Marler via Digitalmars-d]

On Tuesday, 15 May 2018 at 21:25:05 UTC, Andrei Alexandrescu 
wrote:
Hello, I was reviewing again DIP 1011 and investigated a 
library solution. That led to


https://gist.github.com/run-dlang/18845c9df3d73e45c945feaccfebfcdc

It builds on the opening examples in:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md

I'm displeased at two aspects of the implementation:

* Perfect forwarding is tedious to implement: note that 
makeDelegate hardcodes void as the return type and (int, float) 
as parameter types. Ideally it should accept any parameters 
that the alias passes.


* Pass-by-alias and overloading interact poorly. Does anyone 
know how to refer by alias to one specific overload?



Thanks,

Andrei


Now that I've had a chance to look the example you've shared, the 
only comment I'd make is that DIP1011 aims to allow applications 
to create "delegate-compatible" functions that don't require 
generating a wrapper function to forward a delegate call to the 
function at runtime  In this example, 2 functions have been 
defined that take a class and a struct pointer as the first 
argument, however, these function are not ABI compatible with the 
delegate ABI meaning you will have to generate a runtime 
"conversion" function to forward a delegate call to call the 
function.


extern(delegate) allows the application to generate the function 
using the delegate ABI in the first place so no "conversion" is 
necessary. To achieve this with a libary solution, you need to 
modify the function definition itself, not just create a wrapper 
around it.

[Issue 18853] std.allocator: AllocatorList fails to allocate after a deallocation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18853

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Vladimir Panteleev  ---
This was fixed by https://github.com/dlang/phobos/pull/6462.

--

Re: Extend the call site default argument expansion mechanism?

[Computermatronic via Digitalmars-d]

On Tuesday, 15 May 2018 at 20:31:14 UTC, jmh530 wrote:

On Tuesday, 15 May 2018 at 15:02:36 UTC, jmh530 wrote:

[snip]



Note, it's not an issue if Foo were not a struct. This was 
fixed in Bug 6400 [1]l. The issue is with template instances. I 
have filed a new enhancement request [2]


[1] https://issues.dlang.org/show_bug.cgi?id=6400
[2] https://issues.dlang.org/show_bug.cgi?id=18863


Interestingly, you can get pretty close with a struct nested in a 
template function, however it seems that overload resolution does 
not check opDispatch if a public symbol of the same name exists.


this (https://run.dlang.io/is/ZzfWDs) dosen't work, but this 
(https://run.dlang.io/is/7zvfqc) does (notice SList & DList are 
not directly visible).

Re: Why is 64-bit dmd not built as part of the Windows release?

[Walter Bright via Digitalmars-d]

On 5/15/2018 3:13 PM, Atila Neves wrote:
I'm sure there's a good reason why there's no pre-built 64-bit dmd for Windows, 
I just don't know what it is.


Part of it is there was no Win64 bit code generation capability for quite a 
while.

Then there was the issue of VC not supporting 80 bit reals.

But I think these are resolved now.

Re: Why is 64-bit dmd not built as part of the Windows release?

[Walter Bright via Digitalmars-d]

On 5/15/2018 3:15 PM, Atila Neves wrote:

https://issues.dlang.org/show_bug.cgi?id=18864


:-)

[Issue 18854] std.allocator: StatsCollector counts failed deallocations

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18854

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Vladimir Panteleev  ---
StatsCollector.deallocate is "Defined whether or not `Allocator.deallocate` is
defined". I'm really not sure this was a great idea, because it opens the door
to silent memory leaks, and breaks introspection of any allocators that might
use this information to switch to a different method of tracking allocations.

There's two ways to fix this:

- Make deallocate always return false (and not count allocations) when
ParentAllocator doesn't support deallocation.
- Don't define deallocate if the parent allocator doesn't.

I feel like the first one would defeat the point of always having a deallocate
method. Still, the way things are now is obviously broken.

Andrei, any thoughts?

--

[Issue 18848] std.allocator: Regions are non-copyable, yet are passed around in examples

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18848

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/dlang/phobos/pull/6509

See the comment there for more discussion.

--

[Issue 18847] std.allocator: Region uses .parent before it can be set

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18847

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Vladimir Panteleev  ---
https://github.com/dlang/phobos/pull/6508

--

Re: DIP 1011 library alternative

[Mike Franklin via Digitalmars-d]

On Tuesday, 15 May 2018 at 22:26:54 UTC, Jonathan M Davis wrote:


I _think_ that it only works if the function isn't templated.


A PR to remove that limitation has been submitted at 
https://github.com/dlang/dmd/pull/8195, but once again, we're 
waiting on someone from the top to give it their blessing.


Mike

Re: Sealed classes - would you want them in D?

[Neia Neutuladh via Digitalmars-d]

On Tuesday, 15 May 2018 at 21:05:10 UTC, Jonathan M Davis wrote:
Though if someone expects to be able to just jump into any 
language and use it without reading up on how it works, they're 
just shooting themselves in the foot. And surprisingly often, 
that seems to be how many folks operate.


It works pretty well because programming languages tend to be 
very similar. Knowing Java, you can pretty much just write C#. 
Knowing C++ and a bit of lore, you can transition to Java pretty 
easily. But it's a lot harder to transition from C# to F#, for 
instance, or to OCaml, or METAFONT.


You might be surprised that some things are missing. You might 
not know about some things that would help you. You might be 
writing code inefficiently, and you will likely write code that's 
not idiomatic, that's hard for others to read. But you can still 
get things done.


And then you encounter things that break, and you look for other 
ways of doing that.


D's protection attributes are not that different from Java's, so 
things look the same at first. And when they're different, they 
differ in a hard-to-spot way.


There isn't much cure for this.

Re: Arduino and D

[Filipe Laíns via Digitalmars-d]

On Saturday, 25 October 2014 at 22:55:12 UTC, Israel wrote:

On Saturday, 25 October 2014 at 21:49:53 UTC, Ty Tower wrote:
Has anybody tapped the massive Arduino programming explosion 
using D instead of C++ ?
I got started on Arduino a few years back and it has taken the 
microprocessor popularity through the roof .
Unfortunately you download the IDE (Integrated Development 
Environment) from Arduino.cc direct and then using a $3 
development board with a 328p chip on it ,proceed to program 
the  chip to do pretty much whatever you can think of 
including turning stuff on with your mobile from anywhere in 
the world  and much much more .


I wondered if someone could adapt it to D ?


Well it is ARM so it should be possible.


Actually, most arduinos use Atmel's chips so most of them are AVR.
Apparently, there was some work done to port GDC to AVR [1]. I 
don't really know the usability of this but I suspect it's not 
much.


If you want a board with similar size too small arduino like the 
pro/pro mini that has an ARM chip, you should have a look at 
Teensy[2]. Using D to program ARM chips shouldn't be that hard.


[1] https://github.com/D-Programming-microD/GDC/tree/microD-4.9
[2] https://www.pjrc.com/teensy/

Re: DIP 1011 library alternative

[Jonathan M Davis via Digitalmars-d]

On Tuesday, May 15, 2018 17:25:05 Andrei Alexandrescu via Digitalmars-d 
wrote:
> * Pass-by-alias and overloading interact poorly. Does anyone know how to
> refer by alias to one specific overload?

AFAIK, the only way that something like that could be done would be to use
__traits(getOverloads, ...) to get at the correct overload, which is a bit
of a pain, and I _think_ that it only works if the function isn't templated.

- Jonathan M Davis

Re: Why is 64-bit dmd not built as part of the Windows release?

[Atila Neves via Digitalmars-d]

On Tuesday, 15 May 2018 at 19:43:25 UTC, Walter Bright wrote:

On 5/15/2018 9:01 AM, Atila Neves wrote:
I just spent 45min trying to build 64-bit dmd on Windows. It 
wasn't fun.


Please file this post on bugzilla.


https://issues.dlang.org/show_bug.cgi?id=18864

Re: Why is 64-bit dmd not built as part of the Windows release?

[Atila Neves via Digitalmars-d]

On Tuesday, 15 May 2018 at 19:54:03 UTC, Ethan Watson wrote:

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:

Isn't it just make -f win64.mak?", I hear you ask.


I wouldn't ask that. Every time I need a 64-bit dmd, I open the 
project in src/vcbuild and let Visual Studio and Visual D take 
care of it.


Unfortunately, that doesn't work so well when one is trying to 
automate the provisioning of a Windows dev/CI box from scratch. I 
guess I could try msbuild on it...


But I agree with the subject entirely. 64-bit DMD is absolutely 
required for my own usage. The Linux platforms have i386/x64 
downloads. OSX is going 64-bit only. Having both packages 
available for Windows would be much appreciated.


I'm sure there's a good reason why there's no pre-built 64-bit 
dmd for Windows, I just don't know what it is.

Re: Why is 64-bit dmd not built as part of the Windows release?

[Atila Neves via Digitalmars-d]

On Tuesday, 15 May 2018 at 19:41:25 UTC, Rubn wrote:

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:

[...]


Which DMD version are you using to compile with?


dmd 2.080.0 installed today.


Yah I have no idea how making the installer works


I know how it works, I just don't know how it built the dmd that 
it packaged.


but it obviously isn't a works by default and needs to be built 
in a certain environment. There isn't any documentation on this 
as far as I know.


Martin posted somewhere about what was needed to build the 
installer. I can't remember where though, and it wouldn't be 
trivial to reproduce, let alone automate. In any case, I can't 
build it myself to find out.


What I do is just grab what is built from appveyor and replace 
the dmd.exe that was installed using the installer. Worked a 
while back not sure if that's still the case:


https://ci.appveyor.com/project/greenify/dmd/build/artifacts


I didn't know that was a thing - it might just be the way 
forward. Thanks!


Atila

[Issue 18864] New: Building 64-bit dmd on Windows results in a debug build. The release build doesn't work.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18864

  Issue ID: 18864
   Summary: Building 64-bit dmd on Windows results in a debug
build. The release build doesn't work.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: atila.ne...@gmail.com

https://forum.dlang.org/post/fiyfbeczwihhsbiud...@forum.dlang.org

--

Re: Why is 64-bit dmd not built as part of the Windows release?

[Atila Neves via Digitalmars-d]

On Tuesday, 15 May 2018 at 17:40:46 UTC, 12345swordy wrote:

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:

[...]


Wait, dmd doesn't use cmake to generate the makefile!? IMO this 
is the reason why configuration tools like cmake exist.


CMake? Hah, no. They're hand crafted Makefiles written with 
quills.

Re: Why is 64-bit dmd not built as part of the Windows release?

[Atila Neves via Digitalmars-d]

On Tuesday, 15 May 2018 at 18:20:29 UTC, Stefan Koch wrote:

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
I don't know why even bother with 32-bit dmd to begin with, 
but at least there should be an option.


[...]


You need to do make clean.
As the backend build with debug symbols will be ABI 
incompatible to the release frontend.


make clean on a just-cloned git repo?

Re: DIP 1011 library alternative

[Ali Çehreli via Digitalmars-d]

For convenience:

  https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md

Ali

Re: Question over C++ to D conversion

[Filipe Laíns via Digitalmars-d]

On Tuesday, 15 May 2018 at 22:07:02 UTC, Filipe Laíns wrote:

On Tuesday, 15 May 2018 at 21:00:25 UTC, Richard wrote:

On Monday, 12 March 2018 at 03:42:41 UTC, jmh530 wrote:

On Monday, 12 March 2018 at 02:48:17 UTC, Laeeth Isharc wrote:

[snip]
For conversion of C headers, watch this space.  C first, C++ 
eventually.  Might be a talk at Dconf on it.


I think I saw a reference to this somewhere else. Sounds 
pretty darn cool.


This might be it
https://github.com/atilaneves/dpp
I noticed it mentioned on the online DConf 2018 youtube video


Are you aware of DStep? It has been working great for me. The 
only downside is that it doesn't do C++ at all :/ .


https://github.com/jacob-carlborg/dstep


Oh sorry, my mistake. I missed your link above.

Re: Question over C++ to D conversion

[Filipe Laíns via Digitalmars-d]

On Tuesday, 15 May 2018 at 21:00:25 UTC, Richard wrote:

On Monday, 12 March 2018 at 03:42:41 UTC, jmh530 wrote:

On Monday, 12 March 2018 at 02:48:17 UTC, Laeeth Isharc wrote:

[snip]
For conversion of C headers, watch this space.  C first, C++ 
eventually.  Might be a talk at Dconf on it.


I think I saw a reference to this somewhere else. Sounds 
pretty darn cool.


This might be it
https://github.com/atilaneves/dpp
I noticed it mentioned on the online DConf 2018 youtube video


Are you aware of DStep? It has been working great for me. The 
only downside is that it doesn't do C++ at all :/ .


https://github.com/jacob-carlborg/dstep

Re: DIP 1011 library alternative

[Jonathan Marler via Digitalmars-d]

On Tuesday, 15 May 2018 at 21:25:05 UTC, Andrei Alexandrescu 
wrote:
Hello, I was reviewing again DIP 1011 and investigated a 
library solution. That led to


https://gist.github.com/run-dlang/18845c9df3d73e45c945feaccfebfcdc

It builds on the opening examples in:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md

I'm displeased at two aspects of the implementation:

* Perfect forwarding is tedious to implement: note that 
makeDelegate hardcodes void as the return type and (int, float) 
as parameter types. Ideally it should accept any parameters 
that the alias passes.


* Pass-by-alias and overloading interact poorly. Does anyone 
know how to refer by alias to one specific overload?



Thanks,

Andrei


thought this was dead...good to see you're looking into it :)

Re: Question over C++ to D conversion

[Johan Engelen via Digitalmars-d]

On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote:


The first is the use of BetterC, although from what I can tell 
DMD now has support for a minimal runtime feature as part of 
2.079.0

https://dlang.org/changelog/2.079.0.html#minimal_runtime
so hopefully when this makes it's way into LDC I can then make 
use of it for an Arm MCU for creating class's without the full 
runtime.


Have you tried with LDC 1.9.0? (dlang 2.079)
Would be very interesting to hear about your experiences in 
trying to put together / use a minimal runtime.


Cheers,
  Johan

Re: Splitting up large dirty file

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, May 15, 2018 20:36:21 Dennis via Digitalmars-d-learn wrote:
> I have a file with two problems:
> - It's too big to fit in memory (apparently, I thought 1.5 Gb
> would fit but I get an out of memory error when using
> std.file.read)
> - It is dirty (contains invalid Unicode characters, null bytes in
> the middle of lines)
>
> I want to write a program that splits it up into multiple files,
> with the splits happening every n lines. I keep encountering
> roadblocks though:
>
> - You can't give Yes.useReplacementChar to `byLine` and `byLine`
> (or `readln`) throws an Exception upon encountering an invalid
> character.
> - decodeFront doesn't work on inputRanges like
> `byChunk(4096).joiner`
> - std.algorithm.splitter doesn't work on inputRanges either
> - When you convert chunks to arrays, you have the risk of a split
> being in the middle of a character with multiple code units
>
> Is there a simple way to do this?

If you're on a *nix systime, and you're simply looking for a solution to
split files and don't necessarily care about writing one, I'd suggest trying
the split utility:

https://linux.die.net/man/1/split

If I had to write it in D, I'd probably just use std.mmap and operate on the
files as a dynamic array of ubytes, since if what you care about is '\n',
that can easily be searched for without needing any decoding, and using mmap
avoids having to chunk anything.

- Jonathan M Davis

DIP 1011 library alternative

[Andrei Alexandrescu via Digitalmars-d]

Hello, I was reviewing again DIP 1011 and investigated a library 
solution. That led to


https://gist.github.com/run-dlang/18845c9df3d73e45c945feaccfebfcdc

It builds on the opening examples in:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1011.md

I'm displeased at two aspects of the implementation:

* Perfect forwarding is tedious to implement: note that makeDelegate 
hardcodes void as the return type and (int, float) as parameter types. 
Ideally it should accept any parameters that the alias passes.


* Pass-by-alias and overloading interact poorly. Does anyone know how to 
refer by alias to one specific overload?



Thanks,

Andrei

Re: Splitting up large dirty file

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/15/18 4:36 PM, Dennis wrote:

I have a file with two problems:
- It's too big to fit in memory (apparently, I thought 1.5 Gb would fit 
but I get an out of memory error when using std.file.read)
- It is dirty (contains invalid Unicode characters, null bytes in the 
middle of lines)


I want to write a program that splits it up into multiple files, with 
the splits happening every n lines. I keep encountering roadblocks though:


- You can't give Yes.useReplacementChar to `byLine` and `byLine` (or 
`readln`) throws an Exception upon encountering an invalid character.

- decodeFront doesn't work on inputRanges like `byChunk(4096).joiner`
- std.algorithm.splitter doesn't work on inputRanges either
- When you convert chunks to arrays, you have the risk of a split being 
in the middle of a character with multiple code units


Is there a simple way to do this?



Using iopipe, you can split on N lines (iopipe doesn't autodecode when 
searching for newlines), or split on a pre-determined chunk size (and 
ensure you don't split a code point).


Splitting on N lines:

import iopipe.bufpipe;
import iopipe.textpipe;

auto infile = openDev("filename").bufd.assumeText.byLine;

foreach(i; 0 .. N) infile.extend(0); // ensure N lines in the buffer

Splitting on pre-determined chunk size

auto infile = openDev("filename")
.bufd!(ubyte, chunkSize) // use chunkSize as minimum read size
.assumeText // it's text, not ubyte
.ensureDecodeable; // do not end in the middle of a codepoint

The output isn't as straightforward. Ideally you would want to simply 
create an output pipe that split into multiple files, and process the 
whole thing at once. I haven't created such a thing yet though (will add 
an enhancement request to do so).


Easiest thing to do is to write the entire window of the input pipe into 
an output pipe, or cast it back to ubyte[] and write directly to an 
output device.


e.g.:

auto infile = ... // one of the above ideas
   .encodeText; // convert to ubyte

auto outfile = openDev("outputFilename1", "w");
outfile.write(infile.window);
outfile.close;
infile.release(infile.window.length); // flush the input buffer
... // refill the buffer using the chosen technique above.

-Steve

Re: Sealed classes - would you want them in D?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, May 15, 2018 12:21:23 Dlang User via Digitalmars-d wrote:
> On 5/15/2018 10:17 AM, aliak wrote:
> > On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:
> >> The way you use the word "leak" make is sounds that this is
> >> unintentional, while in reality it is intentional by design. That why
> >> reading the specification is important!
> >>
> >> Alexander
> >
> > Ya I guess you be right - but a leak is what it is to people who expect
> > private to mean private. Which is not a small number of people ;)
> >
> > And while I agree reading a spec is important. Language specs are not
> > known for being trivial to go through and it's not really something you
> > read but more of something you refer to, and that also probably for more
> > advanced developers. This is not something you can expect newcomers or
> > even intermediate level devs to go through. And the less you need to
> > refer to a spec the better (i.e. more intuitive) a language is.
>
> I concur with that.  When I first started learning D (coming from a C#
> background), I figured that I already knew all of the OOP stuff and
> didn't dig too deeply into it, figuring that it worked pretty close to
> the same as C#.  It did catch me off guard when I first realized how it
> really worked in D.  But the work around (putting it in its own module),
> seemed pretty trivial and is what I typically do in C# anyways, so it
> didn't bother me too much.

I think that if there's an actual problem here, it's the fact that how
private works in D is surprising to folks coming from languages like C++,
C#, or Java. IMHO, D's approach works extremely well, but if you don't
understand what it is, you risk problems, just like with any other feature
that you don't understand properly. And to better deal with that, we
probably need more in the way of documentation geared towards teaching
newbies. The "spec" is pretty poor in that it's not precise enough to be a
spec, meaning that it doesn't really do its job in that respect, but it's
also not really written with the idea that it's teaching someone, so it
doesn't do a great job teaching the language either. There's a lot of great
information there, but it's ultimately not all that accessible for many
folks.

Though if someone expects to be able to just jump into any language and use
it without reading up on how it works, they're just shooting themselves in
the foot. And surprisingly often, that seems to be how many folks operate.

Ultimately, if newcomers don't want to be tripped up on stuff like this,
their best bet is probably to read books like Andrei's "The D Programming
Language" and Ali's "Programming in D."

https://wiki.dlang.org/Books

- Jonathan M Davis

Re: Question over C++ to D conversion

[Richard via Digitalmars-d]

On Monday, 12 March 2018 at 03:42:41 UTC, jmh530 wrote:

On Monday, 12 March 2018 at 02:48:17 UTC, Laeeth Isharc wrote:

[snip]
For conversion of C headers, watch this space.  C first, C++ 
eventually.  Might be a talk at Dconf on it.


I think I saw a reference to this somewhere else. Sounds pretty 
darn cool.


This might be it
https://github.com/atilaneves/dpp
I noticed it mentioned on the online DConf 2018 youtube video

Splitting up large dirty file

[Dennis via Digitalmars-d-learn]

I have a file with two problems:
- It's too big to fit in memory (apparently, I thought 1.5 Gb 
would fit but I get an out of memory error when using 
std.file.read)
- It is dirty (contains invalid Unicode characters, null bytes in 
the middle of lines)


I want to write a program that splits it up into multiple files, 
with the splits happening every n lines. I keep encountering 
roadblocks though:


- You can't give Yes.useReplacementChar to `byLine` and `byLine` 
(or `readln`) throws an Exception upon encountering an invalid 
character.
- decodeFront doesn't work on inputRanges like 
`byChunk(4096).joiner`

- std.algorithm.splitter doesn't work on inputRanges either
- When you convert chunks to arrays, you have the risk of a split 
being in the middle of a character with multiple code units


Is there a simple way to do this?

Re: Extend the call site default argument expansion mechanism?

[jmh530 via Digitalmars-d]

On Tuesday, 15 May 2018 at 15:02:36 UTC, jmh530 wrote:

[snip]



Note, it's not an issue if Foo were not a struct. This was fixed 
in Bug 6400 [1]l. The issue is with template instances. I have 
filed a new enhancement request [2]


[1] https://issues.dlang.org/show_bug.cgi?id=6400
[2] https://issues.dlang.org/show_bug.cgi?id=18863

[Issue 18863] New: opDispatch with WithStatement & Template Instance

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18863

  Issue ID: 18863
   Summary: opDispatch with WithStatement & Template Instance
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.michael.h...@gmail.com

The with statement does not check opDispatch with template instances. An older
bug (#6400) was resolved fixing the case of a symbol. This enhancement is for
template instances.

See below:

struct Foo(int x)
{
auto opDispatch(string s)()
if (s == "bar")
{
x++;
return x;
}
}


void main()
{
int y = 0;
with(Foo!1)
{
y = bar; //error: undefined identifier bar
}
assert(y == 2);
}

By contrast, the following compiles without error

struct Foo
{
int x;
auto opDispatch(string s)()
if (s == "bar")
{
x++;
return x;
}
}


void main()
{
int y = 0;
with(Foo(1))
{
y = bar;
}
assert(y == 2);
}


Discussion thread:
https://forum.dlang.org/thread/becssptpaecvxddbr...@forum.dlang.org

--

Re: Why is 64-bit dmd not built as part of the Windows release?

[Meta via Digitalmars-d]

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
I don't know why even bother with 32-bit dmd to begin with, but 
at least there should be an option.


I just spent 45min trying to build 64-bit dmd on Windows. It 
wasn't fun. "Isn't it just make -f win64.mak?", I hear you ask. 
Yes. If you want a version with debug messages turned on. It 
took me 45min to learn that disabling those is... non-trivial.


As it turns out, trying to build dmd yourself from the released 
tag and replacing the .exe from the installer by the one you 
created works, unless:


1. You remove -debug
2. You add -O

If you do #1 or #2, then the produced dmd.exe doesn't work. At 
all. 32 *or* 64 bits. And this is something you need to edit 
the makefile for, trying to do that from the command line was 
an exercise in futility.


"How does the installer-built version work then?", I again hear 
you ask. No idea. Debug 64-bit dmd it is!


I *would* try and add a 64-bit dmd to the installer, but 
apparently to build the Windows installer you need a special 
Windows box commisioned by the Vatican and blessed by the Pope 
himself.


Atila


I haven't tried 64-bit builds in awhile, but every time I try to 
build on Windows I run into some new issue that I have to work 
through. Just recently there was a check added to the build 
process which fails if there are Windows line endings in any 
source files, which IMO is insane since you're just building, not 
committing.

Re: Sealed classes - would you want them in D?

[Patrick Schluter via Digitalmars-d]

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:

On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:

[...]


If 'getting a module to respect the enscapsulation boundaries 
the programmer puts in place would change the language so 
'fundamentally', then the language 'already' presents big 
problems for large complex application development.



Evidence for this claim please.


- Object independence
- Do not violate encapsulation
- Respect the interface

All large software projects are done in (or moving toward) 
languages that respect these idioms.


Those that don't, are the ones we typically have problems with.

Isn't that evidence enough?


That's not evidence, that's pure opinion. There's not a shred of 
data in that list.

Re: Two really good looking GUI libraries that can work for D

[aberba via Digitalmars-d]

On Saturday, 12 May 2018 at 19:16:32 UTC, Basile B. wrote:

On Friday, 11 May 2018 at 21:43:24 UTC, aberba wrote:

[...]


I didn't know this one and it looks nice, maybe not too adapted 
to big desktop apps.
Based on the screenshots this looks more designed for 
skeuomorphic UIs or small UIs, e.g mobile dev.


Its actually for embedded systems.

Re: Why is 64-bit dmd not built as part of the Windows release?

[Ethan Watson via Digitalmars-d]

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:

Isn't it just make -f win64.mak?", I hear you ask.


I wouldn't ask that. Every time I need a 64-bit dmd, I open the 
project in src/vcbuild and let Visual Studio and Visual D take 
care of it.


But I agree with the subject entirely. 64-bit DMD is absolutely 
required for my own usage. The Linux platforms have i386/x64 
downloads. OSX is going 64-bit only. Having both packages 
available for Windows would be much appreciated.

Re: Why is 64-bit dmd not built as part of the Windows release?

[Rubn via Digitalmars-d]

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
I don't know why even bother with 32-bit dmd to begin with, but 
at least there should be an option.


I just spent 45min trying to build 64-bit dmd on Windows. It 
wasn't fun. "Isn't it just make -f win64.mak?", I hear you ask. 
Yes. If you want a version with debug messages turned on. It 
took me 45min to learn that disabling those is... non-trivial.


As it turns out, trying to build dmd yourself from the released 
tag and replacing the .exe from the installer by the one you 
created works, unless:


1. You remove -debug
2. You add -O

If you do #1 or #2, then the produced dmd.exe doesn't work. At 
all. 32 *or* 64 bits. And this is something you need to edit 
the makefile for, trying to do that from the command line was 
an exercise in futility.


"How does the installer-built version work then?", I again hear 
you ask. No idea. Debug 64-bit dmd it is!


I *would* try and add a 64-bit dmd to the installer, but 
apparently to build the Windows installer you need a special 
Windows box commisioned by the Vatican and blessed by the Pope 
himself.


Atila


Which DMD version are you using to compile with? There was an 
issue in DMD a while back that prevented the 64-bit version from 
being compiled.


Yah I have no idea how making the installer works but it 
obviously isn't a works by default and needs to be built in a 
certain environment. There isn't any documentation on this as far 
as I know.


What I do is just grab what is built from appveyor and replace 
the dmd.exe that was installed using the installer. Worked a 
while back not sure if that's still the case:


https://ci.appveyor.com/project/greenify/dmd/build/artifacts

Re: Why is 64-bit dmd not built as part of the Windows release?

[Walter Bright via Digitalmars-d]

On 5/15/2018 9:01 AM, Atila Neves wrote:

I just spent 45min trying to build 64-bit dmd on Windows. It wasn't fun.


Please file this post on bugzilla.

[Issue 18712] [Reg 2.072] bogus "switch skips declaration" error with case in mixin

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18712

Walter Bright  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Component|dmd |dlang.org
 Resolution|WONTFIX |---
   Severity|regression  |normal

--- Comment #6 from Walter Bright  ---
(In reply to Rainer Schuetze from comment #5)
> Thanks for analyzing. I wouldn't be too concerned about possible breakage
> with a fix, because it's a regression (and a very recent if you compiled the
> code with -d).

It's not really a regression. The weirdness with the scope was always there,
it's just that nobody noticed it. When it was implemented, I'm sure nobody
thought about this behavior.


> It seems adding the implicit scope block in the parser is too early, as it
> doesn't know about mixins. OTOH it could be clarified in the spec that
> 'case' in mixins do not share the scope with trailing code.

A spec clarification is indeed in order:

  https://github.com/dlang/dlang.org/pull/2368

Reopening as a spec issue. It is more than just mixins, as the other example I
posted here shows.

I investigated not adding the scope in the parser, but in the semantic() phase.
That just introduces even more subtle issues.

--

Re: Why is 64-bit dmd not built as part of the Windows release?

[Stefan Koch via Digitalmars-d]

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
I don't know why even bother with 32-bit dmd to begin with, but 
at least there should be an option.


[...]


You need to do make clean.
As the backend build with debug symbols will be ABI incompatible 
to the release frontend.

Re: Why is 64-bit dmd not built as part of the Windows release?

[Dmitry Olshansky via Digitalmars-d]

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
I don't know why even bother with 32-bit dmd to begin with, but 
at least there should be an option.


[...]


Far as I know VS project shoukd build x64 version just fine with 
MS C++ compiler. Used to be that way a couple years ago.



As it turns out, trying to build dmd yourself from the released 
tag and replacing the .exe from the installer by the one you 
created works, unless:


[...]

Re: Why is 64-bit dmd not built as part of the Windows release?

[12345swordy via Digitalmars-d]

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
I don't know why even bother with 32-bit dmd to begin with, but 
at least there should be an option.


I just spent 45min trying to build 64-bit dmd on Windows. It 
wasn't fun. "Isn't it just make -f win64.mak?", I hear you ask. 
Yes. If you want a version with debug messages turned on. It 
took me 45min to learn that disabling those is... non-trivial.


As it turns out, trying to build dmd yourself from the released 
tag and replacing the .exe from the installer by the one you 
created works, unless:


1. You remove -debug
2. You add -O

If you do #1 or #2, then the produced dmd.exe doesn't work. At 
all. 32 *or* 64 bits. And this is something you need to edit 
the makefile for, trying to do that from the command line was 
an exercise in futility.


"How does the installer-built version work then?", I again hear 
you ask. No idea. Debug 64-bit dmd it is!


I *would* try and add a 64-bit dmd to the installer, but 
apparently to build the Windows installer you need a special 
Windows box commisioned by the Vatican and blessed by the Pope 
himself.


Atila


Wait, dmd doesn't use cmake to generate the makefile!? IMO this 
is the reason why configuration tools like cmake exist.

Re: Sealed classes - would you want them in D?

[Dlang User via Digitalmars-d]

On 5/15/2018 10:17 AM, aliak wrote:

On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:
The way you use the word "leak" make is sounds that this is 
unintentional, while in reality it is intentional by design. That why 
reading the specification is important!


Alexander


Ya I guess you be right - but a leak is what it is to people who expect 
private to mean private. Which is not a small number of people ;)


And while I agree reading a spec is important. Language specs are not 
known for being trivial to go through and it's not really something you 
read but more of something you refer to, and that also probably for more 
advanced developers. This is not something you can expect newcomers or 
even intermediate level devs to go through. And the less you need to 
refer to a spec the better (i.e. more intuitive) a language is.






I concur with that.  When I first started learning D (coming from a C# 
background), I figured that I already knew all of the OOP stuff and 
didn't dig too deeply into it, figuring that it worked pretty close to 
the same as C#.  It did catch me off guard when I first realized how it 
really worked in D.  But the work around (putting it in its own module), 
seemed pretty trivial and is what I typically do in C# anyways, so it 
didn't bother me too much.

[Issue 2538] Private final method is not involved in inteface method resolution

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2538

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com
Summary|Final method is not |Private final method is not
   |involved in inteface method |involved in inteface method
   |resolution  |resolution

--

Why is 64-bit dmd not built as part of the Windows release?

[Atila Neves via Digitalmars-d]

I don't know why even bother with 32-bit dmd to begin with, but 
at least there should be an option.


I just spent 45min trying to build 64-bit dmd on Windows. It 
wasn't fun. "Isn't it just make -f win64.mak?", I hear you ask. 
Yes. If you want a version with debug messages turned on. It took 
me 45min to learn that disabling those is... non-trivial.


As it turns out, trying to build dmd yourself from the released 
tag and replacing the .exe from the installer by the one you 
created works, unless:


1. You remove -debug
2. You add -O

If you do #1 or #2, then the produced dmd.exe doesn't work. At 
all. 32 *or* 64 bits. And this is something you need to edit the 
makefile for, trying to do that from the command line was an 
exercise in futility.


"How does the installer-built version work then?", I again hear 
you ask. No idea. Debug 64-bit dmd it is!


I *would* try and add a 64-bit dmd to the installer, but 
apparently to build the Windows installer you need a special 
Windows box commisioned by the Vatican and blessed by the Pope 
himself.


Atila

Re: there's no gdc for windows?

[Eugene Wissner via Digitalmars-d-learn]

On Tuesday, 15 May 2018 at 14:25:31 UTC, Dr.No wrote:
Has gdc been supported for Windows? if so, where can I find it? 
I've only find Linux versions so far...


Just the same as GCC, you need mingw or cygwin to run gdc on 
windows. Unfortunately GDC doesn't provide pre-built binaries 
currently, but according to GDC bugzilla there were people who 
successfully built GDC under mingw. Have you tried to build GDC 
with mingw or cygwin?

Re: Sealed classes - would you want them in D?

[bachmeier via Digitalmars-d]

On Tuesday, 15 May 2018 at 15:05:45 UTC, KingJoffrey wrote:

The problem is not so much D, but that C++/Java/C# programmers, 
and many from other languages (Go, Rust) will expect 
private to mean private...not private..depending on


They will expect the interface they defined, to be respected.


I'm not really in agreement with that. If you're coming from 
another language, you'll have to learn the differences. IMO D's 
solution is better...maybe you can convince the other languages 
to change.


I haven't read all of the (many) posts in this thread, so I'll 
leave it at that, since this has probably already been discussed. 
I didn't understand the example, but it's not actually the case 
that there's anything "broken", it's just different from what 
someone would expect if they tried to write C++ or Java in D.

Re: Sealed classes - would you want them in D?

[Jesse Phillips via Digitalmars-d]

On Tuesday, 15 May 2018 at 10:19:58 UTC, KingJoffrey wrote:
My own code in D had bugs, cause I didn't realise all my 
private parts were not just visible, but accessible by all the 
so called 'friends' around me. They could reach in a do 
whatever they want! Without my consent!


You've peaked my interest, could you give some details on one or 
more of these bugs?

Re: Sealed classes - would you want them in D?

[aliak via Digitalmars-d]

On Tuesday, 15 May 2018 at 13:16:55 UTC, 12345swordy wrote:
The way you use the word "leak" make is sounds that this is 
unintentional, while in reality it is intentional by design. 
That why reading the specification is important!


Alexander


Ya I guess you be right - but a leak is what it is to people who 
expect private to mean private. Which is not a small number of 
people ;)


And while I agree reading a spec is important. Language specs are 
not known for being trivial to go through and it's not really 
something you read but more of something you refer to, and that 
also probably for more advanced developers. This is not something 
you can expect newcomers or even intermediate level devs to go 
through. And the less you need to refer to a spec the better 
(i.e. more intuitive) a language is.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 14:34:07 UTC, bachmeier wrote:


I think I'm missing something. Why is it a problem that you can 
do this? How do other languages prevent you from doing it?


C# example (silly, but it demonstrates the point).

The problem is not so much D, but that C++/Java/C# programmers, 
and many from other languages (Go, Rust) will expect private 
to mean private...not private..depending on


They will expect the interface they defined, to be respected.

Then they'll start asking..wtf!@$#?   .. and end up in long 
threads like this one, trying to work out why the world is upside 
down (or seems like it).


And don't get me started on public being the default in D .. 
cause at some point..I gotta get some sleep.


--
public class Program
{
public static void Main(string[] args)
{
Person p = new Person();
//p.name = "King Joffrey"; // dude. this is private!
}
}

public class Person
{
private string name;
public string getName() { return name; }
}

---

Re: Extend the call site default argument expansion mechanism?

[jmh530 via Digitalmars-d]

On Tuesday, 15 May 2018 at 14:52:46 UTC, Steven Schveighoffer 
wrote:

[snip]

It seems opDispatch isn't being used in the with statement. 
That seems like a bug, or maybe a limitation. I'm not sure how 
"with" works, but I assumed it would try calling as a member, 
and then if it doesn't work, try the call normally. Probably 
it's checking to see if it has that member first.


Annoying...

-Steve


Looks like with statements ignore opDispatch.

struct Foo(int x)
{
auto opDispatch(string s)()
if (s == "bar")
{
return x++;
}
}


void main()
{
int y = 0;
with(Foo!1)
{
y = bar; //error: undefined identifier bar
}
assert(y == 2);
}

Re: Extend the call site default argument expansion mechanism?

[Meta via Digitalmars-d]

On Tuesday, 15 May 2018 at 14:52:46 UTC, Steven Schveighoffer 
wrote:
Sadly with(WithAlloc!alloc) doesn't work. (If you have to use 
withAlloc.func everywhere, it kind of destroy the point, 
doesn't it?)


It seems opDispatch isn't being used in the with statement. 
That seems like a bug, or maybe a limitation. I'm not sure how 
"with" works, but I assumed it would try calling as a member, 
and then if it doesn't work, try the call normally. Probably 
it's checking to see if it has that member first.


Annoying...

-Steve


Yeah I tried it with opDispatch but it didn't work. I vaguely 
remember some changes being made to how lookup is done in the 
past year or so... but I can't find the PR in question.

Re: Extend the call site default argument expansion mechanism?

[Steven Schveighoffer via Digitalmars-d]

On 5/15/18 10:26 AM, Yuxuan Shui wrote:

On Tuesday, 15 May 2018 at 13:59:37 UTC, jmh530 wrote:

On Tuesday, 15 May 2018 at 13:16:21 UTC, Steven Schveighoffer wrote:

[snip]

Hm... neat idea. Somehow, opDispatch can probably be used to make 
this work even more generically (untested):


struct WithAlloc(alias alloc)
{
   auto opDispatch(string s, Args...)(auto ref Args args) if 
(__traits(compiles, mixin(s ~ "(args, alloc)")))

   {
  mixin("return " ~ s ~ "(args, alloc);");
   }
}

-Steve


Example:
https://run.dlang.io/is/RV2xIH


Sadly with(WithAlloc!alloc) doesn't work. (If you have to use 
withAlloc.func everywhere, it kind of destroy the point, doesn't it?)


It seems opDispatch isn't being used in the with statement. That seems 
like a bug, or maybe a limitation. I'm not sure how "with" works, but I 
assumed it would try calling as a member, and then if it doesn't work, 
try the call normally. Probably it's checking to see if it has that 
member first.


Annoying...

-Steve

Re: Extend the call site default argument expansion mechanism?

[jmh530 via Digitalmars-d]

On Tuesday, 15 May 2018 at 14:26:48 UTC, Yuxuan Shui wrote:

[snip]
Example:
https://run.dlang.io/is/RV2xIH


Sadly with(WithAlloc!alloc) doesn't work. (If you have to use 
withAlloc.func everywhere, it kind of destroy the point, 
doesn't it?)


Yeah I know, I tried it, but couldn't figure out how to do the 
with statement with it.

[Issue 2194] Variadic parameters of non-array types

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2194

Dmitry Olshansky  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||dmitry.o...@gmail.com
   Severity|enhancement |normal

--- Comment #4 from Dmitry Olshansky  ---
As per Andrei comment, whatever we reject during semantic but don't is a bug.

--

Re: Sealed classes - would you want them in D?

[bachmeier via Digitalmars-d]

On Saturday, 12 May 2018 at 06:35:55 UTC, KingJoffrey wrote:


Come on, your code example misses my point completely.

Take this program below, for example, and tell me that class 
encapsulation is not broken in D:


===
module test;

import std.stdio : writeln;

void main()
{
Person p = new Person("King Joffrey");

writeln(p.getName); // I designed my class to return this.
writeln(p._name); // But D can bypass your intention 
completely.


p._name = "New King"; // even worse, D can nominate another 
king.

writeln(p._name);
}


I think I'm missing something. Why is it a problem that you can 
do this? How do other languages prevent you from doing it?

[Issue 2159] Confusion between function call and C++ style function address

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2159

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #8 from Dmitry Olshansky  ---
import core.thread;

void main()
{
int g;
int run()
{
for(int i = 0; i < 1000; ++i)
++g;
return 0;
}
auto t = new Thread(run);
t.start;
t.wait;
}

Now it doesn't fail and I fail to see how we fix the general since optional
parens became a thing after UFCS was finally fully implemented.

--

Re: Extend the call site default argument expansion mechanism?

[Yuxuan Shui via Digitalmars-d]

On Tuesday, 15 May 2018 at 13:59:37 UTC, jmh530 wrote:
On Tuesday, 15 May 2018 at 13:16:21 UTC, Steven Schveighoffer 
wrote:

[snip]

Hm... neat idea. Somehow, opDispatch can probably be used to 
make this work even more generically (untested):


struct WithAlloc(alias alloc)
{
   auto opDispatch(string s, Args...)(auto ref Args args) if 
(__traits(compiles, mixin(s ~ "(args, alloc)")))

   {
  mixin("return " ~ s ~ "(args, alloc);");
   }
}

-Steve


Example:
https://run.dlang.io/is/RV2xIH


Sadly with(WithAlloc!alloc) doesn't work. (If you have to use 
withAlloc.func everywhere, it kind of destroy the point, doesn't 
it?)

there's no gdc for windows?

[Dr.No via Digitalmars-d-learn]

Has gdc been supported for Windows? if so, where can I find it? 
I've only find Linux versions so far...

Re: Sealed classes - would you want them in D?

[Mike Parker via Digitalmars-d]

On Tuesday, 15 May 2018 at 10:19:58 UTC, KingJoffrey wrote:


Actually, I kinda get it for unit tests.

Surely there's more??


I use it all the time. One way is to replace what would have been 
a "Manager" class in Java or elsewhere.


module foo.window;
class Window {
private WindowHandle _handle;
private void close() {}
}

private Window[WindowHandle] _windows;
package void closeWindow(Window window) {
_windows.remove(window._handle);
_window.close();
}

This is exactly how I reason about the code and is similar to how 
I would have structured it in C, but with the benefit of both 
package- and module-level encapsulation. _windows, 
window._handle, and window.close are hidden from both the outside 
world and the package.


I can't see any possible reason why I would want to hide the 
implementation of Window from closeWindow -- they're in the same 
module! It's not like C++, where multiple classes can belong to 
multiple namespaces in the same source file. Everything in 
window.d is in the same namespace.




And btw, people grabbing your private parts without your 
explicit consent, is a really serious matter! Just ask those in 
the me-too movement.


Why should a programmers code be exempt from such 
considerations?


D doesn't make that exemption. No one from outside the module has 
access to your private parts. If you have access to the class, 
you also have access to the module, and everything is in the same 
namespace by design, so you're grabbing your own private parts. 
Why should programmers be prevented from doing that?

[Issue 2128] Template function argument binding is too restrictive wrt qualifiers

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2128

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #5 from Dmitry Olshansky  ---
Works with s/invariant/immutable/:


void foo(Idx)(Idx a, Idx b) {}

void main(string[] args)
{
uint x;
immutable uint y;
foo(x, y);
}


Compiles just fine.

--

Re: Extend the call site default argument expansion mechanism?

[jmh530 via Digitalmars-d]

On Tuesday, 15 May 2018 at 13:16:21 UTC, Steven Schveighoffer 
wrote:

[snip]

Hm... neat idea. Somehow, opDispatch can probably be used to 
make this work even more generically (untested):


struct WithAlloc(alias alloc)
{
   auto opDispatch(string s, Args...)(auto ref Args args) if 
(__traits(compiles, mixin(s ~ "(args, alloc)")))

   {
  mixin("return " ~ s ~ "(args, alloc);");
   }
}

-Steve


Example:
https://run.dlang.io/is/RV2xIH

[Issue 2126] class template specialization and inheritance

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2126

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #2 from Dmitry Olshansky  ---

> According to the documentation, the colon in 'C(T:A!(TT),TT)' means "the same 
> > as or derived from". So the second line of the output should be
> "implememtation for T the same as or derived from A!(TT)." in my opinion.

Was fixed in the meantime, since the original code in 2.079 prints:

implememtation for T the same as or derived from A!(TT).
implememtation for T the same as or derived from A!(TT).
implementation for generic T.

Whereas it was:
implememtation for T the same as or derived from A!(TT).
implementation for generic T.
implementation for generic T.

So this ehancement was done sometime ago.

--

[Issue 2052] Static initialization of every kind of variable in aggregates, including classes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2052

Dmitry Olshansky  changed:

   What|Removed |Added

Summary|Static initialization of|Static initialization of
   |every kind of variable, |every kind of variable in
   |including classes   |aggregates, including
   ||classes

--

[Issue 2052] Static initialization of every kind of variable, including classes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2052

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com
Summary|Allow initialization of |Static initialization of
   |every kind of member|every kind of variable,
   |variable in place of its|including classes
   |declaration |

--

[Issue 1297] [module] Static modules, aka enforcing static import.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1297

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #3 from Dmitry Olshansky  ---
A whole language feature to save on one-liner:

static import Db = foo.bar.Db;

> and call all functions via 'Db.func()

Which is partly subjective style anyway.

--

[Issue 1164] Unordered GC finalization leading to memory bugs

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1164

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com
Summary|Wrong order of memory   |Unordered GC finalization
   |deallocation|leading to memory bugs

--

[Issue 1023] Struct implementing interfaces and struct member enumeration

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1023

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #8 from Dmitry Olshansky  ---
> An enumeration of the methods of the
struct would also be nice.

__trait(getMembers, ...)

Far as duck typing goes, this may produce a DIP on compile-time interfaces
(a-la concepts).

And we have had good library solutions that check all of boxes for a long time
now, see:
https://github.com/atilaneves/concepts

Which has `models` UDA to check if struct follows interface statically.

--

Re: Sealed classes - would you want them in D?

[12345swordy via Digitalmars-d]

On Tuesday, 15 May 2018 at 12:20:34 UTC, aliak wrote:

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:
On Tuesday, May 15, 2018 04:22:30 Mike Parker via 
Digitalmars-d wrote:

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
> - Object independence
> - Do not violate encapsulation
> - Respect the interface

This is what I don't get from your position. What is 
encapsulation? Here's what Wikipedia says [1]:

[...]


The class in D *is* encapsulated. The interface *is* 
respected. I'm not sure what you mean by object independence.



[1]
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)


If you really insist on the viewpoint that class encapsulation 
means that nothing outside of that class can access any of its 
private members, then what D does definitely breaks 
encapsulation. But having friends in C++ already provides a 
way to break that. And having access levels like protected and 
package break it. Ultimately, a good language provides ways to 
encapsulate data and control access to the internals of a data 
type, but there are a variety of ways that that can be 
achieved, and I don't think that I've ever used a language 
that strictly enforces that nothing can access the internals 
of a class. It's just that each language provides different 
ways for stuff outside the class to access the class' 
internals.


D happens to have gone with a very liberal approach to 
encapsulation by essentially making everything inside a module 
friends of each other. It doesn't break the concept of 
encapsulation any more than C++'s friend or Java's package 
attribute do. It's just a much more liberal default, and if 
you're really insistent that nothing outside of a class has 
access to the stuff inside a class, then D's choice is likely 
to be seem terrible. So, in that sense, I can see where he's 
coming from, but ultimately, I think that it's a very narrow 
viewpoint about what encapsulation means, and for most of us, 
experience has shown that D's choice works extremely well in 
practice.


Either way, as long as you understand how D works with 
private, you have basically the same level of control as what 
you get with C++ and friend. It's just that if you _really_ 
don't want anything else to be a friend, you're forced to 
stick it in another module. So, ultimately, I think that it's 
mostly a theoretical debate. Pretty much the worst that 
happens is you accidentally use a member variable directly 
instead of using a property function to access it, and that's 
rarely a big deal. Often, it's even desirable.



[...]


- Jonathan M Davis


With one big difference, in that those other languages make you 
explicitly leak object internals, if you want it, and also 
allow you to maintain it, if you want it, whereas D implicitly 
leaks class privates to the module whether you want it or not. 
So private in a class is nonintuitive and does indeed break 
encapsulation. This is why Swift has fileprivate to distinguish 
this case, and for good reason.


So I understand D wants to be liberal, but I also understand 
the value of "encapsulation where I want encapsulation to 
happen", which D doesn't let me do without jumping through 
extra hoops (extracting class to another module with the caveat 
that you lose first-class UFCS enabled function access), and 
only after I've spent hours trying to track a state-related bug 
because private is not scoped at the declaration level.


Cheers
- Ali


The way you use the word "leak" make is sounds that this is 
unintentional, while in reality it is intentional by design. That 
why reading the specification is important!


Alexander

Re: Extend the call site default argument expansion mechanism?

[Steven Schveighoffer via Digitalmars-d]

On 5/15/18 7:53 AM, Yuxuan Shui wrote:

On Friday, 11 May 2018 at 18:55:03 UTC, Meta wrote:

On Friday, 11 May 2018 at 15:03:41 UTC, Uknown wrote:

[...]


It's not as pretty, and I don't know if it works outside this toy 
example yet, but you can do:


import std.stdio;

struct Allocator
{
    auto call(alias F, Args...)(Args args)
    {
    return F(this, args);
    }

    void deallocateAll()
    {
    writeln("deallocateAll");
    }
}

void f1(Allocator a, int n) { writeln("f1"); }
void f2(Allocator, string s, double d) { writeln("f2"); }

void main()
{
    with (Allocator())
    {
    scope(exit) deallocateAll;
    call!f1(2);
    call!f2("asdf", 1.0);
    }
}


I found another alternative to this:

https://godbolt.org/g/3Etims


Hm... neat idea. Somehow, opDispatch can probably be used to make this 
work even more generically (untested):


struct WithAlloc(alias alloc)
{
   auto opDispatch(string s, Args...)(auto ref Args args) if 
(__traits(compiles, mixin(s ~ "(args, alloc)")))

   {
  mixin("return " ~ s ~ "(args, alloc);");
   }
}

-Steve

Re: Extend the call site default argument expansion mechanism?

[Atila Neves via Digitalmars-d]

On Friday, 11 May 2018 at 13:22:12 UTC, Meta wrote:

On Friday, 11 May 2018 at 11:42:07 UTC, Dukc wrote:

On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:

...
// constructor of DataStructure
this(Allocator alloc=__ALLOC__) {...}
...
auto alloc = new SomeAllocator();
define __ALLOC__ = alloc;
// And we don't need to pass alloc everytime
...

Is this a good idea?


Doesn't this basically mean including the implicits Martin 
Odersky talked about at Dconf in D?


Yes it does. I was thinking the exact same thing while watching 
his talk; implicits would be perfect for allocators.


D doesn't have Scala's implicits though. However, one can write 
up a reader monad in the D we have right now.


Atila

[Issue 936] Optimization by compiler hints

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=936

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #6 from Dmitry Olshansky  ---
This is just wishful discussion from the past.
Things like that should have a DIP and some proof of concept.

--

[Issue 921] DMD should optimize calls to final members in derived classes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=921

Dmitry Olshansky  changed:

   What|Removed |Added

   Keywords||performance
 CC||dmitry.o...@gmail.com

--- Comment #1 from Dmitry Olshansky  ---
Still not inlined, after 10 years. But then there is LDC/GDC if one wants
optimization.

--

[Issue 864] Omit function definitions in interface modules without -inline

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=864

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #1 from Dmitry Olshansky  ---
DMD already does attempt to remove all code in -H. Whatever is not working
should be reported as specific bugs

--

On encapsulation

[Bastiaan Veelo via Digitalmars-d]

On Friday, 11 May 2018 at 10:32:39 UTC, KingJoffrey wrote:

On Friday, 11 May 2018 at 09:47:39 UTC, Dukc wrote:
You can use D private with Java-like "only for members 
functions" meaning by putting it alone in it's module, if you 
want.


Yes. I do know this. But that is essentially.. a hack.


Funny that you call this a hack, see below.

A 'private' declaration should be part of the implementation of 
the class, not the class+module. Some say this is just a 
philosphical difference - I say it's a key design issue for 
structured programming.


(OT: "structured programming" is generally understood as a 
concept introduced by the Pascal programming language, and has 
nothing to do with OOP. You probably use the term in a broader 
sense here though, and that's OK.)


[...]

So now, in D, to understand the class, you must also understand 
the module.


Yes.

This is a backwards step in language design, in my opinion - 
for various reasons which are easy to examine further.


Sometimes it is good to do a step back, if thereby you correct 
steps taken in the wrong direction. I have been watching video's 
of Robert Martin lately, a.k.a. Uncle Bob. His experience is far 
greater than mine, and his view on encapsulation is pretty clear. 
Here are a few of his quotes, made in for example [1]:


  "We had absolutely perfect encapsulation in C."
  "This all got screwed up by C++."
  "In C++, header files got polluted with variables and we lost 
encapsulation. To fix that, we did this really horrible hack: we 
invented the word 'private'."
  "'private:' is a terrible hack which attempts to recapture at 
least some tiny bit of the lost encapsulation that we had in C."
  "Then [...] we invented the word 'protected' and ever since 
then we have been figuring out other ways to open that up so now 
we've got 'package scope' and this cope and that scope and God 
help us all there's no encapsulation left."

  "OO has ruined encapsulation."

I am not suggesting that everybody should accept that view, but 
defining modules as the unit of encapsulation cleans up a lot of 
the mess -- at the cost of having to design a sensible module 
hierarchy. Encapsulation predates OO and it is not something that 
can only be had with OO. D puts encapsulation back where it used 
to be and where it works well: decoupled from OO so that the 
public interface can be designed independently from inheritance 
and polymorphism.


[1] https://www.youtube.com/watch?v=t86v3N4OshQ=20m4s

Re: Sealed classes - would you want them in D?

[aliak via Digitalmars-d]

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:
On Tuesday, May 15, 2018 04:22:30 Mike Parker via Digitalmars-d 
wrote:

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
> - Object independence
> - Do not violate encapsulation
> - Respect the interface

This is what I don't get from your position. What is 
encapsulation? Here's what Wikipedia says [1]:

[...]


The class in D *is* encapsulated. The interface *is* 
respected. I'm not sure what you mean by object independence.



[1]
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)


If you really insist on the viewpoint that class encapsulation 
means that nothing outside of that class can access any of its 
private members, then what D does definitely breaks 
encapsulation. But having friends in C++ already provides a way 
to break that. And having access levels like protected and 
package break it. Ultimately, a good language provides ways to 
encapsulate data and control access to the internals of a data 
type, but there are a variety of ways that that can be 
achieved, and I don't think that I've ever used a language that 
strictly enforces that nothing can access the internals of a 
class. It's just that each language provides different ways for 
stuff outside the class to access the class' internals.


D happens to have gone with a very liberal approach to 
encapsulation by essentially making everything inside a module 
friends of each other. It doesn't break the concept of 
encapsulation any more than C++'s friend or Java's package 
attribute do. It's just a much more liberal default, and if 
you're really insistent that nothing outside of a class has 
access to the stuff inside a class, then D's choice is likely 
to be seem terrible. So, in that sense, I can see where he's 
coming from, but ultimately, I think that it's a very narrow 
viewpoint about what encapsulation means, and for most of us, 
experience has shown that D's choice works extremely well in 
practice.


Either way, as long as you understand how D works with private, 
you have basically the same level of control as what you get 
with C++ and friend. It's just that if you _really_ don't want 
anything else to be a friend, you're forced to stick it in 
another module. So, ultimately, I think that it's mostly a 
theoretical debate. Pretty much the worst that happens is you 
accidentally use a member variable directly instead of using a 
property function to access it, and that's rarely a big deal. 
Often, it's even desirable.



[...]


- Jonathan M Davis


With one big difference, in that those other languages make you 
explicitly leak object internals, if you want it, and also allow 
you to maintain it, if you want it, whereas D implicitly leaks 
class privates to the module whether you want it or not. So 
private in a class is nonintuitive and does indeed break 
encapsulation. This is why Swift has fileprivate to distinguish 
this case, and for good reason.


So I understand D wants to be liberal, but I also understand the 
value of "encapsulation where I want encapsulation to happen", 
which D doesn't let me do without jumping through extra hoops 
(extracting class to another module with the caveat that you lose 
first-class UFCS enabled function access), and only after I've 
spent hours trying to track a state-related bug because private 
is not scoped at the declaration level.


Cheers
- Ali

Re: Sealed classes - would you want them in D?

[bauss via Digitalmars-d]

On Tuesday, 15 May 2018 at 10:19:58 UTC, KingJoffrey wrote:


- Voldemort types (cause yeah...we all use them so often).



Actually yes. Most people who has been writing D for a long time 
uses them.

Re: Extend the call site default argument expansion mechanism?

[Yuxuan Shui via Digitalmars-d]

On Friday, 11 May 2018 at 18:55:03 UTC, Meta wrote:

On Friday, 11 May 2018 at 15:03:41 UTC, Uknown wrote:

[...]


It's not as pretty, and I don't know if it works outside this 
toy example yet, but you can do:


import std.stdio;

struct Allocator
{
auto call(alias F, Args...)(Args args)
{
return F(this, args);
}

void deallocateAll()
{
writeln("deallocateAll");
}
}

void f1(Allocator a, int n) { writeln("f1"); }
void f2(Allocator, string s, double d) { writeln("f2"); }

void main()
{
with (Allocator())
{
scope(exit) deallocateAll;
call!f1(2);
call!f2("asdf", 1.0);
}
}


I found another alternative to this:

https://godbolt.org/g/3Etims

[Issue 18862] New: bugstats chart missing due to missing iframe Cross-Origin policy

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18862

  Issue ID: 18862
   Summary: bugstats chart missing due to missing iframe
Cross-Origin policy
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

Load denied by X-Frame-Options:
https://issues.dlang.org/reports.cgi?product=D=NEW=ASSIGNED=REOPENED=RESOLVED
does not permit cross-origin framing.

On Firefox 60 that is.

--

[Issue 13012] Open bugs chart is missing from http://dlang.org/bugstats.php

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13012

Martin Nowak  changed:

   What|Removed |Added

 CC||e...@gnuk.net

--- Comment #6 from Martin Nowak  ---
*** Issue 12618 has been marked as a duplicate of this issue. ***

--

[Issue 12618] bugstats graph broken since bugzilla upgrade

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12618

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Nowak  ---


*** This issue has been marked as a duplicate of issue 13012 ***

--

Re: iopipe v0.0.4 - RingBuffers!

[biocyberman via Digitalmars-d-announce]

On Monday, 14 May 2018 at 14:23:43 UTC, Steven Schveighoffer 
wrote:

On 5/14/18 6:02 AM, bioinfornatics wrote:
On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer 
wrote:

[...]


Hi Steve,

It is an exciting works, that could help in bioinformatics 
area.
Indeed in bioinformatics we are I/O bounding and we process 
lot of big files the amount of data can be in gigabytes, 
terabytes and even some times in petabytes.


So processing efficiently these amount of data is critic. Some 
years ago I got a request 'How to parse fastq file format in 
D?' and monarch_dodra wrote a really fast parser (code: 
http://dpaste.dzfl.pl/37b893ed )


It could be interesting to show how iopipe is fast.


Yeah, I have been working on and off with Vang Le (biocyberman) 
on using iopipe to parse such formats. He gave a good 
presentation at dconf this year on using D in bioinformatics, 
and I think it is a great fit for D!


At dconf, I threw together a crude fasta parser (with the 
intention of having it be the base for parsing fastq as well) 
to demonstrate how iopipe can perform while parsing such 
things. I have no idea how fast or slow it is, as I just barely 
got it to work (pass unit tests I made up based on wikipedia 
entry for fasta), but IMO, the direct buffer access makes fast 
parsing much more pleasant than having to deal with your own 
buffering (using phobos makes parsing a bit difficult, however, 
I still see a need for some parsing tools for iopipe).


You can find that library here: 
https://github.com/schveiguy/fastaq


Not being in the field of bioinformatics, I can't really say 
that I am likely to continue development of it, but I'm 
certainly willing to help with iopipe for anyone who wants to 
use it in this field.


-Steve


Hi Steve

Great work continuing to improve iopipe. Thank you for the 
example implementation of fasta/q parser with iopipe. I will 
definitely continue to work on this. It still requires some more 
time for me to get over beginner barriers in D. I am currently 
trying out some work over here https://github.com/bioslaD.


@Johnathan(bioinformatics) It will be great if you can join 
bioslaD and offer some help to make things move faster.


Vang

Re: How do I make the debugger break when an exception is thrown in D?

[WebFreak001 via Digitalmars-d-learn]

On Tuesday, 15 May 2018 at 10:50:15 UTC, Ethan Scott wrote:

I constantly keep getting this error.
Please help.


you can override the default exception handling to skip the 
global try/catch block and then GDB will halt instead of letting 
it run.


http://arsdnet.net/this-week-in-d/2016-aug-07.html

You can also add a breakpoint in a specific exception constructor 
or throw clause (for example find out line and column by browsing 
source) or check this forum post: 
https://forum.dlang.org/post/ucjzpvtpslyvskgyk...@forum.dlang.org