ddox documentation generator
The documentation generator used for vibed.org (e.g. http://vibed.org/api/vibe.core.file/FileStream) is now available as a stand-alone project: https://github.com/rejectedsoftware/ddox also available as a VPM module: http://registry.vibed.org/view_package/ddox Features: - Supports DDOC sections and macros - Fully interlinked types - Automatically inherits members and documentation from base classes - Clean structure without endless spaghetti pages (customizable) - Diet template based and thus fully customizable output - Built-in HTTP server for local docs serving - Easily embeddable into existing vibe.d based sites - Can generate offline documentation as HTML files - Function for filtering the DMD .json file by module prefixes, protection level and doc comment
Remus
Hi, I'd like to present you Remus. First things first. What is Remus? Remus is a (Pre)Compiler for D. It adds D or rather the natural Syntax of D through various things, which are at the moment only offered by library solutions or not at all. This includes: - Not null references - Stack instances (also known as scope instances) - Namespaces - Safe Null invocation Planned further still: memoize for functions and methods as well as ref counted instances. Here's one code example of what already works: http://dpaste.dzfl.pl/bc50f081 Why did I do that? Many library solutions from D are for me (and probably for many others here) essentially built (built in) missing features that can't be missing. An example would be not null references: Not Null references doesn't exist and are not intended for D. They are at least a structure / library solution. Remus instead provides a simple, clear syntax. There is certainly more to say about the other features, but I'm not fond of many words: Try it out, or leave it. It's your choice, but I will use it in future for myself, my fellow students and my university stuff. Nevertheless I am thankful for suggestions and feedback. You can download Remus here: http://rswhite.de/?q=downloads. This is my own little website (however, in German) on where I give you some informations, details and features about Remus as well as how you install it: http://rswhite.de/?q=remus. I advise you to try reading some of the remus chapters to understand what's working and what doesn't and for what reason. On this page there will soon (about 2 - 4 weeks) be released the Beta-version of my 2D game framework called Dgame. This builds on the SDL and OpenGL and should become a worthy substitute to SFML from C++. It already has been tested enough in 2-3 simulations. Even an Pong Clone has been developed by it. But what's missing is an adequate documentation. So much of me. Greetings and in advance: sorry for my english ;)
Re: Remus
Namespace: - Not null references - Stack instances (also known as scope instances) - Namespaces - Safe Null invocation Planned further still: memoize for functions and methods as well as ref counted instances. Similar efforts are useful almost as the Haskell GHC compiler extensions: to allow the community to try to use features not yet present in the language, to judge them better, allowing to understand if they are worth putting in the language, and trying few alternative implementation ideas looking for the best one of them. But to do this well, people need to understand such extensions very well. So instead of just offering the source code and one uncommented example, I suggest to explain each feature, why they are present, what design choices you have taken and why, and how to use them in some common cases, with few specific examples. This will make your work useful for the development of the mainstream D too. Bye, bearophile
Re: Remus
I have, but until now only in german. If you understand german, you could read it on my website on the remus chapter. I'm going to translate and explain it more detailed this week. :)
Re: ddox documentation generator
On 2012-10-07 18:06, Sönke Ludwig wrote: The documentation generator used for vibed.org (e.g. http://vibed.org/api/vibe.core.file/FileStream) is now available as a stand-alone project: https://github.com/rejectedsoftware/ddox also available as a VPM module: http://registry.vibed.org/view_package/ddox Features: - Supports DDOC sections and macros - Fully interlinked types - Automatically inherits members and documentation from base classes - Clean structure without endless spaghetti pages (customizable) - Diet template based and thus fully customizable output - Built-in HTTP server for local docs serving - Easily embeddable into existing vibe.d based sites - Can generate offline documentation as HTML files - Function for filtering the DMD .json file by module prefixes, protection level and doc comment This looks awesome. -- /Jacob Carlborg
Re: Remus
On 2012-10-07 19:32, Namespace wrote: Hi, I'd like to present you Remus. First things first. What is Remus? Remus is a (Pre)Compiler for D. It adds D or rather the natural Syntax of D through various things, which are at the moment only offered by library solutions or not at all. This includes: - Not null references - Stack instances (also known as scope instances) - Namespaces - Safe Null invocation This looks cool, especially not null references and stack instances. But as bearophile said, it would be nice with some explanation of the features. -- /Jacob Carlborg
Re: Remus
On Sunday, 7 October 2012 at 19:41:30 UTC, Jacob Carlborg wrote: On 2012-10-07 19:32, Namespace wrote: amazing, good work...! what license is this under, is it allowed to be used commercially?
Re: ddox documentation generator
Server overloaded? Trying to connect to 'vibed.org' just hangs (without actually timing out, at least not yet).
Re: ddox documentation generator
On 10/07/2012 05:33 PM, Nick Sabalausky wrote: Server overloaded? Trying to connect to 'vibed.org' just hangs (without actually timing out, at least not yet). Same for me.
Re: GtkD 2.0 released, Gtk+ 3 with D.
On Saturday, 6 October 2012 at 13:48:02 UTC, Mike Wey wrote: Using those same instructions... https://github.com/gtkd-developers/GtkD/wiki/Installing-on-Windows ...I only manage to get this error (after ~10 seconds): D:\Documents\GitHub\GtkD\srcdgen.exe Fatal Error: Out of memory Even though Task Manager shows only negligible increase in memory. I seems that dmd runs out of memory when using the -lib switch with GtkD. I've updated the script posted on the wiki. Works great, thanks!
D is wank
Time to pick up the scraps. To take it further would be abuse. Abuse of those unknowing. Time to give back D to whoever wants to be it or something. (it). Adolescent spermage = D. OK? You stroked your dick, found yourself amused by it. Tell me, keepers of D/Dness, what amazing things should we notice (or not!) about your masturbations? That there is a never-ending supply of kids who will have penises and wank? Is not D the holy shrine to endless wanking? More skateboard parks! Yeah man! Then, after we skate, we wank!
Re: References in D
void main()
{
void* x = a(b());
c();
while(goobledegook)
{
x = p();
d(x);
}
e(x); /+ Crash! x is null. +/
}
Where did x's null value come from? Not a. Not p; the while
loop happened to be never executed. To say b would be
closer, but still imprecise. Actually it was created in the
q() function that was called by u() that was called by b()
which then created a class that held the null value and was
passed to a() that then dereferenced the class and returned the
value stored in the class that happened to be null. nulls
create very non-local bugs, and that's why they frustrate me to
no end sometimes.
Since this thread's attracted lots of commotion I thought I'd
just drop by and +1 for non-nullable types, and +1 for your
arguments.
I keep wondering, though, if it is 'enough' to solve the null
problem, or if it would be possible to devise a more general
mechanism for solving other problems too, like say, the fact that
certain integers have to always be positive, or if you want to go
more general, that a certain relationship must hold between two
structures...
Not having used D's invariants so far (well, I haven't used D
itself for a real project actually)... what's stopping D's
invariant mechanism from handling all this?
http://dlang.org/class.html#invariants (as is typical of D
documentation, this says nothing about invariants on structs, but
the page about structs says that they support invariants with an
X.)
I mean, problems are detected at runtime this way, and slightly
too late, but still, it would be better than most popular
languages that can't do anything about nulls at all. Since D's
devs don't even seem to have enough time to implement D as
described in TDPL (published more than two years ago), I wouldn't
expect to see this feature in the D language in the near future.
When will we have std.log?
It has been suspended for a long time. Any plan?
Re: References in D
On 10/07/2012 02:22 AM, David Piepgrass wrote:
void main()
{
void* x = a(b());
c();
while(goobledegook)
{
x = p();
d(x);
}
e(x); /+ Crash! x is null. +/
}
Where did x's null value come from? Not a. Not p; the while loop
happened to be never executed. To say b would be closer, but still
imprecise. Actually it was created in the q() function that was called
by u() that was called by b() which then created a class that held the
null value and was passed to a() that then dereferenced the class and
returned the value stored in the class that happened to be null. nulls
create very non-local bugs, and that's why they frustrate me to no end
sometimes.
Since this thread's attracted lots of commotion I thought I'd just drop
by and +1 for non-nullable types, and +1 for your arguments.
I keep wondering, though, if it is 'enough' to solve the null problem,
or if it would be possible to devise a more general mechanism for
solving other problems too, like say, the fact that certain integers
have to always be positive, or if you want to go more general, that a
certain relationship must hold between two structures...
I agree.
Not having used D's invariants so far (well, I haven't used D itself for
a real project actually)... what's stopping D's invariant mechanism from
handling all this?
http://dlang.org/class.html#invariants (as is typical of D
documentation, this says nothing about invariants on structs, but the
page about structs says that they support invariants with an X.)
I mean, problems are detected at runtime this way, and slightly too
late, but still, it would be better than most popular languages that
can't do anything about nulls at all. Since D's devs don't even seem to
have enough time to implement D as described in TDPL (published more
than two years ago), I wouldn't expect to see this feature in the D
language in the near future.
Invariants might work... create a proxy struct and then have assignment
always check the invariant. I don't like the idea that they get removed
during release mode. I'd like to be able to control which checks I pay
for. I think this might just mean that the important thing is
overloading assignment to do checks, which could be done in principle,
and this could work without invariants and thus give the desired control.
I just haven't had much luck creating proxy types in the past. As of
some months ago, D just wasn't there yet. :(
In another post in this thread I mentioned something similar:
It would be cool to have templates like this:
51. bool isPrime(int val)
52. {
53. ...
54. }
101. Watch!(int,isPrime) primeNumber = primeGenerator();
102. primeNumber = 8;
103. doStuff();
104. checkPrime(primeNumber); /+ Crash! +/
Error: checkPrime(primeNumber): primeNumber is not prime.
primeNumber: isPrime returned false after assignment at
(foobar.d, line 102)
~or~
101. Constrain!(int,isPrime) primeNumber = primeGenerator();
102. primeNumber = 8; /+ Crash! +/
103. doStuff();
104. checkPrime(primeNumber);
foobar.d, line 102: isPrime returned false after assignment.
For convenience one could define this:
alias Constrain!(int,isPrime) PrimeInt;
Maybe these could be turned on/off in release mode on a case-by-case
basis. I would probably leave the checks and tracking in always, with
the one exception of code that has been shown (with profiling) to need
the extra performance.
Re: Preliminary submission - std.rational and std.typelist
On Sat, Oct 6, 2012 at 8:01 PM, Arlen arlen...@gmx.com wrote:
I'm not sure if TypeTuples work well when doing things like dimensional
analysis. For example, if you have two TypeTuples, A and B, what would the
signature of the metafunction to merge the two look like?
template Merge(A, B) { }
won't work, and neither will
template Merge(alias A, alias B) { }
and you certainly can't do something like
template Merge(AB...) { }
Double-stage templates (which reminds me of rocket science :) )
template Merge(A...)
{
template With(B...)
{ }
}
Usage:
Merge!(int,double,string).With!(double,byte)
Re: Preliminary submission - std.rational and std.typelist
On Sat, Oct 6, 2012 at 8:32 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: Your current code may have some bad impact on performance: return ( ~ to!string(res.numerator) ~ / ~ to!string(res.denominator) ~ ); Allocates 4 times. ~ operator is convenient shortcut to get job done but it's unsuitable for building strings and formatted output. And the solution is?
Re: Preliminary submission - std.rational and std.typelist
On Sat, Oct 6, 2012 at 11:52 PM, Arlen arlen...@gmx.com wrote:
#1
template Foldl(alias Fun, Z, alias TL) { }
This is called when dealing with 1-dimensional typelists. For example:
alias Foldl!(MyFun, char, TL) R1; // where TL is, e.g.,
TypeList!(int, char, double)
#2
template Foldl(alias Fun, alias Z, alias TL) { }
This is called when dealing with 2-dimensions or higher. For example:
I had a similar project a few years ago. Here it is:
https://github.com/PhilippeSigaud/dranges/blob/master/typetuple.d
and, somewhat related, to show what can be done with type tuples in D
(regular expressions on types)
https://github.com/PhilippeSigaud/dranges/blob/master/typepattern.d
Re: The sorry state of the D stack?
denizzzka wrote: https://github.com/denizzzka/dpq2 Thank you very much. I think I haven't seen this project. Would you like to add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL Best regards, Thomas Koch
Re: Preliminary submission - std.rational and std.typelist
On Sunday, 7 October 2012 at 07:36:08 UTC, Philippe Sigaud wrote: On Sat, Oct 6, 2012 at 8:32 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: Your current code may have some bad impact on performance: return ( ~ to!string(res.numerator) ~ / ~ to!string(res.denominator) ~ ); Allocates 4 times. ~ operator is convenient shortcut to get job done but it's unsuitable for building strings and formatted output. And the solution is? Appender and formattedWrite can do this with a minimal amount of memory allocations. The best solution is of course the writeTo function from DIP9 [1], which hasn't been accepted yet for some reason. [1] http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote: On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: - I looked for a PostgreSQL client library. I found small personal hacks and dead projects. https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits. Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? From the example I assume that this is just a library for managing connections and that everything else is just string-based SQL statements. Groovy's and Python's lowest level is roughly the same. However on top of these are expression languages in Groovy / Python so as to remove the reliance on string processing, i.e. use an internal DSL to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it will hopefully be GSQL. I am sure Scala and C++ have something similar? So I guess the question is how to ensure this all works with all SQL systems and how to put an abstraction layer over this to avoid all the error prone string manipulation? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
DMD 2.060
Any news on the regressions relating to threads in the 2.059 → 2.060 change? Is a 2.061 with fixes pending? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Is flags enum needed in Phobos?
06.10.2012 23:50, Era Scarecrow пишет:
On Wednesday, 26 September 2012 at 19:11:37 UTC, bearophile wrote:
I think it's a good idea to have a well written EnumFlags data
structure in Phobos. In C# this feature is even built-in. So issue
6946 is not closing, unless Andrei or Walter decide it's a bad idea to
have something like this in Phobos.
I've written one I believe if sufficient and am using in my current
project. I'll add more to my branch as time goes on.
https://github.com/rtcvb32/Side-Projects
example in documentation
[code]
enum ETEST {none = 0, one = 1, two = 2, three = 3, four = 4}
handle_flags!(ETEST, int) ftest;
ftest.set_flag(ETEST.two);//check flag setting
assert(ftest.state == 2);//int and enum compares.
assert(ftest.state == ETEST.two);
ftest.set_flag(ETEST.four);//set second flag
assert(ftest.state == 6);//2+4, no 6 enum.
//Flags can also encompass multiple bits.
//in this case all bits returned with an
//AND must match the flag.
ftest.state = 1;
assert(!ftest.checkAll(one, two, three)); //can't be true, only 1 is
there
ftest.state = 3;
assert(ftest.checkAll(one, two, three)); //must be true, since 1+2
includes 3.
[/code]
Feel free to scrutinize and offer suggestions.
Although it doesn't appear to be mentioned, you can also shorthand the
flag with your alias. So ftest.one would be the same as ETEST.one or
ftest.Enum.one. I recommend using with when you are using such flags.
I'd like to see enum syntax for flug enum. So I dislike function calls
like `set_flag`, `checkAll`, etc. (IMHO)
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Preliminary submission - std.rational and std.typelist
On 07-Oct-12 12:10, Jakob Ovrum wrote:
On Sunday, 7 October 2012 at 07:36:08 UTC, Philippe Sigaud wrote:
On Sat, Oct 6, 2012 at 8:32 PM, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
Your current code may have some bad impact on performance:
return ( ~ to!string(res.numerator) ~ / ~
to!string(res.denominator) ~
);
Allocates 4 times. ~ operator is convenient shortcut to get job done but
it's unsuitable for building strings and formatted output.
And the solution is?
Appender and formattedWrite can do this with a minimal amount of memory
allocations.
The best solution is of course the writeTo function from DIP9 [1], which
hasn't been accepted yet for some reason.
[1] http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
Ehem.. I've been pushing for DIP9 a lot of time. But then I find out
that it is already here (and been for some time).
Like I said use a special overload of toString that is exactly writeTo.
Just define method with this signature:
void toString(scope void delegate(const(char)[]) sink)
And bingo! It's used in all of formatting stuff like write(f)(ln),
format, formattedWrite etc.
e.g. before posting I played with this:
import std.stdio, std.format;
struct A{
int k;
void toString(scope void delegate(const(char)[]) sink)
{
formattedWrite(sink, [%d], k);
}
}
void main(){
A a = A(90);
writeln(a);
}
--
Dmitry Olshansky
Re: Preliminary submission - std.rational and std.typelist
On 07-Oct-12 11:23, Philippe Sigaud wrote:
On Sat, Oct 6, 2012 at 8:01 PM, Arlen arlen...@gmx.com wrote:
I'm not sure if TypeTuples work well when doing things like dimensional
analysis. For example, if you have two TypeTuples, A and B, what would the
signature of the metafunction to merge the two look like?
template Merge(A, B) { }
won't work, and neither will
template Merge(alias A, alias B) { }
and you certainly can't do something like
template Merge(AB...) { }
Double-stage templates (which reminds me of rocket science :) )
template Merge(A...)
{
template With(B...)
{ }
}
Usage:
Merge!(int,double,string).With!(double,byte)
Rox!
--
Dmitry Olshansky
Re: Is flags enum needed in Phobos?
On Sunday, 7 October 2012 at 09:22:17 UTC, Denis Shelomovskij
wrote:
I'd like to see enum syntax for flug enum. So I dislike
function calls like `set_flag`, `checkAll`, etc. (IMHO)
You mean... binary basic syntax? That shouldn't be too hard. So
something like..?
Flags x;
with(Flags) {
x += one; //setflag
x -= two; //clearflag
x ^= four;//flipflag
x += [one,two]; //set flags multiple, same with flipping and
clearing
x -= [one,two];
x ^= [one,two];
//append ~ seemingly would be unused, or equal to +
x = one; //reset completely to flag 'one'
assert(x[one]); //checking, feels like an AA
assert(!x[two]);
x[two] = true; //optionally secondary way to set flag
assert(x[one, two]); //only true if both are set.
Flags y, z;
z = x y; //keep only flags within y
z = x | y; //copy flags of both x y
z = x ^ y; //flip flags in x from y
}
This wouldn't be hard to add, but I was going for basic
functionality, the extras are easy to use/add afterwards :)
Probably for individual flags I'd use a template so when you
optimize it will give you the smallest executing size for your
results. Hmmm...
The else is the only one I'm seeing a problem implementing
easily, although using the built in types you can do it yourself.
I'm not going to add odd binary operators if it doesn't make
sense (Like shifting appending or slicing).
Re: Preliminary submission - std.rational and std.typelist
On Sunday, 7 October 2012 at 09:27:54 UTC, Dmitry Olshansky wrote:
Ehem.. I've been pushing for DIP9 a lot of time. But then I
find out that it is already here (and been for some time).
Like I said use a special overload of toString that is exactly
writeTo.
Just define method with this signature:
void toString(scope void delegate(const(char)[]) sink)
And bingo! It's used in all of formatting stuff like
write(f)(ln), format, formattedWrite etc.
e.g. before posting I played with this:
import std.stdio, std.format;
struct A{
int k;
void toString(scope void delegate(const(char)[]) sink)
{
formattedWrite(sink, [%d], k);
}
}
void main(){
A a = A(90);
writeln(a);
}
Nice! I didn't know that. I thought this toString signature was
only used by BigInt, and not taken advantage of by other routines.
To implement it fully we would still want to change toString for
classes, and probably do something like providing a UFCS function
in object.toString or some other relevant location for
convenience and backwards compatibility.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 09:07:39 UTC, Russel Winder wrote: On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote: On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: - I looked for a PostgreSQL client library. I found small personal hacks and dead projects. https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits. Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? Probably if someones needs work to be done in ie PostreSQL won't care about other DBMS at the time of being. There are other projects for Database handling. - There is SQLd [http://github.com/robik/sqld], that focus on multiple database drivers. Some designs flaws are inherited from SQLAlchemy. Looks promising. - There is DBMI on DSource. I am not 100% sure if it works with D2 tho (but porting should be rather trivial). - Many, many other projects like that shattered on Github/BitBucket/DSource(?) From the example I assume that this is just a library for managing connections and that everything else is just string-based SQL statements. Groovy's and Python's lowest level is roughly the same. However on top of these are expression languages in Groovy / Python so as to remove the reliance on string processing, i.e. use an internal DSL to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it will hopefully be GSQL. I am sure Scala and C++ have something similar? So I guess the question is how to ensure this all works with all SQL systems and how to put an abstraction layer over this to avoid all the error prone string manipulation? Probably because of reason I mentioned before. But yeah, after first glance it looks like project ready for some bigger tasks
Re: The sorry state of the D stack?
On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton Wakeling wrote: On 10/06/2012 10:59 PM, Nick Sabalausky wrote: Definitely not. *DSource* is dying, unfortunately, which has lead some people to assume the same of the rest of D. But no, D is going very strong, and has only been getting bigger. Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org? +1 Getting tired of people heading to dsource and assuming that D is dead.
Re: SQL working [ was Re: The sorry state of the D stack? ]
Russel Winder wrote: On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote: On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: - I looked for a PostgreSQL client library. I found small personal hacks and dead projects. https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits. Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I wrote a PostgreSQL client too, but I also want to make MySQL and SQlite clients/wrappers and release them all at once. This is because I want to create uniform DB interface, and it must be suited for all database systems. I started with PostgreSQL because it's most complex of the three, for instance it supports array and struct fields. From the example I assume that this is just a library for managing connections and that everything else is just string-based SQL statements. Groovy's and Python's lowest level is roughly the same. However on top of these are expression languages in Groovy / Python so as to remove the reliance on string processing, i.e. use an internal DSL to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it will hopefully be GSQL. I am sure Scala and C++ have something similar? As you've said, additional DSL/Abstract layer must be on built on the string based library. We should finish that first.
Re: Preliminary submission - std.rational and std.typelist
On Sunday, October 07, 2012 11:37:30 Jakob Ovrum wrote: To implement it fully we would still want to change toString for classes, and probably do something like providing a UFCS function in object.toString or some other relevant location for convenience and backwards compatibility. Well, considering that we're looking at removing toString, toHash, opCmp, and opEquals from Object entirely, that probably won't be necessary. But that particular plan hasn't gotten past the initial discussions AFAIK, so who knows exactly how it's going to go or when it's going to happen. - Jonathan M Davis
Re: The sorry state of the D stack?
On Sunday, October 07, 2012 11:43:21 Peter Alexander wrote: On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton Wakeling wrote: On 10/06/2012 10:59 PM, Nick Sabalausky wrote: Definitely not. *DSource* is dying, unfortunately, which has lead some people to assume the same of the rest of D. But no, D is going very strong, and has only been getting bigger. Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org? +1 Getting tired of people heading to dsource and assuming that D is dead. Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all. - Jonathan M Davis
Re: Struct polymorphism?
On Sunday, 7 October 2012 at 10:04:57 UTC, Era Scarecrow wrote: 1) struct size can't size (no loss of data). 1) struct sizes and structures can't change (no loss of data)
Struct polymorphism?
What are the possibilities of struct polymorphism? What would be the issues with it? What if we wanted to use it in a limited sense? Currently I'm experimenting with it since classes are too bulky for what I need, yet I really need some type of behavior/dynamic polymorphism. So far I have a working model. It takes the following limitations: 1) struct size can't size (no loss of data). 2) every structure aside from the original needs a copy of the original (and only that) 3) original structure needs an enum specifying behavior mode 4) Template instantiation cannot be used (although automatic type deduction works). Using these and limiting it seems like it would sort of bring back C++'s design of classes, only better, simpler, and more powerful. It won't have an actual full virtual table as everything is known statically ahead of time, with only minor checks by opDispatch to determine which function set to run. Issues: 1) the base/original struct always calls it's own functions. A little work and I can probably remove that limitation, but the original struct would end up being only storage with no behavior at all. 2) Template instantiation. This is a limitation in opDispatch() where calling through it. As shows below. Maybe I'm just using opDispatch wrong. //signatures lacking structs auto ref opDispatch(string fun, Args ...)(auto ref Args args) @property; I templateType2(string val1, I)(I val); //call ps.templateType2!Extra Extra!(50); Error: ps.opDispatch!(templateType2) isn't a template Beyond this it seems to have some potential. Thoughts? Ideas?
Re: opCall/ctor partially sorted out
On 10/07/12 04:24, bearophile wrote:
Recently one of the most important bugs was mostly fixed, beside Win64
support this is one of the most important changes in dmd 2.061:
http://d.puremagic.com/issues/show_bug.cgi?id=6036
Do you think this has to be correct code?
struct Adder {
int v;
int opCall(int x) { return x + v; }
}
void main() {
auto a = Adder(5);
}
Yes, with resulting a.v==5.
This should result in an int == 42:
auto a = Adder(37)(5);
'static' either needs to be handled properly or another op needs to be
introduced - opStaticCall(). Which might look like a hack, but doing it
like that may be simpler to implement and relatively harmless (as the
aggregate.op* namespace has to be treated as reserved in practice).
Also, the type and instance methods shouldn't form an overload set, so
separating them is a good idea (a matching non-static opCall must always
take precedence).
Calling the static-opCall (either opStaticCall or the normal 'static
opCall', if/when that one works properly) with an instance should work.
(not doing this would need changes to how the null-checking is done
and likely cause other problems that i can't think of right now)
artur
Re: Preliminary submission - std.rational and std.typelist
On Sunday, 7 October 2012 at 09:58:54 UTC, Jonathan M Davis wrote: Well, considering that we're looking at removing toString, toHash, opCmp, and opEquals from Object entirely, that probably won't be necessary. But that particular plan hasn't gotten past the initial discussions AFAIK, so who knows exactly how it's going to go or when it's going to happen. - Jonathan M Davis This is definitely something I would like to happen.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 09:56:30 UTC, Piotr Szturmaj wrote: Russel Winder wrote: On Sun, 2012-10-07 at 00:35 +0200, denizzzka wrote: On Saturday, 6 October 2012 at 12:06:07 UTC, Thomas Koch wrote: - I looked for a PostgreSQL client library. I found small personal hacks and dead projects. https://github.com/denizzzka/dpq2 This is my personal project but it is not dead, and I am determined to see it through. At the moment, it is quite suitable to be used in simple situations. Compiles without warnings by dmd 2.060, also it can be used with rdmd. I really need users, comments, suggestions, bug reports and commits. Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I wrote a PostgreSQL client too, but I also want to make MySQL and SQlite clients/wrappers and release them all at once. This is because I want to create uniform DB interface, and it must be suited for all database systems. I started with PostgreSQL because it's most complex of the three, for instance it supports array and struct fields. I would also look at commercial DB, otherwise you might still find a few surprises while defining an uniform DB. I went through that pain back in 1999-2001, when we were defining an abstraction mechanism in TCL/C to bind to multiple databases, akin to ActiveRecord on Ruby. For example, on those days using only ODBC was not enough for SQL Server 6. We also needed to make use of another binding provided for compatibility with Sybase SQL Server, to be able to offer all the same API when using SQL Server as DB. That took awhile to figure out how to integrate into the existing architecture. -- Paulo
Re: Feature request: extending comma operator's functionality
On Friday, 5 October 2012 at 13:47:00 UTC, monarch_dodra wrote:
On Friday, 5 October 2012 at 00:22:04 UTC, Jonathan M Davis
wrote:
On Friday, October 05, 2012 02:08:14 bearophile wrote:
[SNIP]
Regarding definition of variables in D language constructs,
there
is one situation where sometimes I find D not handy. This code
can't work:
do {
const x = ...;
} while (predicate(x));
You need to use:
T x;
do {
x = ...;
} while (predicate(x));
Yeah. That comes from C/C++ (and is the same in Java and C#, I
believe). I
don't know why it works that way. It's definitely annoying.
[SNIP]
- Jonathan M Davis
Because it's the only way to guarantee that x exits when you
reach the end of the loop.
do {
if(true) continue; //Yawn... skip.
const x = ... ;
} while (predicate(x)); //What's x?
Basic goto limitations. Unlike goto though, inserting a
continue should never create a compile error, so the compiler
*has* to guarantee that the if condition references nothing
inside its own block.
It is annoying, but nothing that can't be fixed with a scope
bloc.
There is a simple way around this... which addresses both
concerns raised...
1. Semantics of old code is unchanged.
2. no issue with 'continue'
do(const x = ...)
{
}
while(predicate(x));
Re: DMD 2.060
On 10/7/2012 3:12 AM, Alex Rønne Petersen wrote: On 07-10-2012 11:11, Russel Winder wrote: Any news on the regressions relating to threads in the 2.059 → 2.060 change? Is a 2.061 with fixes pending? I'm still not clear on what these regressions are? A list of relevant bugzilla entries would be illuminating.
Re: The sorry state of the D stack?
On 2012-10-07 00:14, Nick Sabalausky wrote: I don't know about the rest of DSSS as I only ever used the 'rebuild' component. But as for rebuild, there are problems: For one thing, 0.76 is generally considered to work much better than 0.77 and the final version, 0.78 (I forget the details, but a lot of people including me have had problems with 0.78 that never showed up with 0.76). But despite that, read-made builds aren't available for 0.76. As DSSS is dead none of this is likely to get fixed. And there's no reason to fix rebuild since RDMD is a superior and non-dead alternative to rebuild. I'm still using 0.75, when I'm using it. Also, rebuild is slow, even with one at a time disabled. Try compiling DVM with the included rebuild-based script and the RDMD-based one. It takes a fair amount of time with rebuild (even with one at a time off), but with RDMD it's almost instant. I'm well aware that RDMD is a lot faster than Rebuild. There's no reason for anyone to use rebuild anymore, and very few people do. Maybe not only Rebuild, but DSSS offers more than RDMD. DSSS supports building libraries, build files, generating documentation and other features. With RDMD you must likely need a shell script for the build flags. Shell scripts aren't cross-platform which means you need a .bat file on Windows. That will result in duplication which is not good. So does RDMD, unless I'm mistaken. Yes, but there are still reasons to use DSSS for D1, see above. -- /Jacob Carlborg
Re: DMD 2.060
On Sun, 2012-10-07 at 03:39 -0700, Walter Bright wrote: On 10/7/2012 3:12 AM, Alex Rønne Petersen wrote: On 07-10-2012 11:11, Russel Winder wrote: Any news on the regressions relating to threads in the 2.059 → 2.060 change? Is a 2.061 with fixes pending? I'm still not clear on what these regressions are? A list of relevant bugzilla entries would be illuminating. I can't find the ones I submitted on 2.060 release, so I just added a couple more 8774 and 8775. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: The sorry state of the D stack?
On Sun, 07 Oct 2012 02:51:42 -0700 Jonathan M Davis jmdavisp...@gmx.com wrote: On Sunday, October 07, 2012 11:43:21 Peter Alexander wrote: On Saturday, 6 October 2012 at 21:19:58 UTC, Joseph Rushton Wakeling wrote: Might be worth placing some prominent message on DSource stating that it's being maintained to document all the D1 work and projects, but that the active work is now over at dlang.org? +1 Getting tired of people heading to dsource and assuming that D is dead. Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all. No, I think he'd just been busy. I've seen him around here a few times lately.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On 2012-10-07 10:55, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? From the example I assume that this is just a library for managing connections and that everything else is just string-based SQL statements. Groovy's and Python's lowest level is roughly the same. However on top of these are expression languages in Groovy / Python so as to remove the reliance on string processing, i.e. use an internal DSL to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it will hopefully be GSQL. I am sure Scala and C++ have something similar? They do. So I guess the question is how to ensure this all works with all SQL systems and how to put an abstraction layer over this to avoid all the error prone string manipulation? ActiveRecord in Ruby on Rails uses several layers to handle all database related functionality. At the highest level there's a DSL which allows you to write the SQL queries mostly in Ruby. Another library, ARel, is used by ActiveRecord to generate the SQL code from the DSL. ARel handles all the differences among all the supported databases. ARel then passes the SQL code back to ActiveRecord where a lower layer handles the connections to the database and performs the actual query. Then you have another layer that transforms the response into objects, sets up all the relations and so on. -- /Jacob Carlborg
Re: It seems pure ain't so pure after all
Am Tue, 02 Oct 2012 09:38:56 +0200 schrieb Don Clugston d...@nospam.com: Any code that behaves differently when compiled with -O, will do this as well. Constant folding of floating point numbers does the same thing, if the numbers are represented in the compiler in a different precision to how the machine calculates them. I believe that GCC, for example, uses very much higher precision (hundreds of bits) at compile time. I'm not an expert, but I would have thought compilers strive to be IEEE compliant - whatever that means in detail. I've seen a compression algorithm that relies on exact floating-point semantics and accuracy. It would just fail, if compilers were creative or lax at certain optimization levels. (excluding the I know what I am doing -ffast-math.) -- Marco
Re: SQL working [ was Re: The sorry state of the D stack? ]
Jacob Carlborg wrote: On 2012-10-07 10:55, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? From the example I assume that this is just a library for managing connections and that everything else is just string-based SQL statements. Groovy's and Python's lowest level is roughly the same. However on top of these are expression languages in Groovy / Python so as to remove the reliance on string processing, i.e. use an internal DSL to do all the SQL stuff. For Python this is SQLAlchemy, for Groovy it will hopefully be GSQL. I am sure Scala and C++ have something similar? They do. So I guess the question is how to ensure this all works with all SQL systems and how to put an abstraction layer over this to avoid all the error prone string manipulation? ActiveRecord in Ruby on Rails uses several layers to handle all database related functionality. At the highest level there's a DSL which allows you to write the SQL queries mostly in Ruby. Another library, ARel, is used by ActiveRecord to generate the SQL code from the DSL. ARel handles all the differences among all the supported databases. ARel then passes the SQL code back to ActiveRecord where a lower layer handles the connections to the database and performs the actual query. Then you have another layer that transforms the response into objects, sets up all the relations and so on. Having distinct layers that don't know each other isn't always a good idea. In my prostgres client one may specify field types at compile time. If I had divided the client into two separate layers it would return a Variant[] at first layer, then convert it to user specified tuple at the second. For example: auto cmd = new SqlCommand(connection, SELECT 1, 'abc'); auto untypedRow = connection.executeRow(); // return DBRow!(Variant[]) auto typedRow = connection.executeRow!(int, string)(); // returns DBRow!(int, string); Internally executeRow could always take a Variant[], then convert it to Tuple!(int, string), but it's suboptimal. Firstly, it must allocate an array of two Variants, then each Variant must be coerced to the corresponding type. Instead, the client fills each of the tuple field directly as they come from the socket stream. With binary formatting all it has to do is swapEndian() on integers and floats (no parsing!). Of course, there's one allocation for the string, but if we change field type to char[4], there'll be no allocation at all. Just wanted to illustrate that layers shouldn't always be separate.
Re: RFC: DConf 2013
On 1 October 2012 19:25, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: The project is not live, it will be within a few days. In the spirit of having the community actively participate, I'm making this as transparent as it gets. Please comment: http://www.kickstarter.com/**projects/dlang/1177501541?**token=df96761ahttp://www.kickstarter.com/projects/dlang/1177501541?token=df96761a Your feedback and suggestions are welcome. Seems like a big budget, what are the projected numbers? (10s? 100s? ... 1000s?) ;)
Re: opCall/ctor partially sorted out
Recently one of the most important bugs was mostly fixed, beside Win64 support this is one of the most important changes in dmd 2.061: http://d.puremagic.com/issues/show_bug.cgi?id=6036 Next important bug to focus on is (in my top5 bug list): http://d.puremagic.com/issues/show_bug.cgi?id=3789 Bye, bearophile
Re: RFC: DConf 2013
On 7 October 2012 00:20, Era Scarecrow rtcv...@yahoo.com wrote: On Wednesday, 3 October 2012 at 17:08:25 UTC, Andrei Alexandrescu wrote: I hear you. We have a detailed budget model and we're not splurging in any way. Organizing a conference has quite a few odds and ends and weird pricing. As an example, location providers offer good prices for the location proper BUT they require using their own catering services, which is how they make money. I co-organized a few conferences and, believe me, a cookie has a different taste when you know it was $5. That being said, if anyone on this forum works in the Bay Area and takes this to their employer, we'd save a ton of expenses if a company could offer a meeting room. I have initiated such with Facebook, and they're looking into it. All - please email me if such an opportunity exists. Depending on how many people would be attending, and I'm sure most of us are far enough away that a place to stay becomes a question. A quick glance suggests room swill be anywhere from $80-$200, and if it hits tourist season that number can double (or triple) easily. I'd rather bring a tent and pitch up on a golf course. :-) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: SQL working [ was Re: The sorry state of the D stack? ]
Having distinct layers that don't know each other isn't always a good idea. Just wanted to illustrate that layers shouldn't always be separate. Actually I'm not sure how separate they are in ActiveRecord. I wanted to mostly point out that generating the SQL was done by a separate library. -- /Jacob Carlborg
Re: RFC: DConf 2013
On 10/7/12 8:42 AM, Manu wrote: On 1 October 2012 19:25, Andrei Alexandrescu seewebsiteforem...@erdani.org mailto:seewebsiteforem...@erdani.org wrote: The project is not live, it will be within a few days. In the spirit of having the community actively participate, I'm making this as transparent as it gets. Please comment: http://www.kickstarter.com/__projects/dlang/1177501541?__token=df96761a http://www.kickstarter.com/projects/dlang/1177501541?token=df96761a Your feedback and suggestions are welcome. Seems like a big budget, what are the projected numbers? (10s? 100s? 1000s?) ;) The budget would cover around 55 attendees for 3 days. That includes (in decreasing order of cost) food, conference space, speaker support, A/V, staff remuneration, T-shirts/swag, and many smaller items. Andrei
Re: Preliminary submission - std.rational and std.typelist
On Sun, Oct 7, 2012 at 11:15 AM, Dmitry Olshansky dmitry.o...@gmail.com wrote:
import std.stdio, std.format;
struct A{
int k;
void toString(scope void delegate(const(char)[]) sink)
{
formattedWrite(sink, [%d], k);
}
}
I see, thanks. And if the string in formattedWrite is a complex beast,
created through lots of if's and while's, I use Appender in its place?
Re: Preliminary submission - std.rational and std.typelist
On Sunday, 7 October 2012 at 15:36:52 UTC, Philippe Sigaud wrote: I see, thanks. And if the string in formattedWrite is a complex beast, created through lots of if's and while's, I use Appender in its place? Ideally, you just write to the sink directly, piece by piece – but if for some reason you _need_ to have one big format string, then yes, prefer using Appender over string concatenation. David
Re: Feature request: extending comma operator's functionality
On 10/05/2012 03:35 PM, monarch_dodra wrote:
On Friday, 5 October 2012 at 00:22:04 UTC, Jonathan M Davis wrote:
On Friday, October 05, 2012 02:08:14 bearophile wrote:
[SNIP]
Regarding definition of variables in D language constructs, there
is one situation where sometimes I find D not handy. This code
can't work:
do {
const x = ...;
} while (predicate(x));
You need to use:
T x;
do {
x = ...;
} while (predicate(x));
Yeah. That comes from C/C++ (and is the same in Java and C#, I
believe). I
don't know why it works that way. It's definitely annoying.
[SNIP]
- Jonathan M Davis
Because it's the only way to guarantee that x exits when you reach the
end of the loop.
s/only/simplest/
do {
if(true) continue; //Yawn... skip.
const x = ... ;
} while (predicate(x)); //What's x?
Basic goto limitations. Unlike goto though, inserting a continue
should never create a compile error, so the compiler *has* to guarantee
that the if condition references nothing inside its own block.
It is annoying, but nothing that can't be fixed with a scope bloc.
Re: The sorry state of the D stack?
Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all. No, I think he'd just been busy. I've seen him around here a few times lately. Are you sure about that? There is a guy named Brad Anderson posting here, but he doesn't seem to be the Brad Anderson that dsource.org is registered to.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Perhaps better as something in Deimos rather than Phobos, as I imagine it would bring in a bunch of external dependencies that the standard library shouldn't really have. Am I right that there's something in Adam Ruppe's web modules that's heading in this direction?
Re: Preliminary submission - std.rational and std.typelist
On 10/07/12 17:24, Philippe Sigaud wrote:
On Sun, Oct 7, 2012 at 11:15 AM, Dmitry Olshansky dmitry.o...@gmail.com
wrote:
import std.stdio, std.format;
struct A{
int k;
void toString(scope void delegate(const(char)[]) sink)
{
formattedWrite(sink, [%d], k);
}
}
I see, thanks. And if the string in formattedWrite is a complex beast,
created through lots of if's and while's, I use Appender in its place?
You can write to the sink directly, eg
struct EnumBits(alias E) {
E e;
alias e this;
void toString(DG, FT)(scope DG sink, in FT fmt) const {
import std.format;
sink(E.stringof ~ {);
int wrote;
foreach (member; __traits(allMembers, E))
if (__traits(getMember, E, member) e){
if (wrote++) sink(|);
sink(member);
}
if (!wrote)
sink(/*No ~ E.stringof ~ */);
sink(});
}
}
It gets a bit more tricky when you for example need to print the
contents of containers w/o copying the data; but you can then just
call their toString method directly:
struct PTR_LIST(T, bool TAGGED=0) {
c_int nr;
PTR_LIST *prev;
PTR_LIST *next;
// ...
void toString(DG, FT)(scope DG sink, in FT fmt) const {
import std.format;
sink(typeof(cast()this).stringof ~ {[);
formatValue(sink, nr, fmt); sink(]);
foreach (p; this) {
p.toString(sink, fmt);
sink(, );
}
sink(});
}
static struct Anchor {
PTR_LIST* list;
// ...
void toString(DG, FT)(scope DG sink, in FT fmt) const {
import std.format;
// Cannot 'formatValue(sink, *list, fmt);' as the struct is passed
// by value and that messes up the list (head pointer doesn't
match).
list.toString(sink, fmt);
}
}
}
/* Obviously, i wasn't trying to avoid allocations, hence the presence of
'~'s. */
artur
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton Wakeling wrote: Am I right that there's something in Adam Ruppe's web modules that's heading in this direction? Yeah, though I'm a little biased toward mysql since that's what I use every day, so some of the stuff that should be in generic database.d are instead in mysql.d. But my stuff indeed does sql strings which can then be passed to a Database class with pretty uniform interface, at least for basic queries, for some major dbs. https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Among the string manipulation stuff is class DataObject, which builds an UPDATE or INSERT query: auto obj = new DataObject(db, table_name); obj.id = 10; obj.name = cool; obj.commitChanges(); /* runs: if(db.query(select id from table_name where id = 10).empty) db.query(insert into table_name (id, name) values (10, 'cool')); else db.query(UPDATE table_name set name = 'cool' where id = 10); */ and also a build data object subclass from sql create table which kinda works, ugly mixin stuff. And there's also a SelectBuilder which does basic concat stuff: auto query = new SelectBuilder(); query.table = something; query.fields ~= something.*; query.wheres ~= id ?0; db.query(query.toString(), 10); expands into select something.* from something where (id 10); Nothing super fancy but it works for me.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton Wakeling wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Perhaps better as something in Deimos rather than Phobos, as I imagine it would bring in a bunch of external dependencies that the standard library shouldn't really have. Am I right that there's something in Adam Ruppe's web modules that's heading in this direction? There was a std.database proposal from Steve Teale, but it appears to have died. http://prowiki.org/wiki4d/wiki.cgi?ReviewQueue It could work like in other languages with OO support. Everything is interface based and it is up to the respective driver to provide proper implementations. Those implementations can be provided either as static or dynamic libraries. The important thing are interfaces, as such you're not bringing external dependencies. Unless the D community decides to have the drivers as part of the language (comes with batteries kind of thing). -- Paulo
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 12:39:35 UTC, Piotr Szturmaj wrote: In my prostgres client one may specify field types at compile time. If I had divided the client into two separate layers it would return a Variant[] at first layer, then convert it to user specified tuple at the second. For example: auto cmd = new SqlCommand(connection, SELECT 1, 'abc'); auto untypedRow = connection.executeRow(); // return DBRow!(Variant[]) auto typedRow = connection.executeRow!(int, string)(); // returns DBRow!(int, string); Internally executeRow could always take a Variant[], then convert it to Tuple!(int, string), but it's suboptimal. Firstly, it must allocate an array of two Variants, then each Variant must be coerced to the corresponding type. Just wanted to illustrate that layers shouldn't always be separate. It's not a very convincing illustration. In practice the overhead of those operations would likely be completely insignificant compared to performing the actual database query. Avoiding intermediate layers for optimality's sake seems like a bad case of premature optimization to me.
Re: When will we have std.log?
On Sat, Oct 6, 2012 at 11:47 PM, domain do.m...@163.com wrote: It has been suspended for a long time. Any plan? I have been working on it in my spare time. I have fixed some basic API issues that were outlined during the review process but not enough to put it through another review process. std.log was originally implemented in a forked phobos repository but I has since create a separate repository so that it could be used even if it is not part of std/phobos. One of the main concerns with std.log is that it has to two different APIs for regular logging: fatal(), error(), info(), etc. and verbose logging: vlog(). I have played around with a different API that would merge the two. The old API is inspired by glog the new non-existing API is inspired by Rust logging. I just need to spend a couple of days to completely flush out the new API and run it by the community. Thanks, -Jose
Re: When will we have std.log?
This is great news. Really looking forward to a std.log module. /Jonas
object states
Imagine you want an image to keep the width of 512:
void func(Image img) {
assert(img.width == 512);
img.doSomething();
assert(img.width == 512);
while (img.somethingElse()) {
assert(img.width == 512)
someFunc(img);
assert(img.width == 512);
}
}
In theory, every call to a function can change the width of the
image. What do you think about this:
https://dl.dropbox.com/u/34762907/temp/prop1.html
I do know it can be implemented in D4 only.
Re: SQL working [ was Re: The sorry state of the D stack? ]
Thiez wrote: On Sunday, 7 October 2012 at 12:39:35 UTC, Piotr Szturmaj wrote: In my prostgres client one may specify field types at compile time. If I had divided the client into two separate layers it would return a Variant[] at first layer, then convert it to user specified tuple at the second. For example: auto cmd = new SqlCommand(connection, SELECT 1, 'abc'); auto untypedRow = connection.executeRow(); // return DBRow!(Variant[]) auto typedRow = connection.executeRow!(int, string)(); // returns DBRow!(int, string); Internally executeRow could always take a Variant[], then convert it to Tuple!(int, string), but it's suboptimal. Firstly, it must allocate an array of two Variants, then each Variant must be coerced to the corresponding type. Just wanted to illustrate that layers shouldn't always be separate. It's not a very convincing illustration. In practice the overhead of those operations would likely be completely insignificant compared to performing the actual database query. Avoiding intermediate layers for optimality's sake seems like a bad case of premature optimization to me. In my opinion everything counts. For thousands of rows x thousands of clients it certainly _should_ make a difference. And I wouldn't call it premature optimization, it's just _designed_ to be fast.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On 10/7/12 1:06 PM, Paulo Pinto wrote: The important thing are interfaces, as such you're not bringing external dependencies. Unless the D community decides to have the drivers as part of the language (comes with batteries kind of thing). Yah, this is a chicken-and-egg kind of thing. In many languages it's the database providers who provide the drivers, but in order for that to happen the language must be widespread enough. Andrei
Re: When will we have std.log?
On Sunday, 7 October 2012 at 18:32:06 UTC, jdrewsen wrote: This is great news. Really looking forward to a std.log module. +1 /Jonas
Re: RFC: DConf 2013
On Sunday, 7 October 2012 at 15:20:44 UTC, Andrei Alexandrescu wrote: Seems like a big budget, what are the projected numbers? (10s? 100s? 1000s?) ;) The budget would cover around 55 attendees for 3 days. That includes (in decreasing order of cost) food, conference space, speaker support, A/V, staff remuneration, T-shirts/swag, and many smaller items. Seems like a low number. I also assumed we would pack our own lunches, and food during the event would end up costing for 55 attendees is roughly $2000 (at least as an estimate). I figured the numbers would be closer to 200-300, but depending on how many speakers and how big the conference room... Just off hand I'm remembering that some hotels have a rentable room for conferences and meetings that may handle about 55 (Which sometimes is their continental breakfast area after the first thing in the morning), and assuming you wouldn't have a huge speaker system set up to disturb the normal customers in the lobby (assuming it's nearby) then in the case there isn't already a projector you can bring and set one up, although it wouldn't likely be too terribly big unless they have a blank white wall Mmmm... Having the meetings in the same hotel/motel you are staying it... Takes care of any commuting issue once you get settled in.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 17:06:31 UTC, Joseph Rushton Wakeling wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Each database engine has a unique distinguishing features that make this engine interesting. (for example, different implementations of transactions - SQL standard does not describe the SQL transactions precisely enough) So, I do not know is it possible to make a universal interface. And why it may need in real life?
Re: The sorry state of the D stack?
On Sunday, 7 October 2012 at 08:05:10 UTC, Thomas Koch wrote: denizzzka wrote: https://github.com/denizzzka/dpq2 Thank you very much. I think I haven't seen this project. Would you like to add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL I could not register there. :( Who have the opportunity, please add https://github.com/denizzzka/dpq2 to this wiki. Thank you!
Re: object states
On 10/07/2012 11:44 AM, Henning Pohl wrote:
Imagine you want an image to keep the width of 512:
void func(Image img) {
assert(img.width == 512);
img.doSomething();
assert(img.width == 512);
while (img.somethingElse()) {
assert(img.width == 512)
someFunc(img);
assert(img.width == 512);
}
}
In theory, every call to a function can change the width of the image.
What do you think about this:
https://dl.dropbox.com/u/34762907/temp/prop1.html
I do know it can be implemented in D4 only.
Sounds good. You haven't mentioned the invariant keyword, so perhaps you
are not aware of that feature?
http://dlang.org/class.html#Invariant
http://dlang.org/dbc.html
Although the docs seem to favor classes, invariant is available for
structs as well.
Ali
--
D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
Re: object states
On Sunday, 7 October 2012 at 20:18:15 UTC, Ali Çehreli wrote: Sounds good. Thanks. You haven't mentioned the invariant keyword, so perhaps you are not aware of that feature? http://dlang.org/class.html#Invariant http://dlang.org/dbc.html Although the docs seem to favor classes, invariant is available for structs as well. Ali How would you resolve the issue I wrote in my first post using invariants? You cannot add/remove checks from invariants while using the object. That's what I made different. But there are still some limits given by the language. Look at point 7 for instance. The problem about contract programming in general is you cannot use it in public library code. Distinction between logic and user input is a very important thing, we really need to improve this. You may have noticed that I did not make use of either assert or enforce. I didn't want to specify this.
Re: opCall/ctor partially sorted out
Le 07/10/2012 04:24, bearophile a écrit :
Recently one of the most important bugs was mostly fixed, beside Win64
support this is one of the most important changes in dmd 2.061:
http://d.puremagic.com/issues/show_bug.cgi?id=6036
Do you think this has to be correct code?
struct Adder {
int v;
int opCall(int x) { return x + v; }
}
void main() {
auto a = Adder(5);
}
Bye,
bearophile
opCall isn't static here. So it shouldn't be involved.
Re: The sorry state of the D stack?
On Sun, 07 Oct 2012 18:39:16 +0200 jerro a...@a.com wrote: Isn't part of the problem that no one can get ahold of the person who runs it? At least, that's what I remember being discussed previously. It was my understanding that that's why we've never been able to get dsource cleaned up or really changed at all. No, I think he'd just been busy. I've seen him around here a few times lately. Are you sure about that? There is a guy named Brad Anderson posting here, but he doesn't seem to be the Brad Anderson that dsource.org is registered to. Oh, I guess I don't know. I just noticed the name.
Re: RFC: DConf 2013
On Monday, 1 October 2012 at 16:25:12 UTC, Andrei Alexandrescu wrote: The project is not live, it will be within a few days. In the spirit of having the community actively participate, I'm making this as transparent as it gets. Please comment: http://www.kickstarter.com/projects/dlang/1177501541?token=df96761a Your feedback and suggestions are welcome. Thanks, Andrei How about any special online materials for backers that can't really attend? :) ( Those Europe-to-USA tickets do not tolerate poor students :( )
Re: The sorry state of the D stack?
On Sun, 07 Oct 2012 21:58:49 +0200 denizzzka 4deni...@gmail.com wrote: On Sunday, 7 October 2012 at 08:05:10 UTC, Thomas Koch wrote: denizzzka wrote: https://github.com/denizzzka/dpq2 Thank you very much. I think I haven't seen this project. Would you like to add it to this wiki page? http://www.prowiki.org/wiki4d/wiki.cgi?DatabaseBindings#PostgreSQL I could not register there. :( Who have the opportunity, please add https://github.com/denizzzka/dpq2 to this wiki. Thank you! You don't really register there, you just go here: http://www.prowiki.org/wiki4d/wiki.cgi?action=editprefsoldid=edit=DatabaseBindings Enter something UpperCamelCased for username (it requires at least two words for some odd reason, so Foobar won't work, but FooBar will), hit save preferences, and that's it.
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sun, 07 Oct 2012 18:54:17 +0200 Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 10/07/2012 10:55 AM, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? I don't have sufficient experience with SQL to be able to really make a judgement here, but is there a case for a std.sql or std.db that would provide a uniform D interface to the arbitrary DB of choice? Probably, yes. But someone needs to build such a lib first and then propose it as a std.db candidate. Perhaps better as something in Deimos rather than Phobos, as I imagine it would bring in a bunch of external dependencies that the standard library shouldn't really have. Not necessarily: Steve Teale's mysqln is a native D MySQL driver that connects to the DB server directly and bypasses MySQL's official client lib entirely. Teale has inexplicably disappeared off the face of the internet, but Vibe.d has adapted the lib for use with Vibe.d, and this guy has also made some updates: https://github.com/simendsjo/mysqln/tree/misc-cleanups I'm using that with Vibe.d and it seems to be working pretty well. (I'm not sure if the simendsjo version or the Vibe.d version is more up-to-date, though.)
Re: Preliminary submission - std.rational and std.typelist
On Sun, Oct 7, 2012 at 2:23 AM, Philippe Sigaud
philippe.sig...@gmail.com wrote:
Double-stage templates (which reminds me of rocket science :) )
template Merge(A...)
{
template With(B...)
{ }
}
Usage:
Merge!(int,double,string).With!(double,byte)
I can live with that, but, as I explained before, TypeTuples cause
code duplication in certain cases because they force 'alias' to be
used in the signature of the metafunctions.
And how would you return a multi-dimensional TypeTuple? The result of
certain metafunctions are multi-dimensional. For example,
Permutations and Combinations will return multi-dimensional
containers.
http://arlen.github.com/phobos/std_typelist2.html#Permutations
Re: Preliminary submission - std.rational and std.typelist
On Sunday, October 07, 2012 22:57:33 Arlen wrote: I can live with that, but, as I explained before, TypeTuples cause code duplication in certain cases because they force 'alias' to be used in the signature of the metafunctions. And how would you return a multi-dimensional TypeTuple? The result of certain metafunctions are multi-dimensional. For example, Permutations and Combinations will return multi-dimensional containers. http://arlen.github.com/phobos/std_typelist2.html#Permutations While this sort of function might be useful from time to time, how often is it actually, realistically needed? Certainly, I'd argue that it's rare enough that having a slightly more complicated solution specifically for it makes more sense than adding a whole new abstraction to the standard library. Adding something like TypeList on top of TypeTuple is generally overkill and overcomplicates things. TypeTuple will do almost everything that TypeList can. The question then is how to make TypeTuple do the parts that it can't currently do or how to provide a reasonable, alternate solution for those rare circumstances. Maybe a multi-dimensional wrapper for TypeTuple would be in order to handle those cases? Regardless, we previously decided that TypeList was unnecessary code duplication and an unnecessary cognitive burden. Everything you add to the standard library has a cost, even if it's valuable in and of itself, and adding something very similar to something else which is already there is that much worse, because then you have to understand the differences and constantly explain them to those who don't know. So, we're not adding TypeList. While I sympathize with your desire to get some of the functionality that TypeList provides and TypeTuple doesn't, please work with us to improve upon TypeTuple rather than trying to add something to Phobos that does almost the same thing as TypeTuple. In most cases, it's simply a matter of adding the appropriate templates to gain TypeList-like functionality on top of TypeTuple rather than adding TypeList, and we've even recently added (post-2.060) some of those templates to std.typetuple, thereby improving what can be done with std.typetuple. - Jonathan M Davis
Re: SQL working [ was Re: The sorry state of the D stack? ]
On Sunday, 7 October 2012 at 09:07:39 UTC, Russel Winder wrote: Why only PostgreSQL. Shouldn't it also work with MySQL, Oracle, DB2, PervasiveSQL, SQLite3, etc.? Good question. A wrong approach since we talk about DB support. Design the Interface first, would be the solution. Then decide what you want. DAL, or Active Record. Then create a DSL, or LINQ or whatsoever. Since you are a Python guy, the data access layer from web2py is simply excellent. But I doubt that D, respective phobos, will ever have more than rudimentary db support.
Re: Preliminary submission - std.rational and std.typelist
On Sat, Oct 6, 2012 at 1:32 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote: Cool, does it work with BigInt? No it doesn't work with BigInt, but I did look into it today briefly. There are issues with BigInt that I'm not sure what to do about: 1. To convert a BigInt to floating-point one needs to convert it to the built-in integer types first. If you go beyond the limits of the built-in types (long), then what's the point? You might as well be using int or long. 2. The functions in std.math don't support BigInt, and most likely never will. Even if they did, you would still need multi-precision floating point to store the irrational numbers. If you decided to use the built-in types, then again what's the point? You might as well go with int or long. Also I think there is better version of toString that has signature: void toString(scope void delegate(const(char)[]) sink) this toString just use functions like formattedWrite to write chars to sink. It thus totally avoids overhead of allocating strings. Your current code may have some bad impact on performance: return ( ~ to!string(res.numerator) ~ / ~ to!string(res.denominator) ~ ); Allocates 4 times. ~ operator is convenient shortcut to get job done but it's unsuitable for building strings and formatted output. Thanks, I'll fix it.
Re: Preliminary submission - std.rational and std.typelist
On Sun, Oct 7, 2012 at 11:16 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: While this sort of function might be useful from time to time, how often is it actually, realistically needed? Certainly, I'd argue that it's rare enough that having a slightly more complicated solution specifically for it makes more sense than adding a whole new abstraction to the standard library. That particular metafunction may not have a lot of usage, I agree, but I was trying to make the point that TypeTuples do not support multi-dimensions. For example, in the Boost.units library that I'm porting to D, multi-dimensional typelist are common. To solve algebraic equations of types can require matrices, and to implement a matrix you'll need a typelist of typelist. So, we're not adding TypeList. Oh, I was aware that a decision had already been made. I thought it was an open issue. While I sympathize with your desire to get some of the functionality that TypeList provides and TypeTuple doesn't, please work with us to improve upon TypeTuple rather than trying to add something to Phobos that does almost the same thing as TypeTuple. In most cases, it's simply a matter of adding the appropriate templates to gain TypeList-like functionality on top of TypeTuple rather than adding TypeList, and we've even recently added (post-2.060) some of those templates to std.typetuple, thereby improving what can be done with std.typetuple. - Jonathan M Davis Since TypeList is out of the question, I need to figure out what to do with the units library first.
Re: Preliminary submission - std.rational and std.typelist
On Monday, October 08, 2012 00:14:04 Arlen wrote: So, we're not adding TypeList. Oh, I was aware that a decision had already been made. I thought it was an open issue. It was decided the last time that std.typelist was brought up. Basically, TypeList doesn't provide enough over TypeTuple to be worth it, and we don't want two different abstractions for essentially the same thing. Since TypeList is out of the question, I need to figure out what to do with the units library first. Well, there may very well be cases that are more work due to the lack of TypeList, but it should be possible to make them work with TypeTuple, though it could mean adding more functionality to std.typetuple to make it work. - Jonathan M Davis
Re: Struct members align in DMD 2.060
http://dlang.org/changelog.html Since 2.060 behavior of align outside aggregate was changed. This explains the first example. Regarding the second one: alignment for the fields of an aggregate doesn't affect the alignment of the aggregate itself - from spec http://dlang.org/attribute.html#align.
Re: ddoc - documenting private variables
On 10/06/2012 01:22 PM, Jonathan M Davis wrote: On Saturday, October 06, 2012 13:10:31 Charles Hixson wrote: How does one generate documentation for private variables? ... Other, I mean, than switching to DOxygen (which has it's own problems with D). AFAIK, you can't. ddoc is configured primarily (entirely?) through the ddoc file that you use, and that's really for configuring how the information is displayed, not what is displayed. ddoc is a nice, simple tool that allows you to easily generate documentation, and you can do some fairly powerful stuff through ddoc macros, but it's not designed to be anywhere near as flexible or powerful as doxygen. - Jonathan M Davis Well, DOxygen works ok if you don't use function contracts, and possibly if you keep the entire program in one file. (It's been awhile since I used it with D, so I don't quite remember the limitations, and maybe they've improved it.) One way in which I prefer DOxygen over ddoc is that the documentation comments are a bit more compact. Since I only have one screen, that sometimes makes things a lot more legible. OTOH, the last time I used it I certainly got annoyed by it's limitations (in dealing with D). But this time I really need to document private variables, so I guess there's no choice (unless I go with something like robodoc...ugh).
Re: ddoc - documenting private variables
On Saturday, October 06, 2012 23:43:39 Charles Hixson wrote: Well, DOxygen works ok if you don't use function contracts, and possibly if you keep the entire program in one file. (It's been awhile since I used it with D, so I don't quite remember the limitations, and maybe they've improved it.) One way in which I prefer DOxygen over ddoc is that the documentation comments are a bit more compact. Since I only have one screen, that sometimes makes things a lot more legible. OTOH, the last time I used it I certainly got annoyed by it's limitations (in dealing with D). But this time I really need to document private variables, so I guess there's no choice (unless I go with something like robodoc...ugh). Why on earth would you need the documentation for private variables to be in the generated documentation? Only the module itself has access to them, so only someone editing the module will even care about them, and if they're editing the module, then they can see the comments on the variables directly. What does it buy you to them in the generated docs? They're not part of the API. Private variables seem exactly like the sort of thing that _shouldn't_ be in the generated docs. - Jonathan M Davis
Re: version(debug)
On Sunday, 7 October 2012 at 01:20:49 UTC, Jonathan M Davis wrote:
On Saturday, October 06, 2012 23:49:23 denizzzka wrote:
I am on dmd 2.060
debug {} else {} was not obvious for me - I thought that debug
is
a kind of qualifer.
I wouldn't expect you to try either version(debug) or debug {}
without seeing
them in the docs or in TDPL. I suppose that I can see why you
would try
version(debug), but it's not listed in the docs.
There isn't really a debug version of anything in D. What debug
{} does is
it's compiled in when -debug is compiled in, and that can be
used in
conjunction with -release if you want to. So talking about
debug vs release in
D is likely to get very confusing. Rather -debug enables debug
blocks which
are intended for inserting debug code, _not_ code which is
meant for non-
release builds.
It looks like version(assert) (which I guess is only in the
github version
right now) will effectively correspond to not having -release,
but if there's
ever a compiler flag which specifically enables or disables
assertions instead
of -release (which does more than just disable assertions -
e.g. it disables
bounds checking in non-@safe code), then it won't actually be
guaranteed to
not be there if -release isn't there. It's close enough though
I guess,
particularly when the type of stuff that you specifically do in
non-release code
is typically the kind of stuff that you want done with
assertions are enabled
and probably wouldn't want enable if assertions were turned
off, even if that
were to somehow happen without -release.
I've got a situation that debug information should be placed into
the class via the constructor. Therefore, when used -debug
constructor has another arguments list, and its need debug {}
else {} for ctor calling.
In any case, -debug and debug{} should be explained in the docs
somewhere.
It's certainly not the sort of thing that I would expect you to
magically
know.
Yes.
Re: version(debug)
On Sunday, October 07, 2012 09:27:31 denizzzka wrote:
I've got a situation that debug information should be placed into
the class via the constructor. Therefore, when used -debug
constructor has another arguments list, and its need debug {}
else {} for ctor calling.
Which is fine. It's just that you need to realize that debug blocks are enabled
with -debug and have nothing to do with whether -release is used or not, so it
doesn't correspond with what people typically mean when they talk about debug
mode and release mode.
- Jonathan M Davis
Function pointer variable not recognized as function by is-operator
The following compiles, which I'm pretty sure must be a bug,
right? Just checking to be sure I won't be polluting the bug
tracker.
void main()
{
auto f = (int i) {};
static assert (!is(f == function)); // should fail
static assert (!is(f == delegate));
}
Re: Function pointer variable not recognized as function by is-operator
On Sunday, October 07, 2012 10:25:41 Tommi wrote:
The following compiles, which I'm pretty sure must be a bug,
right? Just checking to be sure I won't be polluting the bug
tracker.
void main()
{
auto f = (int i) {};
static assert (!is(f == function)); // should fail
static assert (!is(f == delegate));
}
It's not a bug. is(f == function) checks for functions, not function pointers.
http://stackoverflow.com/questions/11067972
- Jonathan M Davis
Re: Function pointer variable not recognized as function by is-operator
On 10/07/2012 10:35 AM, Jonathan M Davis wrote:
On Sunday, October 07, 2012 10:25:41 Tommi wrote:
The following compiles, which I'm pretty sure must be a bug,
right? Just checking to be sure I won't be polluting the bug
tracker.
void main()
{
auto f = (int i) {};
static assert (!is(f == function)); // should fail
static assert (!is(f == delegate));
}
It's not a bug. is(f == function) checks for functions, not function pointers.
http://stackoverflow.com/questions/11067972
- Jonathan M Davis
Actually is(f==function) checks whether or not f is a function type.
The ==function part is unimportant, because f is not even a type.
Re: Function pointer variable not recognized as function by is-operator
On Sunday, October 07, 2012 10:42:49 Timon Gehr wrote:
On 10/07/2012 10:35 AM, Jonathan M Davis wrote:
On Sunday, October 07, 2012 10:25:41 Tommi wrote:
The following compiles, which I'm pretty sure must be a bug,
right? Just checking to be sure I won't be polluting the bug
tracker.
void main()
{
auto f = (int i) {};
static assert (!is(f == function)); // should fail
static assert (!is(f == delegate));
}
It's not a bug. is(f == function) checks for functions, not function
pointers.
http://stackoverflow.com/questions/11067972
- Jonathan M Davis
Actually is(f==function) checks whether or not f is a function type.
The ==function part is unimportant, because f is not even a type.
Ah. That's true. I should have caught that. Regardless, the types of function
pointers still won't be true for == function - e.g. is(typeof(f) == function)
won't be true - because it's checking for functions, not function pointers.
- Jonathan M Davis
Re: Remove element from DList
On Sat, 2012-10-06 at 19:42 -0700, Jonathan M Davis wrote: […] singly-linked lists and doubly-linked lists are completely different beasts. A singly-linked list can't do it sanely, because it has to traverse the list to find the previous node so that it adjust the links. A node in a doubly-linked Not sure about the D implementation, but in other languages all the singly-linked list iterator has to do to allow for removal is to maintain a front foot/back foot state. This is needed for insert as well, so it is already there. list has a link to the previous node in the list instead of just the next node, so it doesn't have that problem. You can add and remove elements from anywhere in a doubly-linked list in O(1). And if you're dealing with iterators, it won't affect any iterators except if they point at the element being removed (so it's a stable remove). With ranges, it would affect the elements in the range, but unless you're removing an element which is at the front or end of a range, it shouldn't invalidate the range at all. And that can be gotten around by letting that node continue to exist and point to what was the next node in the list (in which case, it would go away once no more ranges referred to it - the GC makes doing that fairly easy). Removal from a singly-linked list can be O(1) as well, it depends whether you are deleting using an iterator in progress. So, I don't see any reason why remove wouldn't be stable or non-linear. It's actually kind of hard to make it _un_stable in this case. And actually, looking at the code, stableLinearRemove (and linearRemove is an alias for stableLinearRemove in this case) calls remove, so overall, this is a bit bizarre. Regardless, it's a bug that normal remove doesn't work with the result of take. - Jonathan M Davis -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Remove element from DList
On Sunday, October 07, 2012 10:09:06 Russel Winder wrote: Removal from a singly-linked list can be O(1) as well, it depends whether you are deleting using an iterator in progress. IIRC that dcollections' singly-linked list is like this, but std.container.SList definitely isn't. I'm not a big fan of singly-linked lists in the first place and tend to think that they're useless, but std.container's is particularly bad in that regard. - Jonathan M Davis
Re: Struct members align in DMD 2.060
Thanx Maxim, but what about S2.sizeof (should be 6) = 8 S3.sizeof (should be 6) = 8
Re: Struct members align in DMD 2.060
On Sunday, 7 October 2012 at 10:45:40 UTC, novice2 wrote: Thanx Maxim, but what about S2.sizeof (should be 6) = 8 S3.sizeof (should be 6) = 8 http://dpaste.dzfl.pl/57911897 Alignment attribute specifies members' alignment if it is inside structure and structure alignment if it is placed outside it. In case of S2 and S3 u member is placed without alignment and both structures contain 2+4 bytes, but because structures themselves are not specified with align() attribute, they are aligned to default 4 byte boundary and contain additional 2 trailing bytes. S4 is specified as having no alignment, so it's size is exactly 2+4 bytes.
Re: Remove element from DList
On Sun, 2012-10-07 at 02:15 -0700, Jonathan M Davis wrote: […] IIRC that dcollections' singly-linked list is like this, but std.container.SList definitely isn't. I'm not a big fan of singly-linked lists in the first place and tend to think that they're useless, but std.container's is particularly bad in that regard. I guess I like closed queues for which singly-linked lists are fine. Is there a rationale for having multiple implementation of the same data structure, one in druntime and the other in std.container? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Struct members align in DMD 2.060
Thanx again.
Code align(1) struct ... { align(1): ... }
rescue me and return pre 2.060 behaviour
Re: Struct members align in DMD 2.060
and contain additional 2 trailing bytes But, imho, this is unproperly to include something outside struct in its size.
Re: Remove element from DList
On Sunday, October 07, 2012 12:54:00 Russel Winder wrote: Is there a rationale for having multiple implementation of the same data structure, one in druntime and the other in std.container? Which data structure are you takling about? I'm not aware of anything in std.container being in druntime at all. - Jonathan M Davis
Re: Struct members align in DMD 2.060
On Sunday, 7 October 2012 at 12:42:17 UTC, novice2 wrote: and contain additional 2 trailing bytes But, imho, this is unproperly to include something outside struct in its size. Strictly speaking, nothing special is included, just empty bytes for optimization purposes. This behavior is similar to C/C++ where structures can have internal and trailing padding.
Re: Using inout in delegates
On 2012-10-05 16:09, Ali Çehreli wrote:
This workaround makes the compiler happy:
void foo (inout(int)[] arr)
{
auto a = (inout int) { auto b = arr[0]; };
}
But probably not what you want. :/
IIRC, inout has bugs and incomplete implementation. I think this should
be in the bug database.
Using the above workaround did make it compile. But using typeid it now
contains inout instead. It turns out I didn't need neither const or
inout, don't know why I added it in the first place. Thanks anyway.
--
/Jacob Carlborg
Re: Remove element from DList
On 10/7/12 5:15 AM, Jonathan M Davis wrote: On Sunday, October 07, 2012 10:09:06 Russel Winder wrote: Removal from a singly-linked list can be O(1) as well, it depends whether you are deleting using an iterator in progress. IIRC that dcollections' singly-linked list is like this, but std.container.SList definitely isn't. I'm not a big fan of singly-linked lists in the first place and tend to think that they're useless, but std.container's is particularly bad in that regard. Singly-linked lists are limited in functionality as containers, but very fast for a few applications. It's quite likely someone would choose a singly-linked list primarily for performance. Some more functionality could be implemented for SList if it used for its range a pointer pointing one before the first element. But that would have meant an extra indirection for each and every access, undoing a large fraction of performance benefits. That's why I chose the primitives the way I did. Andrei
