I seem to have missed a few cases in the last commit, would you
mind trying again?
https://github.com/gtkd-developers/GtkD/commit/7e95380bbb4f569c95fc9435711e1f2ec73122fe
Sorry, no changes - still getting the same errors as before.
The OO implementations that I am used to (C++ and D) do not do
virtualization at the data level. Only member functions are virtual.
One of the reasons is that virtual functions remove the need to know
what the exact derived type is. The compiler jumps off the virtual
function pointer table and
It seems:
string me = (typeid(bars[1])).toString;
if(endsWith(me, "Foos")) writeln(to!(Foos)(bars[1]).val);
I see there is another post where somebody has asked if they can
use cast(typeof(typeid(bars[1]))).val, and it was explained that
the compiler won't know typeid until after compilation b
On Wednesday, 19 June 2013 at 23:35:16 UTC, Ali Çehreli wrote:
On 06/19/2013 04:29 PM, Agustin wrote:
Hello guys, my question is, its possible to write a mixin in a
class,
then if that class is inherited, the mixin will be written
again instead
of written the mixin again in the class child, fo
On Thursday, 20 June 2013 at 00:20:36 UTC, Agustin wrote:
On Wednesday, 19 June 2013 at 23:35:16 UTC, Ali Çehreli wrote:
On 06/19/2013 04:29 PM, Agustin wrote:
Hello guys, my question is, its possible to write a mixin in
a class,
then if that class is inherited, the mixin will be written
again
On Wednesday, June 19, 2013 16:35:16 Ali Çehreli wrote:
> On 06/19/2013 04:29 PM, Agustin wrote:
> > Hello guys, my question is, its possible to write a mixin in a class,
> > then if that class is inherited, the mixin will be written again instead
> > of written the mixin again in the class child,
On 06/19/2013 04:29 PM, Agustin wrote:
Hello guys, my question is, its possible to write a mixin in a class,
then if that class is inherited, the mixin will be written again instead
of written the mixin again in the class child, for example:
Class A(T)
{
mixin(WriteFunctionFor!(A));
}
Class B
On Thursday, June 20, 2013 01:29:48 Agustin wrote:
> Hello guys, my question is, its possible to write a mixin in a
> class, then if that class is inherited, the mixin will be written
> again instead of written the mixin again in the class child
No. If you want to put the same mixin in each of the
On 06/19/2013 04:10 PM, Stephen Jones wrote:
Hm... would be a nice idiom to implement generically in D. Like a type
switch.
-Steve
That is what I would prefer, but I tried:
writeln(to!(typeof(bars[1]))(bars[1]).val);
to see if I could access the "DERIVED" (thanks) class type but even
though
Hello guys, my question is, its possible to write a mixin in a
class, then if that class is inherited, the mixin will be written
again instead of written the mixin again in the class child, for
example:
Class A(T)
{
mixin(WriteFunctionFor!(A));
}
Class B : A(B)
{
... -> mixin is written fo
Hm... would be a nice idiom to implement generically in D.
Like a type switch.
-Steve
That is what I would prefer, but I tried:
writeln(to!(typeof(bars[1]))(bars[1]).val);
to see if I could access the "DERIVED" (thanks) class type but
even though bars[1] is initialized as a new Foos i
On 06/17/2013 09:32 PM, Alex Horvat wrote:
On Monday, 17 June 2013 at 17:52:38 UTC, Mike Wey wrote:
On 06/17/2013 04:44 AM, Alex Horvat wrote:
On Sunday, 16 June 2013 at 18:22:47 UTC, Mi
Could you try again with the latest git?
https://github.com/gtkd-developers/GtkD/commit/ab664087b9d354f9c
On Tuesday, 18 June 2013 at 05:46:17 UTC, Aleksandar Ruzicic
wrote:
On Tuesday, 18 June 2013 at 02:02:52 UTC, Josh wrote:
I've added in wsock32.lib, the -J, and the 3 versions, and it
gives the same output. I should mention that I can compile the
examples fine with both vibe and dub by themselv
On Wednesday, June 19, 2013 22:46:59 bioinfornatics wrote:
> so we should to use O_RDONLY fnrom which module?
Well, for whatever reason, it's in core.stdc.stdio on Windows, so if you're on
Windows, that's what you'd use, whereas on Posix systems, it's in
core.sys.posix.fcntl. I would have _thoug
On Wednesday, 19 June 2013 at 17:48:49 UTC, Jonathan M Davis
wrote:
On Wednesday, June 19, 2013 18:50:26 bioinfornatics wrote:
i think they are some duplicate data between std.c.stdio and
core.sys.posix.fcntl
Both module define
O_RDONLY O_WRONLY, O_RDWR, O_APPEND,O_CREAT, O_TRUNC,
O_EXCL
maybe
On Jun 19, 2013, at 12:54 PM, Ali Çehreli wrote:
> On 06/19/2013 11:46 AM, Sean Kelly wrote:
>
> > Thread.sleep(dur!"msecs"(300));
>
> Totally unrelated but there has been some positive changes. :) The following
> is much better:
>
>Thread.sleep(300.msecs);
Hooray for
On Wednesday, June 19, 2013 21:22:00 monarch_dodra wrote:
> Well, there is still ambiguity when you have a standalone char if
> it is holding a (paritally truncated) code unit, or a partial
> code point.
>
> If I write:
> char c = '\xDF'; //0b1101; //Lead UTF-8 2 byte encoding
> wchar w = 'ß';
On Wednesday, 19 June 2013 at 19:14:58 UTC, Roger Stokes wrote:
and got this compiler diagnostic:
Oh, I thought you were writing to a socket. Yeah, to a different
thread, D will complain if you don't make a sharable copy. So you
do want to idup it...
[47, 47, 32, 101, 120, 97,
On 06/19/2013 11:46 AM, Sean Kelly wrote:
>Thread.sleep(dur!"msecs"(300));
Totally unrelated but there has been some positive changes. :) The
following is much better:
Thread.sleep(300.msecs);
Ali
On 06/19/2013 12:14 PM, Roger Stokes wrote:
> and the result compiled and executed with no error signals, but the
> resulting output of the file-copy was not the same as the input, it
> looked like this:
>
> std.concurrency.OwnerTerminated@std\concurrency.d(248): Owner terminated
For a clean exi
On Wednesday, 19 June 2013 at 17:48:49 UTC, Jonathan M Davis
wrote:
On Wednesday, June 19, 2013 19:02:55 anonymous wrote:
On Wednesday, 19 June 2013 at 16:54:01 UTC, monarch_dodra
wrote:
> Hum... well, that's true for UTF-8 strings, if the _codeunit_
> 0xe7 appears, it is not 'ç'.
>
> But when
Many thanks for swift response. I'm still in difficulty, alas.
There were two
possibilities suggested: firstly,
Adam D. Ruppe wrote:
The problem here is that byChunk returns a mutable buffer, type
ubyte[]. If you said "foreach(ubyte[] buffer;
stdin.byChunk(bufferSize)) {...}" you should be
On Jun 16, 2013, at 8:27 AM, Gary Willoughby wrote:
> I'm writing a little program in D to perform some database operations and
> have a small question about design.
>
> Part of my program watches a log file for changes and this involves code
> which is wrapped up in a class. So the usage is s
On Wed, 19 Jun 2013 20:18:17 +0200, Daemon wrote:
> Was readText removed in later versions of Phobos? I don't have it, yet
> it appears in the documentation..
std.file.readText has been around for a long time and still is. Here it
is in Phobos HEAD: https://github.com/D-Programming-Language/pho
On Wednesday, 19 June 2013 at 18:18:18 UTC, Daemon wrote:
Was readText removed in later versions of Phobos? I don't have
it, yet it appears in the documentation..
Sorry for the false alarm, I accidentally had a different copy.
Everything's alright.
On Wednesday, 19 June 2013 at 18:21:09 UTC, Justin Whear wrote:
On Wed, 19 Jun 2013 20:18:17 +0200, Daemon wrote:
Was readText removed in later versions of Phobos? I don't have
it, yet
it appears in the documentation..
std.file.readText has been around for a long time and still is.
Here it
Was readText removed in later versions of Phobos? I don't have
it, yet it appears in the documentation..
On Wednesday, June 19, 2013 19:02:55 anonymous wrote:
> On Wednesday, 19 June 2013 at 16:54:01 UTC, monarch_dodra wrote:
> > Hum... well, that's true for UTF-8 strings, if the _codeunit_
> > 0xe7 appears, it is not 'ç'.
> >
> > But when handling a 'char', there is no encoding, it "should"
> > be r
On Wednesday, June 19, 2013 18:50:26 bioinfornatics wrote:
> i think they are some duplicate data between std.c.stdio and
> core.sys.posix.fcntl
>
> Both module define
> O_RDONLY O_WRONLY, O_RDWR, O_APPEND,O_CREAT, O_TRUNC,
> O_EXCL
>
> maybe std.c.stdio should to use version poix winows and what
On Tue, Jun 18, 2013 at 3:00 PM, Steven Schveighoffer
wrote:
> On Tue, 18 Jun 2013 17:41:57 -0400, Timothee Cour <
> thelastmamm...@gmail.com> wrote:
>
> I'd like to do the following:
>>
>> auto pipes = pipeShell(command, Redirect.stdout | Redirect.stderr);
>>
>> while(true){
>> version(A1)
>>
On Wednesday, 19 June 2013 at 16:54:01 UTC, monarch_dodra wrote:
Hum... well, that's true for UTF-8 strings, if the _codeunit_
0xe7 appears, it is not 'ç'.
But when handling a 'char', there is no encoding, it "should"
be raw _codepoint_.
No, char is a UTF8 code unit.
Code unit and code point
On Wednesday, 19 June 2013 at 15:13:23 UTC, Ali Çehreli wrote:
On 06/19/2013 05:34 AM, monarch_dodra wrote:
> I know a "binary" char can hold the values 0 to 0xFF.
However, I'm
> wondering about the cases where a codepoint can fit inside a
char. For
> example, 'ç' is represented by 0xe7, which t
i think they are some duplicate data between std.c.stdio and
core.sys.posix.fcntl
Both module define
O_RDONLY O_WRONLY, O_RDWR, O_APPEND,O_CREAT, O_TRUNC,
O_EXCL
maybe std.c.stdio should to use version poix winows and whatever
to load these data
that isn't the problem - D allows assignment to an read property - and
there is no write property around, so it should be an compiletime error
i should compile only if the missing write property is available - or?
@property int var(int value) { return _var = value; }
sorry i've totaly lost se
On Wednesday, 19 June 2013 at 15:25:15 UTC, Roger Stokes wrote:
page406x.d(11): Error: cannot implicitly convert expression
(__r24.front()) of type ubyte[] to immutable(ubyte)[]
foreach (immutable(ubyte)[] buffer;
stdin.byChunk(bufferSize)) {
The problem here is that byChunk returns a mu
I'd be grateful for advice. The problem is that I can't get the
example
on page 406-7 of the"The D Programming Language " to compile.
I've cut and pasted the text from the website, and corrected the
typo (undefined tgt, so use stdout instead). I get this
diagnostic:
page406x.d(11): Error: ca
On 06/19/2013 05:34 AM, monarch_dodra wrote:
> I know a "binary" char can hold the values 0 to 0xFF. However, I'm
> wondering about the cases where a codepoint can fit inside a char. For
> example, 'ç' is represented by 0xe7, which technically fits inside a
char.
'ç' is represented by 0xe7 in
On Wednesday, 19 June 2013 at 11:33:43 UTC, deed wrote:
Should this be a compile time error?
Yes it should, in an ideal world. Expanding out the assign
property, what we've got is:
void var(int i)
{
var(i); // endless recursion.
}
Linux segfaults on stack overflow, so that's your cra
Am 19.06.2013 13:40, schrieb Iain Buclaw:
On Wednesday, 19 June 2013 at 11:33:43 UTC, deed wrote:
The following compiles and crashes with DMD 2.063.
Should this be a compile time error?
class A
{
int _var;
/* SNIP */
int var() @property
{
return var;
}
Isn't the
I know a "binary" char can hold the values 0 to 0xFF. However,
I'm wondering about the cases where a codepoint can fit inside a
char. For example, 'ç' is represented by 0xe7, which technically
fits inside a char.
This is illegal:
char c = 'ç';
But this works:
char c = cast(char)'ç';
assert(c =
/* SNIP */
int var() @property
{
return var;
}
Isn't the problem in this property function? (Shouldn't it
return _var :o)
that's also an error. changing to _var gives same result though..
deed:
Should this be a compile time error?
In general it's not easy for a D compiler to perform that kind of
validation.
Bye,
bearophile
On Wednesday, 19 June 2013 at 11:33:43 UTC, deed wrote:
The following compiles and crashes with DMD 2.063.
Should this be a compile time error?
class A
{
int _var;
/* SNIP */
int var() @property
{
return var;
}
Isn't the problem in this property function? (Should
The following compiles and crashes with DMD 2.063.
Should this be a compile time error?
class A
{
int _var;
void var(int i) @property
{
this.var = i; // oops, crashes.
} // should have been this._var
int var() @property
{
return var;
On 2013-06-19 00:15, Ali Çehreli wrote:
val() must appear on Bar. I made it an interface:
interface Bar{
int val();
}
class Foo : Bar{
int val_ = 10;
int val() {
return val_;
}
}
class Foos : Bar{
int val_ = 20;
string str = "some more memory";
int val() {
return val_;
}
}
Why not just mov
On 2013-06-18 23:29, Dmitry Olshansky wrote:
As much as I'm appeased to hear this it's isn't simply "faster then V8".
V8 one is very fast in general case (JIT compiler aids in that) and I
think would come out as winer more often then std.regex.
What is closer to truth is that typically std.rege
On 2013-06-19 00:54, Steven Schveighoffer wrote:
Hm... would be a nice idiom to implement generically in D. Like a type
switch.
Pattern matching :)
You could quite easily implement something like this in library code:
match(b,
(Foo f) => ,// use f
(Foos fs) => // use fs
);
--
/Jacob
47 matches
Mail list logo
