date:20160123

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 10406] std.conv.to of string array to fixed sized array

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |FIXED

--

[Issue 15598] New: core.atomicFence is not @nogc on x86

2016-01-23 Thread Sebastiaan Koppe via Digitalmars-d-learn

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

  Issue ID: 15598
   Summary: core.atomicFence is not @nogc on x86
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

subj. it is @nogc for x86_64, though, and should e the same for x86 (as it
clearly doesn't allocate ;-).

--

Re: D's metaprogramming could be flawed

2016-01-23 Thread maik klein via Digitalmars-d


On Friday, 22 January 2016 at 14:19:30 UTC, rsw0x wrote:

On Friday, 22 January 2016 at 13:28:00 UTC, maik klein wrote:

On Friday, 22 January 2016 at 13:21:11 UTC, rsw0x wrote:

On Friday, 22 January 2016 at 12:57:54 UTC, maik klein wrote:

...


You're looking for AliasSeq in std.meta, it's a tup—er, 
finite ordered list of types :)


I am already aware of AliasSeq as I have written above. But I 
could have misused it, would you mind showing an example with 
TupleRef?


Sorry, I must have skipped that.

Is there a reason you're explicitly using tuples?
Unless I'm misunderstanding you, you're looking for something 
like...


struct Baz(V...) {
  V vals;
}

which can be used like...

void foo(int, int, int) {

}

void main(){
  auto i = Baz!(int, int, int)();
  foo(i.vals);
}

or am I way off base?

If so, is this similar to what you're looking for?
http://dpaste.dzfl.pl/cbae4c4ed7af

Sorry if I'm nowhere near what you meant.


I think that should work but it only works because you do an 
implicit conversion with get which is quite nice.


But I was also looking for a more general solution.

I think the mixin solution could be quite nice.

static template unpack(alias f){
  pragma(inline)
  auto into(alias target, Args...)(ref Args args){
import std.conv;
enum s = 
`target(`~iota(Args.length).map!(i=>text(`f(args[`,i,`])`)).join(",")~`)`;

return mixin(s);
  }
}

and use it like:

auto r = unpack!(i => i * 2).into!((a, b) => a + b)(1,2);


The only semi weird thing is that I can use this directly with my 
version of TupleRef like this:


void foo(ref int, ref int){
}

unpack!((r)=> r.get()).into!(foo)(tref.refTs.expand);


I think that is because "lambda/delegates" can not express ref 
return types?


So I think I need to do this:

ref auto get(R)(R r){
  return r.get();
}

unpack!(get).into!(foo)(tref.refTs.expand);

Re: htod question

On Friday, 22 January 2016 at 01:04:50 UTC, Dibyendu Majumdar 
wrote:
On Friday, 22 January 2016 at 01:03:09 UTC, Dibyendu Majumdar 
wrote:

On Friday, 22 January 2016 at 00:52:59 UTC, W.J. wrote:

Counter question: What's so bad about the D std library ?


I am trying to create bindings for existing C library so I was 
trying to use htod for that.


The library includes various C header files ... causing htod to 
fail


Yeah, htod often requires preparing the files your trying to 
convert. Often removing macro's and the like. Its a manual 
process, and it can get dirty.

[Issue 14804] Comparing two Nullables does not check if either is null

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

b2.t...@gmx.com changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=10771

--

[Issue 10771] std.typecons.Nullable throws an exception on comparision of null values

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

b2.t...@gmx.com changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14804

--

Templates, templates, templates...

2016-01-23 Thread Voitech via Digitalmars-d-learn

Hi, I have a problem with creating proper inheritance chain with 
templates. First i will give some background about my problem.


I'm trying to create a validator for math calculation 
expressions. I don't want to use regexps as this is approach 
gives me headache and probably will not allow further extension i 
want. For now expressions should look like this:

1+2+3/4, -(5*(25-5)/19), sqrt(-5/-6*(212)) etc.

So each of charactes is parsed to something like PrimaryElement
class PrimaryElement {
const dchar value;
SymbolType symbolType;
}
SymbolsType is an enum which contains: 
EXPR_START,+,-,/,DIGIT,(,),.,EXPR_END


So now i want to create validator for input so user couldn't 
insert something like:

/00..34-+/493 but only 0.34-493. I want to divide it into phases.

First phase is SymbolType validation so it will handles problems 
like:

+-/345..3 but not .234+3-53

Second phase will take care about value validation so user cant 
insert .0+3 but only 0.000+3


Third phase would be executed to check expression is completed 
and not allow to calculate expression for situations like 
0.000+3, 3-3+4.5+ or 364/4-5.3+(


Now i'm trying to implement phase one. So i create 
PrimaryElementProcessor which will take some kind of rules and 
check PrimaryElement[] that way if divided parts of array fits 
into one of rules then it is valid. Rules will be trimmed to size 
of expression if necessary.


Model and constants declaration looks like this:


private enum ControllFlag{
none,ommitable,repeatable
}

private enum LogicFlag{
none,or,and
}

private class Rule(V,F){
V value;
F flag;
this(){
}

this(V value){
this.value=value;
}

this(V value,F flag){
this.value=value;
this.flag=flag;
}
}
private alias ControllTemplate(T) =Rule!(T,ControllFlag);
private alias SymbolRule =ControllTemplate!(SymbolType);
private alias StringRule =ControllTemplate!(SymbolRule[]);
private alias LogicTemplate(T...) 
=Rule!(ControllTemplate(T)[],LogicFlag);
private alias LogicRule=LogicTemplate!([SymbolRule,StringRule]); 
<--error


So i first want to handle case like D. or DD where D 
is Digit


instantiation code:

SymbolRule digitRule = new 
SymbolRule(SymbolType.digit,ControllFlag.repeatable);

SymbolRule commaRule = new SymbolRule(SymbolType.comma);
StringRule numericRule = new 
StringRule([digitRule,commaRule,digitRule]);
LogicRule decimalRule = new 
LogicRule([digitRule,numericRule],LogicFlag.or);


error:
Error: type Rule!(Rule!(SymbolType, ControllFlag)[], 
ControllFlag) has no value


Ok so i want to hold different types in LogicRule maybe Algebraic 
implementation would do?


private alias ControllTemplate(T) =Rule!(T,ControllFlag);
private alias SymbolRule =ControllTemplate!(SymbolType);
private alias StringRule =ControllTemplate!(SymbolRule[]);
private alias LogicTemplate(T...) 
=Rule!(Algebraic!(ControllTemplate(T))[],LogicFlag); <--error
private alias AlgebraicLogicRule = 
LogicTemplate!(SymbolRule,StringRule);


error:
Error: cannot pass type (Rule!(SymbolType, ControllFlag), 
Rule!(Rule!(SymbolType, ControllFlag)[], ControllFlag)) as a 
function argument


So maybe something simpler:

private alias ControllTemplate(T) =Rule!(T,ControllFlag);
private alias SymbolRule =ControllTemplate!(SymbolType);
private alias StringRule =ControllTemplate!(SymbolRule[]);
private alias SimpleLogicRule 
=Rule!(Algebraic!(SymbolRule,StringRule)[],LogicFlag);


Compiles but... when i try to instantiate SimpleLogicRule like

SymbolRule digitRule = new 
SymbolRule(SymbolType.digit,ControllFlag.repeatable);

SymbolRule commaRule = new SymbolRule(SymbolType.comma);
StringRule numericRule = new 
StringRule([digitRule,commaRule,digitRule]);
SimpleLogicRule decimalRule = new 
SimpleLogicRule([digitRule,numericRule],LogicFlag.or); <--- error


i get error:
None of the overloads of '__ctor' are callable using argument 
types (Object[], LogicFlag), candidates are: ...


So i understand compiler can't cast/extract array of different 
types to known type.


I created a wrapper for this two types SymbolRule and StringRule 
and init it somewhere before passing to LogicRule ctor. This 
approach makes a lot of boilerplate code for example:


alias Wrapper = Algebraic!(SymbolRule,StringRule);
alias LogicRule =Rule!(Wrapper[],LogicFlag);

SymbolRule digitRule = new 
SymbolRule(SymbolType.digit,ControllFlag.repeatable);

SymbolRule commaRule = new SymbolRule(SymbolType.comma);
StringRule numericRule = new 
StringRule([digitRule,commaRule,digitRule]);

Wrapper digitRuleWrapper =digitRule; <-- how to ommit this ?
Wrapper numericRuleWrapper =numericRule;  <-- how to ommit this ?

LogicRule decimalRule=new 
LogicRule([digitRuleWrapper,numericRuleWrapper],LogicFlag.or);


Is there any nicer way to handle this case ?


Cheers Voitech.

[Issue 15376] The time zone name conversions should not be compiled into Phobos

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

--- 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/635cecee557bf5e82b2f614dd19e41383505c3f7
Fix for issue# 15376. Get time zone conversions at runtime.

It's proven to be a maintenance problem to maintain the time zone
conversions between the IANA TZ database names and the Windows time zone
names in std.datetime. So, rather than compiling them in, this provides
a way to get them at runtime (which will also make it so in the future,
older releases can work properly on up-to-date Windows boxes, which is
not the case currently with regards to time zone conversions). The
current conversion functions can be deprecated after parseTZConversions
has been out for a release (so that it's possible for users to compile
their code for two releases in a row without getting deprecation
messages).

https://github.com/D-Programming-Language/phobos/commit/6be2087858765bdf8b3439ba9cfc4fc2d5e543a7
Merge pull request #3824 from jmdavis/issue15376

Fix for issue# 15376. Get time zone conversions at runtime.

--

Re: Collapsing n-dimensional array to linear (1 dimensional)

2016-01-23 Thread Ali Çehreli via Digitalmars-d-learn


On 01/22/2016 04:07 AM, abad wrote:

Let's say I have an array like this:

int[][][] array;

And I want to generate a linear int[] based on its data. Is there a
standard library method for achieving this, or must I iterate over the
array manually?

What I'm thinking of is something like this:

int[] onedim = std.array.collapse(array);




Something feels extra down there but it seems to work. :)

import std.stdio;
import std.range;
import std.algorithm;

auto collapse(R)(R r)
if (isArray!R) {
return r.joiner.collapse.joiner;
}

auto collapse(R)(R r)
if (!isArray!R) {
return r;
}

unittest {
auto r = 3.iota
 .map!(i => iota(3 * i, 3 * i + 3)
.map!(j => iota(3 * j, 3 * j + 3)
   .array)
.array)
 .array;

writeln("Original:\n", r);
writeln("\nCollapsed:\n", r.collapse);
assert(r.collapse.equal(iota(27)));
}

void main() {
}

Original:
[[[0, 1, 2], [3, 4, 5], [6, 7, 8]], [[9, 10, 11], [12, 13, 14], [15, 16, 
17]], [[18, 19, 20], [21, 22, 23], [24, 25, 26]]]


Collapsed:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 
20, 21, 22, 23, 24, 25, 26]


Ali

Re: [dlang.org] Let's talk about the logo


On 2016-01-22 00:46, anonymous wrote:


http://i.imgur.com/eJaKFtx.png

The first one is the current logo. The last one shows just the core
shape (D + moons), of course.


I vote the last one as the official out of context logo. I vote the 
third one for the web site.


--
/Jacob Carlborg

Re: DIP87: Enhanced Foreign-Language Binding


On 2016-01-23 02:31, Anon wrote:


Ideally, by whether the `extern()` forms a block or it is attached
directly to the symbol. I understand that wouldn't work with existing
implementation in the compiler, but hopefully it wouldn't be too
difficult to do. But I know nothing of compiler internals so am probably
wrong.


That will change the behavior compared to how all other attributes work. 
There's no difference for these syntaxes:


extern(C) int a;
extern(C) { int a; }
extern(C): int a;

Or:

public int a;
public { int a; }
public: int a;


I'll have to look into this more. My cursory reading told me of
"instance" methods and "class" methods, that get mangled as
"_i__..." and "_c__..."
respectively. Is this what you are talking about?


No. In Objective-C there's a protocol (interface) called "NSObject" and 
a class called "NSObject". It needs to be possible to do this:


extern(Objective-C)
class NSObject {} // standard mangling, NSObject

extern(Objective-C) pragma(mangle, "NSObject")
interface NSObjectProtocol {} // custom mangling, NSObject

The mangling for a method is more like L_OBJC_SELECTOR_REFERENCES_0. 
Where 0 is an increasing number.


If you have access to a Mac you can try compiling this [1] example and 
list all symbols with the "nm" command.



Sure, but when using ObjC code from D:

extern(Objective-C) class Something {
void moveTo(float x, float y) @selector("x:y:");
}

// Elsewhere
something.moveTo(1,2);

I don't see how the selector is doing anything more than mangling here.
Even if you have multiple methods in D that mangle to the method name in
ObjC (minus parameters), that selection is done by D, which then mangles
the name according to the selector, right? If not, do you have an
example handy to illustrate?


No. The above call to "moveTo" is lowered to something like this:

objc_msgSend(something, "x:y:", 1, 2);

The Objective-C runtime will find the correct method implementation to 
call based on the selector.


[1] http://dlang.org/spec/objc_interface.html#usage-example

--
/Jacob Carlborg

Re: core.thread.Thread.start is marked as "nothrow" but documentation says it throws

2016-01-23 Thread anonymous via Digitalmars-d-learn


On 23.01.2016 12:44, tcak wrote:

https://dlang.org/phobos/core_thread.html#.Thread

final nothrow Thread.start()

Looking at the code, no "throw new ..." is seen, but the function
"onThreadError" is called
which has "throw" in it.

Most weird thing is that "onThreadError" function is marked as "nothrow"
but it still throws.

I would think that yes, maybe the compiler might not be able to see it
because throw is found
in another function, but how come "onThreadError" throws with nothrow.


onThreadError [1] throws a ThreadError [2] which derives from Error, as 
the name suggests. nothrow functions may throw Errors, because Errors 
are considered a way of force-exiting the program. Errors are not 
supposed to be caught.


So onThreadError is fine. And if Thread.start can actually only throw 
ThreadError, and not ThreadException, then that one is ok too, but the 
documentation is wrong and should be fixed.



[1] 
https://github.com/D-Programming-Language/druntime/blob/33f1962747801be35a48f4875c909e16747fdcce/src/core/thread.d#L2972
[2] 
https://github.com/D-Programming-Language/druntime/blob/33f1962747801be35a48f4875c909e16747fdcce/src/core/thread.d#L88

[Issue 10882] std.random.MersenneTwisterEngine.seed() fails if passed a static array

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |INVALID

--- Comment #1 from b2.t...@gmx.com ---
A static array is not an input range, it can't be consumed. The constaint in
see() clearly only takes input ranges.

--

Re: So... add maxCount and maxPos?

2016-01-23 Thread Era Scarecrow via Digitalmars-d

On Thursday, 21 January 2016 at 14:04:58 UTC, Andrei Alexandrescu 
wrote:

On 01/21/2016 08:42 AM, Era Scarecrow wrote:
I'd almost say lowestCount and highestCount would almost be 
better, but I am not sure.


minCount is already a given. -- Andrei


 I have a slight problem where I'm not already familiar with most 
of the standard library functions (D, libc, etc) that are usually 
available. This usually means I have a naive approach and/or 
naming convention to what's already been in place 15+ years.


 Of course when I do take the time to go through the libraries 
and documentation I'll say 'oohhh that's cool!'; But because I'm 
not actively using it I'll promptly forget it :(

[Issue 15597] New: error messages in mixins should show context

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

  Issue ID: 15597
   Summary: error messages in mixins should show context
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

We need to find a better way of giving errors from mixins.

For instance:
  icomponent.d-mixin-48(55): Error: found '<' when expecting ')'

This tells me nothing, and to proceed I need to start adding pragma(msg, ...)
in strategic places to try and discover what I'm actually dealing with.

Suggest:

Errors in mixins print a context to the error output, that is, the line of text
the compiler is trying to compile, and perhaps even 1-2 lines before/after the
context line if they look interesting.

--

Re: D's metaprogramming could be flawed

2016-01-23 Thread maik klein via Digitalmars-d


On Saturday, 23 January 2016 at 12:13:16 UTC, maik klein wrote:

On Friday, 22 January 2016 at 14:19:30 UTC, rsw0x wrote:

[...]


I think that should work but it only works because you do an 
implicit conversion with get which is quite nice.


[...]


I forgot to show what `tref` was in my last comment.

int i  = 1;
int i2 = 2
auto tref = TupleRef!(int,int)(i, i2);

[Issue 8382] std.bitmanip opCmp bug or user error?

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |FIXED

--

core.thread.Thread.start is marked as "nothrow" but documentation says it throws

2016-01-23 Thread tcak via Digitalmars-d-learn


https://dlang.org/phobos/core_thread.html#.Thread

final nothrow Thread.start()

Looking at the code, no "throw new ..." is seen, but the function 
"onThreadError" is called

which has "throw" in it.

Most weird thing is that "onThreadError" function is marked as 
"nothrow" but it still throws.


I would think that yes, maybe the compiler might not be able to 
see it because throw is found
in another function, but how come "onThreadError" throws with 
nothrow.

DIP 88: Simple form of named parameters


This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag

--
/Jacob Carlborg

Re: [dlang.org] Let's talk about the logo

2016-01-23 Thread Mike Parker via Digitalmars-d


On Saturday, 23 January 2016 at 01:23:20 UTC, H. S. Teoh wrote:


This is not the governance of a country. If you don't like the 
way the decisions are being made, you always have the freedom 
to take the source code (except for the proprietary backend), 
fork it, and build your own community. There will be no army 
sent after you to force you to comply with the "dictator's" 
decisions, since this is a programming language, not a 
government.  If your technical merit is superior, your 
community will eventually prevail.


And besides, calling something a "dictatorship" is again 
confusing the development of a programming language with 
running a government. I still fail to see the connection 
between the two.


(And BTW, I do not speak for this community either. What I 
express here are just my own opinions. If you really have an 
issue with how things are run, you ought to be talking directly 
to Walter & Andrei, not wasting your breath arguing with me.)


+1 many times over.

And back to the original topic, my vote goes for the third one.

Re: [dlang.org] Let's talk about the logo

I always wanted it to be a gif so the planet would appear to be subtly rotating 
and the edge of Deimos might twinkle slightly :-)

Re: Templates, templates, templates...

2016-01-23 Thread anonymous via Digitalmars-d-learn


On 23.01.2016 12:30, Voitech wrote:

Ok so i want to hold different types in LogicRule maybe Algebraic
implementation would do?

private alias ControllTemplate(T) =Rule!(T,ControllFlag);
private alias SymbolRule =ControllTemplate!(SymbolType);
private alias StringRule =ControllTemplate!(SymbolRule[]);
private alias LogicTemplate(T...)
=Rule!(Algebraic!(ControllTemplate(T))[],LogicFlag); <--error


You're missing an exclamation mark there, and you've got the order of 
Algebraic and ControllTemplate wrong. This compiles:


private alias LogicTemplate(T...) = 
Rule!(ControllTemplate!(Algebraic!T)[],LogicFlag);



private alias AlgebraicLogicRule = LogicTemplate!(SymbolRule,StringRule);

error:
Error: cannot pass type (Rule!(SymbolType, ControllFlag),
Rule!(Rule!(SymbolType, ControllFlag)[], ControllFlag)) as a function
argument

[...]

Is there any nicer way to handle this case ?


Instead of Algebraic you could use a common base class, or interface, 
for the Rule instantiations:


abstract class RuleBase
{
... whatever common functionality rules have ...
}
class Rule(V,F) : RuleBase { ...}

But I have to say that I'm having trouble making sense of all that class 
and template complexity, and how it helps in actually validating user input.


Since this is a parsing thing, you may want to look into writing parsers 
an/or using a parse generator. I think Pegged is the most popular one 
for D. http://code.dlang.org/packages/pegged

Re: std.zip for Binary example

2016-01-23 Thread locco via Digitalmars-d-learn


On Sunday, 17 January 2016 at 10:43:55 UTC, Sean Campbell wrote:

On Sunday, 17 January 2016 at 10:34:19 UTC, locco wrote:

Hi :)
I found this example:
==
import std.file: write;
import std.string: representation;
void main()
{
   char[] data = "Test data.\n".dup;
   // Create an ArchiveMember for the test file.
   ArchiveMember am = new ArchiveMember();
   am.name = "test.txt";
   am.expandedData(data.representation);
   // Create an archive and add the member.
   ZipArchive zip = new ZipArchive();
   zip.addMember(am);
   // Build the archive
   void[] compressed_data = zip.build();
   // Write to a file
   write("test.zip", compressed_data);
}
==
But i cound't find example code for binary file.
How can i make ArciveMember for binary file?



std.zip dosen't discriminate against text and binary files 
files.

p.s. remember to import std.zip



import std.stdio;
import std.file:write,getSize;
import std.string: representation;
import std.zip: ArchiveMember, ZipArchive;

void main() {
auto stream = File("example.jpg", "r+");

auto inbytes = new ubyte[ cast(uint)getSize("example.jpg") ];
stream.rawRead(inbytes);

auto zip = new ZipArchive();
ArchiveMember ae = new ArchiveMember();
ae.name = "example_.jpg";
ae.expandedData( inbytes );

zip.addMember(ae);
void[] compressed_data = zip.build();
write("test.zip", compressed_data);
}


I made this, work fine. But i guess it wasn't nice solution. 
Right?

Re: DIP 88: Simple form of named parameters

On 2016-01-23 17:35, Mathias Lang via Digitalmars-d wrote:

About the rationale:
 > Supporting named parameters directly in the language prevents the
need to add workarounds with weird looking syntax like Flag

That's going the opposite way of the current trend, which is shift as
much feature to library as possible.

Yeah, I know. But I think this is worth adding and that Flag is hurting 
more than it's helping. Just because something is possible to do in the 
library doesn't mean it's a good idea.

There's been a lot of C++ related features which purely is about 
mangling. This could be handled in library code together with 
pragma(mangle). Yet these where added anyway. Yeah, I know everyone will 
complain that's not the same thing.

 > When interfacing with Objective-C it might be desirable to have a
method calling syntax which resembles the syntax used in Objective-C and
Swift.

Implementing cosmetic features from a language because it appeals to its
user doesn't sound that useful to me.

This was not part of my initial idea. It was added as a bonus. I can 
remove it from the rational if it's preferred.

The `createReq` example is a bit artificial, as you would usually
replace it with a struct.

Yes.

About the design:
As mentioned earlier, forcing users to say which arguments can be named
and which cannot seems like an unnecessary limit. We'll just end up with
everyone using ':' after parameter names (which is very weird looking
IMO) in order to be able to use that syntax at the call site, if
necessary. Also, bear in mind that a lot of code one will use is not
under one's direct control. So if we want to use named parameter with a
framework which doesn't define this syntax, you cannot.
Since changing the order of parameter is not allowed, it sounds better
to just allow this syntax at the call site.

I think the DIP clearly states why this is the case. There have been 
several proposals for named parameters before, they have all been shot 
down because of this (and the ordering of the parameters). I'm not out 
to create the most ideal and perfect proposal. I'm trying to provide a 
proposal that has a chance of being accepted.

Also, one point which was not covered, should the compiler enforce that
the name used matches ? E.g. if I use `heigh` instead of `height`,
should the compiler tell me "change name `heigh` to `height`" ?

Hmm. That's kind of interesting. My idea was that the compiler should 
enforce that. But if the names don't need to match the only thing that 
is necessary is a syntax for adding names at the call site. The syntax 
for declaring the named parameters would not be required.

Overall, I'm not found of it. It looks like a lot of complication for
little to no benefit.

How is it complicated? I think it's very simple. The feature could be 
summarized with this example:

Rect createRect(int x:, int y:, int width:, int height:);
createRect(x: 0, y: 0, width: 200, height: 200);

Just because I described how the feature work in detail doesn't mean 
it's complicated.

--
/Jacob Carlborg

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread Dejan Lekic via Digitalmars-d

On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


I already see confusing code like:
foo(10, 20, width: ((big) ? 600 : 200), height: ((big) ? 800 : 
480));


I know many people, especially those who are coming from the 
Python world, want named parameters, but I am not entirely sure 
we want that in D.


I would rather use the Builder pattern instead, because that 
typically what people do with named parameters...

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread Marc Schütz via Digitalmars-d

On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


Some comments:

1) Default values

You should specify how to use both the `:` syntax and a default 
parameter value, including an example. They are often going to be 
used together, and it needs to be clear how they interact.


2) Argument order

I think your rule no. 4 is not really necessary, and actually 
diminishes the usability a lot if there are many name flags. 
Argument reordering can be done as an independent step before 
overload resolution (of course this still needs to be aware of 
all the candidates).


But you should add a note that overloading on parameter names 
alone is illegal (i.e. `void foo(int a:)` vs `void foo(int b:)`). 
That way, they don't need to affect name mangling.


3) Variadic parameters

Is this legal: `void foo(int[] param: ...)`? Or this: `void 
bar(Args...)(Args args:)`? If yes, what would the calling syntax 
look like?


Also, opDispatch is often used for forwarding arguments. Can 
parameter names be forwarded, too? If yes, variadic template 
parameters could capture the names, too, and apply them during 
expansion as appropriate.


4) Traits

Are there going to be traits to inspect the parameter names of a 
function? Of a TypeTuple/AliasTuple/AliasSeq?

Re: Is memory-safe IO possible?

2016-01-23 Thread Kagamin via Digitalmars-d-learn

You can try to write a trusted wrapper for one of curl functions 
and ask for a review on forum. Maybe it will be fruitful.

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread tcak via Digitalmars-d

On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


Without making things any complex, the simplest thought of mine 
is:


Keep everything same. But allow caller to put name of parameter 
front its value wherever desired.


Let's say,

Rect createRect(int x, int y, int width, int height);

So you could call it like:

createRect( 10, 20, width: 200, height: 500 );

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread Andre Polykanine via Digitalmars-d-learn


On 2016-01-23 16:34, tcak wrote:


Without making things any complex, the simplest thought of mine is:

Keep everything same. But allow caller to put name of parameter front
its value wherever desired.

Let's say,

Rect createRect(int x, int y, int width, int height);

So you could call it like:

createRect( 10, 20, width: 200, height: 500 );


I think that the DIP clearly states why it doesn't work like the above. 
One of the big objections of previous proposals was that the parameters 
of existing functions would be come part of the API. That is, it would 
not be possible to rename a parameter without breaking the API.


--
/Jacob Carlborg

Re: [dlang.org] Let's talk about the logo

2016-01-23 Thread Artur Skawina via Digitalmars-d

On 01/23/16 02:11, ronaldmc via Digitalmars-d wrote:
> 
> What happens if a technical feature is vetoed by someone is charge even if it 
> has merit?

Every wrong decision affects the project negatively.

> Linux Foundation has a board members to approve or not new features or 
> changes, and finally after that it goes to Linus, and overall after passed by 
> the board it's almost approved by Linus too.

I'd just ignore this, but somebody might actually believe it's true...

Linux development works because Linus is right often enough.
It really is that simple.

artur

Re: Adam D. Ruppe's Minigui using example


On Saturday, 16 January 2016 at 03:14:01 UTC, Adam D. Ruppe wrote:
On Saturday, 16 January 2016 at 01:27:32 UTC, Andre Polykanine 
wrote:
Does anyone have an actual example of, say, a simple form with 
a set of radio buttons or check boxes to start with?

Thanks in advance!


Sort of. I still haven't used it in a real world program so it 
isn't complete but here's one of my test programs:

[...]



On Windows, it uses the native controls, so it should work 
reasonably well, though on Linux it does its own thing and is 
far from complete.




BTW simplewindow doesn't seem to compile on newest dmd because 
of the new core.sys.windows.windows so I'll have to update that 
if you're on the newest release...


Thanks Adam,
I have DMD 2.068.2 so far so it did work.
However it seems to be not so accessible as I expected (tested 
with JAWS for Windows, latest release [1]). For instance, the 
focus lands nowhere when the program is launched. Then there is a 
(not too comfortable) possibility to make it show the elements to 
the screen reader upon pressing Tab.


[1]:https://en.wikipedia.org/wiki/JAWS_(screen_reader)

std.simd vision

2016-01-23 Thread Iakh via Digitalmars-d


I'm thinking of implementation std.simd in fashion different to
https://github.com/TurkeyMan/simd
since it looks dead and too sophisticated.

My proposal is:
- std.simd - processor independent intrinsics and some high 
level stuff.

  You only depend on different sizes of SIMD vector.
- std.simd.x86 - provides unified (compiler independent) 
x86/x86_64 intrinsic
  call. Each SIMD version (sse, sse2, ...) has its own 
namespace(struct) with

  intrinsic wrappers. Each wrapper is straightforward.
- std.simd.arm - provides unified arm-based SIMD.

Demo:
https://github.com/Iakh/simd
At the end of the file
https://github.com/Iakh/simd/blob/master/std/simd/x86.d
is a long unittest with sse2 memchar implementation.

Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"

2016-01-23 Thread Andrei Alexandrescu via Digitalmars-d


On 01/22/2016 09:48 AM, Marc Schütz wrote:

On Thursday, 21 January 2016 at 20:42:17 UTC, Jack Stouffer wrote:

On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote:

* Do NOT alias Flag!"frob" to a new name. This is unnecessary,
unhelpful, and wasteful.


I disagree. Making an alias means the user does not have to import
std.typecons in their code, and as a purely subjective measure,
ReplaceArrayWithPointer.Yes looks better than
Flag!"replaceArrayWithPointer".Yes.


Me too. @Andrei, what exactly is wrong with the alias?


Consider (taken from allocator):

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
size_t minSize, size_t maxSize = minSize,
Flag!"adaptive" adaptive = No.adaptive);

As an aside, this idiom should crystallize to:

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
size_t minSize, size_t maxSize = minSize,
Flag!"adaptive" flag = No.adaptive);

i.e. the name of the flag adds no information in neither declaration, 
definition, nor use. Just call it "flag", "flag1", "flag2" etc.


The alternative is (which is already present in parts of Phobos, e.g. 
std.stdio.KeepTerminator):


/**
... doc for AdaptiveFreeList, must explain that it is used by FreeList 
which HAS NOT YET BEEN DEFINED ...

*/
alias FreeListIsAdaptive = Flag!"adaptive";

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
size_t minSize, size_t maxSize = minSize,
AdaptiveFreeList adaptive = AdaptiveFreeList.no);

The latter version is more conventional - it's the way things are done 
in other languages (define an enum with yes/no, use it etc), and uses 
Flag just as an implementation device. I do agree the familiarity and 
conventionality argument has some strength to it. Other than that, the 
latter version has no advantage over the first, only disadvantages:


* In the first version it suffices to look at one declaration to 
understand everything: there is a yes/no flag related to adaptivity, and 
by default it's "no". In the second version you need to look in two places.


* The name "FreeListIsAdaptive" is introduced over the entire scope and 
must of course be public so the client can use it, yet only FreeList is 
using it.


* The name "FreeListIsAdaptive" by itself does not indicate it's a 
yes/no flag. It may be really any type so a look at the definition or 
documentation is necessary. The name Flag!"adaptive" is properly 
positioned from the get-go.


Flag is a very nice D idiom. I admit it took me a while to realize it 
and its implication, and I felt odd designing APIs with it in the 
beginning, coming from a habit to define my own aliases for such things. 
But the matter of fact is it's a very simple and expressive tool, and 
there's no necessity to blunt it just to use it the old way.



Andrei

[Issue 15592] Template specializations don't work in nested scope

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

Ivan Kazmenko  changed:

   What|Removed |Added

 CC||ga...@mail.ru

--

Re: DIP 88: Simple form of named parameters


On 2016-01-23 15:54, Marc Schütz wrote:


Some comments:

1) Default values

You should specify how to use both the `:` syntax and a default
parameter value, including an example. They are often going to be used
together, and it needs to be clear how they interact.


I can add an example.


2) Argument order

I think your rule no. 4 is not really necessary, and actually diminishes
the usability a lot if there are many name flags. Argument reordering
can be done as an independent step before overload resolution (of course
this still needs to be aware of all the candidates).


Take this for example:

void foo(int a, string b);
void foo(string b, int a);

void main()
{
foo(3, "asd");
foo("asd", 3);
}

The above is legal today. The same example with named arguments:

void foo(int a:, string b:);
void foo(string b:, int a:);

void main()
{
foo(a: 3, b: "asd");
}

What should happen in the above example? Error or which function should 
be called?



3) Variadic parameters

Is this legal: `void foo(int[] param: ...)`? Or this: `void
bar(Args...)(Args args:)`? If yes, what would the calling syntax look like?


I haven't really though of that. My initial though would be to not allow 
that for simplicity. I want to keep it fairly simple to have a chance 
for the proposal to be accepted.



Also, opDispatch is often used for forwarding arguments. Can parameter
names be forwarded, too? If yes, variadic template parameters could
capture the names, too, and apply them during expansion as appropriate.

4) Traits

Are there going to be traits to inspect the parameter names of a
function? Of a TypeTuple/AliasTuple/AliasSeq?


We already have ParameterIdentifierTuple [1]. Are you thinking of 
something else?


I'm not seeing how AliasSeq is related but this PR [2] adds template 
parameter introspection traits.


[1] http://dlang.org/phobos/std_traits.html#ParameterIdentifierTuple
[2] https://github.com/D-Programming-Language/dmd/pull/5201

--
/Jacob Carlborg

Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"

2016-01-23 Thread Andrei Alexandrescu via Digitalmars-d


On 01/22/2016 09:48 AM, Marc Schütz wrote:

On Thursday, 21 January 2016 at 20:42:17 UTC, Jack Stouffer wrote:

On Thursday, 21 January 2016 at 19:31:19 UTC, Andrei Alexandrescu wrote:

* Do NOT alias Flag!"frob" to a new name. This is unnecessary,
unhelpful, and wasteful.


I disagree. Making an alias means the user does not have to import
std.typecons in their code, and as a purely subjective measure,
ReplaceArrayWithPointer.Yes looks better than
Flag!"replaceArrayWithPointer".Yes.


Me too. @Andrei, what exactly is wrong with the alias?


Consider (taken from allocator):

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
size_t minSize, size_t maxSize = minSize,
Flag!"adaptive" adaptive = No.adaptive);

As an aside, this idiom should crystallize to:

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
size_t minSize, size_t maxSize = minSize,
Flag!"adaptive" flag = No.adaptive);

i.e. the name of the flag adds no information in neither declaration, 
definition, nor use. Just call it "flag", "flag1", "flag2" etc.


The alternative is (which is already present in parts of Phobos, e.g. 
std.stdio.KeepTerminator):


/**
... doc for AdaptiveFreeList, must explain that it is used by FreeList 
which HAS NOT YET BEEN DEFINED ...

*/
alias FreeListIsAdaptive = Flag!"adaptive";

/**
... doc for FreeList ...
*/
struct FreeList(ParentAllocator,
size_t minSize, size_t maxSize = minSize,
FreeListIsAdaptive adaptive = FreeListIsAdaptive.no);

The latter version is more conventional - it's the way things are done 
in other languages (define an enum with yes/no, use it etc), and uses 
Flag just as an implementation device. I do agree the familiarity and 
conventionality argument has some strength to it. Other than that, the 
latter version has no advantage over the first, only disadvantages:


* In the first version it suffices to look at one declaration to 
understand everything: there is a yes/no flag related to adaptivity, and 
by default it's "no". In the second version you need to look in two places.


* The name "FreeListIsAdaptive" is introduced over the entire scope and 
must of course be public so the client can use it, yet only FreeList is 
using it.


* The name "FreeListIsAdaptive" by itself does not indicate it's a 
yes/no flag. It may be really any type so a look at the definition or 
documentation is necessary. The name Flag!"adaptive" is properly 
positioned from the get-go.


Flag is a very nice D idiom. I admit it took me a while to realize it 
and its implication, and I felt odd designing APIs with it in the 
beginning, coming from a habit to define my own aliases for such things. 
But the matter of fact is it's a very simple and expressive tool, and 
there's no necessity to blunt it just to use it the old way.



Andrei

Re: [dlang.org] Let's talk about the logo


On Saturday, 23 January 2016 at 08:25:49 UTC, Walter Bright wrote:
I always wanted it to be a gif so the planet would appear to be 
subtly rotating and the edge of Deimos might twinkle slightly 
:-)


If it was meant to be a git then it makes more sense why it was 
as it is originally (but without the borders). I always thought 
the circles on the D was confusing since very few people will 
recognize without being told what it is.


But when the rotation is added, it will be awesome!! (That is 
design).

Re: [dlang.org] Let's talk about the logo


On Friday, 22 January 2016 at 20:28:57 UTC, anonymous wrote:

On 22.01.2016 20:53, ronaldmc wrote:
I don't want to start a war, but this isn't community? I mean 
aren't we
trying to make things better, because the way you said it 
seems like a

dictatorship.


It's dictatorship insofar as Walter and Andrei have veto power. 
If they don't want something in, it doesn't go in. I don't 
think this is a problem in practice. If it was, the community 
could always fork the project and then play by their own rules.


And of all things, the logo wouldn't be a good reason to divide 
over, in my opinion.



I am yet to see any good come from such decisions. Disagreement 
should not be a reason for division. YOU CAN NEVER GET WHAT YOU 
WANT IN ALL SITUATIONS (whether your are right or wrong). So 
please learn from people's mistakes like what happened between 
nodejs and iojs :)


Just a logo? Come on!!

D is the created programming language I have ever used.

Re: Please change alias ReplaceArrayWithPointer = Flag!"replaceArrayWithPointer"

2016-01-23 Thread Benjamin Thaut via Digitalmars-d-learn


On 2016-01-22 23:00, Ilya wrote:


DIP please! --Ilya


http://forum.dlang.org/post/n8024o$dlj$1...@digitalmars.com

--
/Jacob Carlborg

Re: Shared library question

On Saturday, 23 January 2016 at 00:38:45 UTC, Dibyendu Majumdar 
wrote:
On Friday, 22 January 2016 at 22:06:35 UTC, Dibyendu Majumdar 
wrote:

Hi

I am trying to create a simple shared library that exports a D 
function, but when I try to link to it I get errors such as:


 error LNK2001: unresolved external symbol 
_D7xxx12__ModuleInfoZ




I have uploaded my small test here so if anyone can tell me 
what I am doing wrong it will hugely appreciated.


Thanks!

https://github.com/dibyendumajumdar/d-lab/tree/master/sharedlib


Dll support on windows is basically non existant at the moment 
and I strongly advice against trying to use it. Trust me I've 
been there. I'm currently working on propper Dll support but that 
is most likely going to take a few more months.


Your best option currently is to simply link everything 
statically.


Kind Regards
Benjamin

Re: [dlang.org] Let's talk about the logo

2016-01-23 Thread ronaldmc via Digitalmars-d


On Saturday, 23 January 2016 at 01:23:20 UTC, H. S. Teoh wrote:

...
And besides, calling something a "dictatorship" is again 
confusing the development of a programming language with 
running a government. I still fail to see the connection 
between the two.


Because maybe you don't read too much (outside programming), you 
can easily find the term being used on open source. i.e:


http://www.freesoftwaremagazine.com/articles/dictators_free_and_open_source_software

And it's not new, there are old articles like from 2004:

http://www.bloomberg.com/bw/stories/2004-08-17/linus-torvalds-benevolent-dictatorship


(And BTW, I do not speak for this community either. What I 
express here are just my own opinions...




You don't need to draw for me that you're an user as much I am 
and if you're writing something of course it's your opinion.


I'm out for now, I'll don't reply anymore.

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread Chris Wright via Digitalmars-d

On Sat, 23 Jan 2016 15:19:03 +0100, Jacob Carlborg wrote:

> This is mostly to prevent ugly hacks like Flag [1].
> 
> http://wiki.dlang.org/DIP88

Please add proposals to http://wiki.dlang.org/List_of_DIP in the future. 
(I just did it for you.) There's a DIP category, but nobody includes a 
descriptive title in their wiki page names, so the auto-generated 
category name is kind of useless.

> [1] https://dlang.org/phobos/std_typecons.html#.Flag

"Rational" should be "Rationale".

One huge usecase for this is methods with many optional parameters. 
You've missed that. For instance, I wrote a method with six optional 
parameters recently. It's unusable without named parameters. I switched 
to a parameter struct, but it's still not that great.

I'd also add that this proposal doesn't affect UFCS.

What about overloading based on parameter names? The proposal doesn't 
even mention the idea, so there's no guessing whether you considered and 
rejected it or just didn't consider it.

> Any parameter that is supposed to be nameable at the call site needs to
> be explicitly declared as such. This is required because otherwise the
> parameters of all exist functions would become part of the API

I'll note that parameter names are already part of documentation, and 
they're already the only parameter documentation you're guaranteed to 
have.

The Dart devs decided that named parameters must be explicitly set out as 
named, and they cited the same reason. The C# devs, on the other hand, 
made every parameter a named parameter. I haven't heard of any explosions 
in C# land, and it's been five years.

Your proposal is closer to C#'s version than Dart's. In Dart, a named 
parameter cannot be called positionally:

  foo({a, b}) {}
  main() {
// This works:
foo(b: 1, a: 2);

// Error: 0 positional arguments expected, 2 found
foo(2, 1);
  }

In C#, a named parameter is only about the call site and has nothing to 
do with the function being called. A function you wrote for C# 1.1 and 
never modified can be called with named parameters in C# 4.0. You can 
still call these functions with positional-style parameters.

> Changing the order when using the named parameter syntax is not legal:

Why not?

Let's look at languages with named parameters. Python: reorderable. C#: 
reorderable. Dart: reorderable. Scala: reorderable. Ada: reorderable.

Given this trend, people will be confused if they can't reorder named 
parameters. The main benefit of not letting people reorder things is 
reducing the amount of work *you* need to do when creating this DIP (and 
the amount others need to do when implementing it).

To sum up, your proposal is approximately the same as adding a comment by 
each parameter saying which parameter it is. A bit nicer because it's got 
lighter syntax, a lot less usable because the function has to opt in.

Document how it's supposed to handle optional parameters and allow 
reordering, and then we're getting somewhere.

Re: [dlang.org] Let's talk about the logo

2016-01-23 Thread rsw0x via Digitalmars-d


On Saturday, 23 January 2016 at 15:41:43 UTC, ronaldmc wrote:

On Saturday, 23 January 2016 at 01:23:20 UTC, H. S. Teoh wrote:

[...]


Because maybe you don't read too much (outside programming), 
you can easily find the term being used on open source. i.e:


http://www.freesoftwaremagazine.com/articles/dictators_free_and_open_source_software

And it's not new, there are old articles like from 2004:

http://www.bloomberg.com/bw/stories/2004-08-17/linus-torvalds-benevolent-dictatorship



[...]


You don't need to draw for me that you're an user as much I am 
and if you're writing something of course it's your opinion.


I'm out for now, I'll don't reply anymore.


It's actually a very common term in FOSS.
https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

D is indeed Walter's ambition, and D2 is Walter/Andrei's. They 
have put the most effort into the project which is why their word 
gets the most weight, but I disagree with the notion that 
everyone else is shut out.

Define "createXXX" functions for the constructors of class XXX

2016-01-23 Thread Johan Engelen via Digitalmars-d-learn


Hi all,
  While trying to interface C++ and D, I have to new a few D 
objects in C++ code. I am doing this using a D function: "XXX 
createXXX(...) { return new XXX(...); }".
I am sure there must be some great way to automatically generate 
these creator functions, but I don't know how to do it.


In the C++-header I will write manually:
  XXX* createXXX(int a, int b);
  XXX* createXXX(bool flag);

In D source:
  extern (C++) class XXX {
this(int a, int b) { /+...+/ }
this(bool flag) { /+...+/ }
  }

// Somehow define these guys automatically, 
"genCreateCtors!(XXX)" ?

  XXX createXXX(int a, int b) { return new XXX(a, b); }
  XXX createXXX(bool flag) { return new XXX(flag); }

Thanks a lot!
  Johan

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread Mint via Digitalmars-d


On Saturday, 23 January 2016 at 15:34:00 UTC, tcak wrote:
On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


Without making things any complex, the simplest thought of mine 
is:


Keep everything same. But allow caller to put name of parameter 
front its value wherever desired.


Let's say,

Rect createRect(int x, int y, int width, int height);

So you could call it like:

createRect( 10, 20, width: 200, height: 500 );


I concur, the additional syntax for declaring functions that take 
named parameters is entirely extraneous. For the most part, it 
just complicates implementing the feature by adding additional 
considerations in regards to how tuples would represent the set 
of types,


ie. ParameterTypeTuple!foo where foo(int a:, int b:)

For the most part, I wouldn't be opposed to all functions 
accepting this syntax, although there still is the consideration 
of how the call is handled. Notably, is the named-parameter an 
expression of it's own that is only valid (or only meaningful) in 
the context of a function or constructor call? Otherwise, we 
still have the problem of how named-parameters are stored in 
alias sequences.


Also as a minor note, I don't really understand the case for 
parameter reordering. Typically speaking, the use case for named 
parameters is to allow calling a function (or constructing and 
object) without knowledge or concerns for what order the 
parameters are expected in. Otherwise, the syntax is largely just 
irrelevant. It simply adds additional cruft without any gain from 
doing so.

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread Mathias Lang via Digitalmars-d

2016-01-23 15:19 GMT+01:00 Jacob Carlborg via Digitalmars-d <
digitalmars-d@puremagic.com>:

> This is mostly to prevent ugly hacks like Flag [1].
>
> http://wiki.dlang.org/DIP88
>
> [1] https://dlang.org/phobos/std_typecons.html#.Flag
>
> --
> /Jacob Carlborg
>


About the rationale:
> Supporting named parameters directly in the language prevents the need to
add workarounds with weird looking syntax like Flag

That's going the opposite way of the current trend, which is shift as much
feature to library as possible.

> When interfacing with Objective-C it might be desirable to have a method
calling syntax which resembles the syntax used in Objective-C and Swift.

Implementing cosmetic features from a language because it appeals to its
user doesn't sound that useful to me.

The `createReq` example is a bit artificial, as you would usually replace
it with a struct.

About the design:
As mentioned earlier, forcing users to say which arguments can be named and
which cannot seems like an unnecessary limit. We'll just end up with
everyone using ':' after parameter names (which is very weird looking IMO)
in order to be able to use that syntax at the call site, if necessary.
Also, bear in mind that a lot of code one will use is not under one's
direct control. So if we want to use named parameter with a framework which
doesn't define this syntax, you cannot.
Since changing the order of parameter is not allowed, it sounds better to
just allow this syntax at the call site.
Also, one point which was not covered, should the compiler enforce that the
name used matches ? E.g. if I use `heigh` instead of `height`, should the
compiler tell me "change name `heigh` to `height`" ?

Overall, I'm not found of it. It looks like a lot of complication for
little to no benefit.

[Issue 11500] Bringing mixed-in operators and constructors to the overload set

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

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #2 from Adam D. Ruppe  ---
You can

alias __ctor = mixin_thing.__ctor;

if it appears in the right order...

--

Re: Why do some attributes start with '@' while others done't?

2016-01-23 Thread Iain Buclaw via Digitalmars-d-announce


On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad 
wrote:

[...]


I don't necessarily disagree with your overall point, but I 
think the question of whether a few attributes have an @ 
attached to them or not ranks pretty low on the list of "70% 
solutions with marginal support" that need fixing/fleshing out. 
If this is truly among the most pressing issues with D, then D 
must be in great shape.


It seems like poor allocation of resources (both those of the D 
development team, and those of the D users who would be forced 
to update their code) to put much effort into this right now, 
when there are so many other issues of greater practical import 
to work on.



Well, it's a big issue for me :)

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread Marc Schütz via Digitalmars-d

On Saturday, 23 January 2016 at 16:38:13 UTC, Jacob Carlborg 
wrote:

void foo(int a:, string b:);
void foo(string b:, int a:);

void main()
{
foo(a: 3, b: "asd");
}

What should happen in the above example? Error or which 
function should be called?


I hadn't take this into consideration; indeed it would change the 
way overload resolution works, although it is still possible to 
handle this (in this case with an error, because it's ambiguous).


My thought is that for flags (which was your justification for 
this feature), you really wouldn't want to care about order, you 
just want to specify the flags you are interested in and let the 
others assume their default values.


For an example, consider this overload of `spawnProcess` [3]:

@trusted Pid spawnProcess(
in char[][] args,
File stdin = std.stdio.stdin,
File stdout = std.stdio.stdout,
File stderr = std.stdio.stderr,
const string[string] env = null,
Config config = Config.none,
in char[] workDir = null
);

Let's say you want to specify the workdir, stdout and a config 
flag:


auto pid = spawnProcess(
["/usr/bin/grep", "-r.", "some string"],
workDir: "~/Documents",
stdout: fd,
config: Config.retainStderr
);

If the arguments all must be specified in the right order, it's 
very hard to get them right without looking them up in the 
documentation. Besides, if I understand the proposal correctly, 
you'd actually have to specify all arguments up to the last one 
used, even though they already have default values.


We already have ParameterIdentifierTuple [1]. Are you thinking 
of something else?


ParameterIdentifierTuple doesn't distinguish between parameters 
that allow your syntax and those that don't.




I'm not seeing how AliasSeq is related but this PR [2] adds 
template parameter introspection traits.


[1] 
http://dlang.org/phobos/std_traits.html#ParameterIdentifierTuple

[2] https://github.com/D-Programming-Language/dmd/pull/5201


This was part of my thoughts for variadic template params. 
Basically, the following should work:


int foo(int a:, int b:);
int bar(Args...)(Args args:) {
return bar(args);
}
bar(b: 2, a: 1);

Currently, `args` is `(2, 1)`. With name parameters, it would 
become `(b: 2, a: 1)`, i.e. each tuple members gets an (optional) 
name. There would then need to be a trait for reading these names.


[3] http://dlang.org/phobos/std_process.html#.spawnProcess

Re: D is now catching C++ exceptions!

On 18 January 2016 at 23:26, Walter Bright via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> at least for 64 bit Linux. Other platforms to follow.
>
>   https://github.com/D-Programming-Language/dmd/pull/5342
>
> This is what Andrei and I call "enabling" technology, as it opens the door
> for many more uses of D, in this case better interoperability with existing
> C++ codebases.
>
> Thanks to everyone who helped out with this, especially Elie, Iain, David
> and Andrei!
>
> Also looking forward to getting this in GDC and LDC!
>
> Andrei and I feel that better interoperability with C++ is a major
> strategic feature and advantage for D. As the recent thread with Manu's
> frustrations in doing it show, we still have a significant way to go. But I
> hope to push it forward hard in the next few months.
>
> For the fearless who love working under the hood, extending the support to
> the rest of the platforms is a great way to materially contribute.
>

Next step, catching any foreign exception thrown in Go, Ada, Java, [insert
your language here].

Re: Why do some attributes start with '@' while others done't?

2016-01-23 Thread tsbockman via Digitalmars-d


On Saturday, 23 January 2016 at 20:07:48 UTC, karabuta wrote:

On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
I don't necessarily disagree with your overall point, but I 
think the question of whether a few attributes have an @ 
attached to them or not ranks pretty low on the list of "70% 
solutions with marginal support" that need fixing/fleshing 
out. If this is truly among the most pressing issues with D, 
then D must be in great shape.


[...]



Well, it's a big issue for me :)


Then I guess D must be in great shape :-D

Re: Possible to get Class of Interface at runtime

2016-01-23 Thread Adam D. Ruppe via Digitalmars-d-learn


On Saturday, 23 January 2016 at 21:03:21 UTC, Josh Phillips wrote:

I tried this but it will return A not B


Are you sure you correctly casted first?

Re: Dmd sc.ini and VS do not work well together!

The installer should be modernized and provide path information 
and resolve dependencies properly before installing. It is 
clear that dmd was not designed for windows use.


Also, sc.ini global variables should be at the top most section:


[Environment]
DFLAGS="-I%@P%\..\..\src\phobos" 
"-I%@P%\..\..\src\druntime\import"

LIB="%@P%\..\lib"
These should be placed here instead of the individual sections as 
it creates redunancy and is bug prone:

VCINSTALLDIR=C:\PF\VS2015\VC\
WindowsSdkDir=C:\PF\Windows Kits\8.1\
UniversalCRTSdkDir=C:\PF\Windows\Kits\10\

or even in [Version]

[Issue 15599] New: Broken link here: https://dlang.org/features2.html

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

  Issue ID: 15599
   Summary: Broken link here: https://dlang.org/features2.html
   Product: D
   Version: D2
  Hardware: Other
OS: Other
Status: NEW
  Severity: minor
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: zwil...@gmail.com

The link to std.contracts under "Phobos Library Changes" at this webpage
https://dlang.org/features2.html is broken.

--

Re: Possible to get Class of Interface at runtime

2016-01-23 Thread via Digitalmars-d-learn


On Saturday, 23 January 2016 at 21:03:21 UTC, Josh Phillips wrote:

On Friday, 22 January 2016 at 23:44:34 UTC, Adam D. Ruppe wrote:

There's a .classinfo property that works on Objects.

If you have an interface, cast to Object first, and check for 
null, then get .classinfo off that.


I tried this but it will return A not B


http://dpaste.dzfl.pl/f1bcf74d8cab

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread Jonathan M Davis via Digitalmars-d

On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


To be pedantic, this would be adding named arguments, not named 
parameters. The parameters are already named, but mixing up 
arguments and parameters is a common mistake to make, and folks 
do frequently talk about named parameters with regards to this 
sort of feature.


Regardless, I for one, hope that we never have named arguments. 
It's just one more thing that's then part of the function's 
signature that you can't change without breaking code and will 
cause that much more bikeshedding. At least right now, parameter 
names don't matter much, whereas if they're part of the API, then 
they're open to all of the issues that function naming has.


And while I appreciate that this DIP does not make named 
arguments the default behavior for a function, making it up to 
the library writer whether they support named arguments or not is 
likely to create a lot of bikeshedding and debates over whether a 
particular function or library should support named arguments. 
Personally, I'd never use them under any circumstances.


However, I do appreciate that the DIP doesn't allow for 
reordering the arguments based on their names. It does make named 
arguments a bit less ugly.


- Jonathan M Davis

Re: Possible to get Class of Interface at runtime

2016-01-23 Thread Josh Phillips via Digitalmars-d-learn


On Friday, 22 January 2016 at 23:44:34 UTC, Adam D. Ruppe wrote:

There's a .classinfo property that works on Objects.

If you have an interface, cast to Object first, and check for 
null, then get .classinfo off that.


I tried this but it will return A not B

Re: Dmd sc.ini and VS do not work well together!

2016-01-23 Thread Jack Stouffer via Digitalmars-d-announce


On Saturday, 23 January 2016 at 22:47:35 UTC, Walter Bright wrote:

On 1/23/2016 1:38 PM, Igor wrote:

As of now I personally cannot use dmd to build windows apps.


You know, sc.ini is editable by you!


Yes, But why do you expect me to be so smart or have a desire to 
waste my time looking for paths and such when YOU can write about 
100 lines of code in about the same time it would take me to get 
sc.ini to work properly?


There is a multiplicative factor here. If you do the work then it 
saves N people N hours of there life. If I do it, it wastes 1 hr 
of my life and helps no one!


Please don't be a life thief! I know it takes your own life-hours 
to implement the code but you are the head D hauncho! Maybe hire 
someone or ask someone? You seem to have a following!


If I actually knew what sc.ini really needed to work properly 
then I might do it myself, but it looks kinda crappy old win3.1 
style stuff that never made much sense in the first place.

Re: alias template parameter

2016-01-23 Thread QAston via Digitalmars-d-learn


On Friday, 21 June 2013 at 14:08:43 UTC, Sergei Nosov wrote:

Hi!

I've been thinking about how alias template parameters work and 
I'm really confused =)


It makes perfect sense for literals, names, etc. But what I 
can't get is how does it work for delegates.


If I have a function
auto apply(alias fun, T...)(T args)
{
return fun(args);
}

And then I have
int y = 2;
apply!(x => y)(1);

How in the world does this work? Is the context address known 
at compile-time?


y is allocated on the heap and the pointer is implicitly passed 
to the apply, or is a field of a struct if you use map!(x => y) 
instead.

Re: Bruce Eckel is evaluating languages


On Friday, 22 January 2016 at 20:19:55 UTC, Ali Çehreli wrote:


https://www.reddit.com/r/programming/comments/426pwq/a_language_is_more_than_a_language/

Would someone from the D community add D to his project:

  http://bruceeckel.github.io/Language-Evaluation-Checklist/

Ali


Meh. Doesn't exactly look like a popular initiative; currently it 
has less than 10 stars on GitHub.

Improving CSV parsing performance, Episode 2 (Was: Re: Speed of csvReader)

2016-01-23 Thread H. S. Teoh via Digitalmars-d-learn

On Fri, Jan 22, 2016 at 10:04:58PM +, data pulverizer via 
Digitalmars-d-learn wrote:
[...]
> I guess the next step is allowing Tuple rows with mixed types.

Alright. I threw together a new CSV parsing function that loads CSV data
into an array of structs. Currently, the implementation is not quite
polished yet (it blindly assumes the first row is a header row, which it
discards), but it does work, and outperforms std.csv by about an order
of magnitude.

The initial implementation was very slow (albeit still somewhat fast
than std.csv by about 10% or so) when given a struct with string fields.
However, structs with POD fields are lightning fast (not significantly
different from before, in spite of all the calls to std.conv.to!). This
suggested that the slowdown was caused by excessive allocations of small
strings, causing a heavy GC load.  This suspicion was confirmed when I
ran the same input data with a struct where all string fields were
replaced with const(char)[] (so that std.conv.to simply returned slices
to the data) -- the performance shot back up to about 1700 msecs, a
little slower than the original version of reading into an array of
array of const(char)[] slices, but about 58 times(!) the performance of
std.csv.

So I tried a simple optimization: instead of allocating a string per
field, allocate 64KB string buffers and copy string field values into
it, then taking slices from the buffer to assign to the struct's string
fields.  With this optimization, running times came down to about the
1900 msec range, which is only marginally slower than the const(char)[]
case, about 51 times faster than std.csv.

Here are the actual benchmark values:

1) std.csv: 2126883 records, 102136 msecs

2) fastcsv (struct with string fields): 2126883 records, 1978 msecs

3) fastcsv (struct with const(char)[] fields): 2126883 records, 1743 msecs

The latest code is available on github:

https://github.com/quickfur/fastcsv

The benchmark driver now has 3 new targets:

stdstruct   - std.csv parsing of CSV into structs
faststruct  - fastcsv parsing of CSV into struct (string fields)
faststruct2 - fastcsv parsing of CSV into struct (const(char)[] fields)

Note that the structs are hard-coded into the code, so they will only
work with the census.gov test file.

Things still left to do:

- Fix header parsing to have a consistent interface with std.csv, or at
  least allow the user to configure whether or not the first row should
  be discarded.

- Support transcription to Tuples?

- Refactor the code to have less copy-pasta.

- Ummm... make it ready for integration with std.csv maybe? ;-)


T

-- 
Fact is stranger than fiction.

Re: Define "createXXX" functions for the constructors of class XXX

2016-01-23 Thread tcak via Digitalmars-d-learn


On Saturday, 23 January 2016 at 19:42:29 UTC, Johan Engelen wrote:

Hi all,
  While trying to interface C++ and D, I have to new a few D 
objects in C++ code. I am doing this using a D function: "XXX 
createXXX(...) { return new XXX(...); }".
I am sure there must be some great way to automatically 
generate these creator functions, but I don't know how to do it.


In the C++-header I will write manually:
  XXX* createXXX(int a, int b);
  XXX* createXXX(bool flag);

In D source:
  extern (C++) class XXX {
this(int a, int b) { /+...+/ }
this(bool flag) { /+...+/ }
  }

// Somehow define these guys automatically, 
"genCreateCtors!(XXX)" ?

  XXX createXXX(int a, int b) { return new XXX(a, b); }
  XXX createXXX(bool flag) { return new XXX(flag); }

Thanks a lot!
  Johan


Wow! There are lots of XXX there.

Anyway, I did a similar thing to yours for automatic attribute 
definition before. Three things:


1. Template
2. Mixin
3. Compile time function

You define a compile time function which generates a string that 
is valid D code.
You define template that takes some parameters (Your XXX values), 
and calls the function to merge them.
In your class, you use mixin and template to generate the string 
and inject the generated code.


Not that complex once you do it.

Try to understand this code.
http://david.rothlis.net/d/templates/

Its in there.

Re: Dub needs some additions


On Saturday, 23 January 2016 at 20:54:36 UTC, develop32 wrote:

On Saturday, 23 January 2016 at 20:24:05 UTC, Igor wrote:
Some simple extensions to dub are required for proper windows 
support:


1. The Ability to generate full build selections for Visual D. 
I only get Win32 when using `dub generate VisualD`. Win64 
support should be added, along with alternate compiler 
support. (GDC and LDC)


dub generate visuald --arch=x86_64 etc.

You have to use flags to configure the project.



No, I am talking about adding the different build options inside 
the visual studio project. When one generates the project, it 
should add the 64bit build options regardless. It is a standard 
with all Visual Studio projects in C++, C#, and VB. It should not 
require a flag to set. It doesn't change the architecture but 
only provides a simple build option.


When I use the flag, I only get 64... I want both!!! I should be 
able to switch seemlessly between 64-bit and 32-bit by using the 
configuration manager/combo box like every other normal project 
in VS has as default.





2. The ability to refresh a project by adding new dependencies 
and files to the previously generate Visual D project. It 
should retain modified settings of the project file. I'm 
thinking of something like `dub refresh VisualD` would work.


Yeah, that would be nice.



The current generate settings are just child's toys without 
the ability to retain and update project info.


Thank You.

Re: Dmd sc.ini and VS do not work well together!


On 1/23/2016 3:49 PM, Igor wrote:

Yes, But why do you expect me to be so smart or have a desire to waste my time
looking for paths and such when YOU can write about 100 lines of code in about
the same time it would take me to get sc.ini to work properly?

There is a multiplicative factor here. If you do the work then it saves N people
N hours of there life. If I do it, it wastes 1 hr of my life and helps no one!

Please don't be a life thief! I know it takes your own life-hours to implement
the code but you are the head D hauncho! Maybe hire someone or ask someone? You
seem to have a following!


Sucking the life force from D users is all the sustenance I need.

Re: Why do some attributes start with '@' while others done't?


On Saturday, 23 January 2016 at 20:11:35 UTC, tsbockman wrote:

On Saturday, 23 January 2016 at 20:07:48 UTC, karabuta wrote:

On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote:
I don't necessarily disagree with your overall point, but I 
think the question of whether a few attributes have an @ 
attached to them or not ranks pretty low on the list of "70% 
solutions with marginal support" that need fixing/fleshing 
out. If this is truly among the most pressing issues with D, 
then D must be in great shape.


[...]



Well, it's a big issue for me :)


Then I guess D must be in great shape :-D



And now they will argue about curly braces and semi-colons and 
the real issues for this thread will be forgotten and there will 
always be issues not resolved. People keep the hate in their 
heart and it leads to a whole lot of problem and heart  and 
mental disease :)


Seriously, @

Dub needs some additions

Some simple extensions to dub are required for proper windows 
support:


1. The Ability to generate full build selections for Visual D. I 
only get Win32 when using `dub generate VisualD`. Win64 support 
should be added, along with alternate compiler support. (GDC and 
LDC)


2. The ability to refresh a project by adding new dependencies 
and files to the previously generate Visual D project. It should 
retain modified settings of the project file. I'm thinking of 
something like `dub refresh VisualD` would work.


The current generate settings are just child's toys without the 
ability to retain and update project info.


Thank You.

Re: Dmd sc.ini and VS do not work well together!


On 1/23/2016 1:38 PM, Igor wrote:

As of now I personally cannot use dmd to build windows apps.


You know, sc.ini is editable by you!

Re: Define "createXXX" functions for the constructors of class XXX

2016-01-23 Thread Chris Wright via Digitalmars-d-learn

On Sat, 23 Jan 2016 19:42:29 +, Johan Engelen wrote:
> // Somehow define these guys automatically, "genCreateCtors!(XXX)" ?
>XXX createXXX(int a, int b) { return new XXX(a, b); }
>XXX createXXX(bool flag) { return new XXX(flag); }

Check out http://dpaste.dzfl.pl/430dabf25935

I used string mixins to be absolutely, 100% sure that the right things 
ended up in the symbol table.

__traits(getOverloads, Type, "name") gets function overloads for the 
given name. It gets them as an AliasSeq, which presents an array-like 
interface.

Constructors use the name "__ctor". So you can get all constructors for a 
class named MyClass with:

__traits(getOverloads, MyClass, "__ctor")

This only includes explicitly defined constructors, not the default 
constructor, so we handle that separately.

std.traits defines a Parameters template that takes a function and yields 
a parameter type tuple. We can hand it a constructor and it does the 
right thing. We can treat a bunch of values as one value if their type is 
a type tuple, so that's exactly what we do.

Then it's just a bit of string manipulation to get the right class names 
and overloads in the right places and we've generated a string of D code 
that does what we want. Mix it in and Bob's your uncle.

In your code, the line
  mixin(factory!MyClass);
should be inside an extern(C++) block, naturally.

The major caveat there: wherever you call "mixin(factory!MyClass);", you 
need MyClass to be in scope directly. If you have to refer to it with a 
qualified name, this will break. If that causes problems for you, you can 
use:

extern(C++) {
  {
import mypkg.mymodule : MyClass;
mixin(factory!MyClass);
  }
}

And that should import just that class for just that one block of code.

Re: Dub needs some additions

2016-01-23 Thread develop32 via Digitalmars-d


On Saturday, 23 January 2016 at 20:24:05 UTC, Igor wrote:
Some simple extensions to dub are required for proper windows 
support:


1. The Ability to generate full build selections for Visual D. 
I only get Win32 when using `dub generate VisualD`. Win64 
support should be added, along with alternate compiler support. 
(GDC and LDC)


dub generate visuald --arch=x86_64 etc.

You have to use flags to configure the project.



2. The ability to refresh a project by adding new dependencies 
and files to the previously generate Visual D project. It 
should retain modified settings of the project file. I'm 
thinking of something like `dub refresh VisualD` would work.


Yeah, that would be nice.



The current generate settings are just child's toys without the 
ability to retain and update project info.


Thank You.

Dmd sc.ini and VS do not work well together!

I feel like I am in the cave man times.  I installed Dmd2 from 
scratch. VisualD x64 project would not compile due to libucrt.lib 
not being found.


Using Process Monitor, it seems that dmd is looking all over the 
place for libucrt.lib but can't find it. Check out sci.ini has 
some weird results.


I have installed some windows kits and sdk's for win 8.1 and win 
10 but I do not remember all the details.


What I do know is that I have about 20 libucrt's in on my 
harddrive(global search).



1. The archaic sc.ini file gets things backwards. It uses 
VCINSTALLDIR before it is defined!



This is the exact file generated on my system minus the comments:

[Version]
version=7.51 Build 020
; environment for both 32/64 bit
[Environment]
DFLAGS="-I%@P%\..\..\src\phobos" 
"-I%@P%\..\..\src\druntime\import"

LIB="%@P%\..\lib"

[Environment32]
LIB="%@P%\..\lib"
LINKCMD=%@P%\link.exe

[Environment64]
LIB="%@P%\..\lib64"
DFLAGS=%DFLAGS% -L/OPT:NOICF
LINKCMD=%VCINSTALLDIR%\bin\link.exe ;;; <<< UM, Where is 
VCINSTALLDIR?


VCINSTALLDIR=C:\PF\VS2015\VC\
WindowsSdkDir=C:\PF\Windows Kits\8.1\
UniversalCRTSdkDir=C:\PF\Windows\Kits\10\
UCRTVersion=winv6.3
LINKCMD=%VCINSTALLDIR%\bin\x86_amd64\link.exe
PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\bin
LIB=%LIB%;"%VCINSTALLDIR%\lib\amd64"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x64"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
LIB=%LIB%;"%WindowsSdkDir%\Lib\winv6.3\um\x64"
LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x64"
LIB=%LIB%;"%WindowsSdkDir%\Lib\x64"
LIB=%LIB%;"%DXSDK_DIR%\Lib\x64"

[Environment32mscoff]
LIB="%@P%\..\lib32mscoff"
DFLAGS=%DFLAGS% -L/OPT:NOICF
VCINSTALLDIR=C:\PF\VS2015\VC\
WindowsSdkDir=C:\PF\Windows Kits\8.1\
UniversalCRTSdkDir=C:\PF\Windows\Kits\10\
UCRTVersion=winv6.3
LINKCMD=%VCINSTALLDIR%\bin\link.exe
PATH=%PATH%;%VCINSTALLDIR%\bin
LIB=%LIB%;"%VCINSTALLDIR%\lib"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\um\x86"
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x86"
LIB=%LIB%;"%WindowsSdkDir%\Lib\winv6.3\um\x86"
LIB=%LIB%;"%WindowsSdkDir%\Lib\win8\um\x86"
LIB=%LIB%;"%WindowsSdkDir%\Lib"
LIB=%LIB%;"%DXSDK_DIR%\Lib\x86"



Um, So, first off VCINSTALLDIR is used before defined!! Pretty 
basic bug here, should never have happened. Second, UCRTVersion 
is just wrong. I have no winv6.3 subdir. Windows 10 and VS2015 
use some folder names like


C:\PF\Windows\Kits\10\Lib\10.0.10150.0
and
C:\PF\Windows\Kits\10\Lib\10.0.10240.0


Which contains the libucrt libs. It seems the installer is pretty 
ignorant of reality and almost surely not designed by someone 
that uses windows as a development platform. As of now I 
personally cannot use dmd to build windows apps. I imagine there 
are other people in similar situations with similar build setups.


The installer should be modernized and provide path information 
and resolve dependencies properly before installing. It is clear 
that dmd was not designed for windows use.

Re: [dlang.org] Let's talk about the logo

2016-01-23 Thread Jesse Phillips via Digitalmars-d-learn


On 1/23/2016 11:47 AM, karabuta wrote:

On Saturday, 23 January 2016 at 08:25:49 UTC, Walter Bright wrote:

I always wanted it to be a gif so the planet would appear to be subtly
rotating and the edge of Deimos might twinkle slightly :-)


If it was meant to be a git then it makes more sense why it was as it is
originally (but without the borders). I always thought the circles on the D was
confusing since very few people will recognize without being told what it is.

But when the rotation is added, it will be awesome!! (That is design).


Something like this:

https://www.youtube.com/watch?v=ou6JNQwPWE0=player_detailpage#t=348

Re: Dub needs some additions

2016-01-23 Thread develop32 via Digitalmars-d


On Saturday, 23 January 2016 at 21:24:27 UTC, Igor wrote:
No, I am talking about adding the different build options 
inside the visual studio project. When one generates the 
project, it should add the 64bit build options regardless. It 
is a standard with all Visual Studio projects in C++, C#, and 
VB. It should not require a flag to set. It doesn't change the 
architecture but only provides a simple build option.


When I use the flag, I only get 64... I want both!!! I should 
be able to switch seemlessly between 64-bit and 32-bit by using 
the configuration manager/combo box like every other normal 
project in VS has as default.




Ah, yeah, that makes sense.

To me personally setting project working directory to $(OUTDIR) 
when generating would be nice. Doesn't sound like a hard thing to 
do, I'll try making a pull request for that.

Re: Dmd sc.ini and VS do not work well together!

2016-01-23 Thread Mike Parker via Digitalmars-d


On Saturday, 23 January 2016 at 23:49:23 UTC, Igor wrote:

Yes, But why do you expect me to be so smart or have a desire 
to waste my time looking for paths and such when YOU can write 
about 100 lines of code in about the same time it would take me 
to get sc.ini to work properly?


There is a multiplicative factor here. If you do the work then 
it saves N people N hours of there life. If I do it, it wastes 
1 hr of my life and helps no one!


Please don't be a life thief! I know it takes your own 
life-hours to implement the code but you are the head D 
hauncho! Maybe hire someone or ask someone? You seem to have a 
following!


If I actually knew what sc.ini really needed to work properly 
then I might do it myself, but it looks kinda crappy old win3.1 
style stuff that never made much sense in the first place.


If editing a configuration file is so difficult, you should use 
the installer. It will find your Microsoft tool installations and 
configure everything for you.

Re: Dmd sc.ini and VS do not work well together!

2016-01-23 Thread Mike Parker via Digitalmars-d


On Sunday, 24 January 2016 at 05:16:06 UTC, Igor wrote:


Please don't parrot! I, Of course, used the installer and it 
didn't work, else why would I be here? The installer is 
obviously flawed, if you looked in to this you would see that 
it is the case.


When you said, "I installed Dmd2 from scratch", I took that 
coupled with your problems to mean that you installed manually. 
My mistake.

Re: Dmd sc.ini and VS do not work well together!

2016-01-23 Thread Brad Anderson via Digitalmars-d

On Saturday, 23 January 2016 at 21:38:19 UTC, Igor wrote:
I feel like I am in the cave man times. I installed Dmd2 from
scratch. VisualD x64 project would not compile due to
libucrt.lib not being found.

Sorry you are having trouble. The Universal CRT and Visual Studio
2015 are very new and I'm sure there are still some bugs to work
out.

Using Process Monitor, it seems that dmd is looking all over
the place for libucrt.lib but can't find it. Check out sci.ini
has some weird results.

I have installed some windows kits and sdk's for win 8.1 and
win 10 but I do not remember all the details.

What I do know is that I have about 20 libucrt's in on my
harddrive(global search).

1. The archaic sc.ini file gets things backwards. It uses
VCINSTALLDIR before it is defined!

Well spotted but this case you are missing some details.
VCINSTALLDIR is used at that point so dmd linking will still work
for people who install using the zip file but run DMD through
Visual Studio Command Prompts (which define VCINSTALLDIR). You'll
notice LINKCMD is than replaced with a different value further
along by the installer. The comments could be better to explain
why it is this way.

It actually shouldn't matter if it's defined later though. My
understanding is the environment variables aren't expanded as the
config file is read. They all get read and set verbatim as
environment variables. Windows expands them once they are used
meaning VCINSTALLDIR would be set.

[snip]

Um, So, first off VCINSTALLDIR is used before defined!! Pretty
basic bug here, should never have happened. Second, UCRTVersion
is just wrong. I have no winv6.3 subdir. Windows 10 and VS2015
use some folder names like

C:\PF\Windows\Kits\10\Lib\10.0.10150.0
and
C:\PF\Windows\Kits\10\Lib\10.0.10240.0

We are using:

HKLM "Software\Microsoft\Windows Kits\Installed Roots"
"KitsRoot10"

Then searching for the latest UCRT version in a subdirectory.
That's probably where the bug is. This is brand new detection
however so it might be buggy.

You can see how it works here:
https://github.com/D-Programming-Language/installer/blob/master/windows/d2-installer.nsi#L379

Would you happen to know a better way to do this?

[snip]

The installer should be modernized and provide path information
and resolve dependencies properly before installing. It is
clear that dmd was not designed for windows use.

We make updates to it pretty much every release cycle. We'd love
some help making it bulletproof. Rock solid VS/Platform SDK
detection is what we want but it's proved a bit trickier than
expected (Microsoft has changed a few things up with different VS
releases so there is not just one way to do it).

First project: questions on how-to, and on language features

2016-01-23 Thread Alex Vincent via Digitalmars-d-learn


Source code:
https://alexvincent.us/d-language/samples/intervalmap-rev1.d.txt

After reading Ali Çehreli's book, "Programming in D", I wrote 
this little sample up as a starting point for my explorations 
into D.  I've long admired the D language, but I've never 
actually tried to write practical code in D.


So I wrote this little sample up in dlangide, and as I was going, 
I realized I had quite a few questions.


(1) It's not clear how to specify certain parts of a module or 
library as non-exportable.  Is that possible?  Is it desirable?  
(It's not that important, yet, but still...)


(2) In the unittest code, I have a block that I want to rewrite 
using assertThrown, but I can't figure out from either the book 
or the website the correct usage.  What's the right way to 
specify a StringException with a particular message I expect to 
receive?


(3) How do I actually create a library in dub?  How does dub 
determine what files to build?


(4) How should the scope(exit) and scope(failure) guard 
statements intermix with preconditions and postconditions?


(5) My append() function has a postcondition that currently 
depends on debug-only members of the class being set in the 
precondition.  This seems artificial - not the part about setting 
these variables in the precondition, but having the variables 
defined on the class to begin with.  If they were defined only 
for the lifetime of the function's execution, starting in the 
precondition, this would be more natural.  Is there a Right Way 
to define function-only debug variables for use in 
postconditions?  If not, would this be a valid use-case to 
consider amending the language specification to clarify?


(6) Would someone please review my sample code and offer 
feedback?  :-)


(7) Naming:  This code is the start of a port of a mini-library I 
wrote in JavaScript which I called "ObjectRange".  However, in 
Phobos, the term "Range" has a very different meaning - in fact, 
almost the opposite meaning of what this code does.  I asked for 
a better name in the D IRC channel, and someone suggested 
Interval, based on the mathematical definition of the word.  
IntervalMap seemed more accurate, since there is a payload to 
each interval.  Does the name make sense in the context?


(8) Is there a similar, more mature library out there which tries 
to achieve what I'm doing here?  I'm rather surprised I didn't 
see anything like it in the standard library...

Re: Improving CSV parsing performance, Episode 2 (Was: Re: Speed of csvReader)


On Sunday, 24 January 2016 at 01:57:11 UTC, H. S. Teoh wrote:

- Ummm... make it ready for integration with std.csv maybe? ;-)


T


My suggestion is to take the unittests used in std.csv and try to 
get your code working with them. As fastcsv limitations would 
prevent replacing the std.csv implementation the API may not need 
to match, but keeping close to the same would be best.

Re: Dmd sc.ini and VS do not work well together!


On Sunday, 24 January 2016 at 00:46:32 UTC, Walter Bright wrote:
Sucking the life force from D users is all the sustenance I 
need.


Lol, ok! ;) Well, Sorry, I don't have much life force to give!

Re: DIP 88: Simple form of named parameters

2016-01-23 Thread jmh530 via Digitalmars-d

On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


Someone on another thread made a comment that it wasn't clear 
what : does in D. I suspect this won't help. I'm more used to 
equals from R than : in C# and Swift, though I'm not sure that 
really matters much.


There is a good discussion of named parameters here (particularly 
amon's answer):

http://programmers.stackexchange.com/questions/219593/why-do-many-languages-not-support-named-parameters

Re: Dub needs some additions


On Sunday, 24 January 2016 at 00:24:27 UTC, develop32 wrote:

On Saturday, 23 January 2016 at 21:24:27 UTC, Igor wrote:

Ah, yeah, that makes sense.

To me personally setting project working directory to $(OUTDIR) 
when generating would be nice. Doesn't sound like a hard thing 
to do, I'll try making a pull request for that.



I don't mind too much where it is put but I would just like it to 
work well and provide the standard build options to make life 
easy.

Re: Dmd sc.ini and VS do not work well together!