Is this a bug, if so, how would you summarize it?
See this code: http://dpaste.dzfl.pl/b3ae1667 On DMD it gives the error message if version=bug, but not if version=bug AND version=workaround1 (through 6). On LDC it segfaults at run time if version=bug, but not if version=bug AND version=workaround1 (through 6). Workaround1 - workaround4 are more or less boring. However it is surprising that workaround5 and workaround6 work but in the bug (when there's two aliases) you then get an error message for each alias.
Re: howto dispatch to derived classes?
=?UTF-8?B?QWxpIMOHZWhyZWxp?= wrote: > a virtual function like accept() can do the trick This would require changes in the whole class hierarchy. But because of > The actual type of the object is implicitly stored in the > vtbl of each type. and in addition, because the statement | writeln( getC.classinfo.create.classinfo); gives the correct type there should be a possibility to dispatch to the correct `visit' function without any changes in the class hierarchy. I see that a sequence of statements | if( auto tmp= cast(Ci) getC) visit( tmp); can dispatch to the correct `visit' function. But this again would require knowledge of all `Ci'. A solution seems very close, but ... -manfred
Re: copying const struct
On Monday, 14 October 2013 at 18:36:00 UTC, Maxim Fomin wrote: Funniest thing happen in cases like this when he reports the bug himself and soon fixes it, later bug is hit by someone else but during reporting it is realized that bug is already fixed, pull is pushed to master and everyone salutes Kenji. Obviously Kenji has a time machine. With it, he discovers bugs in the future and fixes them in the present and sometimes even in the past.
objects as AA keys
hi, i am a bit confused. the official language ref ( http://dlang.org/hash-map.html ) states: " Classes can be used as the KeyType. For this to work, the class definition must override the following member functions of class Object: hash_t toHash() bool opEquals(Object) int opCmp(Object) ... " but now i stumbled on http://forum.dlang.org/post/mailman.2445.1354457588.5162.digitalmars-d-le...@puremagic.com " int[typeof(O)] rc; rc[O] = 42; auto O2 = O; // [...] if (auto r = O2 in rc) return *r; else return rc[O2] = compute(O2); IOW explicitly taking the address may not be necessary when doing that kind of things. " and i did a quick test and indeed, it seems to work out of the box - without overriding any member functions. in my use case, i wouldn't be able to modify the class anyway. so my questions: why is it working, is it just syntactic sugar for using cast(void*)Obj as key? what is the danger of using objects as keys? when would it fail? as it seems to be working against language specs, will this 'feature' eventually be removed? (then maybe i should use cast(void*)Obj right away...) thanks, det
Re: howto dispatch to derived classes?
On 10/14/2013 02:09 PM, Manfred Nowak wrote:
>> class C{}
>>class C1:C{}
>>// ...
>>class Cn:C{}
>>
>> C getC(){ return new Cn;} // might be extern
>>// and deliver some Ci
>>
>> void visit( C1 fp){}
>> // ...
>> void visit( Cn fp){}
>> void main(){
>>visit( getC); // dispatch?
>> }
>
> -manfred
>
>visit( getC);
> }
>
>
That it not exactly the same but looks like the visitor pattern. The
actual type of the object is implicitly stored in the vtbl of each type.
So, a virtual function like accept() can do the trick:
import std.stdio;
class C{
abstract void accept();
}
class C1:C {
override void accept() { visit(this); }
}
class Cn:C{
override void accept() { visit(this); }
}
C getC(){ return new Cn;} // might be extern
// and deliver some Ci
void visit( C1 fp) {
writeln("visiting C1");
}
void visit( Cn fp){
writeln("visiting Cn");
}
void main(){
getC().accept();
}
Ali
Re: How can this best be done?
Johan Fjeldtvedt: https://gist.github.com/Jaffe-/6983847 I think something like that should go in Phobos. But I'd like some improvements: - Perhaps you can use a syntax similar to the tuples one: ParallelStaticArray!(int,"field1", string,"field2", double,"field3", 5) test1; auto test2 = ParallelDynArray!(int,"field1", string,"field2", double,"field3")(5); A version is meant to have fixed size and the other is more like a dynamic array. - I think it's useful to have a syntax to "group" fields, so they are represented as parallel arrays of smaller structs instead of just parallel arrays. This is useful if you have to read/write fields in a coherent way. - I think this data structure should have a basic capability to analyse its usage patterns (this feature is off on default and can be switched on with a template argument). This is useful to tune the grouping of fields. - Iteration is a bit tricky. Probably it's a good idea to iterate only on one group at a time. Bye, bearophile
How can this best be done?
This post concerns the following code: https://gist.github.com/Jaffe-/6983847 It is an attempt to abstract away the details of storing a collection of struct elements as so-called parallel arrays (http://en.wikipedia.org/wiki/Parallel_array) instead of storing them sequentially. The ParallelArray template takes a struct, S, and a number of elements, SIZE, and creates a struct where each field is an array of size SIZE, for each field of S. The struct overloads opIndex, opIndexAssign and opApply, so that it can be used just like an ordinary array of structs. It's pretty neat and works fine, but I feel it's somewhat hacky. Is it okay to use .tupleof the way I do here? It does work, but I can't say I understand exactly how. Also, the recursive template bugs me. Can the code which declares the struct members be generated in some better way? I've tried writing a CTFE-able function to build the string instead of doing it recursively in the template, but I haven't been able to do it yet.
Re: Immutable variadic lambda
http://d.puremagic.com/issues/show_bug.cgi?id=11264 Bye, bearophile
Re: RosettaCode proposal: RFC diagram converter
qznc: Nice idea! :) I assume 1 column corresponds to 1 bit. This should probably be mentioned explicitly in the task description. OK. http://rosettacode.org/wiki/ASCII_art_diagram_converter Bye, bearophile
Re: Starting D with a project in mind.
On Monday, 14 October 2013 at 20:59:25 UTC, Andrew wrote: So now I compile Hello World and I get a 2MB executable ! gdc makes kinda large executables... but with my gdc cross compiler for arm, the hello world is 360 KB after stripping, but I used printf instead of writefln. phobos is pretty bad about its dependencies - use writef() and it pulls 20 modules. But even so 2MB is 5x bigger than it should be... My current C code has an embedded web server, json libraries and mongodb client and it's 80kb - what can I expect for the same thing in D ? D's size cost is mostly up-front - hello world bears the brunt of the size and increases after that are small (since the hello world already includes most that functionality due to the web of dependencies!). I'd estimate your size to be between 500 KB and 2.5 MB once you get all your functionality in. You *can* go much smaller if you don't touch phobos at all, writing your D with just C libraries. Then it'll be probably around 400 KB like my hello world test - still the size of grabbing druntime, but you don't get the phobos functions.
howto dispatch to derived classes?
> class C{}
> class C1:C{}
> // ...
> class Cn:C{}
>
> C getC(){ return new Cn;} // might be extern
> // and deliver some Ci
>
> void visit( C1 fp){}
> // ...
> void visit( Cn fp){}
> void main(){
> visit( getC); // dispatch?
> }
-manfred
visit( getC);
}
Re: Starting D with a project in mind.
Hallelujah - it's built ! Thanks Stefan for the link to the ARM fork, that and a pile of messing about with float ABI types and I managed to get it built and installed on my Cubieboard A20 (ARM7 debian distro). So now I compile Hello World and I get a 2MB executable ! This compares with 8kb for the same in C. Have I done something wrong ? I can understand that it has GC and UTF8 with bounds checking so I was expecting maybe 100kb. Does it need to be stripped or optimised in some way ? Surely only the used functions get linked in. My current C code has an embedded web server, json libraries and mongodb client and it's 80kb - what can I expect for the same thing in D ? Thanks Andrew
Re: warning, the message just before this one is an ad!
Le 14/10/2013 14:10, Agnew Daniel a écrit : I know I am too late, as you know best thing always delay. So visit KoolChart to find best chart library. This has nothing to do with D. It is for the Web, and it's not free. I take this message as an ad, I don't think it is the good place for this. I hate ads, especially where they are not expected, and the best thing to fight again them might be to show a free product which does better than the advertised product. Those interested in charts and pies in html5 might be interested in taking a look at http://www.flotcharts.org/ Sorry for the off topic.
Re: copying const struct
On Monday, 14 October 2013 at 17:38:22 UTC, Ali Çehreli wrote: On 10/14/2013 10:33 AM, Kenji Hara wrote: > On Monday, 14 October 2013 at 14:18:10 UTC, Maxim Fomin wrote: >> This is compilable using git head. When I read that line ... > Kenji Hara ... I was thinking about that person. :) Thank you Kenji! Ali Right. Kenji is true D celebrity. Funniest thing happen in cases like this when he reports the bug himself and soon fixes it, later bug is hit by someone else but during reporting it is realized that bug is already fixed, pull is pushed to master and everyone salutes Kenji. What bothers me is that some (in fact, probably many) delicate language cases are silently fixed by Kenji without proper documentation so D language has some sparse and obsolete spec, even more obsolete book and sporadic patches - just couple of developers are aware about each of them. When someone hits corner language case - weird compiler behavior it is general unknown what should compiler do, whether current behavior is bug or a fix for some other previous bug about which you are unaware of. When different parts of language interact, problem becomes even more complicated.
Re: copying const struct
On 10/14/2013 10:33 AM, Kenji Hara wrote: > On Monday, 14 October 2013 at 14:18:10 UTC, Maxim Fomin wrote: >> This is compilable using git head. When I read that line ... > Kenji Hara ... I was thinking about that person. :) Thank you Kenji! Ali
Re: copying const struct
On Monday, 14 October 2013 at 14:18:10 UTC, Maxim Fomin wrote:
On Monday, 14 October 2013 at 11:35:32 UTC, Jack Applegame
wrote:
Why this doesn't compile?
http://dpaste.dzfl.pl/21ef5b04
class Foo {}
struct Bar1 {
const(Foo[]) member;
}
struct Bar2 {
const Foo member;
}
void main() {
const Bar1 bar1;
const Bar2 bar2;
Bar1 b1 = bar1; // ok
Bar2 b2 = bar2; // cannot implicitly convert expression
(bar2) of type const(Bar2) to Bar2
}
This is compilable using git head.
Recently I found a small compiler bug.
http://d.puremagic.com/issues/show_bug.cgi?id=11187
And, a week ago it is fixed. 2.064 beta1 contains the fix.
Kenji Hara
Re: Understanding opAssign and 'alias this'
On Monday, 14 October 2013 at 10:45:26 UTC, Maurice wrote:
On Monday, 14 October 2013 at 09:32:15 UTC, Maxim Fomin wrote:
On Monday, 14 October 2013 at 09:17:12 UTC, John Colvin wrote:
Everything is working fine except for the error on [2] when
xxx == true, which I think is a bug.
minimised test:
struct A
{
void opAssign(A a) {}
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
b = a;
}
Error: function assign.B.opAssign (B p) is not callable using
argument types (A)
This does not work (and need not) because compiler generates
default function B.opAssign(B) which is really not callable
using argument types (A).
Then why does it work when replacing "opAssign(A a)" with
"opAssign(int)"?
struct A {
void opAssign(int) {}
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
b = a; // This now compiles fine...
}
OK, it seems to be what actually causes the problem is implicit
conversion from B to A. Situation depends on presence of
A.opAssign(A ) because when compiler tries to resolve function
call, it is confused between calling B.opAssign(B) and casting
through alias this B to A and calling A.opAssign(A). When it
realizes that there is no best match it throws error. Since
argument B is casted to A, the error message looks so weird.
Re: copying const struct
Am 14.10.2013 16:19, schrieb Maxim Fomin: On Monday, 14 October 2013 at 13:56:58 UTC, Benjamin Thaut wrote: Am 14.10.2013 13:54, schrieb Dicebot: On Monday, 14 October 2013 at 11:45:30 UTC, Jack Applegame wrote: On Monday, 14 October 2013 at 11:38:23 UTC, Benjamin Thaut wrote: The line "Bar2 b2 = bar2;" would remove const from "member" Seems strange, because b2.member is const by declaration. Strange indeed and smells like a bug. `auto bar = Bar2(bar2.member)` works so it should be assignable. d.puremagic.com/issues/show_bug.cgi?id=9665 I don't see how this is related to the topic. I thought maybe its related to this bug.
Re: copying const struct
On Monday, 14 October 2013 at 11:35:32 UTC, Jack Applegame wrote:
Why this doesn't compile?
http://dpaste.dzfl.pl/21ef5b04
class Foo {}
struct Bar1 {
const(Foo[]) member;
}
struct Bar2 {
const Foo member;
}
void main() {
const Bar1 bar1;
const Bar2 bar2;
Bar1 b1 = bar1; // ok
Bar2 b2 = bar2; // cannot implicitly convert expression (bar2)
of type const(Bar2) to Bar2
}
This is compilable using git head.
Re: copying const struct
On Monday, 14 October 2013 at 13:56:58 UTC, Benjamin Thaut wrote: Am 14.10.2013 13:54, schrieb Dicebot: On Monday, 14 October 2013 at 11:45:30 UTC, Jack Applegame wrote: On Monday, 14 October 2013 at 11:38:23 UTC, Benjamin Thaut wrote: The line "Bar2 b2 = bar2;" would remove const from "member" Seems strange, because b2.member is const by declaration. Strange indeed and smells like a bug. `auto bar = Bar2(bar2.member)` works so it should be assignable. d.puremagic.com/issues/show_bug.cgi?id=9665 I don't see how this is related to the topic.
Re: copying const struct
Am 14.10.2013 13:54, schrieb Dicebot: On Monday, 14 October 2013 at 11:45:30 UTC, Jack Applegame wrote: On Monday, 14 October 2013 at 11:38:23 UTC, Benjamin Thaut wrote: The line "Bar2 b2 = bar2;" would remove const from "member" Seems strange, because b2.member is const by declaration. Strange indeed and smells like a bug. `auto bar = Bar2(bar2.member)` works so it should be assignable. d.puremagic.com/issues/show_bug.cgi?id=9665
Re: Is there a graphing library for D?
I know I am too late, as you know best thing always delay. So visit KoolChart to find best chart library.
Re: copying const struct
On Monday, 14 October 2013 at 11:45:30 UTC, Jack Applegame wrote: On Monday, 14 October 2013 at 11:38:23 UTC, Benjamin Thaut wrote: The line "Bar2 b2 = bar2;" would remove const from "member" Seems strange, because b2.member is const by declaration. Strange indeed and smells like a bug. `auto bar = Bar2(bar2.member)` works so it should be assignable.
Re: copying const struct
On Monday, 14 October 2013 at 11:38:23 UTC, Benjamin Thaut wrote: The line "Bar2 b2 = bar2;" would remove const from "member" Seems strange, because b2.member is const by declaration.
copying const struct
Why this doesn't compile?
http://dpaste.dzfl.pl/21ef5b04
class Foo {}
struct Bar1 {
const(Foo[]) member;
}
struct Bar2 {
const Foo member;
}
void main() {
const Bar1 bar1;
const Bar2 bar2;
Bar1 b1 = bar1; // ok
Bar2 b2 = bar2; // cannot implicitly convert expression (bar2)
of type const(Bar2) to Bar2
}
Re: copying const struct
Am 14.10.2013 13:35, schrieb Jack Applegame:
Why this doesn't compile?
http://dpaste.dzfl.pl/21ef5b04
class Foo {}
struct Bar1 {
const(Foo[]) member;
}
struct Bar2 {
const Foo member;
}
void main() {
const Bar1 bar1;
const Bar2 bar2;
Bar1 b1 = bar1; // ok
Bar2 b2 = bar2; // cannot implicitly convert expression (bar2) of
type const(Bar2) to Bar2
}
Because in D const is transitive. That means if a reference is const the
object it points to is also const. And everything that object points to
is const, and so on.
The line "Bar2 b2 = bar2;" would remove const from "member" which does
not happen because const is not convertible to mutable implicitly.
Kind Regards
Benjamin Thaut
Re: Understanding opAssign and 'alias this'
On Monday, 14 October 2013 at 10:45:26 UTC, Maurice wrote:
On Monday, 14 October 2013 at 09:32:15 UTC, Maxim Fomin wrote:
On Monday, 14 October 2013 at 09:17:12 UTC, John Colvin wrote:
Everything is working fine except for the error on [2] when
xxx == true, which I think is a bug.
minimised test:
struct A
{
void opAssign(A a) {}
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
b = a;
}
Error: function assign.B.opAssign (B p) is not callable using
argument types (A)
This does not work (and need not) because compiler generates
default function B.opAssign(B) which is really not callable
using argument types (A).
Then why does it work when replacing "opAssign(A a)" with
"opAssign(int)"?
struct A {
void opAssign(int) {}
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
b = a; // This now compiles fine...
}
Or when just not defining any opAssign: struct A {}, that also
works. I don't get how adding a opAssign(A) disables 'b = a'.
Re: Understanding opAssign and 'alias this'
On Monday, 14 October 2013 at 09:32:15 UTC, Maxim Fomin wrote:
On Monday, 14 October 2013 at 09:17:12 UTC, John Colvin wrote:
Everything is working fine except for the error on [2] when
xxx == true, which I think is a bug.
minimised test:
struct A
{
void opAssign(A a) {}
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
b = a;
}
Error: function assign.B.opAssign (B p) is not callable using
argument types (A)
This does not work (and need not) because compiler generates
default function B.opAssign(B) which is really not callable
using argument types (A).
Then why does it work when replacing "opAssign(A a)" with
"opAssign(int)"?
struct A {
void opAssign(int) {}
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
b = a; // This now compiles fine...
}
Re: Starting D with a project in mind.
On Monday, 14 October 2013 at 07:36:03 UTC, Andrew wrote: Thanks Stefan, those were the instructions that I tried. With GDC, is it possible to generate portable intermediate C code so that I can compile D sources on the Mac and then just copy the resultant C code to an ARM debian machine and build that there ? That would allow me to work around the problem of not being able to build D directly on the target system. Thanks Hi, I actually managed to build GDC over the weekend, directly on the RPi. It required some small changes to the process as compared to [1]: - Fresh raspbian install (same). - Installed the packages (same). - Set up swap USB HD (same). - I got gcc-4.8.1 release sources, didn't apply the patches (seems they are already in place now), nor did I rerun the autoconf. I then proceeded to clone GDC, run the scripts and build, however I ran into a set of bugs[2]. I tried to get around those with my limited knowledge but got stuck. Luckily Johannes Pfau has been doing some great work as usual and already fixed these problems (mostly) in his fork / ARM branch [3]. So I redid this part of the process, with a fresh GCC source directory, using a clone of his fork, and the compilation ran to completion. A small test program also worked, but Johannes warned that there is some codegen issue in his fork, which is why he hasn't opened a pull request to merge into GDC proper yet[2]. I don't know the details of that but this might be good enough for now for your purposes. I assume that by the time 2.064 comes around and GDC's frontend is update one can go back to the main GDC master branch, as most fixes are already in druntime as well. Cheers, Stefan [1] http://gdcproject.org/wiki/Raspberry%20Pi/build/Raspbian%28Hardfloat%29/GCC-Devel [2] http://bugzilla.gdcproject.org/show_bug.cgi?id=80 [3] https://github.com/jpf91/GDC/tree/arm
Re: Understanding opAssign and 'alias this'
On Monday, 14 October 2013 at 09:17:12 UTC, John Colvin wrote:
Everything is working fine except for the error on [2] when xxx
== true, which I think is a bug.
minimised test:
struct A
{
void opAssign(A a) {}
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
b = a;
}
Error: function assign.B.opAssign (B p) is not callable using
argument types (A)
This does not work (and need not) because compiler generates
default function B.opAssign(B) which is really not callable using
argument types (A).
Re: Understanding opAssign and 'alias this'
On Sunday, 13 October 2013 at 21:37:31 UTC, Maurice wrote:
Hello,
Can anybody explain my what is happening here?
enum xxx = true;
struct A {
static if (xxx) ref A opAssign(ref const A a) { return this; }
ref A opAssign(int v) { return this; }
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
a = b; // [1]
b = a; // [2]
}
When xxx is false:
[1] Gives an error
[2] Compiles fine
When xxx is true:
[1] Compiles fine
[2] Gives an error
What exactly is happening here? When xxx is false, what does 'b
= a' do that is wrong when xxx is true?
I can't find any clear documentation about opAssign and its
'default' implementation.
Thanks!
-Maurice-
Everything is working fine except for the error on [2] when xxx
== true, which I think is a bug.
minimised test:
struct A
{
void opAssign(A a) {}
}
struct B {
A a;
alias a this;
}
void main() {
A a;
B b;
b = a;
}
Error: function assign.B.opAssign (B p) is not callable using
argument types (A)
Re: Understanding opAssign and 'alias this'
On Sunday, 13 October 2013 at 22:47:12 UTC, Kozzi wrote: It is a bug from my POV It sure seems like it. But what would be the correct behaviour? Should [1] and [2] both work in both cases? What are the rules around the default opAssign? Does the default one disappear by adding a opAssign(int)?
Re: Starting D with a project in mind.
Thanks Stefan, those were the instructions that I tried. With GDC, is it possible to generate portable intermediate C code so that I can compile D sources on the Mac and then just copy the resultant C code to an ARM debian machine and build that there ? That would allow me to work around the problem of not being able to build D directly on the target system. Thanks
