Re: about const and immutable (again)
On 11.10.2011 03:29, Andrei Alexandrescu wrote: On 10/10/11 5:55 PM, Don wrote: On 06.10.2011 20:56, Steven Schveighoffer wrote: On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan wrote: I see. Thanks for the detailed answer. I should clarify one point, I realized I am somewhat inaccurate on the reason the type is set to immutable(dchar). In fact, nobody actually wrote the immutable(dchar) function, it's just that the element type is immutable(dchar). However, the reasons why someone would want to create a function that takes an immutable(dchar) function are as I stated -- so you don't accidentally change the value. That seems like the discussed-and-discarded 'final' storage class for parameters. But this is worse. It has an *enormous* cost. Walter and I have agreed for a long time that upon function calls with by-value passing, there should be some simple transforms done: 1. If a parameter has no indirections, qual(T) becomes T. 2. qual(T[]) becomes qual(T)[]. 3. qual(T*) becomes qual(T)*. This would improve many aspects of the language. Walter never got to implementing it, but I'm bringing this up in case one of the wonderful compiler contributors would want to take it up. Again, I have reasons to believe Walter would approve of the change. Thanks, Andrei Excellent! That'd be a huge improvement.
Re: Static arrays, typeof and IFTI?
On 10.10.2011 08:58, Gor Gyolchanyan wrote: > There is a huge difference between a static and a dynamic array. > Dynamic array is an indirected type (objects of that type are pointers > to the actual data), while static arrays are PODs (directly refers to > the data). > Dynamic arrays are always size_t.sizeof * 2 bytes long, while static > arrays are typeof(T[0]).sizeof * T.length bytes long. That makes > static arrays expensive to move around. Making the array literals > static by default would mean unnecessary copying most of the time. In > those few cases, where it is necessary, you can explicitly make them > static arrays. Actually, my problem is not so much the choice of the "default" but that there is no easy way to work around it: I couldn't find any way to force a variable or function argument to be of static array type without explicitly stating the length. In an assignment like int[3] myvar = [1,2,3,4] the compiler will complain. However there does not seem to be any way to state int[...whatever...] myvar = [1,2,3,4]; enum N = typeof(myvar).init.length; and let the compiler deduce that N==4. Even worse for template arguments. My first idea (inspired by C++, also suggested by kennytm) template(T,int N) myfunc(T[N] arg) does not work in D and I could not find any alternative way to allow writing myfunc([1,2,3,4]) and determine the length of the static array at compile time.
Re: [std.database]
Johann MacDonagh wrote: Maybe "Database" should be an abstract class rather than an interface? That's how ADO.net does it: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.aspx Why "Database" instead of PGConnection, MySqlConnection, SQLiteConnection, etc. ? And of course base SqlConnection.
Re: Matrix-type-friendly syntax and more
"Robert Jacques" wrote: > On Mon, 10 Oct 2011 08:46:05 -0400, kennytm wrote: >> Don wrote: >>> On 10.10.2011 04:41, kenji hara wrote: 2011/10/10 bearophile: > So is this: > y[$-6, 0..$:2] > > Translated like this? > y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2)) I have no thought about it. I'm not sure that the additional stepping is really useful, but I think adding it into syntax is not impossible -- it might not conflict with associative array literal. Kenji Hara >>> >>> Personally, I think that since strided operations are so inefficient, >>> they should remain ugly. >> >> Slicing an nD static array is just as in/efficient as strides. That said, >> I'm still -1 on having a..b:c since (1) I see no practical need for strides >> and (2) even if we striding it doesn't need to be in the form a..b:c, e.g. >> arr[stride(0..$, 2)]. >> > > Regarding (1), from a computer vision/graphics perspective, being able to > only operate on the red channel, for example, is very nice. And I use > striding all the time in my CUDA code, but that's not as applicable in D, > yet. Striding tends to be most useful for working with packed data of some > kind. Why not use a 'Color' struct?
Re: Support of dmd2 in Waf
On Mon, Oct 10, 2011 at 7:09 PM, Russel Winder wrote: > Not sure about CMake, I have tried is with D. > CMake for D2 limps along. At last check, it passed regression with 2.054 but may need some TLC for 2.055. http://code.google.com/p/cmaked2/wiki/GettingStarted
Re: [std.database]
Another dumb idea.
I was thinking about Johathan's idea about std.sql. What if we did
something like the following - let the compiler do the work.
enum Disposition { ... }
Disposition Insert(string database, S)(out ulong ra, S s, string table)
if (is(S == struct))
{ ... }
Disposition Insert(string database)
(out ulong ra, Variant[string] vaa, string table) { ... }
Disposition PrepareInsert(string database, S)(S s) if (is(S == struct))
{ ... }
Disposition PrepareInsert(string database)(Variant[string] vaa)
{ ... }
Disposition ExecInsert(string database, S)
(out ulong ra, S s) if (is(S == struct))
Disposition ExecInsert(string database)
(out ulong ra, Variant[string] vaa)
{ ... }
Disposition Update(string database, string whereClause, S, T...)
(out ulong ra, S s, string table, T args) if (is(S == struct)) { ... }
Disposition Update(string database, string whereClause, T...)
(out ulong ra, Variant[string] vaa, string table, T args)
{ ... }
...
Disposition Delete(string database, string whereClause, S)
(out ulong ra, S s) if (is(S == struct)) { ... }
Disposition Delete(string database, string whereClause)
(Variant[string] vaa) { ... }
...
Disposition SelectSequence(string database, SIN, SOUT)
(SIN sin, SOUT sout, string table)
if (is(SIN == struct) && is(SOUT == struct)) { ... }
Disposition SelectSequence(string database)
(Variant[string] vaain, Variant[string] vaaout, string table)
{ ... }
Disposition SelectResultSet(string database, SIN, SOUT)
(out ulong rc, SIN sin, SOUT sout, string table)
if (is(SIN == struct) && is(SOUT == struct))
{ ... }
Disposition SelectResultSet(string database)
(out ulong rc, Variant[string] vaain, Variant[string] vaaout,
string table)
{ ... }
...
...
This would sidestep the need for a lowest common denominator approach.
The compiler would generate code for a specified database, and could
generate SQL with appropriate parameter markers and escaping. and the
code to execute it.
If some operation wasn't supported it could do a static assert.
This would be on top of a set of modules that provided nitty-gritty
operations for each database - database oriented modules as opposed to
SQL oriented. If the compile time SQL option didn't work for your app,
you'd fall back for specifics on these.
Could it be done?
Steve
Re: Matrix-type-friendly syntax and more
On Mon, 10 Oct 2011 08:46:05 -0400, kennytm wrote: Don wrote: On 10.10.2011 04:41, kenji hara wrote: 2011/10/10 bearophile: So is this: y[$-6, 0..$:2] Translated like this? y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2)) I have no thought about it. I'm not sure that the additional stepping is really useful, but I think adding it into syntax is not impossible -- it might not conflict with associative array literal. Kenji Hara Personally, I think that since strided operations are so inefficient, they should remain ugly. Slicing an nD static array is just as in/efficient as strides. That said, I'm still -1 on having a..b:c since (1) I see no practical need for strides and (2) even if we striding it doesn't need to be in the form a..b:c, e.g. arr[stride(0..$, 2)]. Regarding (1), from a computer vision/graphics perspective, being able to only operate on the red channel, for example, is very nice. And I use striding all the time in my CUDA code, but that's not as applicable in D, yet. Striding tends to be most useful for working with packed data of some kind.
Re: [std.database]
On Mon, 10 Oct 2011 23:08:30 -0400, Johann MacDonagh wrote:
> I've written up a prototype for a "LINQ" style database querying
> mechanism in D (read about "LINQ to SQL" if you've never heard of it).
> Legally speaking, it has very little to do with LINQ, but the concept is
> similar.
>
> Basically, it allows you to write code like this:
>
> auto x = new SqliteConnection("mydata.db");
>
> foreach(y; x.MyTable.where("someField > 10")) {
>// y is a wrapper around Variant[string] with some opDispatch magic
>writeln(to!string(y.MyField));
>writeln(to!int(y.SomeOtherField));
> }
>
> Of course, "MyTable" is handled via opDispatch. The SqliteConnection
> doesn't care what tables are available in "mydata.db". You can also do
> much more. Such as:
>
> x.MyTable.startAt(20).limit(10).where("blah").select("somefield",
> "sometingElse");
>
> In addition, you should be able to do something like this (don't think
> I've implemented this yet):
>
> x.MyTable.select!MyStruct();
>
> Doing that would return a range of MyStruct structs, rather than the
> wrapper around Variant[string] like above. This would allow you to do:
>
> auto x = new SqliteConnection("mydata.db");
>
> foreach(y; x.MyTable.where("someField > 10").select!MyStruct()) {
>// y is a wrapper around Variant[string] with some opDispatch magic
>writeln(y.MyField); // No more needing the to! template
>writeln(y.SomeOtherField);
> }
>
> Of course, this would allow you to find typos in field names at compile
> time (provided your struct is kept in sync with the database), and means
> you don't have to go through the Variant[string] for all your database
> accesses.
>
> To implement this, a database "driver" would have to have a shared
> opDispatch implementation (perhaps done with a mixin or maybe with an
> abstract class), and it would have to be able to translate the "query"
> into a SQL query that works with their underlying database system.
>
> I have a working prototype somewhere that works with Sqlite, and it
> seems to work very nicely. Clearly a system like this shows off what D
> can do out of the box (opDispatch), and makes writing scripts very easy.
>
> Let me know if this is something you think should be part of
> std.database (or whatever we end up calling it).
I was lying in bed last night and realized that Variant[string] was
attractive for various purposes. It's kind of like a Javascript Object.
That and the possibilities with strictly name structs creates some
interesting possibilities.
Re: [std.database]
On Mon, 10 Oct 2011 11:09:34 -0400, Andrei Alexandrescu wrote: On 10/10/11 7:01 AM, Steve Teale wrote: [snip] That's a bug in std.variant. Large structs should be supported automatically by using an indirection and dynamic allocation. For what it's worth, my improved Variant proposal, does do that. (i.e. it fixes the bug)
Re: [std.database]
On Mon, 10 Oct 2011 23:08:30 -0400, Johann MacDonagh
wrote:
On 10/8/2011 2:43 AM, Steve Teale wrote:
I use this title at Andrei's suggestion, and repeat his idea that it be used
as a prefix for discussions as we navigate toward a design. Unless there is
resistance to the idea, I will on the job of implementing whatever we decide
is appropriate. I am retired, and have the time to do it.
It seems that every man, and possibly his dog, has a private implementation
for at least a favorite DB, so we should have plenty of material to build on.
At this point I would like to get responses from those who feel they are
likely to contribute to the design through to completion.
I'd also like to get a feel for the magnitude of the task, so I'd like to ask
what database systems you think should be supported.
I have started a github account, and will put my mysqld stuff there shortly,
then you can kick me out if you don't like what you see.
Steve
I've written up a prototype for a "LINQ" style database querying
mechanism in D (read about "LINQ to SQL" if you've never heard of it).
Legally speaking, it has very little to do with LINQ, but the concept is
similar.
Basically, it allows you to write code like this:
auto x = new SqliteConnection("mydata.db");
foreach(y; x.MyTable.where("someField > 10"))
{
// y is a wrapper around Variant[string] with some opDispatch magic
writeln(to!string(y.MyField));
writeln(to!int(y.SomeOtherField));
}
For what it's worth, my Variant proposal has this kind of opDispatch magic
built-in.
Re: Garbage collection book
> > > The books have different authors. I don't suppose someone has both and can > comment on the differences? I have the older version as well, but wouldn't > mind picking up this new one if it brings enough new stuff to the table. Perhaps you can take a look at the ToC here http://www.amazon.co.uk/gp/product/toc/1420082795/ref=dp_toc?ie=UTF8&n=266239
Re: std.database design suggestion
On 10/10/2011 7:19 AM, bls wrote:
if(args[0] == "MySQL")
factory = new MySQLFactory();
else
factory = new PostreSQLFactory();
Perhaps my design pattern knowledge is a bit shaky (it is), but isn't
the point of a factory to give it hints about what you want to create,
and it decides how to do it? Something like:
Database d = Factory.gimmeAConnection("MySql", "server", "username", "pwd");
Re: [std.database]
On 10/8/2011 2:43 AM, Steve Teale wrote:
I use this title at Andrei's suggestion, and repeat his idea that it be used
as a prefix for discussions as we navigate toward a design. Unless there is
resistance to the idea, I will on the job of implementing whatever we decide
is appropriate. I am retired, and have the time to do it.
It seems that every man, and possibly his dog, has a private implementation
for at least a favorite DB, so we should have plenty of material to build on.
At this point I would like to get responses from those who feel they are
likely to contribute to the design through to completion.
I'd also like to get a feel for the magnitude of the task, so I'd like to ask
what database systems you think should be supported.
I have started a github account, and will put my mysqld stuff there shortly,
then you can kick me out if you don't like what you see.
Steve
I've written up a prototype for a "LINQ" style database querying
mechanism in D (read about "LINQ to SQL" if you've never heard of it).
Legally speaking, it has very little to do with LINQ, but the concept is
similar.
Basically, it allows you to write code like this:
auto x = new SqliteConnection("mydata.db");
foreach(y; x.MyTable.where("someField > 10"))
{
// y is a wrapper around Variant[string] with some opDispatch magic
writeln(to!string(y.MyField));
writeln(to!int(y.SomeOtherField));
}
Of course, "MyTable" is handled via opDispatch. The SqliteConnection
doesn't care what tables are available in "mydata.db". You can also do
much more. Such as:
x.MyTable.startAt(20).limit(10).where("blah").select("somefield",
"sometingElse");
In addition, you should be able to do something like this (don't think
I've implemented this yet):
x.MyTable.select!MyStruct();
Doing that would return a range of MyStruct structs, rather than the
wrapper around Variant[string] like above. This would allow you to do:
auto x = new SqliteConnection("mydata.db");
foreach(y; x.MyTable.where("someField > 10").select!MyStruct())
{
// y is a wrapper around Variant[string] with some opDispatch magic
writeln(y.MyField); // No more needing the to! template
writeln(y.SomeOtherField);
}
Of course, this would allow you to find typos in field names at compile
time (provided your struct is kept in sync with the database), and means
you don't have to go through the Variant[string] for all your database
accesses.
To implement this, a database "driver" would have to have a shared
opDispatch implementation (perhaps done with a mixin or maybe with an
abstract class), and it would have to be able to translate the "query"
into a SQL query that works with their underlying database system.
I have a working prototype somewhere that works with Sqlite, and it
seems to work very nicely. Clearly a system like this shows off what D
can do out of the box (opDispatch), and makes writing scripts very easy.
Let me know if this is something you think should be part of
std.database (or whatever we end up calling it).
Re: [std.database]
On 10/9/2011 2:22 PM, Andrei Alexandrescu wrote:
On 10/9/11 11:54 AM, Adam Ruppe wrote:
The way I'd do it is:
interface Database {
// support shared functions here, and other stuff useful enough to
// warrant emulation
}
class Postgres : Database {
// implement the interface, of course, but also all other postgres
// specific stuff
}
When you go to use it, if you're happy with the basics, declare
Databases.
If you need something special, use Postgres objects.
Makes sense. JDBC does that, too.
Andrei
Maybe "Database" should be an abstract class rather than an interface?
That's how ADO.net does it:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.aspx
This is architecturally a little "cleaner", because whatever Postgres
database class we have is a "database" class at heart, not a class that
implements a database interface.
Also, perhaps some actual code that would exist in the abstract class
would be a call to Close() in the destructor. That way you can declare a
database connection on the stack, open it, do some stuff, allow it to
leave scope, and clean up that resource without a timeout on the server end.
Re: Support of dmd2 in Waf
On Tue, 2011-10-11 at 00:38 +, Bernard Helyer wrote: > If you don't mind me asking, why? I wasn't sure whether to answer this in this public and recorded medium, but here goes anyway: You would have to ask him why his actions, but he gave me the following impression before ceasing to answer any of my emails: I am merely an analyst and trainer, not a developer, and therefore a person of no consequence, and certainly not a person able to contribute to Waf development. That because I contribute to SCons, I am out to destroy Waf and should be excluded from Waf society to not allow me to spread sedition. Despite this, I like and use Waf in the contexts where I consider it to have winning USPs. I also like and use SCons in contexts where I consider it to have winning USPs. I also mention both in my Python courses. To bring us back on topic: D support in SCons and Waf does need improving. Not sure about CMake, I have tried is with D. I have set up an infrastructure to allow contributions to SCons D support evolution based on a Mercurial repository on BitBucket, https://bitbucket.org/russel/scons_dmd_new. Any and all constructive contributions most welcome. A particular issue is that only DMD is supported really, so gdc, ldc, etc. support needs testing and work. Also the actual test harness for the tool needs work. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: about const and immutable (again)
On 10/10/11 5:55 PM, Don wrote: On 06.10.2011 20:56, Steven Schveighoffer wrote: On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan wrote: I see. Thanks for the detailed answer. I should clarify one point, I realized I am somewhat inaccurate on the reason the type is set to immutable(dchar). In fact, nobody actually wrote the immutable(dchar) function, it's just that the element type is immutable(dchar). However, the reasons why someone would want to create a function that takes an immutable(dchar) function are as I stated -- so you don't accidentally change the value. That seems like the discussed-and-discarded 'final' storage class for parameters. But this is worse. It has an *enormous* cost. Walter and I have agreed for a long time that upon function calls with by-value passing, there should be some simple transforms done: 1. If a parameter has no indirections, qual(T) becomes T. 2. qual(T[]) becomes qual(T)[]. 3. qual(T*) becomes qual(T)*. This would improve many aspects of the language. Walter never got to implementing it, but I'm bringing this up in case one of the wonderful compiler contributors would want to take it up. Again, I have reasons to believe Walter would approve of the change. Thanks, Andrei
Slightly modified array copies
New features (like transitive immutability) give birth to new appetites, like
the following one, that weren't present before.
Sometimes I have an array of immutable things, like a string (and maybe I can't
use an array of chars because I will have to use the strings as associative
array keys), and I have to generate slightly modified arrays.
I need to keep both the original and the modified version, so in theory there
is no need to go into undefined behaviour converting doing a const->mutable
operation.
Here is a way to do it now, this is save and clean and easy, but it contains an
unnecessary copy. This is acceptable often, but it's not acceptable if similar
code is in critical path that needs to be fast:
char[] aux = text.dup; // not nothrow still
aux[i] = 'A';
aux[j] = 'B';
text = aux.idup;
This is a bit better, there is only a single copy. In practice this is rather
safe code (assumeUnique sets aux to empty string), but D type system doesn't
help you a lot here:
char[] aux = text.dup; // not nothrow still
aux[i] = 'A';
aux[j] = 'B';
text = assumeUnique(aux);
In the latest versions of D this is an alternative solution that avoids
punching any kind of hole in the D type system:
static string temp_(immutable string d, size_t i1, char c1,
size_t i2, char c2) pure {
char[] aux = d.dup; // not nothrow
aux[i1] = c1;
aux[i2] = c2;
return aux;
}
data = temp_(data, i, 'A', j, 'B');
But that't long, and slow.
Note that today you can't write this, despite the semantics is similar:
static void temp_(ref string d, size_t i1, char c1,
size_t i2, char c2) pure {
char[] aux = d.dup; // not nothrow
aux[i1] = c1;
aux[i2] = c2;
d = aux;
}
temp_(data, i, 'A', j, 'B');
In languages designed for mostly immutable data structures (like Clojure,
Haskell) the immutable data structures offer ways to safely (and efficiently!)
create slightly modified versions of them. This is a common need.
This is a possible syntax to create a slightly modified copy of an array of
immutables, keeping full type system safety (time ago I have found a similar
syntax in another language, maybe Ada, I don't remember well):
text = text.idup(i: 'A', j: 'B');
-
Partially related, are you able to tell me if this enhancement request of mine
is valid?
http://d.puremagic.com/issues/show_bug.cgi?id=6783
That enhancement request asks for code like this too to be accepted, but I am
not sure it is legit:
immutable(int[]) foo(in int[] x) pure {
return new int[1];
}
void main() {}
Bye,
bearophile
Re: Support of dmd2 in Waf
On Mon, 10 Oct 2011 17:52:48 +0100, Russel Winder wrote: > The project lead for Waf has declared me persona non grata and banned me > from any and all aspects of the Waf community that it is possible for > him to ban me from. If you don't mind me asking, why?
Re: C, D, undefined behavours, ++ -- operators
Sorry for the "typo" in the post Subject :-( bearophile
C, D, undefined behavours, ++ -- operators
This Reddit thread:
http://www.reddit.com/r/programming/comments/l6yn1/deep_c_and_c_slides/
Has let me find this curious pack of slides about C and C++:
http://good.net/dl/au/061c/deepcslidesoct2012-111010033910-phpapp01.pdf
While reading those slides I was glad that D avoids me several of those ugly
problems (not all of them, because variable definitions are allowed with =void
in D, but they are uncommon).
This is the cute page 194 of the slides:
What do these code snippets print?
int a=41; a++; printf("%d\n", a); 42
int a=41; a++ & printf("%d\n", a); Undefined
int a=41; a++ && printf("%d\n", a); 42
int a=41; if (a++ < 42) printf("%d\n", a); 42
int a=41; a = a++; printf("%d\n", a); Undefined
-
Regarding a line of C code like:
a = b() + c();
Negitivefrags from Reddit says:
http://www.reddit.com/r/programming/comments/l6yn1/deep_c_and_c_slides/c2qe43i
>The order is undefined so that the optimiser can do it's work. It is quite
>possible that after inlining doing C first and B after is faster than the
>other way around.<
In my not so humble opinion on modern computers this is acceptable only in a
language able to enforce the purity of the b and c functions (maybe it was
acceptable on 1970 year computers).
D has purity, so I really hope D will throw in the trash can most of this crazy
C stuff about undefined behaviours :-) If something compiles, it has to give a
deterministic output on all compilers, otherwise it has to become a
compile-time error.
Walter has expressed several times his desire to turn this code to defined in D:
a++ & printf("%d\n", a);
a = b() + c();
(But D will be free to run b and c in its preferred order if both b and c
functions are strongly pure.)
Turning that code into defined behaviour, shared by all future D compilers,
will be a large improvement for D. The little performance loss is nothing
compared to having code that gives the correct result. I firmly believe that
speed is _nothing_ if the code gives the wrong answers.
The alternative acceptable solution is to statically forbid as many things as
possible that will produce undefined behaviour at run time (but probably you
can't remove all of those behaviours from D code).
In real C code that I have to digest and debug I find every day lines almost
like this one (a bit simpler than this):
z = w[x] = a[x + ++b[y + ++j]]++;
Turning this C code into defined behaviour in D will be an significant
improvement, but maybe it's not enough. A part of me desires a language
(something like D, let's call it D-like) that statically forbids shitty code
like that because for me it is almost impossible to understand (maybe it's just
a limit of my brain, who knows). This is why I think turning that code into
defined D behaviour is not enough for me... :-(
I usually laboriously and slowly unpack a line of C like that, running tests
every little refactoring step, to turn it into several lines that are a bit
more sane and understandable for me.
To avoid many of those troubles it is enough to change the semantics of the
pre/post increment/decrement operators, to let them return only void. This
small change is able to avoid several troubles of C code.
Python doesn't have the ++ -- operators, this was a wonderful design decision.
Unfortunately I don't have statistics, but I think the ++ -- operators are a
common source of bugs in C and C++ code. I know they are handy, but they ask me
too much in turn.
On the other hand that legacy C code usually works. If I have to convert C code
like that to D-like, and D-like increment/decrement operators return void, this
makes a large percentage of C code invalid D code, this will make _much_ harder
for me to port C code to D-like.
A little solution to this problem is to put a compiler switch (like the -d for
deprecated features) that when present makes the ++ -- operators return a
value, otherwise they return void. So using -d I am able to port C code to
D-like, I slowly convert the code, and later I stop using -d for this converted
code.
-
>From the Go specs:
http://golang.org/doc/go_spec.html
As the ++ and -- operators form statements, not expressions, they fall outside
the operator hierarchy. As a consequence, statement *p++ is the same as (*p)++.
Go designers share some of my concerns on this.
-
In slide 215 it says C99 has introduced %zu to print size_t values with printf,
I didn't know this. This D code seems to work:
import core.stdc.stdio: printf;
void main() {
size_t x = 155;
printf("%zu\n", x);
}
Bye,
bearophile
Re: about const and immutable (again)
On 06.10.2011 20:56, Steven Schveighoffer wrote:
On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan
wrote:
I see. Thanks for the detailed answer.
I should clarify one point, I realized I am somewhat inaccurate on the
reason the type is set to immutable(dchar). In fact, nobody actually
wrote the immutable(dchar) function, it's just that the element type is
immutable(dchar). However, the reasons why someone would want to create
a function that takes an immutable(dchar) function are as I stated -- so
you don't accidentally change the value.
That seems like the discussed-and-discarded 'final' storage class for
parameters. But this is worse. It has an *enormous* cost.
Making immutable(dchar) parameters different from dchar causes *massive*
code bloat. Every n parameter template gets 3^^n copies!! And that has a
speed cost (use of code cache, branch prediction, etc).
You can see the 2^^n explosion in action in std.writefln; executables
bloat up enormously.
But it gets worse -- it makes it harder to write templates correctly.
For example, if the signature is:
bool foo(X)(X a, X b) if (is(X : double)) {...}
then foo doesn't accept (double, const(double)).
And it's entirely unnecessary. The question of whether a function can
modify its value parameters is an internal implementation detail of that
function. It has no consequences for the caller, so it shouldn't be
externally visible. Nobody else needs to know or care.
We need to reconsider this. I think it's the way it is by accident; I
don't remember any discussion about it.
Still no excuse that delegates cannot be implicitly cast to compatible
versions.
Re: Static arrays, typeof and IFTI?
On 10.10.2011 08:58, Gor Gyolchanyan wrote:
There is a huge difference between a static and a dynamic array.
Dynamic array is an indirected type (objects of that type are pointers
to the actual data), while static arrays are PODs (directly refers to
the data).
Dynamic arrays are always size_t.sizeof * 2 bytes long, while static
arrays are typeof(T[0]).sizeof * T.length bytes long. That makes
static arrays expensive to move around. Making the array literals
static by default would mean unnecessary copying most of the time. In
those few cases, where it is necessary, you can explicitly make them
static arrays.
If they'd been made immutable, the way they should be, this wouldn't be
an issue.
The efficiency argument is bogus, I think. Because they're mutable, they
always have to be created on the heap. So by default, they are very slow.
Cheers,
Gor.
On Mon, Oct 10, 2011 at 10:42 AM, Norbert Nemec wrote:
Hi there,
after a very busy and eventful year in my personal life, I have now
finally found some time to play with D2. I am very impressed by the
progress!
One thing I noticed was that static arrays are somehow strangely limited:
It is possible to overload based on the length:
void f(int[3] x) {
writeln("int[3]: ",x);
}
void f(int[4] x) {
writeln("int[4]: ",x);
}
int main(string argv[]) {
f([1,2,3]);
f([1,2,3,4]);
return 0;
}
However, used as function template argument, a static array is casted to
a dynamic array:
---
void g(T)(T x) {
static assert (__traits(isStaticArray,T));
enum N = T.init.length;
writeln(N,": ",x);
}
int main(string argv[]) {
g([1,2,3]);
return 0;
}
gives the error message:
| Error: static assert (__traits(isStaticArray,int[])) is false
| instantiated from here: g!(int[])
Without the assertion, N is defined to 0.
Further investigation shows:
---
g!(int[3])([1,2,3]); // passes a static array
---
int[3] x3 = [1,2,3];
g(x3);// passes a static array
---
auto z3 = [1,2,3];// defines z3 as dynamic array
g(y3);// passes a dynamic array
---
So it seems, the problem is that array literals on their own turned into
dynamic arrays unless you explicitly state a static array type in some way.
Wouldn't it make more sense the other way around? After all, turning a
static array into a dynamic array is easy, the other way around is
prohibited by the compiler. If array literals simply had a static array
type, they could be implicitly casted to dynamic arrays when necessary
but stay static if possible.
Greetings,
Norbert
Re: Garbage collection book
On 08/10/2011 08:45, Trịnh Quang Anh wrote: > IMO it's hard to apply a single GC design to many different languages, as > each language has it's distinct properties that require the GC to work in s > different manner. Out of curiosity, did anybody try to stick a recent (conservative) bdwgc* in and see how D's gc compares to it? It allows to embed some basic type-info regarding what should be considered pointer or not**. *: https://github.com/ivmai/bdwgc/ **: https://github.com/ivmai/bdwgc/blob/master/include/gc_typed.h > > 2011/10/8 bearophile > >> Caligo: >> >>> I'm just wondering, does Glasgow Haskell Compile (GHC) have the most >> advanced GC? >>> I remember reading where it said that GHC is like 10 years ahead of all >> the other compilers, >>> or something to that effect. >> >> If you want to find an advanced GC that is years ahead of all other ones, >> take a look at the garbage collectors inside the Oracle JavaVM. >> Haskell is almost purely functional, and its GC has to do a work different >> from a Java or D GC. A D GC has to do a work different from a Java GC, and >> more similar to a C# GC (but not exactly the same of C# because I think in D >> there is a larger percentage of pinned down data). Even if it is not >> perfectly fit, I think the recently created good GC for the C# Mono is good >> enough for D, maybe with some tuning. >> Unfortunately, despite being both Mono and D open source projects, there is >> a furiously intense "not invented here" syndrome in the whole planetary >> effort of Open Source. Every open source language seems to implement its own >> GC If you look at this situation from 15000 feet above it looks like an >> incredibly dumb situation. In practice once you get closer, you see >> incompatible open source licenses, and differences in the language semantics >> that make GC transplants hard or not so useful. Devil is in the details. >> >> Bye, >> bearophile >> >
Re: D on GDC announced on reddit
On Mon, Oct 10, 2011 at 4:04 PM, Bane wrote: > Simen Kjaeraas Wrote: > >> On Fri, 07 Oct 2011 17:11:45 +0200, Nick Sabalausky wrote: >> >> > "Trass3r" wrote in message >> > news:op.v2ze74ma3ncmek@enigma... >> >>> Now D is also quite cool, I would just like for the language compilers >> >>> to be a bit more stable. >> >> >> >> They have been vastly improving, really. >> >> >> >>> Currently I do have more sucess proposing C++11 based solutions as Go >> >>> or >> >>> D based ones, on the type of corporate environment I work in. >> >> >> >> That's not D's or Go's fault. Most guys especially in bigger >> >> corporations >> >> are plain ignorant and wear blinders. >> >> Strangely that even applies to universities. >> > >> > Not real surprising. Universities can be *enormously* ignorant and >> > conceited. (Community colleges too...my god, some of the flaming egos and >> > politics around there are mind-boggling, especially considering it's >> > *just* >> > a CC...) >> > >> >> Hell, they didn't even know about clang even though they were >> >> progressive >> >> enough to use C++0x. >> > >> > I once had a university professor who openly admitted C was the only >> > language he knew - and yet he didn't even understand how C's >> > null-terminated >> > strings work. So he didn't really even know that one language. >> >> I helped a friend with some assignments from a professor who wrote >> absolutely unreadable code, and who taught students to use int[101] >> to allocate 100 ints, because he couldn't grasp indexing from 0 to >> 99. >> >> I also really liked the assignment where we were told of a mythical >> processor that would multiply 2 NxN matrices in O(N^4) time. >> >> -- >> Simen > > Those who know, work with it. Those who don't know, teach it. > > I'm at a research university, and I haven't really had this problem at all. I've had a professor teach us his commandments of multithreaded programming who admitted he used to be a bit of a hypocrite according to his own rules, but that's about it. I even have one professor who just came back from a one year sabbatical in which he worked at a startup.
Re: D on GDC announced on reddit
On 10.10.2011 22:35, Simen Kjaeraas wrote: On Fri, 07 Oct 2011 17:11:45 +0200, Nick Sabalausky wrote: "Trass3r" wrote in message news:op.v2ze74ma3ncmek@enigma... Now D is also quite cool, I would just like for the language compilers to be a bit more stable. They have been vastly improving, really. Currently I do have more sucess proposing C++11 based solutions as Go or D based ones, on the type of corporate environment I work in. That's not D's or Go's fault. Most guys especially in bigger corporations are plain ignorant and wear blinders. Strangely that even applies to universities. Not real surprising. Universities can be *enormously* ignorant and conceited. (Community colleges too...my god, some of the flaming egos and politics around there are mind-boggling, especially considering it's *just* a CC...) Hell, they didn't even know about clang even though they were progressive enough to use C++0x. I once had a university professor who openly admitted C was the only language he knew - and yet he didn't even understand how C's null-terminated strings work. So he didn't really even know that one language. I helped a friend with some assignments from a professor who wrote absolutely unreadable code, and who taught students to use int[101] to allocate 100 ints, because he couldn't grasp indexing from 0 to 99. I also really liked the assignment where we were told of a mythical processor that would multiply 2 NxN matrices in O(N^4) time. Wow.. Looking forward to start my CS degree next year... :)
Re: D on GDC announced on reddit
Simen Kjaeraas Wrote: > On Fri, 07 Oct 2011 17:11:45 +0200, Nick Sabalausky wrote: > > > "Trass3r" wrote in message > > news:op.v2ze74ma3ncmek@enigma... > >>> Now D is also quite cool, I would just like for the language compilers > >>> to be a bit more stable. > >> > >> They have been vastly improving, really. > >> > >>> Currently I do have more sucess proposing C++11 based solutions as Go > >>> or > >>> D based ones, on the type of corporate environment I work in. > >> > >> That's not D's or Go's fault. Most guys especially in bigger > >> corporations > >> are plain ignorant and wear blinders. > >> Strangely that even applies to universities. > > > > Not real surprising. Universities can be *enormously* ignorant and > > conceited. (Community colleges too...my god, some of the flaming egos and > > politics around there are mind-boggling, especially considering it's > > *just* > > a CC...) > > > >> Hell, they didn't even know about clang even though they were > >> progressive > >> enough to use C++0x. > > > > I once had a university professor who openly admitted C was the only > > language he knew - and yet he didn't even understand how C's > > null-terminated > > strings work. So he didn't really even know that one language. > > I helped a friend with some assignments from a professor who wrote > absolutely unreadable code, and who taught students to use int[101] > to allocate 100 ints, because he couldn't grasp indexing from 0 to > 99. > > I also really liked the assignment where we were told of a mythical > processor that would multiply 2 NxN matrices in O(N^4) time. > > -- >Simen Those who know, work with it. Those who don't know, teach it.
Re: D on GDC announced on reddit
On Fri, 07 Oct 2011 17:11:45 +0200, Nick Sabalausky wrote: "Trass3r" wrote in message news:op.v2ze74ma3ncmek@enigma... Now D is also quite cool, I would just like for the language compilers to be a bit more stable. They have been vastly improving, really. Currently I do have more sucess proposing C++11 based solutions as Go or D based ones, on the type of corporate environment I work in. That's not D's or Go's fault. Most guys especially in bigger corporations are plain ignorant and wear blinders. Strangely that even applies to universities. Not real surprising. Universities can be *enormously* ignorant and conceited. (Community colleges too...my god, some of the flaming egos and politics around there are mind-boggling, especially considering it's *just* a CC...) Hell, they didn't even know about clang even though they were progressive enough to use C++0x. I once had a university professor who openly admitted C was the only language he knew - and yet he didn't even understand how C's null-terminated strings work. So he didn't really even know that one language. I helped a friend with some assignments from a professor who wrote absolutely unreadable code, and who taught students to use int[101] to allocate 100 ints, because he couldn't grasp indexing from 0 to 99. I also really liked the assignment where we were told of a mythical processor that would multiply 2 NxN matrices in O(N^4) time. -- Simen
Re: [std.database]
Steve Teale wrote: I've just been looking at the documentation for the PostgreSQL C api. Wow! It is so different from MySQL, and so clean. No out parameters from queries. That one is not going to be a problem. Steve PostgreSQL's C lib is not needed if we handle postgres protocol directly (already done).
Re: [std.database]
bls wrote: Am 10.10.2011 16:07, schrieb Steve Teale: interface SQLDBConnection How do you support different database connection requirements. f.i. a non default port number What about special parameters only available on db system xxx ? Since D support associative arrays, I vote to use them for passing connection properties instead of connection string. See PGConnection.open in pszturmaj.github.com/ddb/postgres.html.
Re: RFC - mysqlD
On 10/10/2011 01:46 AM, Jonathan M Davis wrote: On Sunday, October 09, 2011 16:35:20 Sean Kelly wrote: On Oct 9, 2011, at 2:42 PM, Jonathan M Davis wrote: On Sunday, October 09, 2011 14:35:35 Jonathan M Davis wrote: On Sunday, October 09, 2011 19:37:31 GrahamC wrote: The C types which may differ between x86 and x86_64 are defined in core.stdc.config. Though it currently only does so for the integral types. Which other standard C types vary between x86 and x86_64? On Windows, I don't believe that there's a difference on anything. On Linux, long int, unsigned long int, and long double all differ. I thought that long long int differed too (being 128 bit on 64-bit systems), but trying it now on my 64-bit Linux box, it's 64-bit for both -m32 and -m64, so I guess that it doesn't differ. But regardless, the primary one missing from core.stdc.config is long double. - Jonathan M Davis real is the same size as long double, on both 32 and 64 bits linux. -- Mike Wey
Re: Matrix-type-friendly syntax and more
On 10.10.2011 07:34, Don wrote: > On 10.10.2011 04:41, kenji hara wrote: >> 2011/10/10 bearophile: >>> So is this: >>> y[$-6, 0..$:2] >>> >>> Translated like this? >>> y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2)) >> >> I have no thought about it. >> I'm not sure that the additional stepping is really useful, but I >> think adding it into syntax is not impossible -- it might not conflict >> with associative array literal. >> >> Kenji Hara > > Personally, I think that since strided operations are so inefficient, > they should remain ugly. Inefficient?! For multidimensional arrays, all but one dimension have non-trivial, runtime-dependent strides anyway. Anyway, the expressiveness gained by strides is significant and the effort to allow it in the language is minimal.
Re: [std.database]
Same guys. It's great to see this moving from theory to application so quickly. On Oct 10, 2011, at 7:30 AM, Sean Kelly wrote: > Surprising. I read a research paper about a proposed language just a few > months ago. I wonder if this is by the same guys. > > Sent from my iPhone > > On Oct 10, 2011, at 12:05 AM, "Roald Ribe" wrote: > >> On Sun, 09 Oct 2011 20:31:35 -0300, Sean Kelly >> wrote: >> >>> On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote: >>> On 10/9/11 5:31 PM, Walter Bright wrote: > On 10/9/2011 5:28 AM, Piotr Szturmaj wrote: >> 1. I think that we should not design this API using the least common >> denominator >> approach. This is to not limit some databases. For example PostgreSQL >> has many >> great features not available in MySQL. That's why I started with >> postgres in my >> ddb project. I think DB API should be designed to support the most >> featureful >> databases and those that have less features may be easily adapted to >> that API. > > > Haven't common denominator designs been more or less failures in at > least one category - gui libraries? A common database interface is not a common denominator API; more like the opposite. This is not difficult because most differences across database systems lie in their SQL, which is strings from D's perspective. >>> >>> Assuming that by "database" you mean SQL. Pretty fair assumption, though >>> NoSQL databases (which cover a broad range of designs since there's no >>> standard language yet for key-value DBs, etc) are rapidly gaining >>> popularity. I almost wonder if the base type should be named SqlDatabase >>> instead of Database. >> >> There is a standard language defined for NoSQL, namely UnQL: >> http://.unqlspec.org/display/UnQL/Home >> >> Roald
Re: Support of dmd2 in Waf
Hi, The project lead for Waf has declared me persona non grata and banned me from any and all aspects of the Waf community that it is possible for him to ban me from. I therefore cannot contribute to Waf even though I would like to have done. The standard SCons tool has the same problem of being specific to D1. I have started a fork of the SCons D tool as a Mercurial repository https://bitbucket.org/russel/scons_dmd_new I should have created a patch for the latest SCons release but missed the deadline. There needs to be more work on this tool to really make it a good SCons tool, but it does work with D2. The Waf folk may be able to use the history of the SCons D tool in my repository to evolve the Waf tool to be D2 capable. On Mon, 2011-10-10 at 17:48 +0400, kdmult wrote: > Hi, > > Waf is a nice tool for configuring, compiling and installing > applications (like cmake). Currently it supports dmd1. > > Could somebody please update the issue > http://code.google.com/p/waf/issues/detail?id=1052 > with explanation on how dmd2 is supposed to compile and link an example > which is a part of waf repository (waf\demos\d)? > > I am a beginner in D, so I am afraid I can not help the waf author with > this. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [std.database]
On Mon, 10 Oct 2011 10:09:34 -0500, Andrei Alexandrescu wrote: > On 10/10/11 7:01 AM, Steve Teale wrote: >>> >>> You can glean all needed information from the resultset after having >>> issued the query. >>> It's probably true to say that the syntax/semantics of the interface will suck slightly more in the Variant case than in the struct case. >>> >>> That's a given. The suckiness won't come, however, in the form of >>> additional trips to the database. >>> >>> >>> Andrei >> >> Maybe in some cases. But at least with MySQL you have to bind before >> you fetch, and you don't have the meta-data about the columns until >> after the fetch, so you have to insert a call to >> mysql_stmt_result_metadata() to set up the Variant types before you >> bind. > > I'm confused. Isn't binding setting values to parameters prior to > executing a query? That's a different thing from getting the row of a > resultset. > > So, you first prepare, bind, and execute a query. Then you call > mysql_stmt_result_metadata() to get the number of columns in the > result set and their individual types. At that point you get to allocate > the Variant[] row appropriately. After that you're ready to iterate > rows. I was not making a big deal. I was just comparing operations with a struct to operations with an array of Variants. With a struct I can automate the construction of the OUT binding parameters before executing the query. If the user, with knowledge of the expected results cares to assign appropriate values to each array element in the Variant array, that can be done prior to execution also, and I guess it is not much more effort than defining the struct. But if the initialization of the array is to be automated, I first have to get the metadata. I presume that information comes from the server - perhaps it doesn't. But if it does, then in the Variant array case, there's an extra server call. >> I also discovered after some time wasted this morning that the MySQL >> struct used for date/time is too big for Variant. > > That's a bug in std.variant. Large structs should be supported > automatically by using an indirection and dynamic allocation. OK, I can work around it for now, since in a sense they are supported now. All I had to do was: alias VariantN!(maxSize!(creal, char[], void delegate(), MYSQL_DATETIME ...)) MyVariant; Steve
Re: [std.database]
Am 10.10.2011 17:09, schrieb Andrei Alexandrescu: That's a bug in std.variant. Large structs should be supported automatically by using an indirection and dynamic allocation. I am curious, what about BLOBs ?
Re: [std.database]
Am 10.10.2011 16:07, schrieb Steve Teale:
interface SQLDBConnection
How do you support different database connection requirements. f.i.
a non default port number
What about special parameters only available on db system xxx ?
MySQL : protocol etc.
PostGreSQL : loglevel, charSet etc.
// JDBC enables us to use..
String url = "jdbc:postgresql://localhost/test";
Properties props = new Properties();
props.setProperty("user","steve");
props.setProperty("password","teale");
props.setProperty("ssl","true");
Connection conn = DriverManager.getConnection(url, props);
atm I am not sure about the implementation of DriverManager, but I can
imagine that DriverManager follows the prototype respective the factory
pattern.
If you like, have a look at my msg.. std.database design suggestion.
my 2 cents
Re: [std.database]
On 10/10/11 7:01 AM, Steve Teale wrote: You can glean all needed information from the resultset after having issued the query. It's probably true to say that the syntax/semantics of the interface will suck slightly more in the Variant case than in the struct case. That's a given. The suckiness won't come, however, in the form of additional trips to the database. Andrei Maybe in some cases. But at least with MySQL you have to bind before you fetch, and you don't have the meta-data about the columns until after the fetch, so you have to insert a call to mysql_stmt_result_metadata() to set up the Variant types before you bind. I'm confused. Isn't binding setting values to parameters prior to executing a query? That's a different thing from getting the row of a resultset. So, you first prepare, bind, and execute a query. Then you call mysql_stmt_result_metadata() to get the number of columns in the resultset and their individual types. At that point you get to allocate the Variant[] row appropriately. After that you're ready to iterate rows. I also discovered after some time wasted this morning that the MySQL struct used for date/time is too big for Variant. That's a bug in std.variant. Large structs should be supported automatically by using an indirection and dynamic allocation. Andrei
Re: [std.database]
I've just been looking at the documentation for the PostgreSQL C api. Wow! It is so different from MySQL, and so clean. No out parameters from queries. That one is not going to be a problem. Steve
Re: [std.database]
Surprising. I read a research paper about a proposed language just a few months ago. I wonder if this is by the same guys. Sent from my iPhone On Oct 10, 2011, at 12:05 AM, "Roald Ribe" wrote: > On Sun, 09 Oct 2011 20:31:35 -0300, Sean Kelly wrote: > >> On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote: >> >>> On 10/9/11 5:31 PM, Walter Bright wrote: On 10/9/2011 5:28 AM, Piotr Szturmaj wrote: > 1. I think that we should not design this API using the least common > denominator > approach. This is to not limit some databases. For example PostgreSQL > has many > great features not available in MySQL. That's why I started with > postgres in my > ddb project. I think DB API should be designed to support the most > featureful > databases and those that have less features may be easily adapted to > that API. Haven't common denominator designs been more or less failures in at least one category - gui libraries? >>> >>> A common database interface is not a common denominator API; more like the >>> opposite. This is not difficult because most differences across database >>> systems lie in their SQL, which is strings from D's perspective. >> >> Assuming that by "database" you mean SQL. Pretty fair assumption, though >> NoSQL databases (which cover a broad range of designs since there's no >> standard language yet for key-value DBs, etc) are rapidly gaining >> popularity. I almost wonder if the base type should be named SqlDatabase >> instead of Database. > > There is a standard language defined for NoSQL, namely UnQL: > http://.unqlspec.org/display/UnQL/Home > > Roald
Re: [std.database]
Here's a sketch of an interface. This is based on my experiments with
MySQL, and as such it is probably mid-level, and not a top level covers-
all interface.
Hopefully it will create a number of discussion points.
// Can interfaces include template functions???
interface SQLDBConnection
{
@property Handle handle();
Handle connect(string host, string user, string password,
string database = null);
T getProperty(T)(string name);
T getProperty(T)(int id);
void setProperty(T)(T property, string name);
void setProperty(T)(T property, int id);
Handle disconnect();
}
// There should possibly be a connection pool as well, and that
// should handle the RAII aspects of connections. Handle is an
// alias to suit the database system.
interface Raw
{
// Delete, insert, update, createXXX, and the like - no result set
rowcount_t exec(string sql);
// Select and such with result set - result set buffered to the
// client to provide a Random Access Range of Rows
rowcount_t execResultSet(string sql);
// Select and such with result set - prepares for sequential
// processing of an Input Range of Rows
void execSequence(string sql);
// Do the range defining methods need to be in the interface?
}
enum ParamDirection
{
ParamIn,
ParamOut,
ParamInOut
}
interface Prepared
{
void createParam(T)(ref T target, ParamDirection pd);
void createInParams(T...)(ref T args)
void createOutParams(T...)(ref T args)
void createVariantParam(ref Variant v, ParamDirection pd);
void createVariantParams(T...)(ref Variant[] va, T);
// If D type arrays are the bound type, it's likely that some
// updating of the bindings will be required when a new value
// is set, since a.ptr and a.length may change. Otherwise
// these operations are no-ops.
void updateInputParam(T)(ref T target);
void updateInParameters(T...)(ref T args);
void updateInArray(Variant[]);
void updateInStruct(S)(ref S s);
// Create a set of in parameters from an array of Variants
void setInArray(ref Variant[] va);
// Create a set of out parameters from an array of Variants
void setOutArray(ref Variant[] va);
// Initialize an array of out Variants to types appropriate for a query
void getTypesForArray(ref MyVariant[] va);
// Create a set of input params from a struct
void setInStruct(S)(ref S s) if (is(S== struct));
// Create a set of out params from a struct
void setOutStruct(S)(ref S s) if (is(S== struct));
prepare(string sql);
// Delete, update, createXXX, and the like - no result set
// returns rows affected;
rowcount_t exec();
// Select and such with result set - result set buffered
// to the client to
// provide a Random Access Range of Rows
rowcount_t execResultSet();
// Select and such with result set - prepares for sequential
// processing of an Input Range of Rows
void execSequence();
// A composite operation prepare, bind, and execute a statement
// to get a single column value into a D variable.
// execScalar(T)(ref T target);
// Do the range defining methods need to be in the interface?
}
interface Row // mmm bit close to Raw
{
// Get the values from a fetched row into a D struct
void rowToStruct(S)(ref S s) if (is(S == struct));
// Get the values from a fetched row into an array of Variants
void rowToStruct(ref Variant[] va);
// Get a column value by index into a D variable from the current row
T getValue(T)(out T target, int index, out bool isnull);
// Get a column value by index into a D variable from the current row
T getValue(T)(out T target, string colName, out bool isnull)
string toString(uint index);
string toString(string colName);
}
interface ResultSet
{
// Get the entire result set into an array of structs/Variants
S[] getAllRows(S)(ref S dummy) if (is(S == struct));
Variant[] getAllRows();
// This should be automated where possible
void free();
}
I can currently do most of this for MySQL, and what I haven't done
is mostly rehashing of what I have.
As an example of how level 2 interfaces may differ from the top-level one
is that in my implementation, chunking is supported for transfer and
disposal of large objects - either auto-chunking, or chunking via a
delegate. That stuff is not shown here.
Steve
Support of dmd2 in Waf
Hi, Waf is a nice tool for configuring, compiling and installing applications (like cmake). Currently it supports dmd1. Could somebody please update the issue http://code.google.com/p/waf/issues/detail?id=1052 with explanation on how dmd2 is supposed to compile and link an example which is a part of waf repository (waf\demos\d)? I am a beginner in D, so I am afraid I can not help the waf author with this.
Re: Formal Review of std.regex (FReD)
On 09.10.2011 22:47, Jacob Carlborg wrote: On 2011-10-09 17:29, Dmitry Olshansky wrote: On 09.10.2011 19:09, Jacob Carlborg wrote: On 2011-10-09 17:01, Dmitry Olshansky wrote: On 09.10.2011 18:49, Jacob Carlborg wrote: On 2011-10-09 16:09, Dmitry Olshansky wrote: On 09.10.2011 14:33, Jacob Carlborg wrote: On 2011-10-08 21:56, Jesse Phillips wrote: Hello everyone, I have taken the role of review manager of the std.regex replacement by Dmitry Olshansky. The review period begins now 2011-10-8 and will end on 2011-10-23 at midnight UTC. A voting thread to include into Phobos will be held after review assuming such is appropriate. The Voting period is one week. Please note that you can try FRed as part of Phobos (Code) or by itself (Package of FReD) which includes docs. Doc: http://nascent.freeshell.org/fred/doc/ What's the difference between Regex and RegEx? I can see RegEx in the documentation but I cannot find its definition in the docs. RegEx is a template parameter (it's that usual abstract 'T'), that in the end deduced as StaticRegex!Char or Regex!Char where Char is char/wchar/dchar. I don't think the documentation should refer to RegEx if it's not defined in the docs. Yes, I think I see the typo now, thanks. The second parameter type of the match function (and a couple of other functions) is RegEx, is that possible to fix as well? No, that's what I tried to point out but failed obviously. The thing is that it is a templated parameter and due to constraint it could be either StaticRegex!Char or Regex!Char. They represent pattern compiled as machine code or bytecode respectively for character width of Char. All of the 6 versions of compiled patterns in the end do not have a common type nor one is technically possible (w/o some quite bad performance trade offs). Aha, ok, I see. Could RegEx be explained in the docs so it won't cause further confusion? Mm... it could get even more confusing. I guess putting "The RegEx parameter can be either Regex!Char or StaticRegex!Char depending on the actual type of pattern passed" all over the place won't cut it. Placing it somewhere on the top has disadvantage of lacking any prior context, and most users will miss it anyway. Maybe I'll just add Params: section with short description to all functions that still lack one. -- Dmitry Olshansky
Re: Matrix-type-friendly syntax and more
Don wrote: > On 10.10.2011 04:41, kenji hara wrote: >> 2011/10/10 bearophile: >>> So is this: >>> y[$-6, 0..$:2] >>> >>> Translated like this? >>> y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2)) >> >> I have no thought about it. >> I'm not sure that the additional stepping is really useful, but I >> think adding it into syntax is not impossible -- it might not conflict >> with associative array literal. >> >> Kenji Hara > > Personally, I think that since strided operations are so inefficient, > they should remain ugly. Slicing an nD static array is just as in/efficient as strides. That said, I'm still -1 on having a..b:c since (1) I see no practical need for strides and (2) even if we striding it doesn't need to be in the form a..b:c, e.g. arr[stride(0..$, 2)].
Re: Hooray for DustMite
Yep, it's a really nifty tool. I already filed several bugs that had been reduced with DustMite.
Re: [std.database]
> > You can glean all needed information from the resultset after having > issued the query. > >> It's probably true to say that the syntax/semantics of the interface >> will suck slightly more in the Variant case than in the struct case. > > That's a given. The suckiness won't come, however, in the form of > additional trips to the database. > > > Andrei Maybe in some cases. But at least with MySQL you have to bind before you fetch, and you don't have the meta-data about the columns until after the fetch, so you have to insert a call to mysql_stmt_result_metadata() to set up the Variant types before you bind. I also discovered after some time wasted this morning that the MySQL struct used for date/time is too big for Variant. I had to define a MyVariant taking that struct into consideration. Is Variant supposed to throw if you initialize an instance with a struct that is bigger than maxSize? It didn't - I just got mysterious segfaults when fetch tried to store the result via a null buffer pointer. Anyway, that's working now. >From the comments we're getting, it looks like we need to head toward a generic std.sql (or std.database) that provides basic functionality for most databases. This would be implemented over more capable modules for individual databases that covered the differentiating features as well as what would be needed for the generic case. Kind of between your options 2 and 3. Steve
Re: D on GDC announced on reddit
Le 07/10/2011 17:49, Trass3r a écrit : Hell, they didn't even know about clang even though they were progressive enough to use C++0x. I once had a university professor who openly admitted C was the only language he knew - and yet he didn't even understand how C's null-terminated strings work. So he didn't really even know that one language. Had a workmate who apparently was real good at using C for microprocessor programming. But he didn't have the slightest clue about how C++ works and what OOP overhead really means. And when I used Lua to create a small conversion script (which was only needed cause the legacy code was crap, hardcoded paths and the like) that even turned into some kind of running gag. I don't need to say that nobody had ever heard of it nor was anyone willing to try it out before judging. You can do function pointer in C and thus, do OOP manually. He probably already did that without really knowing this is OOP.
Re: Matrix-type-friendly syntax and more
Don: > Personally, I think that since strided operations are so inefficient, > they should remain ugly. In Chapel (that's a high performance language full of nice ideas) the stride is present, see page 16 "Range operators": http://chapel.cray.com/tutorials/CUG2011/CUG11-2-Basics.pdf Bye, bearophile
Re: [std.database]
On Sat, 08 Oct 2011 17:19:02 +0100, Andrei Alexandrescu wrote: On 10/8/11 8:36 AM, Adam Burton wrote: I'd also like to get a feel for the magnitude of the task, so I'd like to ask what database systems you think should be supported. mysql, postgresql, sqllite are the 3 I am aiming at in my personal implementation. I had lunch yesterday with a database expert and discussed the matter with him. He advised that we take a driver-oriented approach in which we define a common API for all databases (modeled at high level after e.g. JDBC to reuse that accumulated experience) Just a small note, because it's on my mind currently, with regards to JDBC. This is slightly OT, but pertains to the comment about how we should model std.database. JDBC has Statement and PreparedStatement objects, the latter allows you to 'bind' parameters, which is great. But, it requires you actually 'prepare' them as well.. I am not 100% certain, but I believe similar C/C++ code can bind parameters without actually 'preparing' the statement for reuse. We use this in cases where we do not re-use the statement, and want to avoid the excess work of preparing it for re-use. In addition we bind parameters to avoid getting unique query strings, which (I believe) get cached by SQL server.. resulting in thousands of unique queries in the cache, slowing things down. So, my comment is simply to say, assuming I am not talking rubbish, make sure the design allows for binding/not binding parameters with prepared/not-prepared statements. This came up recently because some of our JDBC code was taking 12 minutes to do a select, due to using a PreparedStatement, and changing to a Statement reduced this to <10 sec. But, it means the select is now unique, and we will be introducing more cached queries.. anyone know how to avoid this using Statement? R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: std.database design suggestion
well, the previous code was half baked, this should explain what I want
to archive...
int main(string[] args)
{
DatabaseFactory factory;
if(args[0] == "MySQL")
factory = new MySQLFactory();
else
factory = new PostreSQLFactory();
updatePricelist(factory);
return 0;
}
abstract class Database {
//common database stuff
public abstract void connect(string user, string pw);
// execSql(); prepare() etc...
}
abstract class DatabaseFactory {
public abstract Database GetDatabase();
}
final class PostgreSQL:Database {
// common
public override void connect(string user, string pw) {
}
//PostgreSQL specif
public void funkyPGstuff() {}
}
final class PostreSQLFactory:DatabaseFactory {
public override Database GetDatabase() {
return new PostgreSQL();
}
}
final class MySQL:Database {
// common
public override void connect(string user, string pw) {
}
//MySQL specif
public void funkyMySQLstuff() {}
}
final class MySQLFactory:DatabaseFactory {
public override Database GetDatabase() {
return new MySQL();
}
}
// Update PriceList without knowing the concrete database
void updatePricelist(DatabaseFactory factory) {
Database db = factory.GetDatabase();
//db.execSQL("UPDATE ...");
}
Re: Matrix-type-friendly syntax and more
Kenji Hara: > Posted pull request. > https://github.com/D-Programming-Language/dmd/pull/443 Things are getting interesting. Thank you. Such syntax is the building material for a good enough user-defined dense nD array. I presume the memory representation of such arrays (possibly in Phobos) will be tiled, to help CPU caches. > This patch does not break existing codes (at least dmd test suite and > phobos building). Given how important multi-dimensional slicing it, a bit of breakage is acceptable if it allows to make the situation simpler & cleaner. People that will implement a nD array years from now will thank you :-) > I have not added stride syntax (e.g. a[0..$:2]), but I think that > adding it is not so difficult. OK. Bye, bearophile
Re: Color your terminal's output
Johannes Pfau wrote: > Jens Mueller wrote: > >Johannes Pfau wrote: > >> Jens Mueller wrote: > >> >Johannes Pfau wrote: > >> >> You could use ANSI codes on posix to avoid a dependency on curses: > >> >> http://en.wikipedia.org/wiki/ANSI_escape_code#Colors > >> >> But I think using curses is ok. ncurses is MIT licensed and can be > >> >> used as a dynamic library, so I don't think there are license > >> >> problems. > >> >> > >> >> However, I'd recommend to load ncurses dynamically with > >> >> dlopen/dlsym and fallback to simple text output if the ncurses > >> >> library cannot be loaded. > >> > > >> >Using the ANSI codes is fine with me. I assumed they aren't that > >> >portable but it seems fine. > >> > >> I'd still use curses though, as it abstracts some things away. > >> Finding terminal capabilities and similar stuff. > >> > >> >> >Any help is very appreciated. > >> >> > > >> >> >Though this module is functionality-wise inferior to something > >> >> >like ncurses it conveniently allows coloring output for most use > >> >> >cases. > >> >> > >> >> as you already use these functions: > >> >> http://linux.die.net/man/3/setupterm > >> >> it'd be nice to have wget-like progressbars and 'updateable' text > >> >> labels. Shouldn't be as fancy as full ncurses, for most use cases > >> >> it's good enough to modify the current line. +Points if it > >> >> properly handles terminal width and resizing. > >> > > >> >I believe progress bars are easy to add. Boost's progress_bar > >> >should be fairly easy to port. It'll be nice if you could provide a > >> >pull request for this. Is this feasible for you? > >> > >> Sure, I'll have a look at it soon. You're talking about this > >> progress_display class, right? > >> http://www.boost.org/doc/libs/1_47_0/boost/progress.hpp > > > >Yes. Maybe it's too simple compared to wget's. > > > >> >Regarding update able text labels I'm not sure how they are > >> >typically used. So I would also prefer some pull request from > >> >somebody with a common use case. > >> > >> Well, think of wget's output: > >> 0% [ ] 1.154.567123K/s > >> ETA 57m 6s || > >> | | | updateable label > >> progressbar u-label u-label u-label > > > >That looks very useful. Is this difficult to add? > >Can't one just delete the entire line and replace it with an > >appropriately updated one? Is this too naive? > > Yes it's implemented exactly that way. But I think having it in a > library is useful nevertheless. > > Here's what I have so far: > https://gist.github.com/1273678 Looks good on first view. > Some improvements to be done: > -Autodetect terminal width > -test on windows > -use isatty and produce useful output for non-ttys > -refactoring, docs Can you create a pull request then? Anyway it would be nice to know if there is enough value to add it to phobos? Is there any chance? Otherwise I will put it in its own library and host it on github. Jens
Re: Color your terminal's output
Marco Leise wrote: > Am 09.10.2011, 12:32 Uhr, schrieb Jens Mueller : > > >Johannes Pfau wrote: > >>Jens Mueller wrote: > >>BTW: you could also use isatty (http://linux.die.net/man/3/isatty) to > >>detect if stdout has been redirected and disable color output in that > >>case. > >>For windows: > >>https://forums.embarcadero.com/thread.jspa?threadID=21194 > >>or > >>http://msdn.microsoft.com/de-de/library/f4s0ddew(v=vs.80).aspx > > > >Nice idea. Thanks. > > > >Jens > > But allow the programmer to force color output anyway. In some cases > you redirect to a program that itself supports or passes through > escape sequences. "grep --color=always | less" would > be an example of that. Make sense. Thanks. Jens
std.database design suggestion
-- Sorry for posting on D.announce --
Hi, what do you people think about using the GoF
Factory (design) pattern ?
F.I.
abstract class Database {
//common database stuff
public abstract void connect(string user, string pw);
// execSql(); prepare() etc...
}
abstract class DatabaseFactory {
public abstract Database GetDatabase();
}
class PostgreSQL:Database {
// common
public override void connect(string user, string pw) {
}
//PostgreSQL specific
public void funkyPGstuff() {}
}
class PostreSQLFactory:DatabaseFactory {
public override Database GetDatabase() {
return new PostgreSQL();
}
}
class MySQL:Database {
// common
public override void connect(string user, string pw) {
}
//MySQL specific
public void funkyMySQLstuff() {}
}
class MySQLFactory:DatabaseFactory {
public override Database GetDatabase() {
return new MySQL();
}
}
Re: Matrix-type-friendly syntax and more
Posted pull request. https://github.com/D-Programming-Language/dmd/pull/443 This patch does not break existing codes (at least dmd test suite and phobos building). I have not added stride syntax (e.g. a[0..$:2]), but I think that adding it is not so difficult. Kenji Hara 2011/10/10 kenji hara : > I got an idea for multidimentional indexing and slicing. > http://d.puremagic.com/issues/show_bug.cgi?id=6798 > > I think opSlice!n (n is dimension integer typed size_t) is rarely > used, therefore using that name for the enhancement is almost safe for > backward compatibility. > > Kenji Hara > > 2011/10/10 Denis Shelomovskij : >> 09.10.2011 21:29, bearophile пишет: >>> >>> Kenji Hara has just copied in GIT a large patch by Don: >>> https://github.com/9rnsr/dmd/branches/opDollar >>> >>> It allows user defined collections usable with this syntax: >>> >>> x[$-2, y[$-6, $-9], $-2] >>> >>> See: >>> http://d.puremagic.com/issues/show_bug.cgi?id=3474 >>> >>> >>> But a syntax like this too is quite important for a user-defined matrix >>> type to be used in numerical code: >>> >>> m[i..j, k..w] >>> >>> Similar slicing and dicing of arrays is used all the time in NumPy (array >>> library for Python) code. >>> >>> This is a comment by Don about it: >>> (4) I have NOT implemented $ inside opSlice(), opSliceAssign(). It could be done, but I believe those language features need work. They don't permit multi-dimensional slicing. I think they should be removed, and the functionality folded into opIndex. >>> >>> Isn't it better to improve opSlice() instead of deprecating it? >>> >>> >>> I don't remember if people appreciate the idea of a stride (like the third >>> step argument of std.range.iota), this too is used in scientific >>> array-oriented code: >>> >>> m[i..j:2, k..w:3] >>> >>> --- >>> >>> In Python code there is often the need for a good multi-dimensional array >>> type, even in not-scientific code. >>> >>> In the Python standard library there is a array module, but it's almost a >>> joke, it's 1D, and it's not used much: >>> http://docs.python.org/library/array.html >>> >>> Python programmers use the multi-dimensional array of NumPy, it's widely >>> used around the world, it's used by SciPy too (a scientific programming >>> library). >>> >>> The experience of Python, with its sorely felt lack of a good >>> multi-dimensional array type, the failure of its array module, and the >>> success of NumPy, the problems caused by two precedent incompatible array >>> libraries Numeric (http://people.csail.mit.edu/jrennie/python/numeric/ ) and >>> numarray >>> (http://www.stsci.edu/resources/software_hardware/numarray/numarray.html), >>> tells me that it will be good to have a bare-bones, but efficient >>> multi-dimensional array type. Plus external libraries (not present in >>> Phobos) that use those arrays to implement all the things they want. >>> >>> I think that's a good tradeoff between the opposed needs of: >>> - Keeping Phobos of reasonable size (to not increase too much the burden >>> of its management, to not slow down too much its development); >>> - Avoiding the risk of incompatible multi-dimensional array types. Most >>> code out there is able to build on a common foundation. This avoids >>> duplication (like the creation of Python numarray and Numeric), allows a >>> better focusing of efforts and speeds up the development of a language-wide >>> standard for such arrays; >>> - Offer a nD array type to the casual D programmer, even one that doesn't >>> want or can't install other libraries. Even some 30-lines long D programs >>> need multi-dimensional arrays, but they often don't need a complex >>> scientific library too (example of a problem: in the preconditions of my >>> functions that take an array of arrays I always have to test the input is >>> not jagged and it is a rectangular matrix. Such test is not necessary for a >>> multi-dimensional array that is never jagged). Putting the bare bones >>> multi-dimensional array type in Phobos allows people to use them with zero >>> other installs. >>> >>> This multi-dimensional Phobos array type doesn't even need to contain code >>> to invert a matrix or compute determinant, etc. It just needs basic >>> operations like allocation, indexing, multi-dimensional slicing, change of >>> shape, iteration... Everything else is in modules/packages external to >>> Phobos. >>> >>> I am not suggesting to put a sparse multi-dimensional array type in >>> Phobos. This need is much less common in casual short programs. This is >>> better left to external modules. >>> >>> Bye, >>> bearophile >> >> Suddenly, I had a talk with an Fortran guy at previous weekend and have >> wrote something like Fortran arrays in D last week. I had an idea of adding >> it into Phobos, but just had no time for review of my code. Draft version is >> in attachment. >> >> rarray.d - something like Fortran array >> main.d - example of using rarray module >> output.txt - main
Re: [std.database]
On Sun, 09 Oct 2011 20:31:35 -0300, Sean Kelly wrote: On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote: On 10/9/11 5:31 PM, Walter Bright wrote: On 10/9/2011 5:28 AM, Piotr Szturmaj wrote: 1. I think that we should not design this API using the least common denominator approach. This is to not limit some databases. For example PostgreSQL has many great features not available in MySQL. That's why I started with postgres in my ddb project. I think DB API should be designed to support the most featureful databases and those that have less features may be easily adapted to that API. Haven't common denominator designs been more or less failures in at least one category - gui libraries? A common database interface is not a common denominator API; more like the opposite. This is not difficult because most differences across database systems lie in their SQL, which is strings from D's perspective. Assuming that by "database" you mean SQL. Pretty fair assumption, though NoSQL databases (which cover a broad range of designs since there's no standard language yet for key-value DBs, etc) are rapidly gaining popularity. I almost wonder if the base type should be named SqlDatabase instead of Database. There is a standard language defined for NoSQL, namely UnQL: http://.unqlspec.org/display/UnQL/Home Roald
Re: Static arrays, typeof and IFTI?
Norbert Nemec wrote:
> Hi there,
>
> after a very busy and eventful year in my personal life, I have now
> finally found some time to play with D2. I am very impressed by the
> progress!
>
> One thing I noticed was that static arrays are somehow strangely limited:
>
> It is possible to overload based on the length:
>
>
> void f(int[3] x) {
>writeln("int[3]: ",x);
> }
>
> void f(int[4] x) {
>writeln("int[4]: ",x);
> }
>
> int main(string argv[]) {
>f([1,2,3]);
>f([1,2,3,4]);
>return 0;
> }
>
>
> However, used as function template argument, a static array is casted to
> a dynamic array:
>
> ---
> void g(T)(T x) {
>static assert (__traits(isStaticArray,T));
>enum N = T.init.length;
>writeln(N,": ",x);
> }
>
> int main(string argv[]) {
>g([1,2,3]);
>return 0;
> }
>
>
> gives the error message:
>
> | Error: static assert (__traits(isStaticArray,int[])) is false
> | instantiated from here: g!(int[])
>
> Without the assertion, N is defined to 0.
>
> Further investigation shows:
>
> ---
> g!(int[3])([1,2,3]); // passes a static array
> ---
> int[3] x3 = [1,2,3];
> g(x3);// passes a static array
> ---
> auto z3 = [1,2,3];// defines z3 as dynamic array
> g(y3);// passes a dynamic array
> ---
>
> So it seems, the problem is that array literals on their own turned into
> dynamic arrays unless you explicitly state a static array type in some way.
>
> Wouldn't it make more sense the other way around? After all, turning a
> static array into a dynamic array is easy, the other way around is
> prohibited by the compiler. If array literals simply had a static array
> type, they could be implicitly casted to dynamic arrays when necessary
> but stay static if possible.
>
> Greetings,
> Norbert
I think you could use something like
void f(T, size_t n)(T[n] param) { ... }
(not tested)
Re: Static arrays, typeof and IFTI?
There is a huge difference between a static and a dynamic array.
Dynamic array is an indirected type (objects of that type are pointers
to the actual data), while static arrays are PODs (directly refers to
the data).
Dynamic arrays are always size_t.sizeof * 2 bytes long, while static
arrays are typeof(T[0]).sizeof * T.length bytes long. That makes
static arrays expensive to move around. Making the array literals
static by default would mean unnecessary copying most of the time. In
those few cases, where it is necessary, you can explicitly make them
static arrays.
Cheers,
Gor.
On Mon, Oct 10, 2011 at 10:42 AM, Norbert Nemec wrote:
> Hi there,
>
> after a very busy and eventful year in my personal life, I have now
> finally found some time to play with D2. I am very impressed by the
> progress!
>
> One thing I noticed was that static arrays are somehow strangely limited:
>
> It is possible to overload based on the length:
>
>
> void f(int[3] x) {
> writeln("int[3]: ",x);
> }
>
> void f(int[4] x) {
> writeln("int[4]: ",x);
> }
>
> int main(string argv[]) {
> f([1,2,3]);
> f([1,2,3,4]);
> return 0;
> }
>
>
> However, used as function template argument, a static array is casted to
> a dynamic array:
>
> ---
> void g(T)(T x) {
> static assert (__traits(isStaticArray,T));
> enum N = T.init.length;
> writeln(N,": ",x);
> }
>
> int main(string argv[]) {
> g([1,2,3]);
> return 0;
> }
>
>
> gives the error message:
>
> | Error: static assert (__traits(isStaticArray,int[])) is false
> | instantiated from here: g!(int[])
>
> Without the assertion, N is defined to 0.
>
> Further investigation shows:
>
> ---
> g!(int[3])([1,2,3]); // passes a static array
> ---
> int[3] x3 = [1,2,3];
> g(x3); // passes a static array
> ---
> auto z3 = [1,2,3]; // defines z3 as dynamic array
> g(y3); // passes a dynamic array
> ---
>
> So it seems, the problem is that array literals on their own turned into
> dynamic arrays unless you explicitly state a static array type in some way.
>
> Wouldn't it make more sense the other way around? After all, turning a
> static array into a dynamic array is easy, the other way around is
> prohibited by the compiler. If array literals simply had a static array
> type, they could be implicitly casted to dynamic arrays when necessary
> but stay static if possible.
>
> Greetings,
> Norbert
>
