Re: D2 port of Tango
On Saturday, 24 December 2011 at 22:15:59 UTC, Jordi Sayol wrote:
Al 24/12/11 14:20, En/na mta`chrono ha escrit:
Unlike SiegeLord's branch I've removed tango's runtime and
build on top
of druntime. This step is inevitable in order to make tango
and phobos
work side by side.
SiegeLord's branch do not need druntime lib to be present on
the system when compiling tango-d2, and the resulting libraries
can be used together with phobos.
import std.stdio;
import tango.io.Stdout;
void main()
{
writeln(hello phobos!);
Stdout(hello tango!).newline;
}
Properly compiles and run.
So, is it not a good idea to join forces to advance more
strongly, since pursued the same goal?
Best regards,
They got 2 different goals. SiegeLord wants to keep as much of
original Tango as possible and make it D2-wish while mt'chrono
changes Tango itself, because he thinks something is
wrong-designed (or he doesn't get idea properly). tango.net.* for
example. That's all, that's why there are 2 branches.
And SiegeLord's branch *IS* built on top of druntime. Extra
features that Tango runtime had, are inside version blocks, so
you may want use them also :) But out of box it works with
druntime without any additional steps.
Re: Carmack about static analysis
Universal Function Call Syntax. C# calls them extension methods. Basically, the ability to call a method directly on a class (in the form of A.MyMethod) without it being declared in the class. Usually just a static/global method that gets rewritten. Instead of MyMethod(A), you can use A.MyMethod. On 25/12/2011 1:51 AM, Chad J wrote: On 12/24/2011 10:37 PM, Kapps wrote: The two biggest things that I believe D would benefit from, in terms of readability, are UFCS and C#-style lambdas (which were already discussed). Something like 'array(find(test, select!(a.name)(filter!(a.num 3)(Elements' Could be rewritten much cleaner as Elements.filter!a.num 3 .select!a.name .find(test) .array(); The first one is very confusing, hard to split across multiple lines without losing meaning, and difficult to see what it even operates on (assume Elements is not an array and thus can not be used with the current implementation of UFCS). The second one, you can clearly see operates on Elements, you can clearly split it across multiple lines, and it's very obvious where things stop and end. Plus, it eliminates at least one set of parenthesis per function call, not to mention being much easier to write as it's in order of steps instead of opposite order. Pardon, what does UFCS stand for?
D - dynamic_cast only?
I'll try again on this. My reading of the current documentation on casts leaves me with the impression that D now has only the equivalent of the C++ dynamic_cast. This seems unreasonably restrictive given that C++ has traditional C- style cast, dynamic_cast, static_cast, and reinterpret_cast - or maybe it's changed now? If D is a system programming language should I not be able to tell the compiler that a given set of bits represents what I say it is, and suffer the consequences if I get things wrong? Steve
Re: D - dynamic_cast only?
On Sunday, 25 December 2011 at 08:37:21 UTC, Steve Teale wrote: I'll try again on this. My reading of the current documentation on casts leaves me with the impression that D now has only the equivalent of the C++ dynamic_cast. This seems unreasonably restrictive given that C++ has traditional C- style cast, dynamic_cast, static_cast, and reinterpret_cast - or maybe it's changed now? If D is a system programming language should I not be able to tell the compiler that a given set of bits represents what I say it is, and suffer the consequences if I get things wrong? The topic regarding confusion caused by having one cast syntax for everything is not new to this group. However, to unconditionally cast any reference type to any reference type, simply cast to void* first to avoid the runtime check.
Re: Carmack about static analysis
On 12/25/2011 02:57 AM, Kapps wrote: Universal Function Call Syntax. C# calls them extension methods. Basically, the ability to call a method directly on a class (in the form of A.MyMethod) without it being declared in the class. Usually just a static/global method that gets rewritten. Instead of MyMethod(A), you can use A.MyMethod. On 25/12/2011 1:51 AM, Chad J wrote: On 12/24/2011 10:37 PM, Kapps wrote: The two biggest things that I believe D would benefit from, in terms of readability, are UFCS and C#-style lambdas (which were already discussed). Something like 'array(find(test, select!(a.name)(filter!(a.num 3)(Elements' Could be rewritten much cleaner as Elements.filter!a.num 3 .select!a.name .find(test) .array(); The first one is very confusing, hard to split across multiple lines without losing meaning, and difficult to see what it even operates on (assume Elements is not an array and thus can not be used with the current implementation of UFCS). The second one, you can clearly see operates on Elements, you can clearly split it across multiple lines, and it's very obvious where things stop and end. Plus, it eliminates at least one set of parenthesis per function call, not to mention being much easier to write as it's in order of steps instead of opposite order. Pardon, what does UFCS stand for? Ah good. I always thought it a bit odd that we didn't have that. Better yet if it worked with operator overloading... then the operator overloads could check for null.
Re: D - dynamic_cast only?
Steve Teale: My reading of the current documentation on casts leaves me with the impression that D now has only the equivalent of the C++ dynamic_cast. I'd like this in Phobos: http://d.puremagic.com/issues/show_bug.cgi?id=5559 Bye, bearophile
Re: Carmack about static analysis
On Saturday, 24 December 2011 at 20:19:48 UTC, Andrei Alexandrescu wrote: Analogies of programming language with human language are flawed and take nowhere interesting. The only text that gets close to the level of precision and non-ambiguity needed is legal text; reading any amount of legal text blunts one's desire to be more like it. Andrei I know of one attempt for natural language programming, Hypertalk, the language of the Hypercard multimedia tool Apple developped in the 1990's. The tool was very interesting in itself, but the programming language is very limited and quite verbose due to the choice of being a natural language. I suspect it is the case of all natural languages used as programming languages. Apart maybe in artificial intelligence, I believe natural language has no useful use.
Re: D - dynamic_cast only?
On Sun, 25 Dec 2011 08:37:21 +, Steve Teale wrote: So what do you think is happening here? ColorSelectionDialog csd = new ColorSelectionDialog(Choose a Color); writefln(csd %s, csd); void* vp = cast(void*) csd.getColorSelection(); ColorSelection cs = cast(ColorSelection) vp; writefln(cs %s, cs); cs.setCurrentColor(cto.baseColor); writeln(A); Output: csd gtk.ColorSelectionDialog.ColorSelectionDialog cs gtk.Widget.Widget Segmentation fault The segfault is presumably because Widget does not have a setCurrentColor method, but why is the cast being ignored? Is the compiler optimizing the intermediate cast to void away? I don't find the asm from obj2asm helpful. Steve
Re: Carmack about static analysis
On 25.12.2011 00:44, Timon Gehr wrote:
Not really. Functional style code tends to be conceptually simpler.
Having code that is more readable can help. Getting rid of (({return
{return}}){return()}) makes the code more readable, whereas excessively
shortening identifiers does the opposite.
See here for an example of what bearophile is talking about:
http://pastebin.com/2rEdx0RD
r=cons(st(1UL),cons(st(1UL),lz({return zipWith((Lazy!ulong a,Lazy!ulong
b){return lz({return a()+b();});},r,r().tail)();})));
Re: Carmack about static analysis
On 2011-12-25 02:20, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 23:51:57 UTC, bearophile wrote:
Using certain abstractions sometimes helps to write one idea only once
in a program. Etc.
This is the biggest one, and applies to all kinds of code.
I like to write little functions with meaningful names.
bool isOdd(int i) {
if((i % 2) == 0)
return false;
else
return true;
}
filter!isOdd(myCollection);
I find that nicer than
filter!i % 2 != 0(myCollection);
despite it being longer.
With the former, it says very simply that it wants odd
numbers at the usage location.
With the latter, you have to think for a second about
what the modulus operator actually does and what the
definition of an odd number is before you can get to
why the filter is there at all.
It gets even worse if the other function has non-trivial
code. Best to just give it a name so you don't have to think
about the implementation at all at the usage site.
I completely agree with this. It can be used in if-statements and
similar as well.
--
/Jacob Carlborg
Re: Proposal for custom time string formatting in std.datetime
On 2011-12-25 04:05, zhang wrote: On Fri, 23 Dec 2011 02:21:37 -, Walter Bright newshou...@digitalmars.com wrote: On 12/22/2011 11:25 AM, Piotr Szturmaj wrote: I wish D could support partial modules - partial as analogy to C#'s partial classes. module std.datetime-unit1; import std.datetime-unit2; // dash allowed only in submodules with the same module name ... module std.datetime-unit2; import std.datetime-unit1; ... // then module whatever; import std.datetime; // as usual I have no idea why anyone would want this. (Is it because the file is too big to fit on a floppy disk?g) As for big module, my solutions are: 1) put related modules into a package (or directory) 2) add a module named all.d into the directory, and this module will import all the other modules publicly 3) now just import the *all* module when needed Here we have yet another example of some one who wants to use import foo.*;. -- /Jacob Carlborg
Re: D - dynamic_cast only?
On Sunday, 25 December 2011 at 13:39:15 UTC, Steve Teale wrote: The segfault is presumably because Widget does not have a setCurrentColor method, but why is the cast being ignored? Is the compiler optimizing the intermediate cast to void away? I don't find the asm from obj2asm helpful. I don't understand. Casting a void* to a class bypasses all static type checks. This is one of those cases where you tell the compiler that you know what you're doing - and if you try to call a method that wasn't in the original class's vtable, that's obviously not true.
Re: Carmack about static analysis
On 2011-12-25 05:44, Andrei Alexandrescu wrote:
On 12/24/2011 07:20 PM, Adam D. Ruppe wrote:
On Saturday, 24 December 2011 at 23:51:57 UTC, bearophile wrote:
Using certain abstractions sometimes helps to write one idea only once
in a program. Etc.
This is the biggest one, and applies to all kinds of code.
I like to write little functions with meaningful names.
bool isOdd(int i) {
if((i % 2) == 0)
return false;
else
return true;
}
filter!isOdd(myCollection);
I find that nicer than
filter!i % 2 != 0(myCollection);
despite it being longer.
Different strokes for different folks. IMHO it would be difficult to
justify the verboseness and the unnecessary (twice) flow of control. I
see every letter beyond this as a liability:
bool isOdd(int i)
{
return (i 1) != 0;
}
The point was not how to implement isOdd, it was to use a symbol instead.
With the former, it says very simply that it wants odd
numbers at the usage location.
Giving an operation, however trivial, a symbol, is often a good thing.
There are of course limits, and each engineer has their own ideas where
to draw the line.
Andrei
--
/Jacob Carlborg
Re: Proposal for custom time string formatting in std.datetime
On Sunday, 25 December 2011 at 14:00:58 UTC, Jacob Carlborg wrote: On 2011-12-25 04:05, zhang wrote: On Fri, 23 Dec 2011 02:21:37 -, Walter Bright newshou...@digitalmars.com wrote: On 12/22/2011 11:25 AM, Piotr Szturmaj wrote: I wish D could support partial modules - partial as analogy to C#'s partial classes. module std.datetime-unit1; import std.datetime-unit2; // dash allowed only in submodules with the same module name ... module std.datetime-unit2; import std.datetime-unit1; ... // then module whatever; import std.datetime; // as usual I have no idea why anyone would want this. (Is it because the file is too big to fit on a floppy disk?g) As for big module, my solutions are: 1) put related modules into a package (or directory) 2) add a module named all.d into the directory, and this module will import all the other modules publicly 3) now just import the *all* module when needed Here we have yet another example of some one who wants to use import foo.*;. I agree it would be nice to have a proper way to do this. Providing .all modules feels hacky and they need to be manually maintained - it also doesn't look as good. The _really important thing_ to note here is, there are at least two kinds of D libraries when it comes to this issue. Some libraries, including Phobos, prefer putting a lot of stuff in one module rather than splitting it up into a package. But many other libraries prefer splitting a library over multiple modules and using the package system to tie them together. Arguing over which approach is better comes down to a wide range of arguments, many quite subjective. I do not believe either approach is always better than the other. But I do believe it's important not to disregard the package approach, because it has advantages and adherents as well. Right now, the language favours the single module approach. When packages are used instead, it's clunky to provide a convenient interface to the entire library, and it's not very intuitive to look for a .all module, which could be named anything. I really like the idea of simply adding import myPackage;, behaving like your average .all module. Doing it this way solves at least three problems: No more clunky maintenance of convenience modules, big modules can later be split up into a package without breaking any client code, and we don't have to worry about a .all module for Phobos anymore (which is a suggestion that has been on the table several times).
Re: Looking for SciLib
On Tue, 20 Dec 2011 23:38:05 +0100, Paul D. Anderson wrote: I recall seeing several times someone mentioning they were working on a project called SciLib or SciLb or similar. If you're that person or if you know who that person is, could you send me an e-mail? Hi! Author of SciD here. I know you've gotten some replies already, but I just thought I'd clarify a few things. As you've been told, you can find SciD at GitHub: https://github.com/kyllingstad/scid/wiki It's been a while since I added anything new to it, but the project is by no means dead. If you find any bugs, please let me know, and I will fix them as soon as I am able. As others have pointed out, Cristi Cobzarenco forked my code when he was writing a linear algebra library for GSoC. However, in the process he has removed almost everything that is not related to linear algebra. In other words, if you are looking for a linear algebra library, you should get Cristi's library, whereas if you are looking for calculus or nonlinear equation solvers you should check out mine. (My library has some linear algebra stuff in it as well, but it is pretty limited, feature-wise.) Let me know if you have any questions. :) -Lars
Re: Could we use something better than zip for the dmd package?
Jacob Carlborg d...@me.com wrote in message news:jd4qg2$9r5$1...@digitalmars.com... On 2011-12-23 22:38, Somedude wrote: Le 23/12/2011 18:11, Nick Sabalausky a écrit : I'm actually inching closer to being a linux guy. Being able to easily script just about everything is pretty nice, and after Vista, Win7, and what I've seen of Win8, I've been loosing the loyalty I've had in windows since 3.1. (YMMV, of course). Don't know when I'll actually make the switch though, there's a few things I'd like to find/make for linux before I'd feel comfortable using it full time. You can virtualize if you have a good amount of RAM. I find virtualization gives the best of both worlds. If one wants to use both Windows and Linux, running one native and one virtualized. Which one is best to run native Dosn't really matter as far as I've ever been able to tell. I'd say whichever one you use more. and which one is best to run virtualized? The other one. :)
Re: Proposal for custom time string formatting in std.datetime
On 2011-12-25 15:31, Jakob Ovrum wrote: On Sunday, 25 December 2011 at 14:00:58 UTC, Jacob Carlborg wrote: On 2011-12-25 04:05, zhang wrote: On Fri, 23 Dec 2011 02:21:37 -, Walter Bright newshou...@digitalmars.com wrote: On 12/22/2011 11:25 AM, Piotr Szturmaj wrote: I wish D could support partial modules - partial as analogy to C#'s partial classes. module std.datetime-unit1; import std.datetime-unit2; // dash allowed only in submodules with the same module name ... module std.datetime-unit2; import std.datetime-unit1; ... // then module whatever; import std.datetime; // as usual I have no idea why anyone would want this. (Is it because the file is too big to fit on a floppy disk?g) As for big module, my solutions are: 1) put related modules into a package (or directory) 2) add a module named all.d into the directory, and this module will import all the other modules publicly 3) now just import the *all* module when needed Here we have yet another example of some one who wants to use import foo.*;. I agree it would be nice to have a proper way to do this. Providing .all modules feels hacky and they need to be manually maintained - it also doesn't look as good. The _really important thing_ to note here is, there are at least two kinds of D libraries when it comes to this issue. Some libraries, including Phobos, prefer putting a lot of stuff in one module rather than splitting it up into a package. But many other libraries prefer splitting a library over multiple modules and using the package system to tie them together. Arguing over which approach is better comes down to a wide range of arguments, many quite subjective. I do not believe either approach is always better than the other. But I do believe it's important not to disregard the package approach, because it has advantages and adherents as well. Right now, the language favours the single module approach. When packages are used instead, it's clunky to provide a convenient interface to the entire library, and it's not very intuitive to look for a .all module, which could be named anything. I really like the idea of simply adding import myPackage;, behaving like your average .all module. Doing it this way solves at least three problems: No more clunky maintenance of convenience modules, big modules can later be split up into a package without breaking any client code, and we don't have to worry about a .all module for Phobos anymore (which is a suggestion that has been on the table several times). I'm not sure if I like that syntax because you wouldn't be able to tell the difference between importing a package and a module. But perhaps that's the point. Otherwise I agree. -- /Jacob Carlborg
Ants AI, language matters
Ants AI Challenge sponsored by Google is now finished, 24 people have played
this contest using D2:
http://aichallenge.org/language_profile.php?language=D
The best D entry, by Minthos, with rank 439 (over about 8000 entries!):
http://aichallenge.org/profile.php?user=4823
Minthos D2 code:
http://files.minthos.com/code/minthos.dbot.dm02.tgz
Some low-level comments on Minthos code, about D, and not about game strategy
or other high level things.
His code is:
...
...
My code is the one without those .
---
pqueue.d module: sometimes more collections are needed.
---
Missed !in
assert(!(hill in myAnts));
---
Missed foreach() and maybe more:
struct pfNode{
Loc pos;
pfNode* prev;
float cost;
bool visited;
bool water;
}
...
pfNode[][] nodes = new pfNode[][](map.rows, map.cols);
pfNode*[] openList;
// initialize data structure
for(int y = 0; y map.rows; y++){
for(int x = 0; x map.cols; x++){
nodes[y][x].water = map.water[y][x];
nodes[y][x].visited = false;
nodes[y][x].pos = Loc(y, x);
nodes[y][x].prev = null;
}
}
This is a bit sad because of no named arguments yet in D (add braces as
desired):
foreach (y; row; map)
foreach (x, ref el; row)
el = PfNode(/*pos*/ Loc(y, x),
/*prev*/ null,
/*cost*/ el.cost,
/*visited*/ false,
/*water*/ map.water[y][x]);
---
It's usually better to think of pre/post increments as returning void, and
avoid code like this (but there is _far_ worse C/D code around):
lokeLars = path[index--];
---
Sad need(?) to use GC.disable:
void main(string[] args) {
version(unittest) {
// We don't run the bot or wait for input in this case
} else {
GC.disable();
MyBot b = new MyBot();
b.name = args[0];
Ants.run(b);
}
}
---
Missed AA.byKey(), and required care to use ref to avoid bad bugs here:
foreach(ref hill; map.myHills.keys){
if(engine.manhattan(ant.pos, hill) 5){
goto ignore;
}
}
Often a return or a named break/continue are better in D than that goto.
---
Improving switch to make it work on structs avoids such not nice code
(http://d.puremagic.com/issues/show_bug.cgi?id=596 ):
struct Direction {
char key;
int row;
int col;
}
immutable Direction[4] AIM = [
{'n', -1, 0},
{'e', 0, 1},
{'s', 1, 0},
{'w', 0, -1}
];
...
Direction directionLeft(Direction d){
for(int i = 0; i 4; i++){
if(d == AIM[i]){
return AIM[(i + 1) % 4];
}
}
assert(0);
}
Direction oppositeDirection(Direction d){
if(d == AIM[0]) return AIM[2];
if(d == AIM[1]) return AIM[3];
if(d == AIM[2]) return AIM[0];
if(d == AIM[3]) return AIM[1];
assert(0);
}
I am thinking about something like:
Direction oppositeDirection(in Direction d) pure nothrow {
final switch (d) {
case AIM0: return AIM2;
case AIM1: return AIM3;
case AIM2: return AIM0;
case AIM3: return AIM1;
}
}
Hopefully the final switch too becomes usable here if AIM array becomes an
enum of 4 items.
But I can't even create an enum of structs, maybe I am doing something wrong:
import std.typecons;
// Error: need member function opCmp() for struct Foo to compare
struct Foo { int x, y; }
// Error: template std.typecons.Tuple!(int,x,int,y).Tuple.opCmp(R) if
(isTuple!(R)) does not match any function template declaration
alias Tuple!(int,x, int,y) Foo;
// Error: Integer constant expression expected instead of Foo(1,1)
const struct Foo {
int x, y;
int opCmp(const ref Foo other) const pure nothrow {
return 1;
}
}
enum MyE : Foo { A = Foo(1, 1),
B = Foo(2, 2),
C = Foo(3, 3) }
void main() {}
---
There's a bit of need of std.random.choice, as in Python:
Direction randomDirection(){
return AIM[uniform(0, 3)];
}
Using $ it becomes a bit better (and maybe removes a bug, because AIM length is
4, while uniform on default doesn't return the right extrema):
Direction randomDirection() {
return AIM[uniform(0, $)];
}
But with a choice() it becomes less bug-prone and more clear:
Direction randomDirection() nothrow {
return choice(AIM);
}
---
void clearArray(ref bool[][] a)
{
for(int x = 0; x cols; x++){
for(int y = 0; y rows; y++){
a[y][x] = false;
}
}
}
Seems better:
void clearArray(bool[][] a) pure nothrow {
Re: D - dynamic_cast only?
On Sun, 25 Dec 2011 15:01:31 +0100, Vladimir Panteleev wrote: I don't understand. Casting a void* to a class bypasses all static type checks. This is one of those cases where you tell the compiler that you know what you're doing - and if you try to call a method that wasn't in the original class's vtable, that's obviously not true. Me neither, but it worked before somehow. Anyway, Mike Wey simply fixed gtkD on Christmas day, so now the derived object is handed out instead of the generic Widget.
Re: Ants AI, language matters
On Sunday, 25 December 2011 at 17:07:46 UTC, bearophile wrote: It's usually better to think of pre/post increments as returning void, and avoid code like this (but there is _far_ worse C/D code around): lokeLars = path[index--]; I agree that one should *generally* avoid this kind of code, but this example here is a very common C/C++ idiom, it should be fairly recognizable to anyone.
Re: Could we use something better than zip for the dmd package?
Kagamin: Copy-deployment is an advanced format, and I think it's pretty ok for it to be 7z. I suggest to just offer both zip and 7zip files. Bye, bearophile
Re: Could we use something better than zip for the dmd package?
But not without installing 3rd party software. Windows can handle zip files out of the box. It can't handle the others. rar would have exactly the same problem as 7z files (though from what I've see rar files are much more commonly used). We _could_ use a file format other than zip, but then we'd be requiring that the user download a 3rd party app just to be able to open the file, which is _not_ the case with zip. Availability is achieved by native installers, and AFAIK we have them - installers for Mac, Win, and a bunch for Lin. Copy-deployment is an advanced format, and I think it's pretty ok for it to be 7z. It's not very easy to begin with: you have to figure out how to install it - it's a matter of convention which is yet to get, where to install it, cope with privilege restrictions etc.
Re: Could we use something better than zip for the dmd package?
I suggest to just offer both zip and 7zip files. Sure it can be done, but I doubt zip helps availability a lot.
Re: Carmack about static analysis
On 12/25/2011 02:44 PM, simendsjo wrote:
On 25.12.2011 00:44, Timon Gehr wrote:
Not really. Functional style code tends to be conceptually simpler.
Having code that is more readable can help. Getting rid of (({return
{return}}){return()}) makes the code more readable, whereas excessively
shortening identifiers does the opposite.
See here for an example of what bearophile is talking about:
http://pastebin.com/2rEdx0RD
r=cons(st(1UL),cons(st(1UL),lz({return zipWith((Lazy!ulong a,Lazy!ulong
b){return lz({return a()+b();});},r,r().tail)();})));
http://pastebin.com/C6vf9DQQ
r=cons(st(cast(T)1),lz({return merge(merge(map((Lazy!T a){return
lz({return 2*a();});},r),map((Lazy!T a){return lz({return
3*a();});},r)),map((Lazy!T a){return lz({return 5*a();});},r))();}));
D'oh!
Mac OS X installer is for 64bit
The Mac OS X installer on dlang.org/dowloads says it is for i386 but it's actually for 64bit. -- /Jacob Carlborg
Re: Carmack about static analysis
On Sunday, 25 December 2011 at 04:44:57 UTC, Andrei Alexandrescu
wrote:
I see every letter beyond this as a liability:
Yeah, though like Jacob said, the implementation doesn't
matter as much as the idea of giving it a name.
But, if you're curious about why I wrote it long form, it's
just a quirk I sometimes do; if I read something out loud
differently than how I wrote it, I'll sometimes rewrite it.
Here, I dictated it to myself as if it's divisible by two,
return false (not odd), otherwise, return true (is odd), and
decided to write it almost exactly like that.
Usually, these little things are meaningless once compiled,
but check this out:
===
bool test(int a) {
if(a%2 == 0)
return false;
else
return true;
}
bool test2(int a) {
return a1;
}
===
$ dmd -O -c test.d # 2.057 btw
$ objdump -d test.o
Disassembly of section .text._D5test24testFiZb:
_D5test24testFiZb:
0: 55 push %ebp
1: 8b ec mov%esp,%ebp
3: 50 push %eax
4: 99 cltd
5: 33 c2 xor%edx,%eax
7: 25 01 00 00 00 and$0x1,%eax
c: 03 d0 add%eax,%edx
e: 83 fa 01cmp$0x1,%edx
11: 19 c0 sbb%eax,%eax
13: 8b e5 mov%ebp,%esp
15: 40 inc%eax
16: 5d pop%ebp
17: c3 ret
Disassembly of section .text._D5test25test2FiZb:
_D5test25test2FiZb:
0: 55 push %ebp
1: 8b ec mov%esp,%ebp
3: 50 push %eax
4: 25 01 00 00 00 and$0x1,%eax
9: f7 d8 neg%eax
b: 19 c0 sbb%eax,%eax
d: 8b e5 mov%ebp,%esp
f: f7 d8 neg%eax
11: 5d pop%ebp
12: c3 ret
Almost the same, but not quite I think the two
functions should have compiled identically. With gcc
(compiling the code as C), it comes out:
test:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 8b 45 08mov0x8(%ebp),%eax
6: 83 e0 01and$0x1,%eax
9: 5d pop%ebp
a: c3 ret
for both functions.
(btw Akismet thinks your post looks like spam. LOL)
Re: Carmack about static analysis
On 12/25/2011 11:53 PM, Timon Gehr wrote:
On 12/25/2011 02:44 PM, simendsjo wrote:
On 25.12.2011 00:44, Timon Gehr wrote:
Not really. Functional style code tends to be conceptually simpler.
Having code that is more readable can help. Getting rid of (({return
{return}}){return()}) makes the code more readable, whereas excessively
shortening identifiers does the opposite.
See here for an example of what bearophile is talking about:
http://pastebin.com/2rEdx0RD
r=cons(st(1UL),cons(st(1UL),lz({return zipWith((Lazy!ulong a,Lazy!ulong
b){return lz({return a()+b();});},r,r().tail)();})));
http://pastebin.com/C6vf9DQQ
r=cons(st(cast(T)1),lz({return merge(merge(map((Lazy!T a){return
lz({return 2*a();});},r),map((Lazy!T a){return lz({return
3*a();});},r)),map((Lazy!T a){return lz({return 5*a();});},r))();}));
D'oh!
With UFCS and alternate delegate syntax:
r=st(cast(T)1).cons(lz(= r.map((Lazy!T a)= lz(= 2*a()))
.merge(r.map((Lazy!T a)= lz(= 3*a(
.merge(r.map((Lazy!T a)= lz(= 5*a(()
));
With delegate parameter type inference for non-template delegate type
parameters (as proposed by Andrei in a recent bug report):
r=st(cast(T)1).cons(lz(= r.map((a)= lz(= 2*a()))
.merge(r.map((a)= lz(= 3*a(
.merge(r.map((a)= lz(= 5*a(()
));
With language support for non-strict evaluation:
@nonstrict:
r=cast(T)1
.cons(
r.map((a)= 2*a)
.merge(r.map((a)= 3*a))
.merge(r.map((a)= 5*a))
);
Re: Carmack about static analysis
Timon Gehr:
http://pastebin.com/C6vf9DQQ
If possible I suggest to remove all the BigInt from the module, and put the
bigint import into the main():
void main() {
import std.bigint;
auto h = hamming!BigInt();
writeln(take(20, h));
writeln(h()[1_691]);
writeln(h()[1_000_000]);
}
@nonstrict:
r=cast(T)1
.cons(
r.map((a)= 2*a)
.merge(r.map((a)= 3*a))
.merge(r.map((a)= 5*a))
);
This version looks acceptable :-)
Bye,
bearophile
Re: Carmack about static analysis
On 12/26/2011 12:30 AM, bearophile wrote:
Timon Gehr:
http://pastebin.com/C6vf9DQQ
If possible I suggest to remove all the BigInt from the module, and put the
bigint import into the main():
void main() {
import std.bigint;
auto h = hamming!BigInt();
writeln(take(20, h));
writeln(h()[1_691]);
writeln(h()[1_000_000]);
}
That could be done, but I don't think it is terribly important.
@nonstrict:
r=cast(T)1
.cons(
r.map((a)= 2*a)
.merge(r.map((a)= 3*a))
.merge(r.map((a)= 5*a))
);
This version looks acceptable :-)
Bye,
bearophile
It would be even better with methods-as-operators:
r=cast(T)1 cons (( r map a=2*a ) merge ( r map a=3*a ) merge ( r map
a=5*a ))
Re: Mac OS X installer is for 64bit
On 12/25/11 5:11 PM, Jacob Carlborg wrote: The Mac OS X installer on dlang.org/dowloads says it is for i386 but it's actually for 64bit. Fixed. Looking good? Andrei
Re: Carmack about static analysis
On 12/25/11 5:13 PM, Adam D. Ruppe wrote: On Sunday, 25 December 2011 at 04:44:57 UTC, Andrei Alexandrescu wrote: I see every letter beyond this as a liability: Yeah, though like Jacob said, the implementation doesn't matter as much as the idea of giving it a name. But, if you're curious about why I wrote it long form, it's just a quirk I sometimes do; if I read something out loud differently than how I wrote it, I'll sometimes rewrite it. Here, I dictated it to myself as if it's divisible by two, return false (not odd), otherwise, return true (is odd), and decided to write it almost exactly like that. I understand. Personally, I am unable to bring myself to fathom why writing this has any advantage: if (condition) return true; // or false else return false; // or true, respectively as much as I'm unable to fathom why writing this has any advantage: if (expression == true) ... or if (expression == false) ... I might be biased, but I ask for it to be corrected if I see it during a code review at work, and if someones writes such during an interview, it doesn't gain them any points. Usually, these little things are meaningless once compiled, but check this out: [snip] I'd say that's a good enhancement request for the backend. Andrei
Re: Looking for SciLib
On Sunday, December 25, 2011 15:52:25 Lars T. Kyllingstad wrote: As others have pointed out, Cristi Cobzarenco forked my code when he was writing a linear algebra library for GSoC. However, in the process he has removed almost everything that is not related to linear algebra. Sounds like they should probably be merged at some point. - Jonathan M Davis
Re: Carmack about static analysis
On Saturday, December 24, 2011 21:37:12 Kapps wrote: The two biggest things that I believe D would benefit from, in terms of readability, are UFCS and C#-style lambdas (which were already discussed). Something like 'array(find(test, select!(a.name)(filter!(a.num 3)(Elements' Could be rewritten much cleaner as Elements.filter!a.num 3 .select!a.name .find(test) .array(); The first one is very confusing, hard to split across multiple lines without losing meaning, and difficult to see what it even operates on (assume Elements is not an array and thus can not be used with the current implementation of UFCS). The second one, you can clearly see operates on Elements, you can clearly split it across multiple lines, and it's very obvious where things stop and end. Plus, it eliminates at least one set of parenthesis per function call, not to mention being much easier to write as it's in order of steps instead of opposite order. I think that that's partially a function of how much programming you've done in functional languages. I personally find the first one to be far more readable. The second one seems horribly backwards. - Jonathan M Davis
Re: @noreturn ?
On Saturday, December 24, 2011 22:26:02 Andrei Alexandrescu wrote: On 12/24/2011 06:58 PM, Vladimir Panteleev wrote: On Saturday, 24 December 2011 at 20:09:46 UTC, bearophile wrote: GNU C has a noreturn attribute since a lot of time. I don't fully understand why such attribute is so useful in C programs, but is something like a @noreturn function attribute useful in D too? Maybe to implement a better halt assert(0)? How about: scope(success) assert(0); ? The attribute should be migrated to the signature of the function such that calling code can take advantage of it. I personally think this is a small matter. Right now we have bigger rocks to move. It would be great if 2.058 had all [tdpl] bugs fixed. It's the sort of thing that we could add at any time without breaking backwards compatibility, so there's no rush unless it solves a burning problem. But at best, it solves a minor inconvenience. Solving the TDPL on the other hand would resolve a major usability issue for the language - particularly how it affects newbies reading TDPL. But completely aside from the newbies, it's a major milestone in actually having the full language implemented so that there's a lot less of a distinction between the design and the implementation. - Jonathan M Davis
Re: Ants AI, language matters
I posted about this contest in D.learn, so it was expectable that people try out D there without a good feel for the language and its shortcuts. Rank 439 is respectable, but I hoped for a higher ranked D entry. I don't know if there should to be an optimized boolean matrix in Phobos. Is this a construct that is often needed? Is bool[][] just good enough? All together I think this source code isn't very informative, but it is an example of someone who misses some of the rather obvious features of D, like vector operations and foreach. This is all documented somewhere, probably not easy to stumble over, yet I think chatting with helpful people is the best way to learn by example. Sometimes programming topics were discussed on #aichallenge, but then again mostly about C++/Java/Python, the most used languages in the contest. In the list of D2 users (showing those who submitted a program in D as their last upload) (http://aichallenge.org/language_profile.php?language=D) there are many who did only upload one or two programs in D in the whole two months. Usually that means they just uploaded the starter bot or a slightly modified version. So from the 24 people only 8 active participants remain. This is not much different from other languages though. When I proposed D in the chat, I found that it was generally well received now, with many of the legendary issues fixed. What kept some people from trying D were: - a small standard library (the upcoming curl wrapper is one good addition) - a GC (when they were used to manual memory management) - C++11 People from interpreted languages that wanted to improve the performance, looked more into C/C++, and frankly I know that you have to profile your D code now and then. foreach vs. array slice assignments, BigInt and other features can be slower than in Java, Perl or other, older languages. In this situation I can't tell them to use D, although it is a compiled language. Another point is that C++ users usually don't miss the D features that they don't know about and C++11 seems good enough to them. I don't know how to present contract programming in a chat without going to lengths and looking like a fan boy. D's arrays and associative arrays are usually a good starting point though. Note that the contest so far didn't allow multi-threading (except for runtime threads). When modern convenience and native performance meet, I think more people will see D as the alternative to Java and C++. This will take some time with the GC, the code gen and Phobos.
Re: Looking for SciLib
On Monday, 26 December 2011 at 00:46:44 UTC, Jonathan M Davis wrote: Sounds like they should probably be merged at some point. - Jonathan M Davis Yeah, I've started working on Cristi's fork now that I've built a good enough mental model of the implementation details that I can modify the code. This fork is still very much a work in progress. A merge with Lars's code is a good idea at some point, but right now debugging and fleshing out the linalg stuff is a higher priority.
A little bug
I've found this sort of bug in xfBuild:
import std.stdio;
class Deps { }
struct Mod {
Deps deps;
}
void main() {
Mod[] compileArray;
foreach (i; 0 .. 2) {
compileArray ~= Mod(new Deps);
}
foreach (mod; compileArray) {
mod.deps = null;
}
foreach (mod; compileArray) {
writeln(mod.deps is null); // surprise!
}
}
This will print false, false. It's interesting how easy it is to
lose sight of value semantics. I only discovered this bug by chance
and would have easily missed it by eye. The fix is to use foreach
(ref mod; compileArray). Even though mod.deps ends up being a
reference to an object, it's the reference itself that ends up being
nulled, not the object itself. E.g.:
class Deps { }
struct Mod {
Deps deps;
}
void main() {
Mod mod1 = Mod(new Deps);
Mod mod2 = mod1;
assert(mod1.deps is mod2.deps);
mod1.deps = null;
assert(mod1.deps !is mod2.deps);
}
Anyway I thought this was interesting. I wonder if this sort of bug is
lurking in some other D codebases out there..
Re: Carmack about static analysis
On Monday, 26 December 2011 at 02:31:52 UTC, Adam D. Ruppe wrote: I like an individual line of code to be dumb as a rock anyway. I'm reminded of a discussion I had on another forum, where someone suggested this might be because I started with assembly language. It might be that those first few years shape your brain and old habits die hard.
Re: Carmack about static analysis
On Monday, 26 December 2011 at 00:40:47 UTC, Andrei Alexandrescu wrote: I understand. Personally, I am unable to bring myself to fathom why writing this has any advantage: if(condition) return false just avoids a negation in the condition. It's easier to miss a ! entirely than to miss a return false, and personally, I've been finding it takes an extra brain cycle to invert a condition anyway. I like an individual line of code to be dumb as a rock anyway.
Re: Carmack about static analysis
Le 25/12/2011 05:27, Andrei Alexandrescu a écrit : Got the GC book this morning, already read 2.5 chapters :o). Andrei You'll find that you can do a lot when GC is aware of immutability (in functionnal languages, most things tends to be immutable). In the actual state of druntime, the GC is bad, but worse, cannot be imporoved to take advantage of this, and never will unless a major changement is done in GC interface.
Re: A little bug
On Monday, 26 December 2011 at 02:06:18 UTC, Andrej Mitrovic wrote: This will print false, false. After reading the code, I thought the surprise was that it printed true :) Perhaps making the default foreach behavior to make copies of structs wasn't the best idea, also due to performance reasons. One way it could have been designed was to force one of auto, const or ref to indicate the storage class.
Re: Carmack about static analysis
On 12/25/11 8:56 PM, deadalnix wrote: Le 25/12/2011 05:27, Andrei Alexandrescu a écrit : Got the GC book this morning, already read 2.5 chapters :o). Andrei You'll find that you can do a lot when GC is aware of immutability (in functionnal languages, most things tends to be immutable). In the actual state of druntime, the GC is bad, but worse, cannot be imporoved to take advantage of this, and never will unless a major changement is done in GC interface. What changes do you have in mind? I've gone through a larger portion of the book and one thing has become very clear to me: we must improve the precision of the collector. This would be a gating feature towards taking the GC pretty much anywhere. As a first step, we must make all allocations except stack type-aware, and leave only the stack to be imprecise. A tactical detail of the above has become equally clear to me - we MUST use D's reflection and introspection capabilities in increasing the precision of the collector. It's fairly easy to write a generic function mark() (as in the mark stage of the mark/sweep collector) that accepts any object type with indirections (class, array, associative array, pointer to struct). The function marks the pointer and then iterates through all fields of the object and recurses to itself to mark other reference/pointer/etc fields of the object. This one generic function obviates a lot of the code necessary today for conservatively marking pointers, and also reduces and simplifies enormously the new code that would otherwise be needed in order to define precise collection. Pointers to instances of that generic functions would be accessible from each allocated block; to transitively mark the block, the function is called via pointer. Essentially instances of that function (which I estimate to a 50-liner) would take care of mark() for the entire universe of D types - a humongous success of compile-time reflection. Andrei
versions and 32 vs 64-bit code
Is there a way to change what is compiled in based on whether the -m32 or -m64 option is chosen? I can see that there are predefined versions (for X86 and X86_64 e.g.), but I don't know if this is based on the compile options, or the platform the compilation is being performed on. As an example, if I am compiling on a 64-bit intel machine, is the version X86 or X86_64 set by default? Thanks.
Re: versions and 32 vs 64-bit code
On Monday, 26 December 2011 at 05:41:11 UTC, Nathan Coe wrote: As an example, if I am compiling on a 64-bit intel machine, is the version X86 or X86_64 set by default? The predefined version identifiers specify the *target* architecture. Note that the default target architecture matches the architecture of the compiler binary: the 64-bit DMD compiler has -m64 by default (use -m32 to override). http://dlang.org/version.html#PredefinedVersions lists predefined version identifiers.
Re: Could we have mod in std.math?
On 24.12.2011 22:12, bearophile wrote: Caligo: I'm hoping to see something like the above mod function in Phobos someday. I'd like that, for both int/long/BigInts. And I'd like some functions for BigInts: - divmod: returns both % and div and %, but it's more efficient if you need both values; - gcd These should both exist for int and long as well. - pow: with a third optional argument (like in Python pow built-in) to quickly compute (x ^^ y) % z. Bye, bearophile
Re: Could we have mod in std.math?
On 12/25/2011 10:57 PM, Don wrote:
On 24.12.2011 22:12, bearophile wrote:
Caligo:
I'm hoping to see something like the above mod function in Phobos someday.
I'd like that, for both int/long/BigInts. And I'd like some functions for
BigInts:
- divmod: returns both % and div and %, but it's more efficient if you need
both values;
- gcd
These should both exist for int and long as well.
Consider the following program:
int div(int a, int b)
{
auto x = a / b;
auto y = a % b;
return x + y;
}
Compile with:
dmd -c test -O
Disassemble with obj2asm:
_D4test3divFiiZicomdat
pushEAX
mov EAX,8[ESP]
cdq
idiv[ESP]
add EAX,EDX
pop ECX
ret 4
GetAndSet function (corresponding to cas function)
Hi folks, Is there a GetAndSet function (corresponding to cas (compare and set) function) in D? Thanks.
Re: Reading about D: few questions
25.12.2011 0:48, Mr. Anonymous пишет:
Actually, when I think of it:
int a_orig = a++;
int[] arr_orig = arr[]++;
Should be read as:
int a_orig = a;
++a;
int[] arr_orig = arr[];
++arr[];
(If I'm not mistaken, it was written in the TDPL book)
Which means no copy of arr is made, and both arrays (which reference to
the same block) are affected.
OK. As I wrote: Yes, this allocation sometimes can be optimized out but
not always.. Consider this:
---
void main()
{
int[] a = new int[5];
void f(int[] b)
{
// Here we assume that b is unchanged a.
// As these array differ we need a copy.
assert(b[0] == 0);
assert(a[0] == 1);
}
f(a[]++); // Note: compilation error now
}
---
Why not to rewrite `f(a[]++);` as `f(a); ++a[];`? Because postincrement
is expected to increment its argument when it is executed. It just
returns an unchanged copy. Analogous D code with integers illustrates this:
---
void main()
{
int a;
void f(int b)
{
assert(b == 0);
assert(a == 1);
}
f(a++);
}
---
Re: GetAndSet function (corresponding to cas function)
On 12/25/2011 09:25 AM, Adrian Mercieca wrote: Hi folks, Is there a GetAndSet function (corresponding to cas (compare and set) function) in D? Thanks. core.atomic.cas http://dlang.org/phobos/core_atomic.html#cas -- Mike Wey
Re: GetAndSet function (corresponding to cas function)
On Sun, 25 Dec 2011 13:37:32 +0100, Mike Wey wrote: On 12/25/2011 09:25 AM, Adrian Mercieca wrote: Hi folks, Is there a GetAndSet function (corresponding to cas (compare and set) function) in D? Thanks. core.atomic.cas http://dlang.org/phobos/core_atomic.html#cas I know of the cas function in D. I was asking if there was a getAndSet function. Tks.
dmd linker (OPTLINK) gives Error 42: Symbol Undefined when using extern
Linking the following two files gives me a link-error:
a.d:
import std.stdio;
extern (D) string test ();
void main()
{
writeln(test());
readln();
}
b.d:
string test () {
return hello;
}
the error I get is:
Error 42: Symbol Undefined _D1a4testFZAya`
---errorlevel 1
What is wrong ?
Re: dmd linker (OPTLINK) gives Error 42: Symbol Undefined when using extern
I want to save the hInstance of WinMain so I would be able to use it later in some other module. So how do I accomplish that ?
Re: dmd linker (OPTLINK) gives Error 42: Symbol Undefined when using extern
Am 25.12.2011 22:37, schrieb Tal: I want to save the hInstance of WinMain so I would be able to use it later in some other module. So how do I accomplish that ? just define a public variable in the global scope.
Re: dmd linker (OPTLINK) gives Error 42: Symbol Undefined when using extern
I'm quite new to this language, could you please provide a short snippet of code to clarify ?
Re: dmd linker (OPTLINK) gives Error 42: Symbol Undefined when using extern
Am 25.12.2011 23:26, schrieb Tal:
I'm quite new to this language, could you please provide a short snippet of code
to clarify ?
--- a.d:
import std.stdio;
import b;
void main() {
writeln(some_var from Module b: \, b.some_var, \);
}
--- b.d:
public string some_var = Hello, world!;
//you can also use static module constructors to set your vars
static this() {
some_var ~= -- How are you?;
}
Re: dmd linker (OPTLINK) gives Error 42: Symbol Undefined when using extern
Am 25.12.2011 22:37, schrieb Tal: I want to save the hInstance of WinMain so I would be able to use it later in some other module. So how do I accomplish that ? If you don't know: You can also get the HINSTANCE with GetModuleHandle(NULL);
Re: dmd linker (OPTLINK) gives Error 42: Symbol Undefined when using extern
On Sunday, 25 December 2011 at 22:46:33 UTC, Joshua Reusch wrote: public string some_var = Hello, world!; It's important to note that public is the default access level here.
[Issue 7133] [tdpl] There should be no empty statement
http://d.puremagic.com/issues/show_bug.cgi?id=7133 --- Comment #11 from Jakob Ovrum jakobov...@gmail.com 2011-12-25 01:03:29 PST --- (In reply to comment #10) In fact the oddity is that labels are considered to be statements, yet they don't end with a semicolon. Block, if, while, do, for, foreach, switch, with, etc. Most types of statements don't end with a semicolon. Remember that the label statement is: Identifier : NoScopeStatement The following statement is a sub-statement of the label statement. It's not any more inconsistent than other statements with sub-statements. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5605] [tdpl] foreach with ranges doesn't support opSlice()
http://d.puremagic.com/issues/show_bug.cgi?id=5605 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch, rejects-valid Platform|Other |All OS/Version|Linux |All --- Comment #3 from Kenji Hara k.hara...@gmail.com 2011-12-25 01:07:30 PST --- https://github.com/D-Programming-Language/dmd/pull/579 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4596] [tdpl] Rebinding *this* in class method compiles
http://d.puremagic.com/issues/show_bug.cgi?id=4596 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch Platform|Other |All OS/Version|Windows |All --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-12-25 02:30:01 PST --- Added fix into pull#166. https://github.com/D-Programming-Language/dmd/pull/166 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7161] Passing string literal by ref changes its bounds forever
http://d.puremagic.com/issues/show_bug.cgi?id=7161 Denis verylonglogin@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from Denis verylonglogin@gmail.com 2011-12-25 13:49:32 MSK --- *** This issue has been marked as a duplicate of issue 4539 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4539] Refuse assignment to string literal
http://d.puremagic.com/issues/show_bug.cgi?id=4539 Denis verylonglogin@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #14 from Denis verylonglogin@gmail.com 2011-12-25 13:49:33 MSK --- *** Issue 7161 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4539] Refuse assignment to string literal
http://d.puremagic.com/issues/show_bug.cgi?id=4539
--- Comment #15 from Kenji Hara k.hara...@gmail.com 2011-12-25 07:29:50 PST
---
Updated patch.
https://github.com/D-Programming-Language/dmd/pull/164
A string literal should be able to bind a reference to static array type.
In the context of ref binding, string literal should work as like static array
value.
Example:
void main()
{
void foo1(ref string s){} // ref slice
void foo2(ref const char[10] s){} // difference of length
void foo3(ref char[5] s){}// mutable element
void foo4(ref const char[5] s)
{
assert(s[0] == 'h');
assert(s[4] == 'o');
}
void foo5(ref const ubyte[5] s)
{
assert(s[0] == 0xc3);
assert(s[4] == 0x61);
}
static assert(!__traits(compiles, foo1(hello)));
static assert(!__traits(compiles, foo2(hello)));
static assert(!__traits(compiles, foo3(hello)));
foo4(hello);
foo5(cast(ubyte[5])xc3fcd3d761);
import std.conv;
static assert(!__traits(compiles, parse!int(10) == 10));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5605] [tdpl] foreach with ranges doesn't support opSlice()
http://d.puremagic.com/issues/show_bug.cgi?id=5605 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2011-12-25 15:16:31 PST --- https://github.com/D-Programming-Language/dmd/commit/4443f4295c1ee4b33794e6e2b3d050b1075a3599 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4647] [tdpl] Cannot explicitly call final interface method, ambiguous calls allowed
http://d.puremagic.com/issues/show_bug.cgi?id=4647 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2011-12-25 16:30:01 PST --- https://github.com/D-Programming-Language/dmd/commit/4d9f2e7fd86fcdf9cbfec5c9bbad304ed125132d https://github.com/D-Programming-Language/dmd/commit/d0fcaa80b468c455ce4b25a7af6c61fcaf749ee1 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7164] New: Can't inline function literal
http://d.puremagic.com/issues/show_bug.cgi?id=7164
Summary: Can't inline function literal
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-12-25
19:31:50 PST ---
I can't tell if this is a bug, I was just playing with it and it's not
important to me:
void foo(alias dg)() {
dg();
}
void test() {
foo!({ int x; })();
}
void main() {
test();
}
$ dmd test.d
ok
$ dmd -inline test.d
test.d(3): Error: function test.test.foo!(delegate pure nothrow @safe void()
{
int x = 0;
}
).foo is a nested function and cannot be accessed from main
Note that if I make it a delegate literal it will compile:
void foo(alias dg)() {
dg();
}
void test() {
int y;
foo!({ int x = y; })();
}
void main() {
test();
}
$ dmd -inline test.d
ok
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7165] New: [CTFE] ice converting null pointer to bool with constant member function
http://d.puremagic.com/issues/show_bug.cgi?id=7165
Summary: [CTFE] ice converting null pointer to bool with
constant member function
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis verylonglogin@gmail.com 2011-12-26 09:38:45 MSK
---
Assertion failure: 'e-type == type' on line 5553 in file 'interpret.c'
---
struct S {
int* ptr;
bool f() const { return !!ptr; }
}
enum data = S().f();
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
