Re: Deimos bindings to libmrss

[Ilya Yaroshenko via Digitalmars-d-announce]

On Friday, 4 March 2016 at 07:43:59 UTC, Ilya Yaroshenko wrote:

GitHub: https://github.com/9il/mrss
Dub: http://code.dlang.org/packages/mrss
libmrss: https://github.com/9il/mrss

See also: https://github.com/Laeeth/d_rss/


EDIT:
libmrss: http://www.autistici.org/bakunin/libmrss

Deimos bindings to libmrss

[Ilya Yaroshenko via Digitalmars-d-announce]

GitHub: https://github.com/9il/mrss
Dub: http://code.dlang.org/packages/mrss
libmrss: https://github.com/9il/mrss

See also: https://github.com/Laeeth/d_rss/

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

[Shachar Shemesh via Digitalmars-d]

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

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

Andrei


You just stepped on a pet peeve of mine. NIO isn't async IO. It's 
non-blocking IO. Many people (including Microsoft's MSDN) confuse the 
two, but they are completely and utterly different, and in fact, quite 
orthogonal (though the blocking async combination makes no sense, which 
is possibly the source of the confusion).


Blocking IO means that if a request cannot be served immediately, your 
thread blocks until it can be served. Try to read from a socket with no 
data, the call to "read" will only return once data arrives.


Synchronous IO means that a call only returns once it can be said, on 
some level, to have been performed. If you call "send" on a socket in 
synchronous mode, then, depending on the socket type, it will return 
after it has sent out the information (without waiting for an ACK), or, 
at the very least, after having copied the information into the kernel's 
buffers. If you call an asynchronous version of send, the copying of 
information into the socket may take place after the system call has 
already taken place.


In Linux, for example, non-blocking mode is activated using a fcntl 
(O_NONBLOCK). Asynchronous operations are separate and distinct system 
calls (aio_*, io_* and vmsplice).


Using non blocking mode introduces some challenges, but is, generally 
speaking, not very complicated (particularly when using fibers). Using 
asynchronous IO is considerably more complicated, as you need to keep 
track which of your buffers is currently having async operations done 
on. Not many systems are built around async IO.


This may change, as most of the user space only low latency IO solutions 
(such as DPDK) are async by virtue of their hardware requirements.



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


Shachar

Re: std.database

[Piotrek via Digitalmars-d]

On Thursday, 3 March 2016 at 18:48:08 UTC, Chris Wright wrote:
You were a bit vague before. I interpreted you as saying "just 
offer a range and an array-like API, and then you can use it 
with std.algorithm". But if you meant to offer an API that is 
similar to std.algorithm and also array-like, that's more 
feasible.


I agree I could be better in describing the concept. But I just 
sketched the idea.



You're still left with the task of transpiling D to SQL.
If someone wants to use SQL in its *full power* no D API nor any 
other language will suffice. Mainly because it will be always a 
traslation layer . The only we can to is to provide an aid like 
things suggested by Andrei (sql parser, value binding, etc).



This model does not work with CouchDB.

I don't know CouchDB so I can't comment.

You must avoid using std.algorithm and std.range functions 
assiduously because they would offer terrible performance.


For big data in db, plain vanilla std.algorithm won't be 
insufficient. I agree.



 * No support for complex queries.


Not sure what you mean by complex queries. Also I think the 
API allows arbitrary complex queries.


Aggregates, especially with joins. Computed fields.


Regarding computed fields and other database vendor specific 
features you are right.
But on the other hand aggregations and joins can be represented 
as objects and proxies of objects.



 * No support for joins.


Can be done by @attributes or other linking functionality 
between DbCollections.


With attributes, you need users to define aggregate types 
instead of just using Row and the like. That's ORM territory.


I don't like ORM with respect to SQL. But quasi object database 
which can look similar to ORM is not a problem for me.


At a previous job I maintained an internal BI site that exposed 
50-100 different queries, each with their own set of result 
fields. We didn't want to use ORM there; it would have been 
cumbersome and inappropriate.


I can see your point. But the problem can be solved by not using 
SQL.


Also, that assumes that you will always want a join when 
querying a table. I maintained an application once, using ORM, 
in which we sometimes wanted an eager join and sometimes wanted 
a lazy one. This posed a nontrivial performance impact.


Something like DbProxy would handle lazy "joins".


I'm not sure ORM would be a candidate for phobos.


As I don't plan to use an (traditional) ORM I'm not involved. 
However if other people would find it worthy I don't object.



 * No support for projections.


You mean something like referring to part of the item's 
fields? I see no problem here.


Let me point you to the existence of the TEXT and BLOB 
datatypes. They can each hold 2**32 bytes of data in MySQL.


This is something a DbProxy would handle. Eventually:

struct OrginalObject
{
  int id;
  string bigString;
}

struct StrippedObject
{
  int id;
}

then
auto collA = db.collection!OrginalObject("Big");
auto collA = db.collection!StrippedObject("Big");

In the second line the string is not fetched.

I'm not splitting those off into a separate table to port my 
legacy database to your API. I'm not dragging in multiple 
megabytes of data in every query.


If you're going full ORM, you can add lazy fields. That adds 
complexity. It's also inefficient when I know in advance that I 
need those fields.




 * In your implementation, updates must bring every affected
row over the wire, then send back the modified row.


In my implementation there is no wire (that's why I call it 
embedded). However I thought we talk about API and not 
particular implementation. I don't see how this API excludes 
RPC. Query strings (e.g. SQL) can be provided in old fashioned 
way.


I'm running a website and decide that, with the latest changes, 
existing users need to get the new user email. So I write:


  UPDATE users SET sent_join_email = FALSE;
  -- ok; 1,377,212 rows affected

Or I'm using your database system. If it uses std.algorithm, I 
have to iterate through the users list, pulling each row into 
my process's memory from the database server, and then I have 
to write everything back to the database server.


Depending on the implementation, it's using a database cursor 
or issuing a new query for every K results. If it's using a 
database cursor, those might not be valid across transaction 
boundaries. I'm not sure. If they aren't, you get a large 
transaction, which causes problems.


If your database system instead offers a string-based API 
similar to std.algorithm, you might be able to turn this into a 
single query, but it's going to be a lot of work for you.


For client-server approach I agree with the above. For embedded 
design (as in my project) this is not a case.



 * Updates affect an entire row. If one process updates one
field in a row and another one updates a different field, one 
of those

writes gets clobbered.


I think this is just a "must have" for any db engine. I don't 
see how it applies 

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

[Ali Çehreli via Digitalmars-d]

On 03/03/2016 06:01 PM, deadalnix wrote:

> 2x64kb L1 cache, which probably reduce the cache trashing due
> to context switches

(I am speaking without measuring anything.)

I imagine that lost cache is one of the biggest costs in thread 
switching. It would be great if a thread could select a thread with 
something like "I'm done, now please switch to my reader". And that's 
exactly one of the benefits of fibers: two workers ping pong back and 
forth, without much risk of losing their cached data.


Is my assumption correct?

Ali

[Issue 15752] Diagnostic: Better Error Message for Assigning Incorrect AA Empty Value

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

   Keywords||diagnostic

--

[Issue 15752] New: Diagnostic: Better Error Message for Assigning Incorrect AA Empty Value

[via Digitalmars-d-bugs]

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

  Issue ID: 15752
   Summary: Diagnostic: Better Error Message for Assigning
Incorrect AA Empty Value
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Because of the use of [] to enclose AA assignment, one could be forgiven in
accidentally doing something like this:

void main() {
int[int] a = [];
}

Which results in the very unhelpful message:

Error: can't have associative array key of void

Of course, the right answer is to use null, but again, the similarities with
array literals one could be expected to make this mistake. The error message is
also different when trying to do this for an optional function parameter.

void func(int[int] b = []) {
}

void main() {
func();
}

Error: cannot implicitly convert expression ([]) of type void[] to int[int]

The message should be something like this: 

Error: can't have associative array key of void. Perhaps you meant to
initialize an empty AA with null?

--

Re: Uniform Function Call Syntax?

[user001 via Digitalmars-d]

On Friday, 4 March 2016 at 02:09:25 UTC, Era Scarecrow wrote:

On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
Was just wondering why UFCS only works in one direction, that 
is why functions can be used as if it were part of a 
struct/class but not the other way around.


int dot;

float value = dot(a, b); // would be same as a.dot(b)
 // doesn't try to use local "int dot"


 Immediately looking at only that part of the code, i have to 
ask 'how the hell are you calling the int???'. Of course i can 
tell from your source dot is also a function in the vector.


 Considering dot could now shadow the variables or function 
names, it would quickly QUICKLY become annoying. A hierarchy of 
how the call is used plus the documentation of what it's 
obviously doing is a much better approach. Not to mention we've 
been using . and -> and * so long for accessing/de-referencing 
members that are attached so long that changing it is probably 
not an option.


You can say the same thing about how it is currently implemented.

int[] arr = [ 0, 1, 2, 3 ];

static map(alias F)(int[])
{
}

	writeln(arr.map!(a => a * 2)); // what does this mean array 
doesnt have a map function, does it use the local map function or 
the global one?


MAYBE if you were starting a language from scratch, but in this 
case i would firmly say no, this is ugly and confusing.


Well it could possibly be happening with C++17 so it's not that 
big of stretch to add it to an existing language, especially if 
that language already has it half implemented.

Re: Uniform Function Call Syntax?

[Era Scarecrow via Digitalmars-d]

On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
Was just wondering why UFCS only works in one direction, that 
is why functions can be used as if it were part of a 
struct/class but not the other way around.


int dot;

float value = dot(a, b); // would be same as a.dot(b)
 // doesn't try to use local "int dot"


 Immediately looking at only that part of the code, i have to ask 
'how the hell are you calling the int???'. Of course i can tell 
from your source dot is also a function in the vector.


 Considering dot could now shadow the variables or function 
names, it would quickly QUICKLY become annoying. A hierarchy of 
how the call is used plus the documentation of what it's 
obviously doing is a much better approach. Not to mention we've 
been using . and -> and * so long for accessing/de-referencing 
members that are attached so long that changing it is probably 
not an option. MAYBE if you were starting a language from 
scratch, but in this case i would firmly say no, this is ugly and 
confusing.

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

[deadalnix via Digitalmars-d]

On Thursday, 3 March 2016 at 20:31:51 UTC, Vladimir Panteleev 
wrote:
3. The first benchmark essentially measures the overhead of 
fiber context switching and nothing else


Ha yes, forgot that. Many JVM use fiber instead of thread 
internally.

Re: Forwarding varadic function arguments

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 4 March 2016 at 01:13:37 UTC, Ali Çehreli wrote:

On 03/03/2016 04:50 PM, Nicholas Wilson wrote:
> [...]

I think so. Also noting that C-style varargs can only work with 
fundamental types (Am I correct there? I am carrying this 
assumption from C++.), you may be happier with a 
template-parameter solution:


import std.stdio;

File f;

static this() {
f = File("hello_world.txt", "w");
}


//f is a File*
void fwrite(int line = __LINE__, Args...)(Args args)
{
f.write("/*",line,"*/ ");
f.write(args);
}

void main() {
fwrite("1 ","2\t","3\n");
}

Ali


The template works great.
Thanks!

Re: GSoC Next Steps

[Craig Dillabaugh via Digitalmars-d]

Haven't yet found email addresses for a few mentors (if you are 
available this year):


Iain Buclaw
Jacob Ovrum

Also, there is still time to sign up if you are a potential 
mentor.



For those of you interested in mentoring, the following is a good 
(and short) read on how students should be selected:


http://en.flossmanuals.net/GSoCMentoring/selecting-a-student/


Cheers,

Craig

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

[deadalnix via Digitalmars-d]

On Thursday, 3 March 2016 at 17:31:59 UTC, Andrei Alexandrescu 
wrote:

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

Andrei


A lot of data presented are kind of skewed. For instance, the 
synchronization costs across cores are done at 0% writes. It 
comes to no surprise that synchronizing read only data is cheap, 
but I don't think the author is justified in concluding that 
synchronization is cheap in the general case.


"new threads are created if all existing are busy but only up to 
MAX_INT threads" More likely only up to the point you run out of 
file handles.


You got to also note that context switches are measure on an 
opteron that has a 81 cycles iret (it is 330 on haswell) so that 
would explain why he find out they are way cheaper than expected. 
Opteron also have 2x64kb L1 cache, which probably reduce the 
cache trashing due to context switches at the cost of single 
threaded performances (which doesn't seems like a very good 
tradeoff for a CPU). In short, the CPU used is good for context 
switches, especially compared to modern intels.


Other result are not that surprising, like blocking IO being 
faster than non blocking one, the gain from async coming from 
multiplexing IO, not making every individual IO operation faster. 
Or, in server terms, it'll change your DB bound frontend to a CPU 
bound one and offload scaling on the DB. If you don't have 
another component to limiting your server, going async is not 
going to improves things (like if you are already CPU bound).

Uniform Function Call Syntax?

[user001 via Digitalmars-d]

Was just wondering why UFCS only works in one direction, that is 
why functions can be used as if it were part of a struct/class 
but not the other way around.


struct Vec3
{
float x;
float y;
float z;

float dot(Vec3 o)
{
return x * o.x + y * o.y + z * o.z;
}
}

int dot;
Vec3 a, b;

float value = dot(a, b); // would be same as a.dot(b)
 // doesn't try to use local "int dot"


It may not add as much value but I think it'd be a bit better as 
now you no longer have a global function with a simple name 
"dot". For mathematical purposes it is a lot easier to understand 
"dot(a, b)" than "a.dot(b)", at least in my opinion. Just curious 
that's all.

Re: Choosing arity of a template function

[Meta via Digitalmars-d]

On Thursday, 3 March 2016 at 21:06:12 UTC, Andrei Alexandrescu 
wrote:
Thanks! That will push introspection considerably further. I 
toggled auto-pull. -- Andrei


I made the simplest change possible to get it to compile, PR 
here[1]. It adds an extra allocation so any suggestions on 
eliminating that are welcome.


1. https://github.com/D-Programming-Language/dmd/pull/5496

Re: Forwarding varadic function arguments

[Ali Çehreli via Digitalmars-d-learn]

On 03/03/2016 04:50 PM, Nicholas Wilson wrote:
> //f is a File*
> void fwrite(int line = __LINE__)(...)
> {
>  f.write("/*",line,"*/ ");
>  f.write(_argptr); //prints e.g 7FFF5B055440
> }
> basically i want
> fwrite("1 ","2\t","3\n");
> to print
> /*7*/ 1 23
>
> do I have to iterate through _argptr

I think so. Also noting that C-style varargs can only work with 
fundamental types (Am I correct there? I am carrying this assumption 
from C++.), you may be happier with a template-parameter solution:


import std.stdio;

File f;

static this() {
f = File("hello_world.txt", "w");
}


//f is a File*
void fwrite(int line = __LINE__, Args...)(Args args)
{
f.write("/*",line,"*/ ");
f.write(args);
}

void main() {
fwrite("1 ","2\t","3\n");
}

Ali

Re: Why not use the address of the TypeInfo symbol as TypeInfo.toHash()?

[Yuxuan Shui via Digitalmars-d]

On Friday, 4 March 2016 at 00:42:28 UTC, Walter Bright wrote:

On 3/3/2016 4:29 PM, Yuxuan Shui wrote:
After linking each _DxxTypeInfo___initZ symbol should have 
a unique address,

so why are we using hash of type name as TypeInfo.toHash()?
I don't think this has anything to do with compacting GC. Is 
there something I'm

missing?


Because when working with DLLs (shared libraries) there may be 
more than one TypeInfo per type.


Hmmm, can we left _DxxTypeInfo___initZ undefined in the 
shared libraries?

Forwarding varadic function arguments

[Nicholas Wilson via Digitalmars-d-learn]

//f is a File*
void fwrite(int line = __LINE__)(...)
{
f.write("/*",line,"*/ ");
f.write(_argptr); //prints e.g 7FFF5B055440
}
basically i want
fwrite("1 ","2\t","3\n");
to print
/*7*/ 1 23

do I have to iterate through _argptr

Re: Why not use the address of the TypeInfo symbol as TypeInfo.toHash()?

[Walter Bright via Digitalmars-d]

On 3/3/2016 4:29 PM, Yuxuan Shui wrote:

After linking each _DxxTypeInfo___initZ symbol should have a unique address,
so why are we using hash of type name as TypeInfo.toHash()?
I don't think this has anything to do with compacting GC. Is there something I'm
missing?


Because when working with DLLs (shared libraries) there may be more than one 
TypeInfo per type.

Re: DigitalWhip

[artemalive via Digitalmars-d-announce]

On Saturday, 13 February 2016 at 19:19:46 UTC, Johan Engelen 
wrote:

On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote:


DigitalWhip is a performance benchmark of statically typed 
programming languages that
compile to native code: 
https://github.com/artemalive/DigitalWhip


Could you add the compiler versions to the outputted .txt file, 
e.g. `dmd --version`? (the example output files don't have it)


DigitalWhip 1.2.0 has been released:
https://github.com/artemalive/DigitalWhip/releases/tag/v1.2.0

Compiler version information is reported now.

Re: Why don't you use the Github issue system?

[deadalnix via Digitalmars-d]

On Thursday, 3 March 2016 at 23:54:15 UTC, cym13 wrote:

On Thursday, 3 March 2016 at 00:27:39 UTC, Walter Bright wrote:

On 3/2/2016 3:59 PM, Seb wrote:
I am just curious whether you have already considered moving 
from Bugzilla to

the Github issue system and where your current opinion is.


1. Bugzilla is working famously for us.

2. I've had occasion to use github issues, and was surprised 
by how lame it was compared to Bugzilla. There's no contest.


3. If Github goes dark, we still have our local complete 
copies of the git database. If Github issues goes dark, we 
lose it all. We control the Bugzilla database. This database 
is ABSOLUTELY CRITICAL to D's future, and not having a copy of 
it is absolutely unacceptable.


We'd still lose all pull requests though and all discussions 
about them. Does any, hmm, "pullrequestzilla" thing exist?


phabricator does a pretty good job (better than github in many 
cases IMO).

Why not use the address of the TypeInfo symbol as TypeInfo.toHash()?

[Yuxuan Shui via Digitalmars-d]

After linking each _DxxTypeInfo___initZ symbol should have a 
unique address, so why are we using hash of type name as 
TypeInfo.toHash()?


I don't think this has anything to do with compacting GC. Is 
there something I'm missing?

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

[Yuxuan Shui via Digitalmars-d-learn]

On Thursday, 3 March 2016 at 23:58:39 UTC, 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.


Oh, I get it. 'a is b' works for the results of typeid(). But not 
for duplicates of TypeInfo.


For example:

import std.stdio;
A a, b;
auto x = typeid(a), y = typeid(b);
writeln(x is y);
	auto xz = ((cast(ubyte 
*)x)[0..typeof(x).classinfo.init.length]).dup; //Evil

auto z = cast(typeof(x))(cast(void *)xz);
writeln(x is z); //false
writeln(x == z); //true

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

[Yuxuan Shui via Digitalmars-d-learn]

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.

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

[Adam D. Ruppe via Digitalmars-d-learn]

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.

Re: Why don't you use the Github issue system?

[cym13 via Digitalmars-d]

On Thursday, 3 March 2016 at 00:27:39 UTC, Walter Bright wrote:

On 3/2/2016 3:59 PM, Seb wrote:
I am just curious whether you have already considered moving 
from Bugzilla to

the Github issue system and where your current opinion is.


1. Bugzilla is working famously for us.

2. I've had occasion to use github issues, and was surprised by 
how lame it was compared to Bugzilla. There's no contest.


3. If Github goes dark, we still have our local complete copies 
of the git database. If Github issues goes dark, we lose it 
all. We control the Bugzilla database. This database is 
ABSOLUTELY CRITICAL to D's future, and not having a copy of it 
is absolutely unacceptable.


We'd still lose all pull requests though and all discussions 
about them. Does any, hmm, "pullrequestzilla" thing exist?

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

[Yuxuan Shui via Digitalmars-d-learn]

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

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

[tsbockman via Digitalmars-d]

On Thursday, 3 March 2016 at 03:22:02 UTC, Andrei Alexandrescu 
wrote:

On 03/02/2016 05:38 PM, tsbockman wrote:
Once you've familiarized yourself with the basics of using D, 
you can

read this:
http://wiki.dlang.org/Starting_as_a_Contributor
To help you get started contributing.


I see each section in that document is still broken down by OS, 
instead of the entire document being broken down by OS, in 
spite of my repeated demands that that be changed.


Somehow I doubt that "demands" will get you very far on an 
volunteer project...


Also, of the eleven sections listed under "Contents", only two 
are broken down by OS. For the other nine, the content is shared 
across all platforms.


I don't think your proposed re-org actually makes sense. This is 
likely part of why no one has done it for you yet.

Re: Error with associative array initializer DMD32 D Compiler v2.070.0

[Ali Çehreli via Digitalmars-d-learn]

On 03/03/2016 05:17 AM, Andrew Edwards wrote:
> On 3/3/16 7:01 PM, MGW wrote:
>> immutable long[string] aa = [
>> "foo": 5,
>> "bar": 10,
>> "baz": 2000
>> ];
>
> The only way this can be done outside the body of a function is if it is
> a manifest constant. This works:
>
> enum long[string] aa = [
>  "foo": 5,
>  "bar": 10,
>  "baz": 2000
> ];

With the caveat that 'aa' is a manifest constant, meaning that its 
values will be placed everywhere 'aa' appears in code. So, the following 
loop *creates* an associative array at avery iteration:


while (/* ... */) {
if (aa[s] == 5) {  // <-- oops :(
// ...
}
}

I think initializing it in a 'shared static this()' (or 'static this()') 
block is better:


immutable long[string] aa;

shared static this() {
aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
}

void main() {
assert(aa["foo"] == 5);
}

Ali

Re: Empty Associative Aarray Literal

[Ali Çehreli via Digitalmars-d-learn]

On 03/03/2016 02:06 PM, Jack Stouffer wrote:


This doesn't work either

string func(int a, int[int] b = int[int].init) {


Parentheses around int[int] works though. I don't know whether it's a bug.

string func(int a, int[int] b = (int[int]).init) {

Ali

Empty Associative Aarray Literal

[Jack Stouffer via Digitalmars-d-learn]

I want to have one of the parameters on a function be optional. 
The problem is, is that it's a AA and D does not seem to support 
empty AA literals. Observe:


string func(int a, int[int] b = []) {
return "mem1";
}

void main() {
func(1);
}

$ dmd test
test.d(8): Error: cannot implicitly convert expression ([]) of 
type void[] to int[int]


This doesn't work either

string func(int a, int[int] b = int[int].init) {
return "mem1";
}

void main() {
func(1);
}

[Issue 15751] New: atomicLoad doesn't return stable result if compiled with -profile

[via Digitalmars-d-bugs]

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

  Issue ID: 15751
   Summary: atomicLoad doesn't return stable result if compiled
with -profile
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: andrey.zheri...@gmail.com

atomicLoad() doesn't constantly return 0 in the following code if it's compiled
with -profile option:
=
import core.atomic;

int main()
{
shared int s = 0;
return atomicLoad(s);
}
=

Compiler: DMD32 D Compiler v2.070.2
Compile command: dmd test.d -oftest_p -profile
Test command:
pass=0; fail=0;
for i in $(seq 1 100);
do
./test_p.exe && pass=$((pass+1)) || fail=$((fail+1));
done;
echo pass=$pass fail=$fail
Test command output (example):
pass=89 fail=11


Even adding "atomicStore(s, 0);" right before atomicLoad doesn't guarantee the
result:
pass=95 fail=5

--

Re: Choosing arity of a template function

[Meta via Digitalmars-d]

On Thursday, 3 March 2016 at 21:06:12 UTC, Andrei Alexandrescu 
wrote:
Thanks! That will push introspection considerably further. I 
toggled auto-pull. -- Andrei


I would recommend cancelling that as it's currently failing on 
Linux and FreeBSD.

Re: Choosing arity of a template function

[Andrei Alexandrescu via Digitalmars-d]

On 03/03/2016 02:54 PM, Meta wrote:

On Friday, 26 February 2016 at 23:09:52 UTC, Andrei Alexandrescu wrote:

So, what's an elegant solution to this? I looked up std.traits but
nothing seems to help. (Tried arity, no avail.)


There's this[1] PR which implements exactly what you want, but it's
currently not passing the auto-tester.

1. https://github.com/D-Programming-Language/dmd/pull/5201


Thanks! That will push introspection considerably further. I toggled 
auto-pull. -- Andrei

Re: Argon: an alternative parser for command-line arguments

[Andrei Alexandrescu via Digitalmars-d-announce]

On 03/03/2016 04:09 AM, Markus Laker wrote:

On Thursday, 3 March 2016 at 01:52:11 UTC, Chris Wright wrote:

You might want to take a minute to shill it here. What's great about it?


OK.  :-)

[snip]

Very nice! I think we should adopt some of these ideas for std.getopt as 
well. -- Andrei

Re: Argon: an alternative parser for command-line arguments

[Markus Laker via Digitalmars-d-announce]

On Thursday, 3 March 2016 at 15:08:37 UTC, Jacob Carlborg wrote:
Does it support some longer documentation for the flags, i.e. 
"git status -h" vs "git status --help"?


Yes.  You can give an option a description, like this:

// ...
uint nr_doors;
// ...
Named("doors", nr_doors, 0) ("number of doors").AddRange(1, 4);

If you do this, the user has a nice, short name to type:

--doors 2

But the description will be used in error messages ("The number 
of doors must be between 1 and 4") and in auto-generated syntax 
summaries ("--doors ").


For a positional parameter, the user never types the name, and so 
you just do this:


Pos("number of doors", nr_doors, 0).AddRange(1, 4);

Then the syntax element we auto-generate will be "doors>" and error messages will be the same as for the equivalent 
named option.


Markus

Re: Mallocator

[Erik Smith via Digitalmars-d]

On Thursday, 3 March 2016 at 20:31:47 UTC, Meta wrote:

On Thursday, 3 March 2016 at 20:16:55 UTC, Erik Smith wrote:


The later works and qualifying the allocator member variable 
shared seems to solve the issue.  Example:


struct A(T) {
alias Allocator = T;
shared Allocator allocator;
this(string url="") {
allocator = Allocator();
void *p1 = cast(void*)(allocator.allocate(1024));
//void p2[] = allocator.allocate(1024); // ICE
}
}


Does this still ICE when you write it as `void[] p2 = 
allocator.allocate(1024)`?


No.  :)

Re: Argon: an alternative parser for command-line arguments

[Markus Laker via Digitalmars-d-announce]

On Thursday, 3 March 2016 at 09:33:38 UTC, Johannes Pfau wrote:
The rest of this list sounds quite good, but please reconsider 
automatically opening files: 
https://media.ccc.de/v/32c3-7130-the_perl_jam_2


I guess the scenario can't happen in D as our open file methods 
won't execute programs (!) but still


I think we're safe:

msl@james:~/d/argon$ perl -wE 'open my $fh, "ls |" or die; print 
for (<$fh>)[0..2]'

argon
argon.d
argon.html
msl@james:~/d/argon$ rdmd --eval='try auto f = std.stdio.File("ls 
|", "r"); catch (Exception e) e.msg.writeln'

Cannot open file `ls |' in mode `r' (No such file or directory)
msl@james:~/d/argon$

Of course, if you can demonstrate a vulnerability, I'll certainly 
fix it.


Markus

Re: Argon: an alternative parser for command-line arguments

[Markus Laker via Digitalmars-d-announce]

On Thursday, 3 March 2016 at 04:48:42 UTC, Jason White wrote:
I was also dissatisfied with std.getopt and wrote a command 
line argument parser (competition!):


https://github.com/jasonwhite/darg

Though it's not quite feature-complete yet, it does everything 
I need it to. It uses compile-time introspection to fill out 
the fields of a struct. It can also generate the help and usage 
strings at compile-time.


I've not explored D's UDAs yet, so it took a moment to click, but 
I think that's very clever.  There's an obvious run-time benefit 
to doing things like that.


Markus

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

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 3 March 2016 at 17:31:59 UTC, Andrei Alexandrescu 
wrote:

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

Andrei


Not an expert on the subject, but FWIW:

1. This is from 2008
2. Seems to be highly specific to Java
3. The first benchmark essentially measures the overhead of fiber 
context switching and nothing else
4. If I tried to write DFeed using this model, it would have been 
a complete trainwreck (there is too much global state and 
interaction between components to reason about using locks).

Re: Mallocator

[Meta via Digitalmars-d]

On Thursday, 3 March 2016 at 20:16:55 UTC, Erik Smith wrote:


The later works and qualifying the allocator member variable 
shared seems to solve the issue.  Example:


struct A(T) {
alias Allocator = T;
shared Allocator allocator;
this(string url="") {
allocator = Allocator();
void *p1 = cast(void*)(allocator.allocate(1024));
//void p2[] = allocator.allocate(1024); // ICE
}
}


Does this still ICE when you write it as `void[] p2 = 
allocator.allocate(1024)`?

Re: Mallocator

[Erik Smith via Digitalmars-d]

On Thursday, 3 March 2016 at 19:32:40 UTC, Brian Schott wrote:

On Thursday, 3 March 2016 at 19:01:52 UTC, Erik Smith wrote:
I get the error "allocate is not callable using a non-shared 
object" and I'm not sure how to resolve it.


Are you calling `Mallocator.allocate()` or 
`Mallocator.instance.allocate()`?


The later works and qualifying the allocator member variable 
shared seems to solve the issue.  Example:


struct A(T) {
alias Allocator = T;
shared Allocator allocator;
this(string url="") {
allocator = Allocator();
void *p1 = cast(void*)(allocator.allocate(1024));
//void p2[] = allocator.allocate(1024); // ICE
}
}

A!Mallocator a;


However, this seems bad because it assumes that all allocators 
are shared.  It appears, however that the qualifier can be 
attached to the type so maybe there is some meta-programming 
tricks that can be used:


alias Allocator = shared T;

I'm not sure if I'm on the right track.  Note also the ICE in the 
example above.


erik

Re: Unable to instantiate template with same name as function

[ag0aep6g via Digitalmars-d-learn]

On 03.03.2016 07:12, Shriramana Sharma wrote:

string ta(string s) { return s ~ "1"; }
template ta(string s) { enum ta = ta(s); }


In `ta(s)` here, `ta` is the enum itself again. It's similar to `int x = 
x;`. Can't do that, of course.


Add a leading dot to refer to the module level `ta` symbols instead: 
`enum ta = .ta(s);`.

Re: A suggestion for modules names / sharing code between projects

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 3 March 2016 at 20:05:03 UTC, ag0aep6g wrote:

[1] https://en.wikipedia.org/wiki/Reverse_domain_name_notation


LOL at the code section of that page.

Re: A suggestion for modules names / sharing code between projects

[ag0aep6g via Digitalmars-d]

On 03.03.2016 07:53, Sebastien Alaiwan wrote:

However, using global package names means you're relying on the library
providers to avoid conflicts, in their package names, although they
might not even know each other. Which basically implies to always put
your name / company name in your package name, like "import
alaiwan.lib_algo.array2d;", or "import apple.lib_algo.array2d".
Or rename my "lib_algo" to something meaningless / less common, like
"import diamond.array2d" (e.g Derelict, Pegged, imaged, etc.).


Yeah, that's a thing. For published libraries one should choose a unique 
name.


I think reverse domain name notation [1] is a convention for exactly 
that. As far as I know, not many D projects do that, though, if any at 
all. But it would be a way out if collisions become a problem.


Also, dub/code.dlang.org plays a role here, as people may assume that a 
name is free as long as it's not on the dub list. This works well when 
dub is indeed the one place to go for libraries. If it isn't, then 
things may get messy.



If, unfortunately, I happen to run into a conflict, i.e my project uses
two unrelated libraries sharing a name for their top-level namespace,
there's no way out for me, right?
(Except relying on shared objects to isolate symbols)


Yeah, as far as I can tell, you would have to change the name of one of 
the libraries, and update all related module declarations and imports.



[1] https://en.wikipedia.org/wiki/Reverse_domain_name_notation

[Issue 15738] Problem with std.experimental.ndslice empty()

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Windows |All
   Severity|normal  |enhancement

--

[Issue 15738] Problem with std.experimental.ndslice empty()

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

 CC||ilyayaroshe...@gmail.com

--- Comment #1 from Илья Ярошенко  ---
This is feature, empty is empty!0, so it checks only first dimension. In
addition, this  is very important for optimization reasons. emptyAny method may
be added for desirable behavior.

--

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

[Ali Çehreli via Digitalmars-d]

On 03/03/2016 09:31 AM, Andrei Alexandrescu wrote:

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

Andrei


Another interesting architecture is LMAX Disruptor:

  https://lmax-exchange.github.io/disruptor/

Ali

Re: Choosing arity of a template function

[Meta via Digitalmars-d]

On Friday, 26 February 2016 at 23:09:52 UTC, Andrei Alexandrescu 
wrote:
So, what's an elegant solution to this? I looked up std.traits 
but nothing seems to help. (Tried arity, no avail.)


There's this[1] PR which implements exactly what you want, but 
it's currently not passing the auto-tester.


1. https://github.com/D-Programming-Language/dmd/pull/5201

Re: An argument for removing monitors from Java

[Meta via Digitalmars-d]

On Thursday, 3 March 2016 at 16:54:40 UTC, Andrei Alexandrescu 
wrote:

http://blog.jooq.org/2016/01/12/if-java-were-designed-today-the-synchronizable-interface/

There was work on removing the default monitor from Object, 
what is the status of it?


Thanks,

Andrei


https://github.com/D-Programming-Language/dmd/pull/3547

Martin has a plan outlined in the comments.

Re: Compile time performance for metaprogramming is somewhat inconsistent

[Steven Schveighoffer via Digitalmars-d]

On 3/2/16 9:33 PM, maik klein wrote:

On Thursday, 3 March 2016 at 02:26:09 UTC, cym13 wrote:

On Thursday, 3 March 2016 at 02:03:01 UTC, maik klein wrote:

Consider the following code

void main()
{
import std.stdio;
import std.range: iota, join;
import std.algorithm.iteration: map;
import std.conv: to;
import std.meta: aliasSeqOf, staticMap, AliasSeq;
enum types = "AliasSeq!(" ~ iota(0,1).map!(i =>
to!string(i)).join(",") ~ ")";
alias t = AliasSeq! (mixin(types));
//alias t1 = aliasSeqOf!(iota(0, 1));
}

[...]


As often, compiler-version-flags please?


default dub.sdl and `dub build` with dmd v2.070


Try dub build -b release

-Steve

Re: Code security: "auto" / Reason for errors

[Steven Schveighoffer via Digitalmars-d]

On 3/3/16 2:03 AM, Daniel Kozak via Digitalmars-d wrote:

Dne 3.3.2016 v 03:39 Jack Stouffer via Digitalmars-d napsal(a):

 Dynamic arrays are reference types in D;

No, they are value types, but mimic reference types in some cases


The case that you pass something by reference, and change what that 
reference is pointing at, is not a special quality of arrays. They are 
most definitely reference types.


What gets people confused is that arrays will change what they reference 
in surprising ways. Appending is one such case. Increasing length is 
another.


-Steve

Re: Why don't you use the Github issue system?

[Patience via Digitalmars-d]

On Thursday, 3 March 2016 at 00:27:39 UTC, Walter Bright wrote:

On 3/2/2016 3:59 PM, Seb wrote:
I am just curious whether you have already considered moving 
from Bugzilla to

the Github issue system and where your current opinion is.


1. Bugzilla is working famously for us.



Is it Kardashian famous?

2. I've had occasion to use github issues, and was surprised by 
how lame it was compared to Bugzilla. There's no contest.


3. If Github goes dark, we still have our local complete copies 
of the git database. If Github issues goes dark, we lose it 
all. We control the Bugzilla database. This database is 
ABSOLUTELY CRITICAL to D's future, and not having a copy of it 
is absolutely unacceptable.


I don't know, Both Khloe and Kim Kardashian went dark and they 
seem to be ok?


Seriously... Sorry!

Re: Mallocator

[Brian Schott via Digitalmars-d]

On Thursday, 3 March 2016 at 19:01:52 UTC, Erik Smith wrote:
I get the error "allocate is not callable using a non-shared 
object" and I'm not sure how to resolve it.


Are you calling `Mallocator.allocate()` or 
`Mallocator.instance.allocate()`?

Mallocator

[Erik Smith via Digitalmars-d]

Just a question on Mallocator and shared.  My code does a lot of 
non-GC heap allocation (malloc) for buffers, so I reached for 
Mallocator as a starting point. I propagate an Allocator type 
generically through my structs, but it is defaulted to Mallocator.


After checking with the docs & TDPL, I'm still a bit confused on 
how to deal with the shared functions in Mallocator and what the 
effect of shared functions is in this context (see code below). I 
get the error "allocate is not callable using a non-shared 
object" and I'm not sure how to resolve it.  I'm not sure if I 
should cast shared away (or how to make that work).  The docs say 
malloc/free is thread safe as far as D is concerned, so 
synchronized doesn't seem to be the answer. Forking Mallocator 
without shared solved the issue temporarily.


Also Allocators are, in general, not copyable so I should 
propagate them around as references (or pointers in struct 
members), correct?


struct Mallocator{
...
@trusted @nogc nothrow
void[] allocate(size_t bytes) shared
{
import core.stdc.stdlib : malloc;
if (!bytes) return null;
auto p = malloc(bytes);
return p ? p[0 .. bytes] : null;
}

@system @nogc nothrow
bool deallocate(void[] b) shared
{
import core.stdc.stdlib : free;
free(b.ptr);
return true;
}
...
}

Re: A suggestion for modules names / sharing code between projects

[Sebastien Alaiwan via Digitalmars-d]

On Thursday, 3 March 2016 at 08:39:51 UTC, Laeeth Isharc wrote:

On Thursday, 3 March 2016 at 06:53:33 UTC, Sebastien Alaiwan
If, unfortunately, I happen to run into a conflict, i.e my 
project uses two unrelated libraries sharing a name for their 
top-level namespace, there's no way out for me, right?

(Except relying on shared objects to isolate symbols)


See modules doc page off dlang.org.
import io = std.stdio;
void main()
{ io.writeln("hello!"); // ok, calls std.stdio.writeln
std.stdio.writeln("hello!"); // error, std is undefined
writeln("hello!"); // error, writeln is undefined
}
Thansk, but I was talking about module name collisions, e.g if my 
project uses two unrelated libraries, both - sloppily - defining 
a module called "geom.utils".


Can this be worked-around using renamed imports?

How is "import myUtils = geom.utils" going to know which of both 
"geom.utils" I'm talking about?
As far as I understand, _module_ renaming at import is rather a 
tool for defining shorthands, than for disambiguation.


I agree that it might not be a problem in practice - just wanting 
to make sure I'm not missing something.

Re: std.database

[Chris Wright via Digitalmars-d]

On Thu, 03 Mar 2016 15:50:04 +, Piotrek wrote:

> On Thursday, 3 March 2016 at 01:49:22 UTC, Chris Wright wrote:
>> If you're trying to connect to a SQL database or a document database,
>> as I'd expect for something called "std.database"
> 
> The thing is I strongly encourage to not reserve std.database for
> external database clients and even what is more limiting to SQL ones
> only.
> 
>> , it's a pretty terrible API:
>>  * No index scans, lookups, or range queries.
> 
> Indexes can be supported by strings and CTFE, can't they?
> e.g.
> filter!q{item.elements.length < 10 && item.model == "Sport"}

You were a bit vague before. I interpreted you as saying "just offer a 
range and an array-like API, and then you can use it with std.algorithm". 
But if you meant to offer an API that is similar to std.algorithm and 
also array-like, that's more feasible.

You're still left with the task of transpiling D to SQL.

This model does not work with CouchDB.

You must avoid using std.algorithm and std.range functions assiduously 
because they would offer terrible performance.

>>  * No support for complex queries.
> 
> Not sure what you mean by complex queries. Also I think the API allows
> arbitrary complex queries.

Aggregates, especially with joins. Computed fields.

>>  * No support for joins.
> 
> Can be done by @attributes or other linking functionality between
> DbCollections.

With attributes, you need users to define aggregate types instead of just 
using Row and the like. That's ORM territory. At a previous job I 
maintained an internal BI site that exposed 50-100 different queries, 
each with their own set of result fields. We didn't want to use ORM 
there; it would have been cumbersome and inappropriate.

Also, that assumes that you will always want a join when querying a 
table. I maintained an application once, using ORM, in which we sometimes 
wanted an eager join and sometimes wanted a lazy one. This posed a 
nontrivial performance impact.

I'm not sure ORM would be a candidate for phobos.

>>  * No support for projections.
> 
> You mean something like referring to part of the item's fields? I see no
> problem here.

Let me point you to the existence of the TEXT and BLOB datatypes. They 
can each hold 2**32 bytes of data in MySQL.

I'm not splitting those off into a separate table to port my legacy 
database to your API. I'm not dragging in multiple megabytes of data in 
every query.

If you're going full ORM, you can add lazy fields. That adds complexity. 
It's also inefficient when I know in advance that I need those fields.

>>  * No support for transactions.
>>  * If you add support for transactions, you'll crash all the
>> time because the transactions got too large, thanks to the full table
>> scan mentality.
> 
> Isn't it just the "index support" case?

You didn't mention transactions at all in the initial outline. After 
that, yes, in large portion index support addresses this. DB-side 
aggregation also helps.

>>  * In your implementation, updates must bring every affected
>> row over the wire, then send back the modified row.
> 
> In my implementation there is no wire (that's why I call it embedded).
> However I thought we talk about API and not particular implementation. I
> don't see how this API excludes RPC. Query strings (e.g. SQL) can be
> provided in old fashioned way.

I'm running a website and decide that, with the latest changes, existing 
users need to get the new user email. So I write:

  UPDATE users SET sent_join_email = FALSE;
  -- ok; 1,377,212 rows affected

Or I'm using your database system. If it uses std.algorithm, I have to 
iterate through the users list, pulling each row into my process's memory 
from the database server, and then I have to write everything back to the 
database server.

Depending on the implementation, it's using a database cursor or issuing 
a new query for every K results. If it's using a database cursor, those 
might not be valid across transaction boundaries. I'm not sure. If they 
aren't, you get a large transaction, which causes problems.

If your database system instead offers a string-based API similar to 
std.algorithm, you might be able to turn this into a single query, but 
it's going to be a lot of work for you.

>>  * Updates affect an entire row. If one process updates one
>> field in a row and another one updates a different field, one of those
>> writes gets clobbered.
> 
> I think this is just a "must have" for any db engine. I don't see how it
> applies to the proposed API other than any implementation of db engine
> has to handle it properly.

Without transactions, MySQL supports writing to two different columns in 
two different queries without those writes clobbering each other.

That's handling it properly.

> When I say DbCollection should behave similar to an ordinal array I
> don't mean it should be an ordinal array.
> 
>>  * The API assumes a total ordering for each DbCollection. This
>> is not valid.
> 
> I don't know 

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

[Brad Anderson via Digitalmars-d]

On Thursday, 3 March 2016 at 17:31:59 UTC, Andrei Alexandrescu 
wrote:

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

Andrei


Related to this, I watched a talk about user-level threads by 
another Google engineer awhile back (also named Paul but not the 
same person).


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

It's been awhile so I may have this a bit wrong but as I remember 
it the gist was that OSes don't have enough information for 
efficient scheduling and context switching of threads but if the 
OS lets the application handle it the context switching cost 
drops significantly (down to roughly 200ns).


I came across it while following some Rust development which was 
a very interesting read:

https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html

It's a bit over two years old now so I'm not sure what path Rust 
took.

Re: Why don't you use the Github issue system?

[Nick Sabalausky via Digitalmars-d]

On 03/02/2016 07:57 PM, sigod wrote:

On Thursday, 3 March 2016 at 00:27:39 UTC, Walter Bright wrote:

3. If Github goes dark, we still have our local complete copies of the
git database. If Github issues goes dark, we lose it all. We control
the Bugzilla database. This database is ABSOLUTELY CRITICAL to D's
future, and not having a copy of it is absolutely unacceptable.


This annoys me a lot in all repository hosting services.


Hear hear!

Re: Argon: an alternative parser for command-line arguments

[Nick Sabalausky via Digitalmars-d-announce]

On 03/02/2016 02:50 PM, Markus Laker wrote:

https://github.com/markuslaker/Argon

Let me know if you do something interesting with it.

Markus



Reminds me of one I used years ago for C#: I like the approach, it's a 
good one. Getopt by comparison, while very good, always seemed like a 
kludge to accomplish a similar thing without the benefit of user 
attributes (which D lacked at the time).

Re: std.database

[Erik Smith via Digitalmars-d]

On Thursday, 3 March 2016 at 17:03:58 UTC, Kagamin wrote:

On Thursday, 3 March 2016 at 15:53:28 UTC, Erik Smith wrote:
auto r = db.connection().statement("select from t").range();  
// nouns


db.execute("select from t").range();
`range` is probably ok.
Or
auto connection = db.createConnection();
connection.execute("select from t").range();

auto r = db.getConnection().getStatement("select from 
t").getRange();  // verbs


Getters must be actually nouns, but these are not getters, but 
factory methods: createConnection, createStatement, probably 
low level and/or private.


Good point.   I will track this as a design option to debate.


db.execute("select from t").reader; //row range
db.execute("select from t").get!long; //scalar
db.execute("select from t"); //non-query


More good options (the 3rd one is there).   Also at the value 
access level there are several options to consider: v.get!long, 
v.as!long, v.to!long, etc.


On the other hand execute can simply return the reader with 
extra getter for scalar

result. Just don't do stuff until it's iterated. Is it possible?
auto rows = db.execute("select * from t");


I'm hedging a bit on this because there are other capabilities 
that need to be introduced that might present a problem.   
Another issue is that this might conflict with the notion of a 
container and the use of opSlice.  Great feedback though and I'm 
tracking it.


erik

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

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 3 March 2016 at 17:31:59 UTC, Andrei Alexandrescu 
wrote:

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


Slide decks are so unbelievably bad at conveying information.


But, looking through it, I think I agree. There's a reason why I 
stick with my cgi.d - using a simple process/thread model is so 
much easier and actually performs fine. fork() is very cheap on 
modern Linux and if you use it, the kernel takes care of 
basically all the hard stuff for you!

Re: std.database

[Erik Smith via Digitalmars-d]

On Thursday, 3 March 2016 at 16:08:03 UTC, Piotrek wrote:
I agree with you we need database manipulation in Phobos. 
However modules like db, gui, xml or similar are too much work 
for a one developer. And as you can see from time to time there 
apears someone with its own vision.


That's why, long time ago, I suggested DIP73 
(http://wiki.dlang.org/DIP73) so the collaborative work would 
be controlled by the D community (or the D foundation). But I 
am aware that there is no agreement nor resources for that.


I agree that we (as a community) should work on common and 
effective APIs. Maybe when D foundation is big enough...



Your process proposal (DIP73) was helpful and gives me a better 
perspective on the standardization process. Thanks for 
referencing that Piotrek.  You are right that areas like this are 
too much work for one developer.  The only leverage I might have 
is a lot of  familiarity working with many of the native C client 
interfaces and experience implementing higher level interfaces on 
top.  That and is also a lot of existing work to draw on that can 
inform the design.  Also, my sense is that while there is less 
process for standardization in D at present, the rate at which 
progress can occur should be much higher (compared to ISOCCP, for 
example).   The last thing I want, however, is to get something 
accepted into std.experimental that is highly contentious or of 
subpar quality.

Re: std.database

[Kagamin via Digitalmars-d]

On the other hand execute can simply return the reader with extra 
getter for scalar result. Just don't do stuff until it's 
iterated. Is it possible?


auto rows = db.execute("select * from t");

A very interesting slide deck comparing sync and async IO

[Andrei Alexandrescu via Digitalmars-d]

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

Andrei

Re: Lilypond Contributor's Guide - an excellent example to emulate

[Iain Buclaw via Digitalmars-d]

On 3 Mar 2016 6:02 pm, "Andrei Alexandrescu via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On 03/03/2016 11:57 AM, Andrei Alexandrescu wrote:
>>
>> This is one beautiful guide for contributors:
>> http://lilypond.org/doc/v2.19/Documentation/contributor/index. A
>> Lilypond advanced user pointed it to me as a good example of community
>> management.
>>
>> Would be awesome if we expanded our small contributor guides on the wiki
>> into a coherent document like this. It's an incremental process so not a
>> big upfront commitment. Any takers?
>
>
> As an aside: the document structure is also quite nice. Does anyone know
what document generator was used? -- Andrei

http://lilypond.org/doc/v2.19/Documentation/contributor/index_abt#SEC_About

"This document was generated by *GUB* on*February 28, 2016* using *texi2html
1.82 *."

Iain.

[Issue 15750] New: net/isemail uses lots of redundant helper methods

[via Digitalmars-d-bugs]

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

  Issue ID: 15750
   Summary: net/isemail uses lots of redundant helper methods
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

In my cleanup task I saw that std.net.isemail seems to do some redundant effort
and defines those methods as its own helper:

- substr
- max
- compareFirstN
- grep
- get

There is `backPop`!

All of these methods (at least max, substr) feel general purpose enough that
they should existent in a general fashion.

Btw for max: doesn't work get with ranges, but there is a pending pull request.
https://github.com/D-Programming-Language/phobos/pull/4019

--

Re: std.database

[Kagamin via Digitalmars-d]

Other options:
db.execute("select from t").reader; //row range
db.execute("select from t").get!long; //scalar
db.execute("select from t"); //non-query

Re: std.database

[Kagamin via Digitalmars-d]

On Thursday, 3 March 2016 at 15:53:28 UTC, Erik Smith wrote:
auto r = db.connection().statement("select from t").range();  
// nouns


db.execute("select from t").range();
`range` is probably ok.
Or
auto connection = db.createConnection();
connection.execute("select from t").range();

auto r = db.getConnection().getStatement("select from 
t").getRange();  // verbs


Getters must be actually nouns, but these are not getters, but 
factory methods: createConnection, createStatement, probably low 
level and/or private.

Re: Lilypond Contributor's Guide - an excellent example to emulate

[Andrei Alexandrescu via Digitalmars-d]

On 03/03/2016 11:57 AM, Andrei Alexandrescu wrote:

This is one beautiful guide for contributors:
http://lilypond.org/doc/v2.19/Documentation/contributor/index. A
Lilypond advanced user pointed it to me as a good example of community
management.

Would be awesome if we expanded our small contributor guides on the wiki
into a coherent document like this. It's an incremental process so not a
big upfront commitment. Any takers?


As an aside: the document structure is also quite nice. Does anyone know 
what document generator was used? -- Andrei

Lilypond Contributor's Guide - an excellent example to emulate

[Andrei Alexandrescu via Digitalmars-d]

This is one beautiful guide for contributors: 
http://lilypond.org/doc/v2.19/Documentation/contributor/index. A 
Lilypond advanced user pointed it to me as a good example of community 
management.


Would be awesome if we expanded our small contributor guides on the wiki 
into a coherent document like this. It's an incremental process so not a 
big upfront commitment. Any takers?



Andrei

An argument for removing monitors from Java

[Andrei Alexandrescu via Digitalmars-d]

http://blog.jooq.org/2016/01/12/if-java-were-designed-today-the-synchronizable-interface/

There was work on removing the default monitor from Object, what is the 
status of it?


Thanks,

Andrei

Re: std.database

[Piotrek via Digitalmars-d]

On Wednesday, 2 March 2016 at 17:13:32 UTC, Erik Smith wrote:
There are a number of areas where this design is an improvement 
over DDBC: ease-of-use, better resource management (no scope, 
no GC), phobos compatibility, to name a few.  There is a lot 
more that needs to be added to make it standards grade.


I agree with you we need database manipulation in Phobos. However 
modules like db, gui, xml or similar are too much work for a one 
developer. And as you can see from time to time there apears 
someone with its own vision.


That's why, long time ago, I suggested DIP73 
(http://wiki.dlang.org/DIP73) so the collaborative work would be 
controlled by the D community (or the D foundation). But I am 
aware that there is no agreement nor resources for that.


Your engine project is interesting.  I think there is common 
ground in the interfaces in the two projects, particularly in 
how the interface for the results might work. I will look more 
closely at the details to see what might be workable.


erik


I agree that we (as a community) should work on common and 
effective APIs. Maybe when D foundation is big enough...


Piotrek

Re: std.database

[John Colvin via Digitalmars-d]

On Thursday, 3 March 2016 at 11:16:03 UTC, Dejan Lekic wrote:

On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
I'm back to actively working on a std.database specification & 
implementation.  It's still unstable, minimally tested, and 
there is plenty of work to do, but I wanted to share an update 
on my progress.


I suggest you call the package stdx.db - it is not (and may not 
become) a standard package, so `std` is out of question. If it 
is supposed to be *proposed* as standard package, then `stdx` 
is good because that is what some people have used in the past 
(while others used the ugly std.experimental. for the same 
purpose).


I humbly believe that this effort **must** be collaborative as 
such package is doomed to fail if done wrong.


std.experimental, ugly or not, is what is in phobos.
See std.experimental.allocator, std.experimental.logger and 
std.experimental.ndslice

Re: std.database

[Erik Smith via Digitalmars-d]

On Thursday, 3 March 2016 at 15:07:43 UTC, Kagamin wrote:
Also member names: methods are named after verbs, you use 
nouns. Method `next` is ambiguous: is the first row the next 
row? `fetch` or `fetchRow` would be better.


Those are actually internal methods not intended for the 
interface user.  They might get exposed in some way to the 
implementer so I'll have to consider this issue.


However, If I apply what you are suggesting to the the interface 
methods, it would look like this:


auto r = db.connection().statement("select from t").range();  // 
nouns


auto r = db.getConnection().getStatement("select from 
t").getRange();  // verbs


Maybe there is a more creative way to change the names rather 
than prepending with get (let me know if you have suggestions), 
but the nouns seem cleaner to me.  I'll have to look at more 
phobos code to get a better sense of the conventions.  Also range 
will be replaced by an opSlice operator.


erik

Re: std.database

[Piotrek via Digitalmars-d]

On Thursday, 3 March 2016 at 01:49:22 UTC, Chris Wright wrote:
If you're trying to connect to a SQL database or a document 
database, as I'd expect for something called "std.database"


The thing is I strongly encourage to not reserve std.database for 
external database clients and even what is more limiting to SQL 
ones only.



, it's a pretty terrible API:
 * No index scans, lookups, or range queries.


Indexes can be supported by strings and CTFE, can't they?
e.g.
filter!q{item.elements.length < 10 && item.model == "Sport"}


 * No support for complex queries.


Not sure what you mean by complex queries. Also I think the API 
allows arbitrary complex queries.



 * No support for joins.


Can be done by @attributes or other linking functionality between 
DbCollections.



 * No support for projections.


You mean something like referring to part of the item's fields?
I see no problem here.


 * No support for transactions.
 * If you add support for transactions, you'll crash all the 
time because
the transactions got too large, thanks to the full table scan 
mentality.


Isn't it just the "index support" case?

 * In your implementation, updates must bring every affected 
row over the

wire, then send back the modified row.


In my implementation there is no wire (that's why I call it 
embedded). However I thought we talk about API and not particular 
implementation. I don't see how this API excludes RPC. Query 
strings (e.g. SQL) can be provided in old fashioned way.


 * Updates affect an entire row. If one process updates one 
field in a
row and another one updates a different field, one of those 
writes gets

clobbered.


I think this is just a "must have" for any db engine. I don't see 
how it applies to the proposed API other than any implementation 
of db engine has to handle it properly.


When I say DbCollection should behave similar to an ordinal array 
I don't mean it should be an ordinal array.


 * The API assumes a total ordering for each DbCollection. This 
is not valid.


I don't know what you mean here. Example would be good.

 * If there are multiple rows that compare as equals, there's 
no way to

update only one of them in your implementation.
 * In your implementation, updating one row is a ϴ(N) 
operation. It still
costs ϴ(N) when the row you want to update is the first one in 
the collection.


I'm still not sure if you are referring to my implementation or 
hypothetical API. To be clear: my current implementation is still 
proof of concept and surly *unfinished*. And in case you refer to 
my implementation I plan to support O(1), O(log n) and O(n) 
access patterns with its "rights and duties".


Cheers,
Piotrek

[Issue 15749] New: allow `with` on an expression

[via Digitalmars-d-bugs]

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

  Issue ID: 15749
   Summary: allow `with` on an expression
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

The motivation is stuff like this:

zip(iota(10), iota(10, 20))
.map!(t => Tuple!(int, "a", int, "b)(t))
.map!(t => with(t) a + b);

which, short of having some proper tuple unpacking syntax (that would be so, so
good), is nicer than the current

.map!((t) { with(t) return a + b; });

that might seem like a small change, but I'm having a hard time selling D and
functional programming to scientists with all the heavyweight syntax, they are
spoiled by the inefficient but neat-looking numpy model.

--

[Issue 15748] inconsistent symbols generated by dmd vs ldc

[via Digitalmars-d-bugs]

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

--- Comment #1 from Sobirari Muhomori  ---
Single underscore is standard mangling for D symbols, most platforms take it
literally, mac traditionally adds extra underscore to all symbols.

--

Re: Problem running code examples in the Home page

[CookiesOfLove via Digitalmars-d]

On Thursday, 3 March 2016 at 14:21:15 UTC, Meta wrote:

On Thursday, 3 March 2016 at 14:19:32 UTC, Meta wrote:

On Thursday, 3 March 2016 at 05:24:26 UTC, Mike Parker wrote:
Works for me. It took a couple of seconds before the output 
appeared, but it did appear.


I just tried to run the "floating point rounding" example in 
Chrome. I got a "service temporarily unavailable" message.


http://imgur.com/1tZtJWv


Ah, this would be why:

XMLHttpRequest cannot load http://dpaste.dzfl.pl/request/. No 
'Access-Control-Allow-Origin' header is present on the 
requested resource. Origin 'http://dlang.org' is therefore not 
allowed access. The response had HTTP status code 403.


Yes that's the problem. It will work with normal "HTTP:"!

In fact I think all the "HTTPS" is a mess here, for example, I 
can access the main page "dlang.org" with "HTTPS", but if I try 
to access the forums from the link there I get: 
NET::ERR_CERT_INVALID, so in the end I need to go back to normal 
"HTTP" to access the forums.


Matheus.

Re: std.range: Lockstep vs. Zip

[Alex Parrill via Digitalmars-d-learn]

On Wednesday, 2 March 2016 at 08:51:07 UTC, Manuel Maier wrote:

Hi there,

I was wondering why I should ever prefer std.range.lockstep 
over std.range.zip. In my (very limited) tests std.range.zip 
offered the same functionality as std.range.lockstep, i.e. I 
was able to iterate using `foreach(key, value; 
std.range.zip(...)) {}` which, according to the docs, is what 
std.range.lockstep was supposed to be designed for. On top of 
that, std.range.zip is capable of producing a 
RandomAccessRange, but std.range.lockstep only produces 
something with opApply.


Cheers
zip uses the InputRange protocol, and bundles up all the values 
in a Tuple.


lockstep uses the opApply protocol, and doesn't bundle the values.

Lockstep is useful for foreach loops since you don't need to 
unpack a tuple, but zip is compatible with all of the std.range 
and std.algorithm functions that take ranges.

Re: std.database

[Kagamin via Digitalmars-d]

Also member names: methods are named after verbs, you use nouns. 
Method `next` is ambiguous: is the first row the next row? 
`fetch` or `fetchRow` would be better.

Re: Argon: an alternative parser for command-line arguments

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-03-02 20:50, Markus Laker wrote:

https://github.com/markuslaker/Argon

Let me know if you do something interesting with it.


Does it support some longer documentation for the flags, i.e. "git 
status -h" vs "git status --help"?


--
/Jacob Carlborg

Re: GSOC Idea.

[Rikki Cattermole via Digitalmars-d]

On 04/03/16 3:09 AM, Marco wrote:

On Thursday, 3 March 2016 at 09:29:38 UTC, Johannes Pfau wrote:

Am Thu, 3 Mar 2016 16:14:24 +1300
schrieb Rikki Cattermole :

[...]



The arduino Due uses a Cortex M3, so arduino could mean ARM or AVR.
GDC can target AVR devices with minimal changes. The main problem
is that you really can't use druntime / typeinfo on such small devices
and that some features (e.g. simply using structs) require
TypeInfo. I have some outdated commits here to disable the TypeInfo
stuff:
https://github.com/D-Programming-microD/GDC/commits/microD

[...]


Thank you for your detailed answers. Now I do understand that working
with D and arduino maybe be out of my capability. I may now decide to
work on porting a parser generator library to phobos. I do know that
pegged is a parser generator in D. Can this new project be easier? I am
also quite interested in parsing, so that would be a very good
experience for me.

Sorry for being such a newbie, I hope you understand my willingness to
learn.


You may want to stay clear of CTFE which is how pegged works primarily.

Re: Compile time performance for metaprogramming is somewhat inconsistent

[maik klein via Digitalmars-d]

On Thursday, 3 March 2016 at 11:40:29 UTC, John Colvin wrote:

On Thursday, 3 March 2016 at 02:03:01 UTC, maik klein wrote:

Consider the following code

void main()
{
import std.stdio;
import std.range: iota, join;
import std.algorithm.iteration: map;
import std.conv: to;
import std.meta: aliasSeqOf, staticMap, AliasSeq;
enum types = "AliasSeq!(" ~ iota(0,1).map!(i => 
to!string(i)).join(",") ~ ")";

alias t = AliasSeq! (mixin(types));
//alias t1 = aliasSeqOf!(iota(0, 1));
}

't' compiles on my machine in ~3.5 seconds while 't1' needs ~1 
minute to compile. It seems that mixins are just way more 
performant than template instantiations. Any ideas why? What 
causes the slowdown and what can I improve?


What happens if you add a few extra branches to 
std.meta.aliasSeqOf, e.g. 
https://github.com/D-Programming-Language/phobos/commit/5d2cdf103bd697b8ff1a939c204dd2ed0eec0b59


Only a linear improvement but maybe worth a try?


I have tried the same thing in general and stuff like this is 
always a huge improvement.


In this case it goes down from ~60 seconds to ~3.8 seconds. I 
have done the same thing with my compile time map function, which 
gave me a drastic improvement.


I think recursion is just really bad in general for compile time 
stuff, for example your version


alias t1 = aliasSeqOf!(iota(0, 1));

compiles in 3.8 seconds and uses roughly 600mb of ram while

alias t1 = aliasSeqOf!(iota(0, 2));

compiles in 10.2 seconds and uses 1.9gb ram.

The mixin version is always the fastest but it also consumes way 
more memory and explodes before 20k elements

Re: std.database

[Erik Smith via Digitalmars-d]

I suggest you call the package stdx.db - it is not (and may not 
become) a standard package, so `std` is out of question. If it 
is supposed to be *proposed* as standard package, then `stdx` 
is good because that is what some people have used in the past 
(while others used the ugly std.experimental. for the same 
purpose).


I humbly believe that this effort **must** be collaborative as 
such package is doomed to fail if done wrong.


I totally agree that it must be collaborative and community 
driven.  I failed to add the proposed qualifier in this thread - 
sorry about that.   Right now I'm just trying to put together 
enough of a substantive design to be worthy of  discussion.   
While I'm presenting a design the way I think it should work, I'm 
definitely asking for feedback and especially opposition to any 
aspect of it.   My package name choice is just an example, the 
package name would have to be changed to whatever the "D 
committee" thinks is appropriate.


erik

Re: Problem running code examples in the Home page

[Meta via Digitalmars-d]

On Thursday, 3 March 2016 at 14:19:32 UTC, Meta wrote:

On Thursday, 3 March 2016 at 05:24:26 UTC, Mike Parker wrote:
Works for me. It took a couple of seconds before the output 
appeared, but it did appear.


I just tried to run the "floating point rounding" example in 
Chrome. I got a "service temporarily unavailable" message.


http://imgur.com/1tZtJWv


Ah, this would be why:

XMLHttpRequest cannot load http://dpaste.dzfl.pl/request/. No 
'Access-Control-Allow-Origin' header is present on the requested 
resource. Origin 'http://dlang.org' is therefore not allowed 
access. The response had HTTP status code 403.

Re: Problem running code examples in the Home page

[Meta via Digitalmars-d]

On Thursday, 3 March 2016 at 05:24:26 UTC, Mike Parker wrote:
Works for me. It took a couple of seconds before the output 
appeared, but it did appear.


I just tried to run the "floating point rounding" example in 
Chrome. I got a "service temporarily unavailable" message.


http://imgur.com/1tZtJWv

Re: Unable to instantiate template with same name as function

[cym13 via Digitalmars-d-learn]

On Thursday, 3 March 2016 at 08:58:25 UTC, Shriramana Sharma 
wrote:

Hello people and thanks for your replies.

Jonathan M Davis via Digitalmars-d-learn wrote:

You can't overload a function and an eponymous template like 
that. They need to have distinct names.


Why is it not possible for the overload to happen? After all, 
the compiler should be able to identify which to use by seeing 
whether it is followed by ! or (), no?


Note that parentheses are optional when no argument is provided. 
Most functions that you use from phobos are really template 
functions for example  but most of the time you don't use them 
with a template argument. So no, the compiler can't make the 
distinction.

Re: GSOC Idea.

[Marco via Digitalmars-d]

On Thursday, 3 March 2016 at 09:29:38 UTC, Johannes Pfau wrote:

Am Thu, 3 Mar 2016 16:14:24 +1300
schrieb Rikki Cattermole :

[...]


The arduino Due uses a Cortex M3, so arduino could mean ARM or 
AVR.
GDC can target AVR devices with minimal changes. The main 
problem
is that you really can't use druntime / typeinfo on such small 
devices

and that some features (e.g. simply using structs) require
TypeInfo. I have some outdated commits here to disable the 
TypeInfo

stuff:
https://github.com/D-Programming-microD/GDC/commits/microD

[...]


Thank you for your detailed answers. Now I do understand that 
working with D and arduino maybe be out of my capability. I may 
now decide to work on porting a parser generator library to 
phobos. I do know that pegged is a parser generator in D. Can 
this new project be easier? I am also quite interested in 
parsing, so that would be a very good experience for me.


Sorry for being such a newbie, I hope you understand my 
willingness to learn.

[Issue 15721] free error when calling Mallocator.dispose on interfaces

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

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

--

Re: std.xml2 (collecting features)

[Tobias Müller via Digitalmars-d]

Adam D. Ruppe  wrote:
> On Wednesday, 2 March 2016 at 06:59:49 UTC, Tobias Müller wrote:
>> What's the usecase of DOM outside of browser 
>> interoperability/scripting? The API isn't particularly nice, 
>> especially in languages with a rich type system.
> 
> I find my extended dom to be very nice, especially thanks to D's 
> type system. I use it for a lot of things: using web apis, html 
> scraping, config file stuff, working on my own documents, and 
> even as my web template system.
> 
> Basically, dom.d made xml cool to me.

Sure, some kind of DOM is certainly useful. But the standard XML-DOM isn't
particularly nice.
What's the point of a linked list style interface when you have ranges in
the language?

Re: Error with associative array initializer DMD32 D Compiler v2.070.0

[Andrew Edwards via Digitalmars-d-learn]

On 3/3/16 7:01 PM, MGW wrote:

immutable long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];


The only way this can be done outside the body of a function is if it is 
a manifest constant. This works:


enum long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];

Release D 2.070.2

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.070.2.

http://dlang.org/download.html

This unplanned point release fixes just a single issue over 2.070.2, see
the changelog for more details.

http://dlang.org/changelog/2.070.2.html

-Martin

Re: Problem running code examples in the Home page

[cym13 via Digitalmars-d]

On Thursday, 3 March 2016 at 10:14:43 UTC, Dominikus Dittes 
Scherkl wrote:

On Thursday, 3 March 2016 at 05:24:26 UTC, Mike Parker wrote:

On Thursday, 3 March 2016 at 05:09:17 UTC, mahdi wrote:
When I click on "Run" I have the text "Running..." inside the 
box and nothing happens. I don't know if this is a problem 
with the code or the website but can someone please take a 
look.


This is the first view of a newcomer on the D language so 
better to be as polished as possible.


Works for me. It took a couple of seconds before the output 
appeared, but it did appear.


Hmm. There aew different code examples. Sure they all actually 
work? (espacially: which one was it that didn't work?)


I think we're down to only two snippets now and both work for me 
(webkit-based browser)

Re: Compile time performance for metaprogramming is somewhat inconsistent

[Stefan Koch via Digitalmars-d]

On Thursday, 3 March 2016 at 02:03:01 UTC, maik klein wrote:

Consider the following code

void main()
{
import std.stdio;
import std.range: iota, join;
import std.algorithm.iteration: map;
import std.conv: to;
import std.meta: aliasSeqOf, staticMap, AliasSeq;
enum types = "AliasSeq!(" ~ iota(0,1).map!(i => 
to!string(i)).join(",") ~ ")";

alias t = AliasSeq! (mixin(types));
//alias t1 = aliasSeqOf!(iota(0, 1));
}

[...]


Templates are by default more work then mixins.
If you want me to I can elaborate on that.

Re: Template mixins and struct constructors

[Adrian Matoga via Digitalmars-d-learn]

On Wednesday, 2 March 2016 at 20:39:57 UTC, Adam D. Ruppe wrote:

On Wednesday, 2 March 2016 at 12:27:04 UTC, Adrian Matoga wrote:

Is it by design or is it a bug?
And, if it is by design, what is the reason for that?


That's by design. It allows you to override names from a 
template mixin like inheritance but no runtime cost.


Read my tip of the week here to see how it works and how you 
can combine ctors from a mixin:


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


Ah, I was on vacation at that time so that's why I don't remember 
reading it. :)


Thanks! It's a nice workaround but it's, well, a workaround. It 
leaks the internals of the template mixin and a potential API 
user would have to remember two additional quirks when using it. 
I guess I'll try a different approach, initializing the mixed in 
members later with a function.

Re: Compile time performance for metaprogramming is somewhat inconsistent

[John Colvin via Digitalmars-d]

On Thursday, 3 March 2016 at 02:03:01 UTC, maik klein wrote:

Consider the following code

void main()
{
import std.stdio;
import std.range: iota, join;
import std.algorithm.iteration: map;
import std.conv: to;
import std.meta: aliasSeqOf, staticMap, AliasSeq;
enum types = "AliasSeq!(" ~ iota(0,1).map!(i => 
to!string(i)).join(",") ~ ")";

alias t = AliasSeq! (mixin(types));
//alias t1 = aliasSeqOf!(iota(0, 1));
}

't' compiles on my machine in ~3.5 seconds while 't1' needs ~1 
minute to compile. It seems that mixins are just way more 
performant than template instantiations. Any ideas why? What 
causes the slowdown and what can I improve?


What happens if you add a few extra branches to 
std.meta.aliasSeqOf, e.g. 
https://github.com/D-Programming-Language/phobos/commit/5d2cdf103bd697b8ff1a939c204dd2ed0eec0b59


Only a linear improvement but maybe worth a try?

Re: Unable to instantiate template with same name as function

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, March 03, 2016 14:28:25 Shriramana Sharma via Digitalmars-d-learn 
wrote:
> Hello people and thanks for your replies.
>
> Jonathan M Davis via Digitalmars-d-learn wrote:
> > You can't overload a function and an eponymous template like that. They
> > need to have distinct names.
>
> Why is it not possible for the overload to happen? After all, the compiler
> should be able to identify which to use by seeing whether it is followed by
> ! or (), no?

It's not legal to overload a variable and a function either. Only functions
can overload functions. One symbol can shadow another if one is in a smaller
scope and both aren't local variables (e.g. one is at module scope whereas
the other is a local variable), but symbols at the same scope level can only
overload if they're functions or templates with differing template
constraints, and even then, they have to be the same thing (not one a
function and the other a template). That's just the way the language is, and
it does avoid certain classes of bugs.

> > > Now, that being said, I don't understand why
> >
> > you'd need to do anything with a template for CTFE in this case. Just
> > write the function and then call it in a context that requires a
> > compile-time result, and it should work. e.g.
>
> OK but say I have a function which returns an array. If I use enum to CTFE
> its result, then it is repeatedly included explicitly in all places it is
> used, thereby using more memory. So I want to do:
>
> string s = ta!"s";
>
> Obviously, I can still do the different name approach, so it brings us back
> to the question as to why the name can't be re-used.

If you want a function to be called at compile time, then its result has to
be assigned to something that's evaluated at compile time - like an enum.
So, you can't do something like

string s = ta("s");

and have it execute at compile time, and yes, having

enum s = ta("s)";

and using s all over the place will result in an allocation each time that s
is used. However, you can combine the two and avoid that problem. e.g.

enum e = ta("s");
string s = e;

The ta is run at compile time, and it's only evaluated once. In general,
it's considered good practice to make something a function when you want to
call it at either compile time or runtime. Then if you want to force it to
be evaluated at compile time, just assign it to an enum and use that, even
if you then assign it to a variable so that it doesn't get evaluated
multiple times. But if you really want a template in addition to the
function for whatever reason, then just name the template version something
different. It may not be quite what you want, but it works just fine.

- Jonathan M Davis

Re: Error with associative array initializer DMD32 D Compiler v2.070.0

[mahdi via Digitalmars-d-learn]

On Thursday, 3 March 2016 at 10:35:50 UTC, MGW wrote:

The citation from https://dlang.org/spec/hash-map.html

Static Initialization of AAs


immutable long[string] aa = [
  "foo": 5,
  "bar": 10,
  "baz": 2000
];

unittest
{
assert(aa["foo"] == 5);
assert(aa["bar"] == 10);
assert(aa["baz"] == 2000);
}

Judging by the text, it is static initialization, during 
compilation.


You have to put that definition inside body of a function (a 
declaration). it should not be placed inside module's root level 
code.

Re: std.database

[Dejan Lekic via Digitalmars-d]

On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
I'm back to actively working on a std.database specification & 
implementation.  It's still unstable, minimally tested, and 
there is plenty of work to do, but I wanted to share an update 
on my progress.


I suggest you call the package stdx.db - it is not (and may not 
become) a standard package, so `std` is out of question. If it is 
supposed to be *proposed* as standard package, then `stdx` is 
good because that is what some people have used in the past 
(while others used the ugly std.experimental. for the same 
purpose).


I humbly believe that this effort **must** be collaborative as 
such package is doomed to fail if done wrong.