Part of your problem may be that D doesn't use copy constructors. Rather, it
has postblit constructors:
http://d-programming-language.org/struct.html#StructPostblit
- Jonathan M Davis
On Thu, 07 Jul 2011 19:33:01 +0200, Mirko Pilger wrote:
> google code is a good choice if you prefer mercurial.
>
> http://code.google.com/projecthosting/
Not really, it's pretty blah. Of the hg providers, BitBucket is the best.
Not a patch on GitHub though.
Dnia niedziela, 9 października 2011 00:13:29 Jonathan M Davis pisze:
> Part of your problem may be that D doesn't use copy constructors. Rather, it
> has postblit constructors:
Yes, i know about naming difference and behavioral difference.
It's not a problem for me anymore, this post is for people
Andrei Alexandrescu wrote:
> On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
>> I've found out what caused my builds to break. The thing is that both
>> std.file & std.stdio use fully qualified std.c.stdio.func calls but
>> never actually import std.c.stdio in any way. I wasn't even aware that's
>> po
On 10/9/11 2:26 AM, Christian Kamm wrote:
Andrei Alexandrescu wrote:
On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
I've found out what caused my builds to break. The thing is that both
std.file& std.stdio use fully qualified std.c.stdio.func calls but
never actually import std.c.stdio in any wa
Andrei Alexandrescu wrote:
> On 10/9/11 2:26 AM, Christian Kamm wrote:
>> Andrei Alexandrescu wrote:
>>
>>> On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
I've found out what caused my builds to break. The thing is that both
std.file& std.stdio use fully qualified std.c.stdio.func calls bu
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 th
On 10/9/2011 12:30 AM, Andrei Alexandrescu wrote:
> On 10/9/11 2:26 AM, Christian Kamm wrote:
>> Andrei Alexandrescu wrote:
>>
>>> On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
I've found out what caused my builds to break. The thing is that both
std.file& std.stdio use fully qualified std
On 2011-10-08 19:00, Andrei Alexandrescu wrote:
1. If we build a D wrapper for ODBC, then we allow people to write code
for any database that has an ODBC driver. This, assuming we commit to
ODBC as D's standard database interface, would complete the project.
2. If we want to go the route of "one
Brad Roberts wrote:
> Isn't this bug #314? Very well known, super old, highly voted for, etc,
> etc.
No, bug 314 is about privately imported symbols being accessible even though
they shouldn't be. This problem is about modules that aren't imported at all
in a file or any of its imports still be
On 2011-10-08 23:11, Adam D. Ruppe wrote:
Microsoft SQL Server is important to cover too. I'm pretty sure
ODBC works fine for that (there's ODBC bindings for D already,
it's part of the Windows headers) and I wrote a little something
for my database.d, but I haven't actually tested it yet!
I ha
On 2011-10-08 23:12, Jonathan M Davis wrote:
On Saturday, October 08, 2011 12:00:37 Andrei Alexandrescu wrote:
1. If we build a D wrapper for ODBC, then we allow people to write code
for any database that has an ODBC driver. This, assuming we commit to
ODBC as D's standard database interface, wo
On 2011-10-08 23:37, Andrei Alexandrescu wrote:
On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
I've found out what caused my builds to break. The thing is that both
std.file & std.stdio use fully qualified std.c.stdio.func calls but
never actually import std.c.stdio in any way. I wasn't even aware
On 2011-10-09 08:33, Vladimir Panteleev wrote:
On Sun, 09 Oct 2011 06:06:21 +0300, Nick Sabalausky wrote:
Great, right? But what about this?:
auto x = [runtimeExpressionA, runtimeExprB, runtimeExprC,
etc].find(blah);
With the anonymous delegate literal syntax suggested by Andrei a while
ago
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
Johannes Pfau wrote:
> Jens Mueller wrote:
> >Trass3r 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,
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
Am 08.10.2011 23:11, schrieb Adam D. Ruppe:
Microsoft SQL Server is important to cover too.
Yeah, it's probably pretty widely used in the Windows world so it should
be supported.
And Oracle should probably be supported as well.
But if we have a generic DB API support for these can be added l
Jacob Carlborg wrote:
> On 2011-10-09 08:33, Vladimir Panteleev wrote:
>> On Sun, 09 Oct 2011 06:06:21 +0300, Nick Sabalausky wrote:
>>
>>> Great, right? But what about this?:
>>>
>>> auto x = [runtimeExpressionA, runtimeExprB, runtimeExprC,
>>> etc].find(blah);
>>
>> With the anonymous delegate
Christian Kamm wrote:
> Andrei Alexandrescu wrote:
>
>> On 10/8/11 3:34 PM, Dmitry Olshansky wrote:
>>> I've found out what caused my builds to break. The thing is that both
>>> std.file & std.stdio use fully qualified std.c.stdio.func calls but
>>> never actually import std.c.stdio in any way. I
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
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
>> >
On 10/9/11 7: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
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 i
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
20
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 pe
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
On 2011-10-09 13:43, Lutger Blijdestijn wrote:
Jacob Carlborg wrote:
On 2011-10-09 08:33, Vladimir Panteleev wrote:
On Sun, 09 Oct 2011 06:06:21 +0300, Nick Sabalausky wrote:
Great, right? But what about this?:
auto x = [runtimeExpressionA, runtimeExprB, runtimeExprC,
etc].find(blah);
Wi
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
On Sun, 09 Oct 2011 01:39:10 -0400, Robert Jacques wrote:
> Yes, there is. Variant is now a struct so:
>
> is(typeof(target)==Variant)
>
> works just like you'd expect.
So it does. Thanks.
There was some discussion prior to this thread about the relative virtues
of binding to structs or binding to arrays of Variants. I was thinking
about this, and have experimented with Variants in my trial MySQL
implementation. My conclusions below - do they make sense?
Using Variant to capture
Further question. Should we assume in the first instance that we should
only attempt to accommodate those DBs that are free or have some free
version that may be limited in some way - e.g. the developer version of
MS SQL Server.
Presumably when D reaches the point of being all-conquering, then
Further generic question. (Yes, I am listening to the answers too)
If some underlying databases don't support the features that our chosen
interface requires, do we attempt to synthesize them - presumably at cost
to performance, or do we just throw a compile-time exception that
basically tells
On Sun, 09 Oct 2011 04:56:45 -0400, Mariusz Gliwiński
wrote:
Dnia niedziela, 9 października 2011 00:13:29 Jonathan M Davis pisze:
Part of your problem may be that D doesn't use copy constructors. Rather, it
has postblit constructors:
Yes, i know about naming difference and behavioral differen
Also, this would be a whole lot easier if D got a full built-in tuple
support, because then all functions would always take a single
argument. :-)
On Thu, Oct 6, 2011 at 10:56 PM, Steven Schveighoffer
wrote:
> On Thu, 06 Oct 2011 12:27:16 -0400, Gor Gyolchanyan
> wrote:
>
>> I see. Thanks for th
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
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
Steve Teale wrote:
To express a personal opinion, then as a first pass we should do
something that is at about the same level as JDBC but without the
concessions to DBs like Postgres that have fancy SQL types.
I disagree. Doing it this way may introduce difficulties or
incompabilities in the f
On 10/8/2011 11:11 AM, Xinok wrote:
On 10/7/2011 12:42 PM, Xinok wrote:
Hi, it's been years since I've posted here. I just wanted to share
something I worked on, a new sorting algorithm. It's a variant of merge
sort, but much more memory efficient with only a small loss in
performance. The most
> We probably should write a page on a wiki describing the API, without
> actually implementing anything. Then anyone involved may contribute to
> its design, so it may evolve into somewhat more thought out API.
I like that idea! Must find out how to put up a wiki.
Steve
Steve Teale wrote:
We probably should write a page on a wiki describing the API, without
actually implementing anything. Then anyone involved may contribute to
its design, so it may evolve into somewhat more thought out API.
I like that idea! Must find out how to put up a wiki.
Or use existin
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 stuf
On 10/9/11 11:15 AM, Steve Teale wrote:
If using variants for a set of out parameters you must have something
equivalent to:
Variant[3] va;
va[0] = cast(byte) 0;
va[1] = 0.0F;
va[2] = cast(char[]) [];
So you have to have exactly the same information at compile time for the
Variant array as you
On 10/9/11 11:40 AM, Steve Teale wrote:
Further generic question. (Yes, I am listening to the answers too)
If some underlying databases don't support the features that our chosen
interface requires, do we attempt to synthesize them - presumably at cost
to performance, or do we just throw a compi
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
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 P
On 2011-10-09 18:54, 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 stuf
Don't forget that quite a few MySQL data structure members are C long types
which are 64 bit on x86_64.
So if you want code to work on x86_64 as well as x86 it needs a type alias.
For example in st_net these members:
struct st_net
{
Vio *vio;
ubyte *buff;
ubyte *buff_end;
ubyte *
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
I've not had a proper look at the code yet, but I recall from when I
read the docs during the pre-review period that the introduction was a
little on the informal side. It doesn't seem to have changed since then,
and IMHO the introduction/description needs a bit of a polish to bring
it up to th
On Sunday, October 09, 2011 19:37:31 GrahamC wrote:
> Don't forget that quite a few MySQL data structure members are C long types
> which are 64 bit on x86_64.
>
> So if you want code to work on x86_64 as well as x86 it needs a type alias.
>
> For example in st_net these members:
>
> struct st_n
On 10/09/11 13:22, Andrei Alexandrescu wrote:
On 10/9/11 11:40 AM, Steve Teale wrote:
Further generic question. (Yes, I am listening to the answers too)
If some underlying databases don't support the features that our chosen
interface requires, do we attempt to synthesize them - presumably at c
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.
On Sunday, October 09, 2011 14:35:35 Jonathan M Davis wrote:
> On Sunday, October 09, 2011 19:37:31 GrahamC wrote:
> > Don't forget that quite a few MySQL data structure members are C long
> > types which are 64 bit on x86_64.
> >
> > So if you want code to work on x86_64 as well as x86 it needs a
On 10/7/2011 11:43 PM, 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 reti
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
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 P
On Oct 9, 2011, at 12:37 PM, GrahamC wrote:
> Don't forget that quite a few MySQL data structure members are C long types
> which are 64 bit on x86_64.
>
> So if you want code to work on x86_64 as well as x86 it needs a type alias.
>
> For example in st_net these members:
>
> struct st_net
> {
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 doe
On Sunday, October 09, 2011 16:31:35 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
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 d
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
On 10/9/11 6:31 PM, 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 som
kenji hara:
> I got an idea for multidimentional indexing and slicing.
> http://d.puremagic.com/issues/show_bug.cgi?id=6798
Thank you, you are good.
So is this:
y[$-6, 0..$:2]
Translated like this?
y.opIndex(y.opDollar!0 - 6, y.opSlice!1(0, y.opDollar!1, 2))
Bye,
bearophile
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 no
> I'd like to suggest that, as a first step, simple translations of the C
> header files for the various databases be added to etc.c. That'll at
> least enable people who need to use a database now to get started.
Walter,
I'm sure they're already out there waiting. I have MySQL. Any offers for
P
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
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?thr
Just wanted to give kudos to Vladimir Panteleev for his excellent
DustMite utility, which reduced a DMD 2.055 backend ICE in Dinecraft
(a ~10,000 line codebase) to this:
struct ChunkLoc {
}
class Chunk {
private ChunkLoc _loc;
@property
public ChunkLoc loc() {
On 2011-10-10 00:31, 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
On 2011-10-10 06:54, Steve Teale wrote:
I'd like to suggest that, as a first step, simple translations of the C
header files for the various databases be added to etc.c. That'll at
least enable people who need to use a database now to get started.
Walter,
I'm sure they're already out there wai
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(i
On 10.10.2011 03:18, bearophile wrote:
> kenji hara:
>
>> I got an idea for multidimentional indexing and slicing.
>> http://d.puremagic.com/issues/show_bug.cgi?id=6798
>
> Thank you, you are good.
>
> So is this:
> y[$-6, 0..$:2]
>
> Translated like this?
> y.opIndex(y.opDollar!0 - 6, y.opSlic
73 matches
Mail list logo
