[Issue 9471] std.xml uses DbC to validate XML syntax

[via Digitalmars-d-bugs]

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

Abhishek Kumar  changed:

   What|Removed |Added

   Keywords||pull
 CC||abhishekkm...@gmail.com

--

[Issue 4509] XML parser in std.xml throws TagException if the attr value is put in apostrophes.

[via Digitalmars-d-bugs]

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

Abhishek Kumar  changed:

   What|Removed |Added

   Keywords||pull

--

[Issue 7519] std.xml cannot manage single quoted attribute values

[via Digitalmars-d-bugs]

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

Abhishek Kumar  changed:

   What|Removed |Added

 CC||abhishekkm...@gmail.com

--

[Issue 4509] XML parser in std.xml throws TagException if the attr value is put in apostrophes.

[via Digitalmars-d-bugs]

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

Abhishek Kumar  changed:

   What|Removed |Added

 CC||abhishekkm...@gmail.com
   Assignee|nob...@puremagic.com|abhishekkm...@gmail.com

--- Comment #2 from Abhishek Kumar  ---
I have sent a PR to fix this bug
https://github.com/D-Programming-Language/phobos/pull/4064 .

--

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

[Rory McGuire via Digitalmars-d-announce]

On Tue, Mar 8, 2016 at 2:23 AM, Manu via Digitalmars-d-announce
 wrote:
>
> On 6 March 2016 at 21:25, WebFreak001 via Digitalmars-d-announce
>  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
>
> Cool, I'll give this a crack.
>
> I've tried out code-d, but it only seems to do anything useful with dub.
> None of my projects use dub. Every project I have combines C/C++/D,
> and dub is an insufficient build system.
> I can configure vscode projects to invoke my builds, but code-d
> doesn't have any project metadata to work with in that context.
> Can you work code-d to get its necessary working state from explicit
> variables in the vscode project file?


Hi Manu,

Have you checked out these dub commands?
preBuildCommands string[] A list of shell commands that is executed
always before the project is built
postBuildCommands string[] A list of shell commands that is executed
always after the project is built

R

Re: std.allocator issues

[Marco Leise via Digitalmars-d]

Am Sat, 20 Feb 2016 08:47:47 -0500
schrieb Andrei Alexandrescu :

> On 02/20/2016 12:39 AM, Steven Schveighoffer wrote:
> > Given that there is "goodAllocSize", this seems reasonable. But for
> > ease-of-use (and code efficiency), it may be more straightforward to
> > allow returning more data than requested (perhaps through another
> > interface function? allocateAtLeast?) and then wrap that with the other
> > allocation functions that simply slice the result down to size.
> 
> Actually I confess that was the exact design for a while, and I, too, 
> found it ingenious. You ask me for 100 bytes but I'll allocate 256 
> anyway, why not I just return you the whole 256? But then that puts 
> burden everywhere. Does the user need to remember 256 so they can pass 
> me the whole buffer for freeing? That's bad for the user. Does the 
> allocator accept 100, 256, or any size in between? That complicates the 
> specification.

I found it ingenious, too. The question how much room was
really made free is common in programming. Aside from memory
allocations it can also appear in single reader/writer
circular buffers, where the reader consumes a chunk of memory
and the waiting writer uses `needAtLeast()` to wait until at
least X bytes are available. The writer then caches the actual
number of free bytes and can potentially write several more
entries without querying the free size again, avoiding
synchronization if reader and writer are threads.

Most raw memory allocators overallocate, be it due to fixed
pools or alignment and the extra bytes can be used at a higher
level (in typed allocators or containers) to grow a data
structure or for potential optimizations. I think for
simplicity's sake they should return the overallocated buffer
and expect that length when returning it in `free()`. So in
the above case, 256 would have to be remembered. This is not a
conceptual burden, as we are already used to the 3 properties:

ptr, length = 100, capacity = 256 

By the way: jemalloc has `mallocx()` to allocate at least N
bytes and `sallocx()` to ask for the actual size of an
allocation.

-- 
Marco

Re: Parameterized Keywords

[Patience via Digitalmars-d]

On Tuesday, 8 March 2016 at 00:47:10 UTC, Mike Parker wrote:

On Monday, 7 March 2016 at 20:54:22 UTC, Patience wrote:

On Monday, 7 March 2016 at 15:09:48 UTC, Lass Safin wrote:

On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

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


You declare arrays of integers with int[size], you know that, 
right?


No, not right. Think again. Get your mind out the gutter. 
Making your own assumptions about what I am talking about can 
get you in to trouble. Only in programming languages were 
int[size] is interpreted as an array does it mean that.




To be fair, this is a D newsgroup and you did not specify that 
you are talking about this as a general concept rather than 
something for D. My first reaction was the same. It's only 
natural to assume you are talking about this as a part of D.


Yes, but that isn't the point. The point is that only retards 
such as Bob takes abstractions literally.


Why does it matter if I used [] or {} or . or \ or <> to 
reference something doesn't exist yet and hence could be defined 
any way one wants? Then be told it is a total waste by someone 
that clearly doesn't have the basic intellectual ability to 
understand abstractions?


Basically: If someone can't understand that a new 
concept/proposition is malleable and not fixed then they really 
shouldn't be discussing it, They need to go back to their 0's and 
1's.


That is, I except someone to have to think about what I'm saying 
and interpret it properly instead of just adding there 2 cents 
and pretending like it's a dollar.

Re: Speed kills

[Marco Leise via Digitalmars-d]

Am Wed, 17 Feb 2016 19:55:08 +
schrieb Basile B. :

> Also, forgot to say, but an uniform API is needed to set the 
> rounding mode, whether SSE is used or the FPU...

At least GCC has a codegen switch for that. A solution would
have to either set both rounding modes at once or the
compilers would need to expose version MathFPU/MathSSE.

-- 
Marco

year to date pull statistics

[Brad Roberts via Digitalmars-d]

A topic that rolls around periodically is the number of open pulls and or the frequency at which a 
pull is 'ignored' (no, it's not ignored, it's just lost in the noise).  I've dug up some rate of 
change statistics for the year to date for pulls to the D-P-L master branches of the dmd, druntime, 
and phobos repositories:


   created  closed  delta
2016-03-06 - today  12  10 -2
2016-02-28 - 2016-03-05 54  48 -6
2016-02-21 - 2016-02-27 29  20 -9
2016-02-14 - 2016-02-20 32  36 +4
2016-02-07 - 2016-02-13 52  52  0
2016-01-31 - 2016-02-06 54  61 +7
2016-01-24 - 2016-01-30 40  37 -3
2016-01-17 - 2016-01-23 31  21-10
2016-01-10 - 2016-01-16 39  42 +3
2016-01-03 - 2016-01-09 26  33 +7
2016-01-01 - 2016-01-02  2   5 +3
   --- ------
   371 365 -6

Not bad at all; lots of activity going on pretty much constantly.  The problem is that there's so 
much traffic with such a large backlog:


   total open: 272
   created since 2016-01-01 and still open: 86

that unless something brings a pull request to the top of the queue then it's visibility is shot.  A 
great illustration of that effect is in the age (in number of days) histogram of closed pulls for 
all pulls created since 2016-01-01:


+--+--+
| age  | count(*) | acc% of closed
+--+--+
|0 |  120 | 42%
|1 |   64 | 65%
|2 |   25 | 73%
|3 |   12 | 78%
|4 |5 | 79%
|5 |5 | 81%
|6 |6 | 83%
|7 |6 | 85%
|8 |5 | 87%
|9 |5 | 89%
|   10 |2 | 89%
|   11 |2 | 90%
|   12 |4 |
|   13 |1 |
|   14 |2 |
|   15 |1 |
|   16 |1 |
|   17 |1 |
|   18 |1 |
|   20 |1 |
|   21 |1 |
|   22 |1 |
|   23 |3 |
|   24 |1 |
|   26 |1 |
|   28 |1 |
|   29 |1 |
|   37 |1 |
|   39 |1 |
|   41 |2 |
|   42 |1 |
|   46 |1 |
|   47 |1 |
+--+--+
 sum: 285

So, I guess one point that comes from this data, and is already anecdotally well known, if you have 
a pull request that you believe is ready to be merged and nothing has progressed in a couple days or 
maybe a week, please ping the PR.  Chances are good that it has simply fallen off the active radar.


To see a live view of the above data:
https://auto-tester.puremagic.com/chart.ghtml?projectid=1

The top graph is a histogram of the current number of open pull requests in monthly sized buckets. 
The next two are the same data as the first chart above broken down by week for the last year.  The 
last two are similar but looking at the issue data rather than the pull data.



Later,
Brad

Re: Parameterized Keywords

[Bob the Viking via Digitalmars-d]

On Monday, 7 March 2016 at 20:54:22 UTC, Patience wrote:

On Monday, 7 March 2016 at 15:09:48 UTC, Lass Safin wrote:

On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

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


You declare arrays of integers with int[size], you know that, 
right?


No, not right. Think again. Get your mind out the gutter. 
Making your own assumptions about what I am talking about can 
get you in to trouble. Only in programming languages were 
int[size] is interpreted as an array does it mean that.


And I really don't see any useful improvement, that could be 
added with this. It would just be wasted efforts.


You sound very intelligent!!! I'm sure glad I asked you before 
I asked god since you seem to know everything about everything. 
Thanks for the input! I will simple cease to think about 
progress from now on since you have decided that no progress 
can be made.


Thanks again brother!


Now listen up, you retarded piece of gutter slime. You are 
posting a newsgroup for D, a language in which int[N] does indeed 
indicate an array of N ints. If that's too hard for you to grasp, 
may I suggest you take up gardening or DIY lobotomy?


While your first post contained what might be interesting ideas, 
your complete lack of understanding of what might be a fruitful 
debate makes me skeptical of them, you, and the future of the 
entire human race. Congratu-fucking-lations.



You have five ideas in your opening post, with limited 
explanations for two of them.


Let's start with those two, because it's actually possible to 
divine what they do. I'm going to stay within the D universe, 
since I like it here, and it gives us at least some modicum of 
solid ground.


== foreach[?] ==

Where is '?' defined? Is it a property of the object being 
iterated over? Is it a global (dog forbid)? Is it just plain 
magic, and you're too stoned to make a sensible explanation?


'executes only if there are one or more iterations'. Just like 
every fucking other foreach, then. What in Wotan's beard would it 
otherwise do with an empty list? Or does it somehow only run 
once, so as to make programming even easier to grasp?


'checks for nullity'. At what bloody level? Suppose there's a 
foreach[?] (a.b.c.allthefuckingletters.ð.ü) - is every single one 
checked? When does it check? Suppose allthefuckingletters above 
suddenly becomes ñúll - does this thing crash? Turn the universe 
into soup?


== int[size] ==

I'm going to pretend I didn't see this. It's a feature that 
exists for small N in D, C, C++ and probably other languages. 
They're called bitfields and are as old as the mountains (unless 
you're a young-earth creationist, in which case they're older).



So, onto your other ravings:

== for[32] ==

What the bloody fuck is this abomination? Like above, who has the 
power to redefine the number 32? Is this some Smalltalk inspired 
thoughtbleed where I can change the metaclass of the number 32 
and give it new features? Can I make it a prime?


Without any kind of explanation, this thing is just weird. I 
can't for the life of me imagine what it'd do, why anyone'd do 
it, or why anyone would even think it up in the first place.


== switch[alpha] ==

Now we might conceivably be getting somewhere. So this turns 
'switch' into a black box that may or may not behave like you 
expect to, depending on how junior and/or crazy the implementer 
is?


I can imagine implementing faster struct comparisons in switch 
statements, and one might even use this to do some interesting 
ADT stuff. But even then, why do I need to specify the type? It's 
right there in the argument to switch.


== if[x](x < 32) ==

See this? This is what madness is made out of. This thing says 'I 
pretend to compare x to 32, but I'm actually downloading horse 
porn and telling your girlfriend it's yours'. It says 'screw you 
and your boolean logic!'. This thing is literally Stalin reborn 
as Hitler.


See, it's not redefining comparison, it's redefining causality. 
This is quantum computing gone bad. What in the name of 
Shub-Niggurath could this possibly do that isn't bad? At least 
with 'switch' there are optimization possibilities, and maybe 
some ADT stuff. Redefining 'if' is like Grassmann numbers or 
Discordianism. Down this path lies chaos.

[Issue 14984] Make it illegal (or at least a warning) to modify the iteration variable in foreach

[via Digitalmars-d-bugs]

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

r...@rcorre.net changed:

   What|Removed |Added

 CC||r...@rcorre.net

--

Re: Parameterized Keywords

[Mike Parker via Digitalmars-d]

On Monday, 7 March 2016 at 20:54:22 UTC, Patience wrote:

On Monday, 7 March 2016 at 15:09:48 UTC, Lass Safin wrote:

On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

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


You declare arrays of integers with int[size], you know that, 
right?


No, not right. Think again. Get your mind out the gutter. 
Making your own assumptions about what I am talking about can 
get you in to trouble. Only in programming languages were 
int[size] is interpreted as an array does it mean that.




To be fair, this is a D newsgroup and you did not specify that 
you are talking about this as a general concept rather than 
something for D. My first reaction was the same. It's only 
natural to assume you are talking about this as a part of D.

[Issue 15726] [REG2.068.0] forward reference error for circular classes, RefCounted

[via Digitalmars-d-bugs]

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

Erik Smith  changed:

   What|Removed |Added

 CC||e...@cruiserhouse.com

--- Comment #1 from Erik Smith  ---
This bug also occurs in other cases where the types are not directly cross
referenced with top level aliases (see example below using same RefCounted as
in first example). This is blocking multiple design paths without a workaround.


struct Util(C,S) {}

struct Connection(T) {
alias Util = .Util!(Connection!T, Statement!T);
}

struct Statement(T) {

struct Payload {
Connection!T con;
}

RefCounted!Payload Data;
}

Connection!int x;

--

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

[Manu via Digitalmars-d-announce]

On 6 March 2016 at 21:25, WebFreak001 via Digitalmars-d-announce
 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

Cool, I'll give this a crack.

I've tried out code-d, but it only seems to do anything useful with dub.
None of my projects use dub. Every project I have combines C/C++/D,
and dub is an insufficient build system.
I can configure vscode projects to invoke my builds, but code-d
doesn't have any project metadata to work with in that context.
Can you work code-d to get its necessary working state from explicit
variables in the vscode project file?

Re: Error: constructor Foo.this default constructor for structs only allowed with @disable, no body, and no parameters

[Nicholas Wilson via Digitalmars-d-learn]

On Monday, 7 March 2016 at 13:23:58 UTC, Nicholas Wilson wrote:

struct Fence
{
VkFence fence;
alias fence this;

 static struct CreateInfo
{
 VkFenceCreateInfo  ci;
 alias ci this;
 this(
   )
{
 ci = typeof(ci)(
 cast(typeof(ci.sType))StructureType.eFenceCreateInfo,
 null,
 0);
 }
 }
}

I'm not quite sure what this error is saying. Is it that the 
only struct constructor that can have no parameters is @disable 
this(){} ?


If so this is rather annoying as I have to create a new code 
path for the generation of this and 7 other structs. What must 
the code be in this case?


 static struct CreateInfo
{
		 VkFenceCreateInfo	ci = 
VkFenceCreateInfo(cast(typeof(ci.sType))StructureType.eFenceCreateInfo,null,0);

 alias ci this;
}
?


"Solved" by having a default parameter. Results in a deprecation 
but w/e.

Re: DDMD: functions defined in both C++ and D

[Walter Bright via Digitalmars-d]

On 3/7/2016 2:19 PM, Daniel Murphy wrote:

That.


Daniel is a man of few words :-)

Re: Speed up `dub`.

[Luis via Digitalmars-d-learn]

On Monday, 7 March 2016 at 18:58:55 UTC, ciechowoj wrote:

dub --version
DUB version 0.9.24+161-gb9ce700, built on Feb 23 2016

`dub.json` is `dub.json` of dstep

`dub test --skip-registry=all`
Do not helps.


I try to grab dstep with dub fetch step (dub version 0.9.24, 
built on Aug 19 2015, on Ubuntu), and try to run dub build step. 
I can confirm that on my machine takes around 5 seconds to check 
if the dependencies are update.

Re: DDMD: functions defined in both C++ and D

[Daniel Murphy via Digitalmars-d]

On 8/03/2016 7:12 AM, Johan Engelen wrote:

 or perhaps a remnant of
semi-automated C++->D conversion?


That.

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

[Rikki Cattermole via Digitalmars-d]

On 08/03/16 7:57 AM, Michalis wrote:

On Sunday, 6 March 2016 at 14:23:51 UTC, Rikki Cattermole wrote:

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 :)


At this point I'm still a noob so still haven't gone through all the
docs yet.
Up until now I find the Docs site extremely helpful and well designed,
and I also like the fact that when I installed D through the package
manager, everything was neatly taken care along with a desktop version
of the docs site.

I have one general question, since I see the DWT library mentioned as
part of the main ecosystem.
Is DWT considered as the official UI framework?


It was going to be (port of SWT), but it never ended up as such although 
it is maintained still.



With Java I use SWT for desktop and RWT (part of Eclipse RAP) for web UI
development as my main framework, and if DWT is to be the official UI
for D, then that would be great news for me.
I did not find DWT though in the DUB repository, so at this point I've
checked it out from Git.
Having a few issues when compiling for 64bit, but that I guess is
something that I'll take care of along the way.. :)

Re: Speed up `dub`.

[Seb via Digitalmars-d-learn]

On Monday, 7 March 2016 at 09:18:37 UTC, ciechowoj wrote:
I'm using `dub` to build project. And every time I run `dub` it 
seems to check if dependencies are up to date, which takes some 
time. Is there a way to switch of that checking? Or any other 
way to speed up building process? It really slows down my 
modify-compile-check iteration time.


Use ld.gold - it will speed up your linking quite dramatically!

https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html

Re: Speed up `dub`.

[xcvn via Digitalmars-d-learn]

On Monday, 7 March 2016 at 19:58:19 UTC, WebFreak001 wrote:

On Monday, 7 March 2016 at 18:58:55 UTC, ciechowoj wrote:

dub --version
DUB version 0.9.24+161-gb9ce700, built on Feb 23 2016

`dub.json` is `dub.json` of dstep

`dub test --skip-registry=all`
Do not helps.


Its because of dub going through all those JSON files. For 
example just querying the import paths would probably take like 
7s in your case. Try "dub describe --import-paths" in your 
project. Its something you can't do anything against except 
reporting it to the dub issues


Yes but if he wants to build then `--describe` will not help that 
much !

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

[Guillaume Piolat 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


Very interesting, thanks!

Re: Parameterized Keywords

[Patience via Digitalmars-d]

On Monday, 7 March 2016 at 16:29:27 UTC, NX wrote:

On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

Just curious if anyone can see the use for them?


I believe 'new' keyword can take advantage of this quite good.
For example you can pass memory usage strategy like so:
MyClass mc = new[stream] MyClass();
MyClass mc2 = new[static] MyClass();

Deja-vu? Yes the idea comes from OpenGL. Also it might come in 
handy for other stuff:

MyClass mc3 = new[no_internal_pointers] MyClass();
MyClass mc4 = new[no_compacting] MyClass();



Yeah, Maybe... new seems more like a keyword hack though. Things 
like if and loop are more natural as keywords(I guess since they 
generally have precise meanings in hardware/assembly). If the 
language already has new as a keyword though, it does seem like a 
good way to modify its behavior.

Re: Parameterized Keywords

[Patience via Digitalmars-d]

On Monday, 7 March 2016 at 15:09:48 UTC, Lass Safin wrote:

On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

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


You declare arrays of integers with int[size], you know that, 
right?


No, not right. Think again. Get your mind out the gutter. Making 
your own assumptions about what I am talking about can get you in 
to trouble. Only in programming languages were int[size] is 
interpreted as an array does it mean that.


And I really don't see any useful improvement, that could be 
added with this. It would just be wasted efforts.


You sound very intelligent!!! I'm sure glad I asked you before I 
asked god since you seem to know everything about everything. 
Thanks for the input! I will simple cease to think about progress 
from now on since you have decided that no progress can be made.


Thanks again brother!

Re: Pitching D to academia

[Timon Gehr via Digitalmars-d]

On 07.03.2016 06:08, Walter Bright wrote:

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.


Why those features in particular?

DDMD: functions defined in both C++ and D

[Johan Engelen via Digitalmars-d]

(this is about DDMD internals, but the DMD-internals forum is 
maillist only, so posting here. Pardon me please. [*] )


Currently some functions are defined (as opposed to declared) 
both in C++ and in D. For example, all of Visitor's virtual 
methods. The "double-defined" methods are all defined such that 
C++ should inline them (C++ spec), but it is causing trouble with 
MSVC (who does not inline as much in debug mode it seems, even 
when explicitly telling it to be spec compliant).
This is causing troubles when building LDC, using MSVC+LDC (using 
LDC as the D-compiler to build itself, instead of DMD who creates 
object files with a more lax linking attribute on all symbols). 
Symbols show up in D-object files and C++-object files and the 
MSVC linker does not want to link ldc2.exe. We can work around 
this... but I'd rather not increase the diff with upstream...


Regardless of LDC's troubles, do we really want methods to be 
double-defined? Is this intentional, or perhaps a remnant of 
semi-automated C++->D conversion? I doubt that the extra inlining 
possibilities are noticable (but I did not measure).


Shall I work on a PR that removes (some of) the double-defined 
guys from C++ source?

(read: would that have a chance of pulling without long debate)

Thanks,
  Johan


[*] Perhaps add a "DMD" section under "Ecosystem"?

Re: Uniform Function Call Syntax?

[Timon Gehr via Digitalmars-d]

On 07.03.2016 01:19, 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.


That "something" is your editor configuration. Seriously, this is a 
trivial problem.

[Issue 14965] [REG2.031] Forward reference to inferred return type of function call when using auto return type

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/4b6779d2ff0b95866205189cb55e5aef00c13c7e
fix Issue 14965 - Forward reference to inferred return type of function call
when using auto return type

If a function symbol is used, its overload resolution should be deferred until:

```d
func(...)   // CallExp.semantic
func.mangleof   // DotIdExp.semanticY
typeof(func)// TypeTypeof.resolve
typeof()   // TypeTypeof.resolve
auto v =  // ExpInitializer.inferType
  // ExpStatement.semantic
return// ReturnStatement
```

When the semantic analysis reaches to them, the function forward reference can
beome actual error.

Other use of 'func' should be treated as a property-like function call (done in
`resolveProperties`) and finally handled in `CallExp`.

https://github.com/D-Programming-Language/dmd/commit/624ad66c0bbfdfad8c5c1fc95339f77ac3659694
Merge pull request #5202 from 9rnsr/fix14965

[REG2.031] Issue 14965 - Forward reference to inferred return type of function
call when using auto return type

--

Re: Uniform Function Call Syntax?

[Timon Gehr via Digitalmars-d]

On 07.03.2016 18:49, Wyatt wrote:

But I really don't want any language features predicated on the
programmer having an APL keyboard.


I can't think of any language feature that would be.

Re: Speed up `dub`.

[WebFreak001 via Digitalmars-d-learn]

On Monday, 7 March 2016 at 18:58:55 UTC, ciechowoj wrote:

dub --version
DUB version 0.9.24+161-gb9ce700, built on Feb 23 2016

`dub.json` is `dub.json` of dstep

`dub test --skip-registry=all`
Do not helps.


Its because of dub going through all those JSON files. For 
example just querying the import paths would probably take like 
7s in your case. Try "dub describe --import-paths" in your 
project. Its something you can't do anything against except 
reporting it to the dub issues

Re: Speed up `dub`.

[Daniel Kozak via Digitalmars-d-learn]

I would say dub is broken and should be fixed. Even dub run is really 
slow and try to build everything. So please report a bug: 
https://github.com/D-Programming-Language/dub/issues


Dne 7.3.2016 v 19:58 ciechowoj via Digitalmars-d-learn napsal(a):

dub --version
DUB version 0.9.24+161-gb9ce700, built on Feb 23 2016

`dub.json` is `dub.json` of dstep

`dub test --skip-registry=all`
Do not helps.

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

[Michalis via Digitalmars-d]

On Sunday, 6 March 2016 at 17:06:12 UTC, Chris Wright wrote:

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#.


Yes, I work with C# (using the Mono framework using the 
MonoDevelop IDE) at work.
We prefer .Mono instead of .Net framework mainly for its platform 
interoperability as well as the fact that .Mono projects are far 
easier and faster to work with than VisualStudio projects.


With F#, I went through a few tutorials and just left it there 
because ...well ..VisualStudio


As for VB, I've had enough of it when I was working at my 1st 
employer.. horrible.. ;)

Re: Pitching D to a gang of Gophers

[landaire via Digitalmars-d]

On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
- tooling, tooling, tooling (IDE plugins and build tools work 
great)


I'd like to add that one of the things that I love about Go is 
that it is crazy easy to cross-compile. `GOOS=freebsd go build` 
and I have a FreeBSD binary sitting in my working directory, 
ready to send off.


Things I really like about D though are the UFC makes for really 
pleasant method chaining and cleaner code (along with 
map/filter/reduce for things), code reuse as you pointed out, and 
Dub being an actual package manager that seems to have common 
issues with dependency management solved. At least with my 
limited experience with D I haven't run into any Dub-related 
issues.


I'd like to toss in that D's lack of solid and stable `io` APIs 
in phobos is kind of sad and resulted in one of my recent 
projects being rewritten in Go.

Re: Uniform Function Call Syntax?

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 7 March 2016 at 18:57:03 UTC, Chris Wright wrote:

It's still not inconsistent to disallow math symbols.


It is inconsistent if you accept that different communities have 
different notations/languages. Why you would you want to exclude 
the scientific community?


here: I want to guide people toward using descriptive names, 
because that makes it easier to read code, which makes it 
easier to verify correctness.


Err, no, the contrary. What you get is an incomprehensible and 
overly verbose mess that hide problems and/or result in excessive 
overloading of the "*" symbol. Try some geometric computing 
problems, it gets messy quickly.


People don't write descriptive names, they write short names, if 
you provide a very limited set of symbols. Like "dot".

Re: Uniform Function Call Syntax?

[Chris Wright via Digitalmars-d]

On Mon, 07 Mar 2016 18:45:34 +, Ola Fosheim Grøstad wrote:
> There are lots of interesting letters from various languages that can be
> used, so prohibiting access to the proper symbols is kinda pointless.
> The end result is that people just pick inappropriate characters
> instead.

I don't think history bears that out. I've never seen this happen in 
Java, C#, or Python.

Re: Named arguments via struct initialization in functions

[Chris Wright via Digitalmars-d]

On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
> The compiler should detect that this call is ambiguous and would not
> allow it.

It's a potentially significant amount of work to determine that the 
expression is ambiguous, or to disambiguate.

> To resolve the ambiguity, the user can write:
> foo(A{ x: 1 });

That's why I suggested it.

>> And you only need explicit type marking at the top level;
>> it's unambiguous after that.
> 
> I'm not sure what you mean by "explicit type marking at the top level".

It always is unambiguous to write things like:
  auto a = A{x: {y: 1}};

Re: Pitching D to academia

[Andrew 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


As an academic, the things I would hope you would cover are:

Simplicity:  That is, its real easy to say something in D, and 
certainly easier than in Java.  The message here is stop teaching 
Java and start teaching D to first year students.


Cleanness of expression: That is, it is so much easier to express 
yourself in D than in C++ (for example, template 
meta-programming).  That is, use D as an intermediate language 
for second year students learning about algorithms.


Multi-paradigm:  That is, since you already know OOP and D, you 
can learn other paradigms with a language you already know 
(functional, parallel, embedded, etc).  That is, use D for third 
year programming language courses too.


If you with to appeal to the brightest students then you need to 
cover topics of interest to them.  That would include interfaces 
to tools they understand (Hadoop, etc), efficiency (i.e. the 
@nogc), distributed programming, and so on.

Re: GSoC 2016 "GDC Project - The GNU D Compiler" project

[Abhishek Kumar via Digitalmars-d]

Hello
I have fixed https://issues.dlang.org/show_bug.cgi?id=4509 and 
sent a PR.Please have a look.How should I discuss my GSoC 
proposal, what things I should work upon etc.?


Thanks
Abhishek Kumar

Re: Speed up `dub`.

[ciechowoj via Digitalmars-d-learn]

dub --version
DUB version 0.9.24+161-gb9ce700, built on Feb 23 2016

`dub.json` is `dub.json` of dstep

`dub test --skip-registry=all`
Do not helps.

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

[Michalis via Digitalmars-d]

On Sunday, 6 March 2016 at 14:23:51 UTC, Rikki Cattermole wrote:

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 :)


At this point I'm still a noob so still haven't gone through all 
the docs yet.
Up until now I find the Docs site extremely helpful and well 
designed, and I also like the fact that when I installed D 
through the package manager, everything was neatly taken care 
along with a desktop version of the docs site.


I have one general question, since I see the DWT library 
mentioned as part of the main ecosystem.

Is DWT considered as the official UI framework?

With Java I use SWT for desktop and RWT (part of Eclipse RAP) for 
web UI development as my main framework, and if DWT is to be the 
official UI for D, then that would be great news for me.
I did not find DWT though in the DUB repository, so at this point 
I've checked it out from Git.
Having a few issues when compiling for 64bit, but that I guess is 
something that I'll take care of along the way.. :)

Re: Uniform Function Call Syntax?

[Chris Wright via Digitalmars-d]

On Mon, 07 Mar 2016 18:45:34 +, Ola Fosheim Grøstad wrote:

> On Monday, 7 March 2016 at 18:35:44 UTC, Chris Wright wrote:
>> The partial integral symbol is not a letter or digit under any
>> circumstances. It is a mathematical symbol. Identifiers cannot contain
>> mathematical symbols in D or C99 or even C#.
> 
> Well, but that argument is kinda bogus. Scientists have "invented" their
> own notation using whatever symbols (characters)
> they had access to since forever. It's not like they will stop just
> because language designers are reactionary. :-)

It's still not inconsistent to disallow math symbols. There's a simple 
rule that the C99 standards writers were attempting to approximate, and 
that simple rule excludes mathematical symbols.

You dislike and disagree with that decision, which is a separate 
complaint. I'm sympathetic to the language designers here: I want to 
guide people toward using descriptive names, because that makes it easier 
to read code, which makes it easier to verify correctness. Math notation 
tends to be very compact and inscrutable, and I don't want to encourage 
users of my language to use inscrutable identifiers.

Re: Const vs Non const method

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Monday, 7 March 2016 at 18:44:01 UTC, Namespace wrote:
Honestly speaking, I think this case is impossible to solve in 
C++. I'll show my fellow students the advantages of D over C++ 
in next couple of weeks, and this example is pretty good. :)


:-) Good luck!

Re: Uniform Function Call Syntax?

[Chris Wright via Digitalmars-d]

On Mon, 07 Mar 2016 12:58:51 +, Lass Safin wrote:
> Have you ever heard of .XCompose?
> For linux: https://github.com/kragen/xcompose For windows:
> https://github.com/samhocevar/wincompose How it works:
> You choose a compose key, then use it to compose special characters with
> specific sequences.

Alternatively, you can create a custom keyboard layout for Linux 
relatively easily. The text format is relatively legible, but to 
simplify, you can use a utility such as
https://github.com/simos/keyboardlayouteditor .

For instance, I find myself using the characters ðþƹāē often for personal 
reasons, plus åøæ when I was learning Norwegian, so I created a keyboard 
layout to simplify that.

Still doesn't make it a great idea, but if your code's audience is 
sufficiently constrained, you might find it makes some things more usable.

Re: Uniform Function Call Syntax?

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 7 March 2016 at 18:35:44 UTC, Chris Wright wrote:
The partial integral symbol is not a letter or digit under any 
circumstances. It is a mathematical symbol. Identifiers cannot 
contain mathematical symbols in D or C99 or even C#.


Well, but that argument is kinda bogus. Scientists have 
"invented" their own notation using whatever symbols (characters) 
they had access to since forever. It's not like they will stop 
just because language designers are reactionary. :-)


There are lots of interesting letters from various languages that 
can be used, so prohibiting access to the proper symbols is kinda 
pointless. The end result is that people just pick inappropriate 
characters instead.

Re: Const vs Non const method

[Namespace via Digitalmars-d-learn]

On Monday, 7 March 2016 at 18:17:18 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 7 March 2016 at 16:30:48 UTC, Namespace wrote:
Thanks to the wildcard modifier inout. Is there any possible 
way to do the same in C++?


In this specific case you could do it with a macro if you don't 
mind dirty macros, but you really should implement the const 
version explicitly or use a free function that cover both cases 
using templating.


If you are looking for information on C++ you probably should 
use stack overflow:


http://stackoverflow.com/questions/7792052/c-template-to-cover-const-and-non-const-method


Honestly speaking, I think this case is impossible to solve in 
C++. I'll show my fellow students the advantages of D over C++ in 
next couple of weeks, and this example is pretty good. :)

Re: Uniform Function Call Syntax?

[Chris Wright via Digitalmars-d]

On Mon, 07 Mar 2016 10:32:09 +, Ola Fosheim Grøstad wrote:
> D is inconsistent in what parts
> of unicode you can use in names though.

The basic idea is that you can use any letter or '_' as the first element 
of an identifier, and you can use any letter or number or '_' as a 
subsequent element of an identifier. That's simple and consistent, right?

Except it's based on C99's fixed list of characters. So the actual rule 
is, you can use symbols from about 25 different writing systems that the 
designers of C99 thought prevalent enough to include, so long as they 
were in Unicode before 1999.

C#, in contrast, uses Unicode categories. You can use the Cherokee 
alphabet in C# identifiers, and there are under 400,000 speakers of 
Cherokee. Making that work took far less effort for the C# standard 
authors than the choice of identifier characters for C99.

I'm relatively certain that Walter went with C99's rules in large part 
because he had already implemented them, whereas he didn't have a readily 
available library with an appropriate license to give the Unicode 
category for a given codepoint.

> But you can already use "π" in D code?

U+03C0 (π) is from the Greek alphabet section of the Unicode inventory. 
It's for writing in the Greek language, which is currently spoken by 
about thirteen million people. It is primarily a letter, with incidental 
usage as a mathematical symbol.

Therefore, based on the rule that you can always start an identifier with 
a letter, you can use π as an identifier.

> I don't think you can use "∂"...

The partial integral symbol is not a letter or digit under any 
circumstances. It is a mathematical symbol. Identifiers cannot contain 
mathematical symbols in D or C99 or even C#.

Re: TypeInfo madness

[Yuxuan Shui via Digitalmars-d]

On Monday, 7 March 2016 at 08:49:36 UTC, Johan Engelen wrote:

On Monday, 7 March 2016 at 01:47:53 UTC, Yuxuan Shui wrote:

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?


LDC produces a crashing program when you change TypeInfo.name:
https://github.com/ldc-developers/ldc/issues/1337


This is because LDC put the TypeInfo struct in .rodata! Which is 
great. Further prove the point that no one is modifying TypeInfo.

Re: Uniform Function Call Syntax?

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 7 March 2016 at 17:49:35 UTC, Wyatt wrote:
I've mentioned this before, but I think a constrained set of 
user-defined operators using annotations/affixes on the 
existing set is a better fit for D.  It's a lesson well-learned 
from other languages (cf. OCaml; F#), and fits with D's 
generally practical bent.


Not sure what you mean by annotations/affixes and what lesson 
there is to be learned? What problems have other languages had 
with this?


I mean, if you want to alias them to Lucky Charms or various 
hieroglyphs of birds disemboweling men later, I guess maybe 
that's could work? But I really don't want any language 
features predicated on the programmer having an APL keyboard.


I don't see how mixfix notation makes this "problem" larger than 
the current prefix notation.


Why is the current situation that allows "ø(x,y)" less 
problematic than the proposed "(x ø y)" ?

Re: Named arguments via struct initialization in functions

[Meta via Digitalmars-d]

On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:

Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda


Unfortunately this will not work. There was a tuple proposal 
sometime back in 2012 or 2013. I can't remember the exact reason, 
but somebody came up with a case where it can be ambiguous as to 
whether it's a tuple or a delegate.

Re: Const vs Non const method

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Monday, 7 March 2016 at 16:30:48 UTC, Namespace wrote:
Thanks to the wildcard modifier inout. Is there any possible 
way to do the same in C++?


In this specific case you could do it with a macro if you don't 
mind dirty macros, but you really should implement the const 
version explicitly or use a free function that cover both cases 
using templating.


If you are looking for information on C++ you probably should use 
stack overflow:


http://stackoverflow.com/questions/7792052/c-template-to-cover-const-and-non-const-method

Re: Uniform Function Call Syntax?

[Wyatt 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:


I've mentioned this before, but I think a constrained set of 
user-defined operators using annotations/affixes on the existing 
set is a better fit for D.  It's a lesson well-learned from other 
languages (cf. OCaml; F#), and fits with D's generally practical 
bent.


I mean, if you want to alias them to Lucky Charms or various 
hieroglyphs of birds disemboweling men later, I guess maybe 
that's could work? But I really don't want any language features 
predicated on the programmer having an APL keyboard.


-Wyatt

Re: Const vs Non const method

[Namespace via Digitalmars-d-learn]

Let's use an example:


import std.stdio;

class Visitor {
public:
void visit(inout A) {
writeln("visit A");
}

void visit(inout B) {
writeln("visit B");
}
}

class A {
public:
void accept(Visitor v) inout {
v.visit(this);
}
}

class B : A {
public:
override void accept(Visitor v) inout {
v.visit(this);
}
}


This piece of code works for both versions below:

#1:

void main() {
A a = new A();
A b = new B();

Visitor v = new Visitor();

a.accept(v);
b.accept(v);
}


#2:

void main() {
const A a = new A();
const A b = new B();

Visitor v = new Visitor();

a.accept(v);
b.accept(v);
}


Thanks to the wildcard modifier inout. Is there any possible way 
to do the same in C++?

Re: Parameterized Keywords

[NX via Digitalmars-d]

On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

Just curious if anyone can see the use for them?


I believe 'new' keyword can take advantage of this quite good.
For example you can pass memory usage strategy like so:
MyClass mc = new[stream] MyClass();
MyClass mc2 = new[static] MyClass();

Deja-vu? Yes the idea comes from OpenGL. Also it might come in 
handy for other stuff:

MyClass mc3 = new[no_internal_pointers] MyClass();
MyClass mc4 = new[no_compacting] MyClass();

Re: Is it safe to use 'is' to compare types?

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/4/16 4:30 PM, Yuxuan Shui wrote:

On Friday, 4 March 2016 at 15:18:55 UTC, Steven Schveighoffer wrote:

On 3/3/16 6:58 PM, Yuxuan Shui wrote:

On Thursday, 3 March 2016 at 23:51:16 UTC, Adam D. Ruppe wrote:

On Thursday, 3 March 2016 at 23:46:50 UTC, Yuxuan Shui wrote:

Will typeid(a) is typeid(b) yield different results than typeid(a) ==
typeid(b)?


No. Indeed, opEquals on TypeInfo just calls is itself.


But opEquals also has extra comparison:

 auto ti = cast(const TypeInfo)o;
 return ti && this.toString() == ti.toString();

This makes me feel they are not the same.


In some cases, for instance using DLLs, the TypeInfo for an object
allocated in one way may be identical, but be a different instance
from the TypeInfo allocated in another way. This is why the string
comparison occurs.

Note that comparing ANY object will first check if they are the same
instance before calling any functions (this is in object.opEquals)



Thanks for answering. But I still don't understand why TypeInfo would
need to be allocated. Aren't typeid() just returning references to the
__DxxTypeInfo___initZ symbol?


You misunderstood, I meant the typeinfo *for* an allocated object, not 
that the typeinfo was allocated.


In some cases, 2 different objects allocated from different libraries 
(usually DLL-land) may reference TypeInfo from different segments, even 
though the TypeInfo is identical.


-Steve

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

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--

[Issue 15777] New: Premature expansion of overload set in tuples

[via Digitalmars-d-bugs]

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

  Issue ID: 15777
   Summary: Premature expansion of overload set in tuples
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

/// a.d //
void fun() {}
/// b.d //
void fun() {}
/ test.d /
alias AliasSeq(X...) = X;

template funA()
{
import a;
alias funA = fun;
}

template funB()
{
import b;
alias funB = fun;
}

template funAB()
{
import a;
import b;
alias funAB = fun;
}

void test(alias tpl)()
{
alias seq = AliasSeq!(tpl!());
foreach (i, n; seq)
pragma(msg, __traits(identifier, seq[i]));
}

void main()
{
test!funA;
test!funB;
test!funAB;
}
//

The AliasSeq iteration works when seq is a single function, but when it's an
overload set, you get an error:

test.d(25): Error: variable test.test!(funAB).test.n variables cannot be of
type void
test.d(25): Error: b.fun at b.d(1) conflicts with a.fun at a.d(1)
test.d(25): Error: expression fun() is void and has no value
fun
test.d(33): Error: template instance test.test!(funAB) error instantiating

--

Re: Speed up `dub`.

[Martin Tschierschke via Digitalmars-d-learn]

On Monday, 7 March 2016 at 09:18:37 UTC, ciechowoj wrote:
I'm using `dub` to build project. And every time I run `dub` it 
seems to check if dependencies are up to date, which takes some 
time. Is there a way to switch of that checking? Or any other 
way to speed up building process? It really slows down my 
modify-compile-check iteration time.


A few hours ago dub.pm alias code.dlang.org was down or slow, so 
I used:


$> dub --skip-registry=all build

might be thats the reason?

Re: Error: constructor Foo.this default constructor for structs only allowed with @disable, no body, and no parameters

[Alex Parrill via Digitalmars-d-learn]

On Monday, 7 March 2016 at 13:23:58 UTC, Nicholas Wilson wrote:
I'm not quite sure what this error is saying. Is it that the 
only struct constructor that can have no parameters is @disable 
this(){} ?


Yes, this is exactly right. You cannot have a structure with a 
default constructor, except with @disable.


You can, however, specify the initial values of fields, as in 
your second example. Note that you can use typeof on the variable 
you are currently declaring.


VkFenceCreateInfo CI = 
typeof(CI)(cast(typeof(CI.sType))StructureType.eFenceCreateInfo, 
null, 0);

Re: Parameterized Keywords

[Lass Safin via Digitalmars-d]

On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

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


You declare arrays of integers with int[size], you know that, 
right?


And I really don't see any useful improvement, that could be 
added with this. It would just be wasted efforts.

Re: std.xml2 (collecting features)

[Craig Dillabaugh via Digitalmars-d]

On Sunday, 6 March 2016 at 11:46:00 UTC, Robert burner Schadek 
wrote:
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


Great.  Can you please get in touch by email so I can add you to 
the mentors list:


craig dot dillabaugh at gmail dot com

Cheers

[Issue 15377] std.stdio: Use MSVCRT's _fseeki64 / _ftelli64 on Windows COFF

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/7af97f8ccc3990f588fc0d9627c645310d30f382
fix Issue 15377 - std.stdio: Use MSVCRT's _fseeki64 / _ftelli64 on Windows COFF

https://github.com/D-Programming-Language/phobos/commit/202565df3ddaf626c0af46f91c6789cb4f23d573
Merge pull request #3828 from CyberShadow/pull-20151124-143559

fix Issue 15377 - std.stdio: Use MSVCRT's _fseeki64 / _ftelli64 on Windows COFF

--

Re: GSoC 2016 "GDC Project - The GNU D Compiler" project

[CraigDillabaugh via Digitalmars-d]

On Monday, 7 March 2016 at 12:46:51 UTC, Abhishek Kumar wrote:

Hello
While looking into D language I found few Phobos standard 
libraries very interesting to work upon during GSoC.I will like 
to work on std.i18n or xml parsing libraries.I looked into 
Phobos github repositories but there's no issues section that I 
can work upon.Can someone help me with some beginner tasks?I'm 
familiar with GNU gettext and D language.I saw Mr. Andrei 
Alexandrescu as prospective mentor.How can I contact him?


Thanks
Abhishek


First off, read the following thread:

http://forum.dlang.org/thread/vsbsxfeciryrdsjhh...@forum.dlang.org

For contact info you can email me:

craig dot dillabaugh at gmail dot com

Cheers,

Craig

Error: constructor Foo.this default constructor for structs only allowed with @disable, no body, and no parameters

[Nicholas Wilson via Digitalmars-d-learn]

struct Fence
{
VkFence fence;
alias fence this;

 static struct CreateInfo
{
 VkFenceCreateInfo  ci;
 alias ci this;
 this(
   )
{
 ci = typeof(ci)(
 cast(typeof(ci.sType))StructureType.eFenceCreateInfo,
 null,
 0);
 }
 }
}

I'm not quite sure what this error is saying. Is it that the only 
struct constructor that can have no parameters is @disable 
this(){} ?


If so this is rather annoying as I have to create a new code path 
for the generation of this and 7 other structs. What must the 
code be in this case?


 static struct CreateInfo
{
		 VkFenceCreateInfo	ci = 
VkFenceCreateInfo(cast(typeof(ci.sType))StructureType.eFenceCreateInfo,null,0);

 alias ci this;
}
?

Re: Determine decimal separator (comma vs point)

[Andre via Digitalmars-d-learn]

On Monday, 7 March 2016 at 12:29:39 UTC, Andre wrote:

Hi,

I execute an external application and get some decimal numbers:

auto p = execute(["curl", "-o", "/dev/null", "-s", "-w",

"%{time_namelookup}:%{time_appconnect}:%{time_redirect}:%{time_starttransfer}:%{time_pretransfer}:%{time_connect}:%{time_total}",
url]);

On my windows system, the decimal separator is "," therefore I 
want
to replace the "," with "." to avoid exceptions while 
converting the value to!double.


I thought following coding should return "," on my OS because 
it is set in the region settings but "." is returned:


import core.stdc.locale;

auto lConv = localeconv();
char decSeparator = *lConv.decimal_point;

How can I determine the correct decimal separator?

Kind regards
André


I just found the answer:

lconv* lc;
setlocale(LC_NUMERIC, "");
lc = localeconv();
writeln(to!string(lc.decimal_point));

[Issue 15377] std.stdio: Use MSVCRT's _fseeki64 / _ftelli64 on Windows COFF

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/D-Programming-Language/phobos/pull/3828

--

Re: GSoC 2016 "GDC Project - The GNU D Compiler" project

[Seb via Digitalmars-d]

On Monday, 7 March 2016 at 12:46:51 UTC, Abhishek Kumar wrote:

Hello
While looking into D language I found few Phobos standard 
libraries very interesting to work upon during GSoC.I will like 
to work on std.i18n or xml parsing libraries.I looked into 
Phobos github repositories but there's no issues section that I 
can work upon.Can someone help me with some beginner tasks?I'm 
familiar with GNU gettext and D language.I saw Mr. Andrei 
Alexandrescu as prospective mentor.How can I contact him?


Thanks
Abhishek


Look into the issue tracker (issues.dlang.org), pick some tasks 
to get started and submit PRs - that is the best way to get in 
touch with him.

Re: Uniform Function Call Syntax?

[Lass Safin via Digitalmars-d]

On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad 
wrote:

immutable π = 3.14;

Oh, the horror!


 With the assumption pi is declared elsewhere (say, in 
std.math), what i wonder is the number for pi vs 2 letters. 
Unicode 03C0h, so now i have to convert that to decimal, code 
960. Alt+960 = └


 That's not pi... Looking up the symbol by itself in the 
character map was annoying enough. No, this is not a good idea 
unless it's easily accessible, preferably with 2 or fewer 
keystrokes to symbolize pi.



 As a reminder most of us are programmers, not scientists or 
mathematicians. Having specialized symbols won't give us any 
benefit. It's not like we're filling out a complex formula with 
college level math for a thesis.


Have you ever heard of .XCompose?
For linux: https://github.com/kragen/xcompose
For windows: https://github.com/samhocevar/wincompose
How it works:
You choose a compose key, then use it to compose special 
characters with specific sequences.


Examples:
ComposeKey, *, p: π.
ComposeKey, s, s: ß
ComposeKey, ComposeKey, d, e, g, c (degree Celsius): ℃

It is not impossible to use unicode special characters on a daily 
base easily, with the use of this tool. No need to use the 
character map or anything.
I think it would be very nice, if one had the option of using 
these special characters.
E.g. → instead of >>, if you desire that; std.math defining π as 
π.
Small gimmicks like these are things I find to be good for a 
language to have.

Re: GSoC 2016 "GDC Project - The GNU D Compiler" project

[Abhishek Kumar via Digitalmars-d]

Hello
While looking into D language I found few Phobos standard 
libraries very interesting to work upon during GSoC.I will like 
to work on std.i18n or xml parsing libraries.I looked into Phobos 
github repositories but there's no issues section that I can work 
upon.Can someone help me with some beginner tasks?I'm familiar 
with GNU gettext and D language.I saw Mr. Andrei Alexandrescu as 
prospective mentor.How can I contact him?


Thanks
Abhishek

Re: Speed up `dub`.

[Luis via Digitalmars-d-learn]

On Monday, 7 March 2016 at 09:18:37 UTC, ciechowoj wrote:
I'm using `dub` to build project. And every time I run `dub` it 
seems to check if dependencies are up to date, which takes some 
time. Is there a way to switch of that checking? Or any other 
way to speed up building process? It really slows down my 
modify-compile-check iteration time.


On my case, I don't see taking too long. Could you check what 
version of dub are you using, and what OS & D compiler and 
version ?

And better, if you can past here your dub.sdl/dub.json .

Determine decimal separator (comma vs point)

[Andre via Digitalmars-d-learn]

Hi,

I execute an external application and get some decimal numbers:

auto p = execute(["curl", "-o", "/dev/null", "-s", "-w",

"%{time_namelookup}:%{time_appconnect}:%{time_redirect}:%{time_starttransfer}:%{time_pretransfer}:%{time_connect}:%{time_total}",
url]);

On my windows system, the decimal separator is "," therefore I 
want
to replace the "," with "." to avoid exceptions while converting 
the value to!double.


I thought following coding should return "," on my OS because it 
is set in the region settings but "." is returned:


import core.stdc.locale;

auto lConv = localeconv();
char decSeparator = *lConv.decimal_point;

How can I determine the correct decimal separator?

Kind regards
André

Re: Pitching D to academia

[Martin Tschierschke 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


Operator overloading!
To build and use the clean Matrix-Vector products syntax M * v 
and not:
mult_matrix_vec(M,v). Combined with all the cool templating to 
define

one function for many types.

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

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 6 March 2016 at 13:21:41 UTC, Shachar Shemesh wrote:
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.


Yes, rule-of-thumb seems to be that regular syscall can be 
expected to have 200-1000 cycles overhead, on a virtualized setup 
2000+ cycles.


But some low level interfaces allow you to submit multiple 
i/o-ops in a single system call.

Re: C++ UFCS update

[Dejan Lekic via Digitalmars-d]

On Wednesday, 2 March 2016 at 15:57:41 UTC, Piotrek wrote:

On Wednesday, 2 March 2016 at 13:29:03 UTC, Dejan Lekic wrote:
I am not sure I agree with this. "->" will make it *visible* 
what is going on, while "." can mean many things, and I would 
have to investigate what .something in part of a chain does. 
Right?


Are you sure that "->" is obvious in C++? I ask because it can 
mean many things, not mentioning it can be overloaded!


Piotrek


Who is talking about C++?? `->` I was talking about is completely 
different thing from what `->` in C++. It would/should be 
semantically different from `.` in D and `->` in C++.

Re: Const vs Non const method

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Monday, 7 March 2016 at 10:52:53 UTC, Ola Fosheim Grøstad 
wrote:

On Sunday, 6 March 2016 at 17:53:47 UTC, Namespace wrote:
What would be the C++ way? Is there any comfortable way to 
solve this problem in a nice way like D?


C++ has a non-idiomatic language culture. There are many ways 
to do it. One clean way could be to use a templated method, 
another way is to use a function object, a dirty way would be 
to use a const-cast.


Another thing in C++ is that you can overload members on rvalue 
and lvalue references, from 
http://en.cppreference.com/w/cpp/language/member_functions :


#include 
struct S {
void f() & { std::cout << "lvalue\n"; }
void f() &&{ std::cout << "rvalue\n"; }
};

int main(){
S s;
s.f();// prints "lvalue"
std::move(s).f(); // prints "rvalue"
S().f();  // prints "rvalue"
}


Of course, all of this is just because you don't get to specify 
the type of the "this" pointer... So not as clean as it should 
be, but that applies to both languages. Adding lots of syntax 
with no real semantic benefits.

Re: Named arguments via struct initialization in functions

[ZombineDev via Digitalmars-d]

On Sunday, 6 March 2016 at 19:10:50 UTC, Chris Wright wrote:

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


[...]


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.



[...]


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.


The compiler should detect that this call is ambiguous and would 
not allow it.


To resolve the ambiguity, the user can write:
foo(A{ x: 1 });
foo(B{ x: 1 });
foo(() { });
foo(delegate void() { });

Which I think is a very reasonably requirement.

Do you have any other examples of ambiguity that can't be easily 
resolved?



Anyway, if it works, it's an improvement.

Yep.


And you only need explicit type marking at the top level;
it's unambiguous after that.


I'm not sure what you mean by "explicit type marking at the top 
level".

Re: Const vs Non const method

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 17:53:47 UTC, Namespace wrote:
What would be the C++ way? Is there any comfortable way to 
solve this problem in a nice way like D?


C++ has a non-idiomatic language culture. There are many ways to 
do it. One clean way could be to use a templated method, another 
way is to use a function object, a dirty way would be to use a 
const-cast.

Re: Named arguments via struct initialization in functions

[ZombineDev via Digitalmars-d]

On Sunday, 6 March 2016 at 20:35:49 UTC, Jacob Carlborg wrote:

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


+100

This can also pave the way for tuple literals, e.g.:
// nothing new, ordinary struct member init
Point2 point = { x: 3, y: 4 };

// auto variables are deduced to be tuples
auto namedTuple = { x: 3, y: 4 }; // a.k.a anonymous classes in C#
auto plainTuple = { 10, "hi", 3.14 }; // See also DIP32

Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda

// unambiguous (disallow delegates that contain only CommaExpr):
auto tuple4 = { getInt(), getString(), getDouble() };

Re: Uniform Function Call Syntax?

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad 
wrote:

immutable π = 3.14;

Oh, the horror!


 With the assumption pi is declared elsewhere (say, in 
std.math), what i wonder is the number for pi vs 2 letters. 
Unicode 03C0h, so now i have to convert that to decimal, code 
960. Alt+960 = └


 That's not pi... Looking up the symbol by itself in the 
character map was annoying enough. No, this is not a good idea 
unless it's easily accessible, preferably with 2 or fewer 
keystrokes to symbolize pi.


But you can already use "π" in D code? D is inconsistent in what 
parts of unicode you can use in names though. I don't think you 
can use "∂"...


 As a reminder most of us are programmers, not scientists or 
mathematicians. Having specialized symbols won't give us any 
benefit. It's not like we're filling out a complex formula with 
college level math for a thesis.


Well, but you already have this possibility in D. Adding custom 
operators is just a small extension. And you don't have to use it 
if you don't want to.


There is no standard english notation for the inner product 
either, "dot" refers to the sigil... But if you want both, you 
can have both. You can both have "innerProduct(v1,v2)" and "(v1 • 
v2)".


In a commercial setting you want as high level of legibility as 
possible. D is doing slightly better than C++, but is far away 
from providing a good legible syntax. More time is spent reading 
code than writing it.


In some cases people want to use their own language. D supports 
that. Math notation is no different than using a non-english 
language in that regard. Why shouldn't mathematicians be allowed 
to user the language they are familiar with if national languages 
are supported?

Re: Uniform Function Call Syntax?

[krzaq via Digitalmars-d]

On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad 
wrote:

immutable π = 3.14;

Oh, the horror!


 With the assumption pi is declared elsewhere (say, in 
std.math), what i wonder is the number for pi vs 2 letters. 
Unicode 03C0h, so now i have to convert that to decimal, code 
960. Alt+960 = └


 That's not pi... Looking up the symbol by itself in the 
character map was annoying enough. No, this is not a good idea 
unless it's easily accessible, preferably with 2 or fewer 
keystrokes to symbolize pi.



 As a reminder most of us are programmers, not scientists or 
mathematicians. Having specialized symbols won't give us any 
benefit. It's not like we're filling out a complex formula with 
college level math for a thesis.


Didn't we have "pitching D to academia" thread recently?

Honestly, any tool can be abused. Javascript, Swift and even 
partially Haskell allow unicode names and I'm sure we all saw 
that toy example that was full of emojis, but can you say it has 
been a problem in practice?

[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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
   Hardware|x86 |All
 OS|Mac OS X|All

--- Comment #2 from ag0ae...@gmail.com ---
(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:

Already addressed by
. See
 for the new
documentation.

(In reply to Timothee Cour from comment #1)
> Also, docs should specify precisely what happens when link ends with a '/'

This is still undocumented.

--

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

[via Digitalmars-d-bugs]

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

--- Comment #1 from Johannes Nordhoff  ---
okay, after looking at it once more i noticed i actually dont have to write the
"import" twice. i failed at that point

--

Re: Speed up `dub`.

[ciechowoj via Digitalmars-d-learn]

On Monday, 7 March 2016 at 09:22:16 UTC, Daniel Kozak wrote:

maybe: dub build --nodeps

Dne 7.3.2016 v 10:18 ciechowoj via Digitalmars-d-learn 
napsal(a):
I'm using `dub` to build project. And every time I run `dub` 
it seems to check if dependencies are up to date, which takes 
some time. Is there a way to switch of that checking? Or any 
other way to speed up building process? It really slows down 
my modify-compile-check iteration time.


I've tried that one already - it makes no difference.
Currently when I run `dub test` it takes about 9s (project is 
already built). When running the executable directly takes only 
0.2s :/.

Re: Speed up `dub`.

[Daniel Kozak via Digitalmars-d-learn]

maybe: dub build --nodeps

Dne 7.3.2016 v 10:18 ciechowoj via Digitalmars-d-learn napsal(a):
I'm using `dub` to build project. And every time I run `dub` it seems 
to check if dependencies are up to date, which takes some time. Is 
there a way to switch of that checking? Or any other way to speed up 
building process? It really slows down my modify-compile-check 
iteration time.

Speed up `dub`.

[ciechowoj via Digitalmars-d-learn]

I'm using `dub` to build project. And every time I run `dub` it 
seems to check if dependencies are up to date, which takes some 
time. Is there a way to switch of that checking? Or any other way 
to speed up building process? It really slows down my 
modify-compile-check iteration time.

Re: std.xml2 (collecting features)

[Lodovico Giaretta via Digitalmars-d]

On Sunday, 6 March 2016 at 11:46:00 UTC, Robert burner Schadek 
wrote:
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


Hi,
I don't know if this is the right spot to join the conversation;
I'm student and I'd really love to work on std.xml for GSoC!

I'm just waiting March 14 to apply.

Re: TypeInfo madness

[Johan Engelen via Digitalmars-d]

On Monday, 7 March 2016 at 01:47:53 UTC, Yuxuan Shui wrote:

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?


LDC produces a crashing program when you change TypeInfo.name:
https://github.com/ldc-developers/ldc/issues/1337

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

[Dmitry via Digitalmars-d]

On Monday, 7 March 2016 at 02:34:41 UTC, Jeremy DeHaan wrote:
Please let me know if you think this is worth the effort and 
would make a good GSoF project.


I don't know, is it good project for GSoC or not, but I will be 
happy if it will be done.

(and yep, I really use DSFML in my projects)

P.S. Thank you for DSFML.

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

[Andrea Fontana via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 20:13:39 UTC, 岩倉 澪 wrote:

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!!


You can use official specs to recreate binary file:
https://msdn.microsoft.com/en-us/library/dd871305.aspx

Ok, not the fastest way. :)

Re: Uniform Function Call Syntax?

[Era Scarecrow via Digitalmars-d]

On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad 
wrote:

immutable π = 3.14;

Oh, the horror!


 With the assumption pi is declared elsewhere (say, in std.math), 
what i wonder is the number for pi vs 2 letters. Unicode 03C0h, 
so now i have to convert that to decimal, code 960. Alt+960 = └


 That's not pi... Looking up the symbol by itself in the 
character map was annoying enough. No, this is not a good idea 
unless it's easily accessible, preferably with 2 or fewer 
keystrokes to symbolize pi.



 As a reminder most of us are programmers, not scientists or 
mathematicians. Having specialized symbols won't give us any 
benefit. It's not like we're filling out a complex formula with 
college level math for a thesis.