Re: Memory Corruption Issue??

[Bottled Gin via Digitalmars-d]

Greetings

I am using my D code as a dynamically loadable library that gets 
loaded at run time into C/C++ world. As discussed earlier on this 
thread, the GC does not mark TLS objects in this scenario and as 
a result the GC ends up collecting TLS objects even though these 
objects are still in use. More details of the issue can be found 
on the bug tracker https://issues.dlang.org/show_bug.cgi?id=15513


@Daniel provided two workarounds to this issue. One was to 
disable the GC altogether. I do not want to do that since my 
application generates too much data that necessitates regular 
sweeping.


The other suggested workaround was to explicitly invoke 
GC.addRoot for all the TLS objects. This worked for me for some 
situations, but in other scenarios I am still facing crashes. I 
think these crashes may be resulting from the invisible TLS 
objects in phobos and druntime etc. I have confirmed that all 
these crashes subside if I disable GC altogether and also that 
the crashes do not happen if I make a D bases executable instead 
of DLL.


I want to know if someone is working on this issue. If no one is, 
I am ready to spend time and get this behind me. Actually I have 
already worked on this bug and I think now I have a fair idea of 
what is happening.


Is it the right forum to discuss my findings, or should I put my 
comments on bugzilla. I need some guidance in finding the right 
fix.


Regards
- Puneet

[Issue 15776] symlink documentation wrong: "Relative paths are relative to the current working directory"

[via Digitalmars-d-bugs]

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #1 from Timothee Cour  ---
(In reply to Timothee Cour from comment #0)
> doc says, for symlink(original, link):
> 
> Relative paths are relative to the current working directory, not the files
> being linked to or from.
> 
> it should be:
> link is relative to cwd (if relative), original is relative to link (if
> relative), so that in the example below:
> 
> buildPath(link.dirName, original).buildNormalizedPath
> =buildPath(`d01/pz2.txt`.dirName, `../z2.txt`).buildNormalizedPath
> =`z2.txt` = actual location of original wrt cwd, which is != original.
> (and this is still valid for directory symlinks)
> Perhaps renaming original to original_wrt_link would make this more obvious
> 
> 
> tree
> .
> ├── d01
> └── z2.txt
> 
> std.file.symlink(`../z2.txt`, `d01/pz2.txt`)
> 
> .
> ├── d01
> │   └── pz2.txt -> ../z2.txt
> └── z2.txt


Also, docs should specify precisely what happens when link ends with a '/'

--

Re: Uniform Function Call Syntax?

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 7 March 2016 at 06:48:10 UTC, Era Scarecrow wrote:
 I'm reminded. Weren't there standard 50-something keyboards, 
and then 101 keyboards? And you actually COULDN'T do 
programming on the 50-key keyboards because literally standard 
symbols were missing?


No unicode. No keys. No mouse. No bitmap graphics. Just a 
hardwired terminal. Welcome to the 60s and 70s.


 I have an excellent idea! I'll start programming using nothing 
but the greek alphabet, better yet unicode characters!


immutable π = 3.14;

writeln( ∑(values) );

x = x + ∆;

Oh, the horror!

Re: Uniform Function Call Syntax?

[Era Scarecrow via Digitalmars-d]

On Monday, 7 March 2016 at 06:02:46 UTC, Patience wrote:

On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
Please no. If I need to open up Character Map just to write 
code, something has gone horribly wrong.


A proper code editor could handle this. Type something like 
ctrl + ? and it pops up all the implemented uni-code operators.


Else we are stuck in the past until you decide to change...


 I'm reminded. Weren't there standard 50-something keyboards, and 
then 101 keyboards? And you actually COULDN'T do programming on 
the 50-key keyboards because literally standard symbols were 
missing?


 Honestly it would be annoying to have to pull up character map, 
memorize ascii or unicode characters, or even require a helper 
program which isn't present on most tools.


 I have an excellent idea! I'll start programming using nothing 
but the greek alphabet, better yet unicode characters!


 //謎機能
 int æ(File ß, int Ɣ, int Ʊ) {
   return Ɣ 乘 Ɣ 加 Ʊ 子 7;
 }

 Actually let's alias off the ints too because, we don't need 
those.


 //謎機能
 數 æ(數 Ɣ, 數 Ʊ) {
   return Ɣ 乘 Ɣ 加 Ʊ 子 7;
 }


 i happy i cut & paste everywhere (instead of relying on 
standardized ascii characters that actually mean something to 
me... Okay maybe this went off track)

[Issue 15776] New: symlink documentation wrong: "Relative paths are relative to the current working directory"

[via Digitalmars-d-bugs]

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

  Issue ID: 15776
   Summary: symlink documentation wrong: "Relative paths are
relative to the current working directory"
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

doc says, for symlink(original, link):

Relative paths are relative to the current working directory, not the files
being linked to or from.

it should be:
link is relative to cwd (if relative), original is relative to link (if
relative), so that in the example below:

buildPath(link.dirName, original).buildNormalizedPath
=buildPath(`d01/pz2.txt`.dirName, `../z2.txt`).buildNormalizedPath
=`z2.txt` = actual location of original wrt cwd, which is != original.
(and this is still valid for directory symlinks)
Perhaps renaming original to original_wrt_link would make this more obvious


tree
.
├── d01
└── z2.txt

std.file.symlink(`../z2.txt`, `d01/pz2.txt`)

.
├── d01
│   └── pz2.txt -> ../z2.txt
└── z2.txt

--

Re: Uniform Function Call Syntax?

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
Please no. If I need to open up Character Map just to write 
code, something has gone horribly wrong.


Modern languages support Unicode in names, so it is too late:

import std.stdio;

real Ø(real radius){ return 6.28*radius; }

void main()
{
   writeln(Ø(3));
}

Re: GSoC Project Feedback - iOS and Android versions of DSFML

[Jeremy DeHaan via Digitalmars-d]

On Monday, 7 March 2016 at 05:40:01 UTC, Joakim wrote:

On Monday, 7 March 2016 at 02:34:41 UTC, Jeremy DeHaan wrote:
For those interested in seeing the actual proposal I am 
working on, I have provided the link below. Just know that 
this is my first draft and *a lot* of revising and editing 
still needs to be done.


https://github.com/Jebbs/DSFML/files/160669/DSFML.Summer.of.Code.Proposal.-.FirstDraft.pdf


Please let me know if you think this is worth the effort and 
would make a good GSoF project.


Certainly worth the effort but I'm not sure it's a good GSoC 
project, as I wonder if this is the kind of grunt work that 
they want to sponsor and if it's enough work for a whole 
summer.  That would all depend on more details about what you 
think needs to be done.


Yeah, that's a pretty fair assessment I think. Not being sure if 
this would be good for GSoC is the reason I asked and it's also 
the reason why I am considering other projects as well. I just 
wanted to start with something I know I could do within the given 
time frame and something that I thought would be really useful 
for the D language and community. If I get similar feedback from 
other people, I will probably work on a different proposal.

Re: Uniform Function Call Syntax?

[Patience via Digitalmars-d]

On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad 
wrote:
I think it would be better idea to just add the ability to add 
unicode operators, and to avoid precedence issues one could 
just require them to use parentheses. That way you could 
define opCustom"•" and use it as:


( point1 • point2 )


Please no. If I need to open up Character Map just to write 
code, something has gone horribly wrong.


A proper code editor could handle this. Type something like ctrl 
+ ? and it pops up all the implemented uni-code operators.


Else we are stuck in the past until you decide to change...

Parameterized Keywords

[Patience via Digitalmars-d]

Just curious if anyone can see the use for them?

e.g., for[32], switch[alpha] //alpha is a user type, if[x](x < 32)
etc..

The idea is two-fold, one is to allow polymorphic keyword 
behavior(it's behavior depends on the argument) and to allow the 
code itself to manipulate the behavior.


Of course, the behavior isn't easily define for the above 
examples. So far all I can think of is various simple 
modifications:


foreach[?] <- executes only if there are one or more iterations 
and checks for nullity. This allow one to avoid writing the if 
check.


int[size] <- creates an integer of size bits.

etc...

I can't see much benefit but maybe someone has some good uses?

These could be thought of as "attributes for keywords". The 
programmer would have to define precisely what if[x] means.


Obviously the biggest objection is "It will obfuscate 
keywords"... Please don't obfuscate the question with such 
responses.

Re: GSoC Project Feedback - iOS and Android versions of DSFML

[Joakim via Digitalmars-d]

On Monday, 7 March 2016 at 02:34:41 UTC, Jeremy DeHaan wrote:
For those interested in seeing the actual proposal I am working 
on, I have provided the link below. Just know that this is my 
first draft and *a lot* of revising and editing still needs to 
be done.


https://github.com/Jebbs/DSFML/files/160669/DSFML.Summer.of.Code.Proposal.-.FirstDraft.pdf


Please let me know if you think this is worth the effort and 
would make a good GSoF project.


Certainly worth the effort but I'm not sure it's a good GSoC 
project, as I wonder if this is the kind of grunt work that they 
want to sponsor and if it's enough work for a whole summer.  That 
would all depend on more details about what you think needs to be 
done.

Re: Pitching D to academia

[Walter Bright via Digitalmars-d]

On 3/5/2016 11:38 PM, Ali Çehreli wrote:

Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, how about
pitching it to a gang of professors and graduate students?

I will be presenting D to such an audience at METU in Ankara. What are the
points that you would stress? I am thinking that they would be interested more
in whether D is better as a teaching tool. Do you agree?

Ali


Things I suspect academics would be interested in are features like D's 
functional programming, purity, transitive immutability, etc.

[Issue 15775] New: Object.factory replacement based on experimental allocators

[via Digitalmars-d-bugs]

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

  Issue ID: 15775
   Summary: Object.factory replacement based on experimental
allocators
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

Object.factory always allocates in the GC-heap. 

We could imagine a replacment that uses std.experimental.allocators to allow
something like a factory that would be manually managed or that would use a
free list, according to the user needs.

--

GSoC Project Feedback - iOS and Android versions of DSFML

[Jeremy DeHaan via Digitalmars-d]

Hi all,

I have been working on a proposal for the upcoming GSoC, and its 
to a point where I wanted to get some feedback on things.


I maintain DSFML, a wrapper and binding to the C++ game library 
SFML. Essentially the core of my proposal is to add the ability 
for binding to build iOS and Android versions which can then 
leverage recent work on LDC to build and run on these mobile 
systems. SFML can already target these OS's, so most of the work 
is done there. Barring anything extreme, this would allow D 
programmers to easily work on games for mobile devices pretty 
much as soon as that functionality is officially released in the 
LDC compiler. I think that's pretty damn awesome. There are a few 
other things in my proposal, like updating some things and fixing 
some bugs, but Android and iOS support is pretty much the meat 
and potatoes.


For those interested in seeing the actual proposal I am working 
on, I have provided the link below. Just know that this is my 
first draft and *a lot* of revising and editing still needs to be 
done.


https://github.com/Jebbs/DSFML/files/160669/DSFML.Summer.of.Code.Proposal.-.FirstDraft.pdf


Please let me know if you think this is worth the effort and 
would make a good GSoF project.

Re: Object-Oriented Programming is Bad

[Era Scarecrow via Digitalmars-d]

On Sunday, 6 March 2016 at 20:33:39 UTC, sigod wrote:
Interesting talk. Especially given that my D code tends to be 
structured very similarly to what Will suggests.


 It's pretty good.

 I'm reminded of my short time working in a tech company where we 
did Java programming. There were multiple things that annoyed me. 
First was EVERYTHING was an object. That didn't make sense for 
logically passing just data as a block together, say 3D points as 
x,y,z, where you'd end up making a final class holding nothing 
but those three types, and no functions just so you could sort of 
emulate a struct.


 Another annoyance was the main function which had to break the 
OO requirements by making a class with a static main you could 
then call. It never quite felt like it fit.


 They also pushed making all members publicly accessible via 
getters and setters. So you'd have a lot of code like this:


  Class X {
private:
int a;

public:
int getA(){return a;}
void setA(int A){a=A;}
 }


 Finally, the last large annoyance was working on Web 
Programming. We'd end up doing a combination of either ASP or 
JSP. It was modeled in 4 layers (UI, Logic, Business, Database) 
where often in the UI layer you'd immediately drop 2-3 levels and 
talk directly to the Database.


 Didn't help how they wanted every call to get data from the 
database, and a simple calendar/timesheet application did like 50 
calls per page to the database making it take FOREVER, i think 30 
seconds? We knew if it was that slow for 1 person, having the 
entire company using it with 600 employees it would totally suck.

[Issue 15767] Why isn't there a deprecation plan for TypeTuple?

[via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
Please don't create bug reports that are questions. If you want to ask a
question, then ask in the newsgroup.

I believe that the primary reason that TypeTuple isn't deprecated is that it's
used a _ton_, and deprecating it would result in a flood of deprecation
messages in many projects. And while personally, I really don't like leaving
aliases like this around, I don't think that either Walter or Andrei think that
it's all that big a deal.

So, while we may yet deprecate TypeTuple and move towards getting rid of it,
there isn't much of a hurry to do so.

--

Re: TypeInfo madness

[Yuxuan Shui via Digitalmars-d]

On Sunday, 6 March 2016 at 23:27:45 UTC, Adam D. Ruppe wrote:
It is just a mistake that TypeInfo isn't immutable, in my 
opinion.


...though changing it would be a breaking change, I think it 
would make sense to do it.


Is there really anything relies on TypeInfo being mutable?

Re: Pitching D to academia

[Ali Çehreli via Digitalmars-d]

Thank you everyone. This thread has been very helpful.

On 03/06/2016 01:55 AM, Russel Winder via Digitalmars-d wrote:
> On Sat, 2016-03-05 at 23:38 -0800, Ali Çehreli via Digitalmars-d wrote:
>> Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, how
>> about pitching it to a gang of professors and graduate students?

Sorry for not asking a clear question. The audience will be the staff 
and students of the CS department. So, I think the following is correct.


> Level of student:
>
>  B. Learning about data structures and algorithms as a second
>  programming course.
>  C. Doing some advanced option.

> Which subject is their main one:
>
>  1. Computing
>  2. Computer Science

Let's see how many will show up. :)

Ali

Re: Uniform Function Call Syntax?

[Xinok via Digitalmars-d]

On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad 
wrote:
I think it would be better idea to just add the ability to add 
unicode operators, and to avoid precedence issues one could 
just require them to use parentheses. That way you could define 
opCustom"•" and use it as:


( point1 • point2 )


Please no. If I need to open up Character Map just to write code, 
something has gone horribly wrong.

Re: Pitching D to academia

[Rikki Cattermole via Digitalmars-d]

On 07/03/16 12:26 PM, Jesse Phillips wrote:

On Sunday, 6 March 2016 at 17:53:23 UTC, Seb wrote:

On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:

Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, how
about pitching it to a gang of professors and graduate students?



If you want D to flourish, you should _really_ focus on this.
Many CS students usually learn only one or two language at university.


I think this can be one of the selling points. In general, languages
aren't the teaching goal of a university.

Python/Java - These get chosen for early courses. Python likely because
of its strict formatting (get people used to formatting code), the
language is high level and has rich collection of libraries. Both of the
languages prevent worrying about a lot of other details (memory,
procedural is easy to explain)

C/C++ - These come into later classes, I'd guess because they are used
in industry and have unique usage requirements (null pointers, double free)

Otherwise courses seem to expect you know one language (java/python) and
try to teach you concepts within that language, and sometimes allow you
to do the homework in any language.

I think D is the right choice because it can demonstrate concepts while
provide the advantages of why other languages are chosen. And it has a
very nice set of toys that many students will enjoy playing with and
using in their homework. It makes a good learning language because it
makes a good using language.


This is actually the primary argument I made for my tertiary institute 
in making D the first language. It ended up with pretty much every tutor 
and even head of department (who was a programmer) agreeing with me.
Of course that's a big change and industry doesn't reflect it. So don't 
expect it to happen.

Re: TypeInfo madness

[Adam D. Ruppe via Digitalmars-d]

It is just a mistake that TypeInfo isn't immutable, in my opinion.

...though changing it would be a breaking change, I think it 
would make sense to do it.

Re: Pitching D to academia

[Jesse Phillips via Digitalmars-d]

On Sunday, 6 March 2016 at 17:53:23 UTC, Seb wrote:

On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:
Motivated by Dmitry's "Pitching D to a gang of Gophers" 
thread, how about pitching it to a gang of professors and 
graduate students?




If you want D to flourish, you should _really_ focus on this.
Many CS students usually learn only one or two language at 
university.


I think this can be one of the selling points. In general, 
languages aren't the teaching goal of a university.


Python/Java - These get chosen for early courses. Python likely 
because of its strict formatting (get people used to formatting 
code), the language is high level and has rich collection of 
libraries. Both of the languages prevent worrying about a lot of 
other details (memory, procedural is easy to explain)


C/C++ - These come into later classes, I'd guess because they are 
used in industry and have unique usage requirements (null 
pointers, double free)


Otherwise courses seem to expect you know one language 
(java/python) and try to teach you concepts within that language, 
and sometimes allow you to do the homework in any language.


I think D is the right choice because it can demonstrate concepts 
while provide the advantages of why other languages are chosen. 
And it has a very nice set of toys that many students will enjoy 
playing with and using in their homework. It makes a good 
learning language because it makes a good using language.

Re: Improve contributor experience and PR backlog

[Rikki Cattermole via Digitalmars-d]

A couple years ago I fixed a bug in dmd.
After like a month it turned out it actually fixed multiple bugs.

It was not merged. Nobody reviewed it past fixing the commits as one.
Many months later another PR was made to fix only one of the bugs and 
that was merged.


Funny how things go. I have not tried to fix any since.

Re: Pitching D to academia

[sigod via Digitalmars-d]

On Sunday, 6 March 2016 at 17:53:23 UTC, Seb wrote:
Why don't we make a Coursera (or similar) course about D? They 
usually have an audience of at least 50-100K.


That's a great idea. I would love to take such course.

TypeInfo madness

[Yuxuan Shui via Digitalmars-d]

In D (tested with D 2.070), one is allowed to modify TypeInfo 
returned by typeid().


Here is an example how this "feature" can be used maliciously.

class A{
}
class C : A{
int a = 1234;
}
class B : A{
float b;
}

@safe void main() {
import std.stdio;
C c = new C;
A a = cast(A)c;
auto y = typeid(c);

B b = new B;
y.base = typeid(b);

b = cast(B)a;
assert(b !is null);
writeln(b.b);
}

With a successful dynamic cast, it should be safe to assume the 
data in the result object is well formed (enforced, for example, 
by invariants). However, the ability to modify a TypeInfo object 
will give the attacker a chance to pass crafted data to a 
function.

[Issue 15768] std.stdio.trustedStdout accesses __gshared data without synchronization.

[via Digitalmars-d-bugs]

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

Ivan Kazmenko  changed:

   What|Removed |Added

 CC||ga...@mail.ru

--

Re: Object-Oriented Programming is Bad

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 6 March 2016 at 20:33:39 UTC, sigod wrote:

Video: https://www.youtube.com/watch?v=QM1iUe6IofM
Article: 
https://medium.com/@brianwill/object-oriented-programming-a-personal-disaster-1b044c2383ab


Interesting talk. Especially given that my D code tends to be 
structured very similarly to what Will suggests.


Perhaps interesting, but also annoying and backwards. OOP was 
developed in Simula in 1961-1967 by Nygaard and Dahl. Dijkstra 
wrote about structured programming in the late 60s, and Dahl, 
Dijkstra and Hoare coauthored the book "Structured Programming" 
in 1972...


If OOP turns into a personal disaster it probably is the result 
of not actually trying to implement an OO-model, which is the 
purpose of having OO mechanisms in a language. However, nobody 
has ever suggested that you should only do OO modelling, and you 
can  implement an OO model in most languages, even C. 
OO-modelling is a tool.


*shrugs*

Re: Object-Oriented Programming is Bad

[Chris Wright via Digitalmars-d]

On Sun, 06 Mar 2016 20:33:39 +, sigod wrote:

> Video: https://www.youtube.com/watch?v=QM1iUe6IofM Article:
> https://medium.com/@brianwill/object-oriented-programming-a-personal-
disaster-1b044c2383ab
> 
> Interesting talk. Especially given that my D code tends to be structured
> very similarly to what Will suggests.

The article didn't make it to suggestions (besides "no OOP ever"), and 
the video was too boring for me to pay any attention. The one example he 
did give was pretty unconvincing.

"Should a Message send() itself?" Messages can be sent to any of a 
variety of places, so you need to send an endpoint along. An endpoint 
comprises some amount of data to specify where it's going, and it might 
be a pointer to memory shared between processes, or a URL for a REST 
interface, or a socket file descriptor, or...

You could pass just that data along, probably as a discriminated union, 
and have a send() function that specializes based on which value is 
passed. But it's simpler and more extensible to use an interface and 
implementations.

[Issue 10777] std.algorithm.multiSort to return a std.range.SortedRange

[via Digitalmars-d-bugs]

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

--- Comment #6 from SzMK  ---
pull
https://github.com/D-Programming-Language/phobos/pull/4061

--

Re: Pitching D to a gang of Gophers

[cym13 via Digitalmars-d]

On Sunday, 6 March 2016 at 14:02:25 UTC, Dmitry Olshansky wrote:

On 06-Mar-2016 10:21, Shammah Chancellor wrote:
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky 
wrote:

[snip]

Here's some stuff D shares with Go:

"Single" binary deployments.
Garbage Collector
In-language slices and maps
Foreach (Although D is much more powerful here)

Some things D is weak on:
* The name -- all I ever hear are penis jokes.


Thankfully not in my country ;)


* Garbage Collector (!)


This is indeed a sore spot, Go rapidly advanced their GC and 
even took advantage of it being non-copying to deliver on 
lower-latency front. Wonder if we could squeeze some more bang 
out of GC.


* dfix and dfmt aren't as good as gofmt and gofix. (And 
believe me I
understand they will be much more difficult to get to parity 
due to the

feature set of D)


Strangely people love single imposed code style of Go, and in 
many ways other enforced conventions.


* Docs  -- although these have gotten much much better 
recently -- the
current implementation of concepts makes it hard for people to 
know

where and when they can use a type.  E.g sort docs
(http://dlang.org/phobos/std_algorithm_sorting.html#sort) How 
do I know
what types of things I can sort as a newcomer? Even if I 
figure out that
I need to look at isForwardRange, the docs there aren't 
terribly helpful

either
(https://dlang.org/phobos/std_range_primitives.html#isForwardRange)  I
would put up a PR, but I don't know how to fix it without 
introducing a
language structure for Concepts -- but this has been veto'd 
for a
variety of reasons (primarily type explosion as I understand 
the arguments)

* Libraries


Probably the biggest issue. Another one I'd pull is complexity, 
there is sooo many moving parts in D by now that we 
consistently fail to deliver a feature complete spec and/or 
compiler for it.




Some things D is much better on (and would cause me to choose 
it every
time and just contribute fixes where I could to the external 
tools):


* Package management/build tools
* Integration with existing build systems/libraries
* Reusable algorithms that are FAST
* Empowering programmer expressiveness without enabling magic


Overall my impression is that if we were to compare D and Go as 
tools, D would be more of meta tool - i.e. a tool to create 
tools whereas Go is ready made toolkit that is nicely crafted 
but quite limited.


Now I only need to appeal to the former somehow ;)


-S.


Just to temper some points that I agree with in principle:


* Garbage Collector (!)
D doesn't need a better GC in my opinion. Go's GC has to be 
really good because AFAIK there is no other way to manage memory. 
Same for Java. But as good as a GC can be it will never be good 
enough for all applications. D solved the problem by proposing 
other memory management schemes so when the GC isn't good enough 
you just don't use it. Developping such schemes is *way* more 
important to D's future than a better GC that can never be more 
than good enough for more people but never everybody.



* Libraries
There again as using C libraries in Go is tiresome there is more 
incentive not to reuse them. OK, this is a weak point, I too 
think this is maybe the most proeminent D flaw.

Re: Named arguments via struct initialization in functions

[Jacob Carlborg via Digitalmars-d]

On 2016-03-06 18:35, Seb wrote:

Hey all,

I wanted to relive the discussion on named arguments and ping for its
current status.

There is a bunch of examples to show how needed a unified solution for
this problem is, let me give you one from phobos [2].

```
// I want to allow downsizing
iota(10).sliced!(Yes.replaceArrayWithPointer, Yes.allowDownsize)(4);
```

There is of course the alternative solution that an author overloads his
function to the utmost, but this results in complexity and duplicated
code (see e.g. redBlackTree in phobos [3]).

Currently the best solution AFAICT is to use a struct to pass such
flags, like

```
struct Options{int x; int y=1; int z=2;}
auto fun(Options options)
{
 return options.x + options.y + options.z;
}

Options options = {x: 4, z: 3};
auto a=fun(options);
```

There are also other workarounds as discussed in [1] (e.g. with CTFE
string analysis [4]).

I general there two solutions to this problem
1) get true named parameters support in D (probably complicated)
2) allow struct inits in functions - e.g. fun({x: 4})

For 2) Jacob Carlborg has proposed something similar three years ago. In
his case he proposed anonymous structs which might be more generally
applicable, however just created the struct seems easier and allows more
It doesn't seem that complicated to me as the compiler already knows the
type of the argument.

Using structs is not ideal, because one can't require parameters, but
this can be solved by having those parameters as normal ones like
`sliced(4, {allowDownsize: true})` and it creates some maybe unnecessary
overhead.
However it is probably the easiest solution right now.

What are your thoughts on this issue?


I think the simplest solution is to allow struct member initializer in 
all places a struct literal is accepted [1].


[1] https://issues.dlang.org/show_bug.cgi?id=15692

--
/Jacob Carlborg

Object-Oriented Programming is Bad

[sigod via Digitalmars-d]

Video: https://www.youtube.com/watch?v=QM1iUe6IofM
Article: 
https://medium.com/@brianwill/object-oriented-programming-a-personal-disaster-1b044c2383ab


Interesting talk. Especially given that my D code tends to be 
structured very similarly to what Will suggests.

Re: Create Windows "shortcut" (.lnk) with D?

[岩倉 澪 via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 11:00:35 UTC, John wrote:

On Sunday, 6 March 2016 at 03:13:23 UTC, 岩倉 澪 wrote:

IShellLinkA* shellLink;
IPersistFile* linkFile;

Any help would be highly appreciated as I'm new to Windows 
programming in D and have no idea what I'm doing wrong!


In D, interfaces are references, so it should be:

  IShellLinkA shellLink;
  IPersistFile linkFile;


That's exactly what the problem was, thank you!!

Re: Named arguments via struct initialization in functions

[Chris Wright via Digitalmars-d]

On Sun, 06 Mar 2016 17:35:38 +, Seb wrote:

> Hey all,
> 
> I wanted to relive the discussion on named arguments and ping for its
> current status.

We want something to let people provide arguments sparsely and 
unambiguously, and if possible in arbitrary order. The existing DIP just 
lets you provide compiler-checked annotations to verify the parameter 
names match your expectations, assuming the writer of the function chose 
to allow it.

Nobody much liked it. I've got a draft DIP on my hard drive to provide 
actual named arguments but haven't gotten around to proposing it.

There was considerable disagreement on whether the function parameters 
should be explicitly marked in order to use them as named or not. Scala, 
Python, C#, Ceylon, and I believe Ada don't require you to mark them. 
Ruby and Dart require you to mark them.

There are a couple other interesting decisions regarding named 
parameters, but nobody much considered them during the discussion. 
Ceylon's the most permissive example.

> 2) allow struct inits in functions - e.g. fun({x: 4})

I looked into this a bit. I've got another draft DIP for it on my hard 
drive. There are two obvious ambiguities:

  struct A { int x; long y; }
  struct B { int x; string y; }
  void foo(A a) {}
  void foo(B b) {}
  foo({x: 1});

There's no way to tell which overload to invoke.

Then let's say I added:
  void foo(void delegate() dg) {}
  foo({});

That could be a default-initialized struct of type A or B, or it could be 
a no-op delegate.

You can resolve that with a slightly different syntax:

  foo(A{x: 1});

I think I noticed an ambiguity with that, too, but I can't recall now. I 
failed to write it down in any case.

Anyway, if it works, it's an improvement. And you only need explicit type 
marking at the top level; it's unambiguous after that.

Re: Improve contributor experience and PR backlog

[Jack Stouffer via Digitalmars-d]

On Sunday, 6 March 2016 at 16:44:31 UTC, Seb wrote:
Rather than the default mode for a change to be rejected until 
enough people sign off, we make the default for every change 
to land. This puts the onus on reviewers to note exactly what 
adjustments need to be made in order for it to land [4].


I really do like this idea. It could work if the review window 
is increased to maybe one week and everything without a "needs 
changes" tag (or "needs consensus" for major changes) is fine 
to merge then.


Unfortunately, this only works when the number of reviewers is 
high and they review everything. Phobos contributions have about 
four regular reviews and about ten people who review on and off. 
I can't blame people for not reviewing things at once, because 
the things that I review take a while for me to get through 
because I find the process a little tedious (not a D/Phobos 
specific thing, it's just about looking at other's code). I 
usually allow for two weeks before I ping someone because of this.


The PR of mine you referred to had serious problems on it's first 
implementation and should not have been pulled in 36 hours. There 
was even a whole form discussion about it: 
http://forum.dlang.org/post/n0p4s3$5em$1...@digitalmars.com


While I would love nothing more than for reviewing to go faster, 
I can't think of any mechanism to force reviews and contributors 
to respond faster to comments/make comments.


On a more positive note, trivial changes usually are merged 
within two days.

Re: Const vs Non const method

[Namespace via Digitalmars-d-learn]

On Thursday, 25 February 2016 at 10:59:43 UTC, Rene Zwanenburg 
wrote:
On Thursday, 25 February 2016 at 10:44:49 UTC, Andrea Fontana 
wrote:

Check this simple code:
http://dpaste.dzfl.pl/2772c9144f1c

I can't understand how to minimize code duplication for 
function like get().
Of course on real case body is much bigger and complex than 
that.


The only way I found is to move the body of function inside a 
mixin template:


mixin template getterImpl()
{
   auto getterImpl() { /* very long body */ return inner; }
}

and then:

auto get() const { mixin getterImpl; return getterImpl; }
auto get() { mixin getterImpl; return getterImpl; }

Am I missing something? I don't think it's the right way.


You can do this using inout:
http://dpaste.dzfl.pl/678cac023051

That getter can be written even shorter due to a quirk in the D 
syntax, like:


inout get() { return inner; }

But I prefer to explicitly state inout for every parameter and 
return type.


inout is kind of a wildcard for mutable, const, and immutable. 
You can also add it to your function parameters, for example:


inout(int[]) doSomething(inout(SomeClass) c);

So the constness of doSomething's return type depends on the 
constness of the passed argument.


What would be the C++ way? Is there any comfortable way to solve 
this problem in a nice way like D?

Re: Pitching D to academia

[Seb via Digitalmars-d]

On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:
Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, 
how about pitching it to a gang of professors and graduate 
students?




If you want D to flourish, you should _really_ focus on this.
Many CS students usually learn only one or two language at 
university.

At our university you can learn those in courses:

- Java for OOP
- Perl (not kidding) for scripting (normally now Python or 
sometimes JS is used)

- Haskell/OCaml/F# for functional programming
- C/C++ for system programming, imperative programming

The awesome part and what I love so much about D is that you can 
teach all of those in ONE language.


However my point is that most students will continue to use the 
language they learn at university (or maybe high school) forever 
- it's really similar to one's "native tongue" - this *not* only 
means that they get used to it, but they also will start new 
projects with it and continue to develop in this language. In 
other words: this will result in a huge increase of the user base 
and thus also (financial) interest in the D.


Why don't we make a Coursera (or similar) course about D? They 
usually have an audience of at least 50-100K.


In case money is pretty tight, some of these platforms even have 
special credit programs (25-50K$) to fund development of new 
courses, but usually a university is happy to sponsor the 
production costs for such a course if they can write their name 
on it.

Named arguments via struct initialization in functions

[Seb via Digitalmars-d]

Hey all,

I wanted to relive the discussion on named arguments and ping for 
its current status.


There is a bunch of examples to show how needed a unified 
solution for this problem is, let me give you one from phobos [2].


```
// I want to allow downsizing
iota(10).sliced!(Yes.replaceArrayWithPointer, 
Yes.allowDownsize)(4);

```

There is of course the alternative solution that an author 
overloads his function to the utmost, but this results in 
complexity and duplicated code (see e.g. redBlackTree in phobos 
[3]).


Currently the best solution AFAICT is to use a struct to pass 
such flags, like


```
struct Options{int x; int y=1; int z=2;}
auto fun(Options options)
{
return options.x + options.y + options.z;
}

Options options = {x: 4, z: 3};
auto a=fun(options);
```

There are also other workarounds as discussed in [1] (e.g. with 
CTFE string analysis [4]).


I general there two solutions to this problem
1) get true named parameters support in D (probably complicated)
2) allow struct inits in functions - e.g. fun({x: 4})

For 2) Jacob Carlborg has proposed something similar three years 
ago. In his case he proposed anonymous structs which might be 
more generally applicable, however just created the struct seems 
easier and allows more
It doesn't seem that complicated to me as the compiler already 
knows the type of the argument.


Using structs is not ideal, because one can't require parameters, 
but this can be solved by having those parameters as normal ones 
like `sliced(4, {allowDownsize: true})` and it creates some maybe 
unnecessary overhead.

However it is probably the easiest solution right now.

What are your thoughts on this issue?

On a side note: many templated functions are also complicated and 
experiencing this issue, so it also might be worth to think about 
this issue too ;-)


Cheers,

Seb

[1] 
http://forum.dlang.org/post/pxndhoskpjxvnoaca...@forum.dlang.org

[2] https://github.com/DlangScience/mir/issues/18
[3] 
https://github.com/D-Programming-Language/phobos/pull/4041/files
[4] 
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d

Re: Pitching D to academia

[Chris Wright via Digitalmars-d]

On Sat, 05 Mar 2016 23:38:01 -0800, Ali Çehreli wrote:

> Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, how
> about pitching it to a gang of professors and graduate students?
> 
> I will be presenting D to such an audience at METU in Ankara. What are
> the points that you would stress? I am thinking that they would be
> interested more in whether D is better as a teaching tool. Do you agree?
> 
> Ali

D has good support for functional programming. It's had support for this 
long enough that it's well baked into the standard library.

It doesn't do single-write, all-values-are-immutable style so well, 
though, which is another intuitive leap learning functional languages. 
But if you get people used to first-class functions in D, where they can 
make everything mutable, it should be easier to teach Haskell or OCaml or 
Elm.

Re: The most enjoyable programming language I've ever used

[Chris Wright via Digitalmars-d]

On Sun, 06 Mar 2016 15:02:20 +, Tourist wrote:

> Cool!
> 
> On Sunday, 6 March 2016 at 14:19:21 UTC, Michalis wrote:
>> Even though Java is still my favorite...
> 
> For completeness... Do you have experience with C#?

They said they use Mono, which means C# or VB or F#. Maybe Nemerle. But 
probably C#.

Improve contributor experience and PR backlog

[Seb via Digitalmars-d]

Hey all,

I came by a couple of old PRs lately and while it's amusing that 
people like @JackStouffer celebrate their PR anniversaries, it's 
a bit sad for such an amazing project. By looking at those old 
PRs there is a common pattern - someone had a great idea for a 
feature, idea or fix and wants to get it merged. However after 
one or two week they usually move on and a lot of pinging on both 
sides is required.
In any case I think you already know this. Let me cite from the 
DLang progress report from H2 2015 [2].


We fell short of our 2000 pull requests goal in H2 2015. We 
have had only 1378 pull requests. This is a 10% decline 
year-over-year compared to the same period in 2014. We 
attribute this to the long time of reviewing many pull 
requests, which works against a good contributor experience.


I do know that the time of reviewers is limited and voluntary, 
but I recently read a nice article [3] about Node's contribution 
policy. It is similar to your current policy:


For non-trivial contributions, pull requests should sit for at 
least 36 hours to ensure that contributors in other timezones 
have time to review. Consideration should also be given to 
weekends and other holiday periods to ensure active committers 
all have reasonable time to become involved in the discussion 
and review process if they wish.


However note the key difference:

Rather than the default mode for a change to be rejected until 
enough people sign off, we make the default for every change to 
land. This puts the onus on reviewers to note exactly what 
adjustments need to be made in order for it to land [4].


I really do like this idea. It could work if the review window is 
increased to maybe one week and everything without a "needs 
changes" tag (or "needs consensus" for major changes) is fine to 
merge then.


Before you start to protest - this is just an idea.

[1] https://github.com/D-Programming-Language/phobos/pull/3765
[2] http://wiki.dlang.org/Vision/2016H1
[3] 
https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951
[4] 
https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.loqfk3zf4

[Issue 15773] D's treatment of whitespace in character classes in free-form regexes is not the same as Perl's

[via Digitalmars-d-bugs]

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

Markus Laker  changed:

   What|Removed |Added

Summary|D's treatment of whitespace |D's treatment of whitespace
   |in character classes in |in character classes in
   |free-from regexes is not|free-form regexes is not
   |the same as Perl's  |the same as Perl's

--

Re: std.database

[Erik Smith via Digitalmars-d]

On Sunday, 6 March 2016 at 08:53:05 UTC, Kagamin wrote:

On Saturday, 5 March 2016 at 18:00:56 UTC, Erik Smith wrote:
I'm definitely going to start working in async capability (or 
more accurately, non-blocking) into the interface.


Huh? Non-blocking operation is not reflected in interface. Only 
asynchronous requires special interface. Vibe interfaces are 
synchronous.


I think a basic non-blocking interface should be similar to the 
synchronous one, but also exposes a file/socket descriptor to 
pass to the event system and also provide status method for 
whether the R/W operation is waiting.


I've looked into OCI headers, they say something about 
asynchronous operations, do you know something about that?


I need to look into this more, but the OCI non-blocking model is 
problematic (a missing file descriptor maybe).  It can probably 
be made to work since Node now has a driver directly from Oracle, 
but I'm not sure if it has the same scaling profile as other 
non-blocking clients.

Re: Is there a standard for whar opAssign/opOpAssign should return?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, March 06, 2016 15:25:46 HSteffenhagen via Digitalmars-d-learn 
wrote:
> In the https://dlang.org/spec/operatoroverloading.html opAssign
> is declared as
>
> void opAssign(S rhs);
>
> in the example.
>
>  From C++ I'm used to return *this when overloading assignment
> operators to allow chaining of assignments (or somewhat more
> rarely, weird tricks for if and while statements), is that not
> done in D as a rule or is the example just weird? Same question
> for the
> opOpAssign family.

void opAssign(S rhs);

will work, but it's not the most flexible. Ideally, the various overloaded
assignment operators would return "this" by ref. e.g.

ref S opAssign(S rhs)
{
...
return this;
}

which is essentially what you do in C++. Without returning by ref, you can't
chain assignments, which is why return by ref is preferable even if it's not
required. The example in the documentation should probably be modified to
return by ref, but void will work - just not with chained assignments.

- Jonathan M Davis

Re: Had not Dllimport in D?

[Rikki Cattermole via Digitalmars-d-learn]

On 07/03/16 4:19 AM, xky wrote:

On Sunday, 6 March 2016 at 14:21:55 UTC, Rikki Cattermole wrote:

Okay, since you clearly have not worked in a native language before,
lets start from scratch.

[...]


Sorry for my idiot question. Thanks.


Not idiot, its just where you are at and that's ok :)
Sorry for making you feel like that though.

Is there a standard for whar opAssign/opOpAssign should return?

[HSteffenhagen via Digitalmars-d-learn]

In the https://dlang.org/spec/operatoroverloading.html opAssign
is declared as

void opAssign(S rhs);

in the example.

From C++ I'm used to return *this when overloading assignment 
operators to allow chaining of assignments (or somewhat more 
rarely, weird tricks for if and while statements), is that not 
done in D as a rule or is the example just weird? Same question 
for the

opOpAssign family.

Re: Had not Dllimport in D?

[xky via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 14:20:34 UTC, WebFreak001 wrote:

On Sunday, 6 March 2016 at 14:12:35 UTC, xky wrote:

First, I really sorry my bad english.

I just want to using Ruby dll file(msvcrt-ruby220.dll).


D can import and use functions from a DLL but you are using a 
C# library, which is probably not going to work. D can only 
call functions from DLLs with a C or D interface. If you want 
to make your own shared libraries or use some C DLLs check 
these links:


http://wiki.dlang.org/Win32_DLLs_in_D (native .dll -> windows)
https://dlang.org/dll-linux.html (shared object .so -> linux)
https://github.com/DerelictOrg/DerelictUtil (library for 
loading dll functions on multiple platforms)


DerelictUtil looks like useful for me. Thank you. :-)

Re: Had not Dllimport in D?

[xky via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 14:21:55 UTC, Rikki Cattermole wrote:
Okay, since you clearly have not worked in a native language 
before, lets start from scratch.


[...]


Sorry for my idiot question. Thanks.

Re: The most enjoyable programming language I've ever used

[Tourist via Digitalmars-d]

Cool!

On Sunday, 6 March 2016 at 14:19:21 UTC, Michalis wrote:

Even though Java is still my favorite...


For completeness... Do you have experience with C#?

[Issue 15729] [REG(master)] broken library causes OPTLINK error 162 and 163

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #3 from Martin Nowak  ---
Thanks for the reduced test case, will fix ASAP.

--

Re: Had not Dllimport in D?

[Rikki Cattermole via Digitalmars-d-learn]

Okay, since you clearly have not worked in a native language before, 
lets start from scratch.


You want to make some bindings to a shared library called "msvcrt-ruby18".
From this I know that it is using the Microsoft Visual C runtime. That 
means you must build D using this as well.
This is done via the -ms32coff switch for 32bit and -m64 for 64bit 
(which is easier all up).

You will need Visual studio with all of the c/c++ stuff installed.
Keep in mind you must match the version of Visual C runtime up with the 
shared libraries one (if you fail enjoy the segfaults!).


Lastly you want some bindings. I won't cover that here. But this should 
help ya out http://dlang.org/spec/interfaceToC.html


After this you should be able to pass the shared library directly to dmd 
when in -ms32coff or -m64 mode and it'll all work.

Re: Had not Dllimport in D?

[WebFreak001 via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 14:12:35 UTC, xky wrote:

First, I really sorry my bad english.

I just want to using Ruby dll file(msvcrt-ruby220.dll).


D can import and use functions from a DLL but you are using a C# 
library, which is probably not going to work. D can only call 
functions from DLLs with a C or D interface. If you want to make 
your own shared libraries or use some C DLLs check these links:


http://wiki.dlang.org/Win32_DLLs_in_D (native .dll -> windows)
https://dlang.org/dll-linux.html (shared object .so -> linux)
https://github.com/DerelictOrg/DerelictUtil (library for loading 
dll functions on multiple platforms)

Re: The most enjoyable programming language I've ever used

[Rikki Cattermole via Digitalmars-d]

On 07/03/16 3:19 AM, Michalis wrote:

Hello everyone,

I just started learning D yesterday evening and at this point I started
playing around with vibe-d and the database connector libraries..

I just have one thing to say about D and that is ...WOW!!

By profession I'm a Java, .Mono and Python developer working on Linux
and I've been a Java/Linux fan-boy for all my life, but I kind of went
through almost every programming and scripting language I could get my
hands on (Rust, GoLang, Perl... even those Javascript off-springs like
TypeScript) but none of them ever topped Java.. until I bumped onto D..

Even though Java is still my favorite,
I must say that D is definitely the most enjoyable programming language
I've ever used!!



Awesome!
Do you have any suggestions for e.g. the docs?
Feedback is welcome :)

The most enjoyable programming language I've ever used

[Michalis via Digitalmars-d]

Hello everyone,

I just started learning D yesterday evening and at this point I 
started playing around with vibe-d and the database connector 
libraries..


I just have one thing to say about D and that is ...WOW!!

By profession I'm a Java, .Mono and Python developer working on 
Linux and I've been a Java/Linux fan-boy for all my life, but I 
kind of went through almost every programming and scripting 
language I could get my hands on (Rust, GoLang, Perl... even 
those Javascript off-springs like TypeScript) but none of them 
ever topped Java.. until I bumped onto D..


Even though Java is still my favorite,
I must say that D is definitely the most enjoyable programming 
language I've ever used!!

Had not Dllimport in D?

[xky via Digitalmars-d-learn]

First, I really sorry my bad english.

I just want to using Ruby dll file(msvcrt-ruby220.dll).
In the case of C#,

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
using INT = System.Int32;

namespace RubyTest01
{
  static class Ruby
  {
public const string RubyDll = "msvcrt-ruby18";

[DllImport(RubyDll)]
public static extern void ruby_init();

[DllImport(RubyDll)]
public static extern INT rb_eval_string_protect(byte[] 
script, ref INT state);


 public static INT rb_eval_string_protect(string script, ref 
INT state)

 {
return 
rb_eval_string_protect(Encoding.UTF8.GetBytes(script + '\0'), ref 
state);

}

}

class Program
{
  static void Main(string[] args)
  {
INT state = 0;
Ruby.ruby_init();
Ruby.rb_eval_string_protect("open('test.txt', 'w') {| fp| 
fp.write(\"Hello World!\\n\")}", ref state);


  }
}


I guess D had something like it, but i don't know how to do it.
Thx!

Re: Pitching D to a gang of Gophers

[Dmitry Olshansky via Digitalmars-d]

On 06-Mar-2016 10:21, Shammah Chancellor wrote:

On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:

[snip]

Here's some stuff D shares with Go:

"Single" binary deployments.
Garbage Collector
In-language slices and maps
Foreach (Although D is much more powerful here)

Some things D is weak on:
* The name -- all I ever hear are penis jokes.


Thankfully not in my country ;)


* Garbage Collector (!)


This is indeed a sore spot, Go rapidly advanced their GC and even took 
advantage of it being non-copying to deliver on lower-latency front. 
Wonder if we could squeeze some more bang out of GC.



* dfix and dfmt aren't as good as gofmt and gofix. (And believe me I
understand they will be much more difficult to get to parity due to the
feature set of D)


Strangely people love single imposed code style of Go, and in many ways 
other enforced conventions.



* Docs  -- although these have gotten much much better recently -- the
current implementation of concepts makes it hard for people to know
where and when they can use a type.  E.g sort docs
(http://dlang.org/phobos/std_algorithm_sorting.html#sort) How do I know
what types of things I can sort as a newcomer? Even if I figure out that
I need to look at isForwardRange, the docs there aren't terribly helpful
either
(https://dlang.org/phobos/std_range_primitives.html#isForwardRange)  I
would put up a PR, but I don't know how to fix it without introducing a
language structure for Concepts -- but this has been veto'd for a
variety of reasons (primarily type explosion as I understand the arguments)
* Libraries


Probably the biggest issue. Another one I'd pull is complexity, there is 
sooo many moving parts in D by now that we consistently fail to deliver 
a feature complete spec and/or compiler for it.




Some things D is much better on (and would cause me to choose it every
time and just contribute fixes where I could to the external tools):

* Package management/build tools
* Integration with existing build systems/libraries
* Reusable algorithms that are FAST
* Empowering programmer expressiveness without enabling magic


Overall my impression is that if we were to compare D and Go as tools, D 
would be more of meta tool - i.e. a tool to create tools whereas Go is 
ready made toolkit that is nicely crafted but quite limited.


Now I only need to appeal to the former somehow ;)


-S.



--
Dmitry Olshansky

Re: A very interesting slide deck comparing sync and async IO

[Shachar Shemesh via Digitalmars-d]

For switching between threads, this seems wrong.

On 04/03/16 20:29, deadalnix wrote:


The minimal cost of a context switch is one TLB miss (~300), one cache
miss (~300)


Why do you claim the first two? Again, assuming threads of the same 
process, where the address space (minus the TLS) is the same.



and iret (~300).


You have an iret whether you switched or not. Going into the kernel and 
coming back has that, whether we switched or not. In particular, since 
you need a system call in order to call "read", "write" and "accept", 
these are there regardless.


BTW, using one thread per client, you need less system calls, which 
reduces that particular overhead.



But then, you usually don't do context
switch for nothing, so some work has to be done in the context switch.
This is where it gets very dependent on which system call you use.

During its work, the system call would have evicted various cache lines
and TLB entries to put its own data there. That means that after the
context switch is done, part of your cache is gone, and you'll need some
time to start again running full speed.


I'm having a hard time following the discussion thread to understand 
what you are replying to here, but surely, you made the system call 
because you needed it to be done.



You may think that it is the
same with a library call, and to some extent it is, but much worse: as
kernel and userspace do not share the same address space


I hate that myth! It is such a difficult one to kill.

The kernel absolutely uses the same address space as the userspace 
(whatever user space happened to be there). That is why we had the 3/1GB 
split in the bad old 32bit days. The 1GB was a chunk of address space, 
bitten off the user space usable address space, that has the same 
mapping regardless of which user space is mapped in. This allows the 
kernel to use the same virtual addresses without loading a new TLB.


In other words, performing a system call is not a context switch.


and access
write,


That much is true, but it is merely a bit change in a register. It has 
no cache implications.



so you typically get way more trashing (you can't reuse TLB
entries at all for instance).


Like I said, not true.

As a side note, some platforms have cookies inside the TLB, so you don't 
have to flush it even when you do an actual context switch, but I'm 
guessing we're discussing Intel here.


Shachar

Re: A very interesting slide deck comparing sync and async IO

[Shachar Shemesh via Digitalmars-d]

On 05/03/16 20:50, Sean Kelly wrote:

On Friday, 4 March 2016 at 06:55:29 UTC, Shachar Shemesh wrote:

On 03/03/16 19:31, Andrei Alexandrescu wrote:

https://www.mailinator.com/tymaPaulMultithreaded.pdf


On a completely different note, me and a colleague started a proof of
concept to disprove the claim that blocking+threads is slower. We did
manage to service several tens of thousands of simultaneous
connections using the one thread per client mode, proving that the
mere context switch is not the problem here. Sadly, we never got
around to bringing the code and the tests up to the level where we can
publish something, but, at least in the case where a system call is
needed in order to decide when to switch fibers, I dispute the claim
that non-blocking is inherently faster.


It's not inherently faster. It just scales better in real-world
scenarios, assuming a limited number of worker threads. Blocking IO is
actually often fine in synthetic tests and in server to server, but in
real world situations where some clients have modem-level bandwidth, a
blocking write can ruin you.


Not if it's in its own thread, or am I missing something.

Shachar

[Issue 15774] New: cant write import std.range; twice

[via Digitalmars-d-bugs]

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

  Issue ID: 15774
   Summary: cant write  import std.range;  twice
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mephi...@nordhoff-online.de

import std.range;

public struct myRng( E)
{
import std.range;

public:
@property E front()
{
return 0;
}
@property void front( int elem)
{
}
void popFront()
{
}
@property bool empty()
{
return true;
}
@property auto save()
{
return this;
}
}
static assert( isForwardRange!( myRng!int));

bool check_( SomeThing)( SomeThing fofo) if( isInputRange!SomeThing)
{
return is( fofo);
}
unittest
{
auto r = myRng!int();
assert( r.check_ == false);
assert( walkLength( r) == 0);
assert( r.walkLength == 1);   // here the compiler fails
}$ 
$ 
$ 
$ 
$ 
$ dmd --version | fgrep -i dmd
DMD64 D Compiler v2.070.1
$ 
$ 
$ 
$ dmd t.d -lib -unittest
t.d(38): Error: cannot resolve type for r.walkLength(Range)(Range range) if
(isInputRange!Range && !isInfinite!Range)
$ 


cant write import std.range; twice in that situation.

its not okay, because with "mixin template" i have to write it twice sometimes.
(the compiler complains, if i dont write the imports into the mixins. i dont
even know, if that is correct behaviour)

--

[Issue 15771] FileLogger should create the output directory if it does not exist

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #1 from ZombineDev  ---
Perhaps this behavior can be supported by adding an additional flag to the
constructor? For example:

- this(in string fn, const LogLevel lv = LogLevel.all)

+ this(in string fn, const LogLevel lv = LogLevel.all,
   bool makeParentDirectories = false)

--

[Issue 15773] D's treatment of whitespace in character classes in free-from regexes is not the same as Perl's

[via Digitalmars-d-bugs]

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

--- Comment #1 from Markus Laker  ---
I've submitted a pull request:
.

--

[Issue 15773] New: D's treatment of whitespace in character classes in free-from regexes is not the same as Perl's

[via Digitalmars-d-bugs]

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

  Issue ID: 15773
   Summary: D's treatment of whitespace in character classes in
free-from regexes is not the same as Perl's
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: d20160306.20.mla...@spamgourmet.com

In Perl, whitespace in a character class is always significant, even in /x
extend mode:

msl@james:~$ perl -wE 'say "Matched" if "a b" =~ /[c d]/'
Matched
msl@james:~$ perl -wE 'say "Matched" if "a b" =~ /[c d]/x'
Matched
msl@james:~$

D's std.regex ignores whitespace in "x" free-form mode:

msl@james:~$ rdmd --eval='auto rx = regex("[c d]", ""); "a
b".matchFirst(rx).writeln'
[" "]
msl@james:~$ rdmd --eval='auto rx = regex("[c d]", "x"); "a
b".matchFirst(rx).writeln'
[]
msl@james:~$ rdmd --eval='auto rx = ctRegex!("[c d]", ""); "a
b".matchFirst(rx).writeln'
[" "]
msl@james:~$ rdmd --eval='auto rx = ctRegex!("[c d]", "x"); "a
b".matchFirst(rx).writeln'
[]
msl@james:~$

I wasted an hour's debugging time because I didn't expect this difference: I
thought whitespace would always be significant inside a character class. 
Perhaps other developers will have the same expectation that I did.  I don't
suggest that we change the behaviour of std.regex, because it would break too
much existing code, but could we explicitly mention D's behaviour in the docs? 
Many thanks.

--

[Issue 13940] std.algorithm.argMin

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

   Keywords||pull
 CC||ntrel-...@mybtinternet.com

--- Comment #6 from Nick Treleaven  ---
https://github.com/D-Programming-Language/phobos/pull/4019

--

Re: Pitching D to a gang of Gophers

[Jacob Carlborg via Digitalmars-d]

On 2016-03-06 10:05, Dmitry Olshansky wrote:


However the opposite is also bad - in D you need to re-implement ALL of
network/IO libraries from scratch to use async+fibers like e.g. vibe.d.
Our famous C/C++ interop actually hurts us in this case because it's
TRIVIAL to stumble on a blocking call in a fiber via some 3rd party
library.


I'm wondering how much work it would be to expose the read/write 
functions from vibe.d, update a C library to use the read/write 
functions from vibe.d and use that C library together with vibe.d.


--
/Jacob Carlborg

Re: std.xml2 (collecting features)

[Robert burner Schadek via Digitalmars-d]

On Saturday, 5 March 2016 at 15:20:12 UTC, Craig Dillabaugh wrote:
Robert, we have had some student interest in GSOC for XML.  
Would you be interested in mentoring a student to work with you 
on this.


Craig


Of course

OSS maintaining is a hard job (or how nanomsg died)

[extrawurst via Digitalmars-d]

a great blog post about insights into maintaining an open source 
software project by drew crawford and the nanomsg project:

http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/

--Stephan

Re: code-debug 0.6.0 released (GDB & LLDB for vscode)

[extrawurst via Digitalmars-d-announce]

On Sunday, 6 March 2016 at 11:25:30 UTC, WebFreak001 wrote:
I just released version 0.6.0 of my debug extension for visual 
studio code. It works really well for debugging D code and I 
also use it everytime I debug my D code. It's still not 
completely finished but it supports lots of features now. If 
you want to debug your code in vscode just install the 
extension with


ext install gdb

The name of the extension is "Debug" but "gdb" is more specific 
for finding it


LLDB is freshly added so be sure to report bugs to the github 
repository. :)


github: https://github.com/WebFreak001/code-debug
vscode: 
https://marketplace.visualstudio.com/items?itemName=webfreak.debug


Great stuff, especially LLDB - if now only code-d would work for 
osx :P


--Stephan

code-debug 0.6.0 released (GDB & LLDB for vscode)

[WebFreak001 via Digitalmars-d-announce]

I just released version 0.6.0 of my debug extension for visual 
studio code. It works really well for debugging D code and I also 
use it everytime I debug my D code. It's still not completely 
finished but it supports lots of features now. If you want to 
debug your code in vscode just install the extension with


ext install gdb

The name of the extension is "Debug" but "gdb" is more specific 
for finding it


LLDB is freshly added so be sure to report bugs to the github 
repository. :)


github: https://github.com/WebFreak001/code-debug
vscode: 
https://marketplace.visualstudio.com/items?itemName=webfreak.debug

Re: Create Windows "shortcut" (.lnk) with D?

[John via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 03:13:23 UTC, 岩倉 澪 wrote:

IShellLinkA* shellLink;
IPersistFile* linkFile;

Any help would be highly appreciated as I'm new to Windows 
programming in D and have no idea what I'm doing wrong!


In D, interfaces are references, so it should be:

  IShellLinkA shellLink;
  IPersistFile linkFile;

[Issue 15772] New: emplace works with abstract classes but it shouldn't

[via Digitalmars-d-bugs]

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

  Issue ID: 15772
   Summary: emplace works with abstract classes but it shouldn't
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

abstract class Foo {}
void main(string[] args)
{
import std.c.stdlib;
auto mem = malloc(typeid(Foo).initializer.length);
import std.conv;
auto c = emplace!Foo(cast(Foo*)mem);
}
--

Re: Pitching D to academia

[Russel Winder via Digitalmars-d]

On Sat, 2016-03-05 at 23:38 -0800, Ali Çehreli via Digitalmars-d wrote:
> Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, how 
> about pitching it to a gang of professors and graduate students?
> 
> I will be presenting D to such an audience at METU in Ankara. What
> are 
> the points that you would stress? I am thinking that they would be 
> interested more in whether D is better as a teaching tool. Do you
> agree?

It all depends who the students are that academics you are pitching to
will be dealing with.

Assuming Turkish academic structure and academics are at least
analogous to UK ones…

Level of student:

A. Learning programming from nothing.
B. Learning about data structures and algorithms as a second
programming course.
C. Doing some advanced option.

Which subject is their main one:

1. Computing
2. Computer Science
3. Electronic Engineering
4. Physics
5. Biology
6. Economics
…

For 3 they will use C: It has been enshrined in canon for about 30
years that electronic engineers will use C.

4, 5, 6, and … will either use Fortran (but not FORTRAN), or Python.
This is due to extant codebases and support for subject specific data
analysis and visualization.

There is likely no point in trying to get D in front of students other
than in categories 1 and 2.

All too often courses labelled "Computer Science" contain little or no
programming, or at best very little quality programming education.
Fashion is generally the driving force behind most language choice,
very few institutions do proper analysis.

For options courses, C above, people will choose a domain related
language rather than a general purpose one. For OS, use C (or C++,
Rust) – the idea of writing an OS in a language with GC will not have
percolated in. FP course will use Haskell, Clean, Lisp, OCaml, SML,…

For second course, B above, it is usual to carry on with the language
of the initial course, especially if there has only been one. If there
hasn't it helps as you get two languages to work with.

For introduction courses, A above, most will use Java (because,
history), or Python. Unless you are Texas A in which case C++. Some
enlightened organizations will use a combination, Haskell and Prolog,
Python and C++,…

The single most important driver is being able to do stuff immediately
on Day 1. This generally means a REPL – usually because that is the
indoctrination the academics have received over the years.

So where does D fit?

Do not try to compete with the FP languages in FP courses, just do not
go there.

OS and hardware could be a good place, especially using the no GC D.

D fits well for data structures and algorithms as it can do the full
multi-paradigm thing way better than C++, and Rust, and you can bring C
in if needed. The material in Phobos is good to show end results, but D
is good for showing the simple algorithms needed in such a course. You
get the full imperative approach and the more declarative approach
possible with D.

Find out which text books they use if any, or which materials they use,
if D fits with that good, if it doesn't then you have to wait for a
change of responsible academic before you get a change of language and
material.

For starting, D's single most important thing is rdmd. Write code, run
it.

The downside for D is that it is big and complex more or less from the
outset, like C++ and Rust, just less so. Biggest competitor will be Go
which is very simple at the outset and only gets complicated later, and
they have "go run".

Type inference is good so you don't spend time writing out the names of
types lots of time (as in Java). Strong compile time typing is good,
mostly because students do not have to know about it at the outset. 
 
Some academics like a bottom up approach; some students like that. Some
academic prefer a more wholistic, experiential approach; some students
like that. Kids love playing and finding out in a morass of lack of
knowledge. By the time people have got to university most students have
had that joy beaten out of them by academics in favour of the structure
bottom up constructivism. How sad.

So D as a language that can handle bottom up and experiential learning
might be a good line.

Anyway this has turned into a long email, and I have to go. Hopefully
this has helped some. 

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

is module ( std.experimental.logger) thread-safe.

[Dsby via Digitalmars-d-learn]

I want to use the filelogger to my application.
is the  sharedLog()  global and  thread-safe.

[Issue 15771] New: FileLogger should create the output directory if it does not exist

[via Digitalmars-d-bugs]

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

  Issue ID: 15771
   Summary: FileLogger should create the output directory if it
does not exist
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: minasm1...@gmail.com

Currectly, this throws an exception, because the folder "oops" does not exist.

//
import std.experimental.logger;

void main()
{
auto logger = new FileLogger("/home/minas/oops/log.txt");
}
//

std.exception.ErrnoException@std/stdio.d(393): Cannot open file
`/home/minas/oops/log.txt' in mode `a' (No such file or directory)



The solution is simple: mkdirRecurse("/home/minas/oops/");
However, this is something that the logging system should be doing, not the
client programmer.

(As an example Java's logback and log4j create the directory structure if it's
not there).

--

Re: If stdout is __gshared, why does this throw / crash?

[Atila Neves via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 01:28:52 UTC, Marco Leise wrote:

Got it now: https://issues.dlang.org/show_bug.cgi?id=15768

writeln() creates a copy of the stdout struct in a non 
thread-safe way. If stdout has been assigned a File struct 
created from a file name this copy includes a "racy" 
increment/decrement of a reference count to the underlying 
C-library FILE*. In the case that the reference count is 
erroneously reaching 0, the file is closed prematurely and when 
Glibc tries to access internal data it results in the 
observable SIGSEGV.


Nice, good work!

Atila

Re: If stdout is __gshared, why does this throw / crash?

[Atila Neves via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 01:10:58 UTC, Anon wrote:

On Saturday, 5 March 2016 at 14:18:31 UTC, Atila Neves wrote:

[...]


Note that `1000.iota.parallel` does *not* run 1000 threads. 
`parallel` just splits the work of the range up between the 
worker threads (likely 2, 4, or 8, depending on your CPU). I 
see the effect you describe with any parallel workload. Smaller 
numbers in place of 1000 aren't necessarily splitting things 
off to additional threads, which is why smaller numbers avoid 
the multi-threaded problems you are encountering.


Err, right.




[...]


`File` uses ref-counting internally to allow it to auto-close. 
`stdout` and friends are initialized in a special way such that 
they have a high initial ref-count. When you assign a new file 
to stdout, the ref count becomes one. As soon as one of your 
threads exits, this will cause stdout to close, producing the 
odd errors you are encountering on all the other threads.


I would avoid reassigning `stdout` and friends in favor of 
using a logger or manually specifying the file to write to if I 
were you.


I see. Here's my problem: I want to make it so code not under my 
control doesn't get to write to stdout and stderr. I don't see 
any other way but to reassign stdout. Maybe I can manually bump 
up the ref count?


Atila

Re: Pitching D to a gang of Gophers

[Dmitry Olshansky via Digitalmars-d]

On 06-Mar-2016 01:13, Walter Bright wrote:

On 3/5/2016 3:05 AM, Dmitry Olshansky wrote:

What features you'd highlight to enterprise-ish user?


Interfacing to existing C and C++ code.



They have no C/C++ code to interface to, so it makes little sense to 
them. Many prominent C libraries actually have fine Go bindings for 
things like compression/encryption, in fact there most likely more of 
them then for D (because of popularity of Go).


--
Dmitry Olshansky

Re: Pitching D to academia

[cym13 via Digitalmars-d]

On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:
Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, 
how about pitching it to a gang of professors and graduate 
students?


I will be presenting D to such an audience at METU in Ankara. 
What are the points that you would stress? I am thinking that 
they would be interested more in whether D is better as a 
teaching tool. Do you agree?


Ali


I would insist heavily on the multiparadigm properties of D: 
being able to teach C-like imperative programming, java-like OOP, 
compilers and assembly, purity and functional paradigms, testing 
and profiling, all that without having to change language even 
once is likely to be D's strongest strength for a teacher I think.

Re: Pitching D to a gang of Gophers

[Dmitry Olshansky via Digitalmars-d]

On 05-Mar-2016 14:31, John Colvin wrote:

On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:

I'm having an opportunity to do a small tech-talk on things D in a
eCommerce shop that is currently sold on Go (migrating to SOA from PHP
monolith). I do not intend that to become Go vs D battle but it gives
the context.

[...]


Have you seen this?
http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/
I'm not sure if it's all correct and how to compare the situation to D,
but it was interesting to read.


Rings true with my (limited) experience with Go.

--
Dmitry Olshansky

Re: Pitching D to a gang of Gophers

[Dmitry Olshansky via Digitalmars-d]

On 05-Mar-2016 20:17, Chris Wright wrote:

On Sat, 05 Mar 2016 14:05:09 +0300, Dmitry Olshansky wrote:


What features you'd highlight to enterprise-ish user?


Go isn't bad from an enterprise perspective -- it's better than D, in
fact. Go has a major company heavily invested in it, and a number of
other companies are supporting it.

D is much more programmer-friendly, and that's where it tends to shine.
C# is close enough that there's no order-of-magnitude difference, plus
it's got corporate support, so for an enterprise crowd I'd sooner
recommend it.


All true. In fact I've been worried that D may look like just another C# 
with a bit different set of trade-offs. Like native code C/C++ inter-op 
friendly C# with strong compile-time meta-programming capabilities.


Keeping in mind that folks sometimes are just fine with run-time 
meta-programming as in being able to use compiler as a library...



Things I might talk about:

Interacting with the fiber scheduler explicitly. Goroutines are
hermetically sealed. D Fibers are much more open.


Interacting with scheduler directly is a type code these folks would 
LOVE to avoid. And looking at in-house library I can wholeheartedly 
agree, there is just not enough system-level expertise to meaningfully 
use this kind of control.



  * Need fiber-local storage? Subclass Fiber and you're a cast away from
it. Need goroutine-local storage? There's a library for it, but it's a
terribly ugly hack.



  * Need to shut down a goroutine and stop it from running? You have to
have it explicitly check in every location another goroutine might want
to stop it, and it's not a trivial check either. Plus you need to
propagate a channel down the stack somehow. In D, it's almost trivial to
stop a Fiber.
  * Need to schedule things precisely?


Most likely the answer would - why should I. And indeed for the most 
purposes of a web-service there is rarely a good need for it.



Impossible. You can sleep, or you
can wait on IO, but that's it. You can't rate-limit an operation,
or add  thread affinity so one set of goroutines is reliably scheduled
independently of another. In D, you can implement all of that.



However the opposite is also bad - in D you need to re-implement ALL of 
network/IO libraries from scratch to use async+fibers like e.g. vibe.d. 
Our famous C/C++ interop actually hurts us in this case because it's 
TRIVIAL to stumble on a blocking call in a fiber via some 3rd party library.



Templates vs interface{}. interface{} is nice to have sometimes, and
we've got std.variant for those times. But almost always we want actual
type safety and not to put casts everywhere.


Working with JSON could be an interesting example as Go's solution 
involves lots of type-casting when working with dynamic structure.



Better control over the garbage collector. You can prevent collections
from running in D and have the compiler enforce non-usage of the GC.

Then there are all the ways in which Go deviates from standard practices
and gets things wrong.


I count a lot of these, mostly all of them have to do with the fact that 
writing anything non-bogus by default requires great discipline to write 
highly repetitive non-trivial patterns. For instance, channels are 
awkwardly non-composable low-level primitives that are easy to get wrong 
in so many ways.



There's a giant list of them, and D doesn't give a
specific advantage.



--
Dmitry Olshansky

Re: std.database

[Kagamin via Digitalmars-d]

On Saturday, 5 March 2016 at 18:00:56 UTC, Erik Smith wrote:
I'm definitely going to start working in async capability (or 
more accurately, non-blocking) into the interface.


Huh? Non-blocking operation is not reflected in interface. Only 
asynchronous requires special interface. Vibe interfaces are 
synchronous.


Postgres also provides non-blocking support.  These are two 
cases that I'm targeting for initial reference implementations.


I've looked into OCI headers, they say something about 
asynchronous operations, do you know something about that?

Re: Pitching D to academia

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:
Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, 
how about pitching it to a gang of professors and graduate 
students?


The geeky graduate students are the better target.

In teaching you usually want a focused clean language related to 
the course or a language that is already adopted by industry.

Re: Pitching D to academia

[Minas Mina via Digitalmars-d]

On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:
Motivated by Dmitry's "Pitching D to a gang of Gophers" thread, 
how about pitching it to a gang of professors and graduate 
students?


I will be presenting D to such an audience at METU in Ankara. 
What are the points that you would stress? I am thinking that 
they would be interested more in whether D is better as a 
teaching tool. Do you agree?


Ali


What about:

D can be used as a high level, high productivity scripting 
language, just like Python, with two exceptions:

1) You get static type checking
2) When can compile the program instead of interpreting when you 
need the performance. No need to re-write it.