GoingNative 2012
I'll give a talk at GoingNative 2012 (http://www.reddit.com/r/programming/comments/momge/goingnative_2012/) at Microsoft in Seattle. Registration is $112. If you're coming, I'd be glad to participate to a D dinner. If there's enough of us, Charles Torre (the conference organizer who has a keen interest in D) may even be convinced to organize a semi-official event (e.g. a Birds of a Feather meeting). Hope to see you there! Andrei
Re: GoingNative 2012
On 11/25/2011 4:46 AM, Andrei Alexandrescu wrote: I'll give a talk at GoingNative 2012 (http://www.reddit.com/r/programming/comments/momge/goingnative_2012/) at Microsoft in Seattle. Registration is $112. If you're coming, I'd be glad to participate to a D dinner. If there's enough of us, Charles Torre (the conference organizer who has a keen interest in D) may even be convinced to organize a semi-official event (e.g. a Birds of a Feather meeting). Hope to see you there! Andrei I'm already signed up!
Open MPI with D
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, so I finally got mpi.h to compile and link with D. A few problems are left to fix, like the fact that I didn't realize that OpenMPI does not care about the types, unless you are building it... Anyways applied a temp fix and got the first program running! young@Dan-Laptop:~/bin/DlanguageBindings/OpenMPI/examples$ mpirun hello_d Hello, world, I am 0 of 1 Not great, but its a start... One thing that has been buggin me.. I don't fully understand how C handles the arguments given to the program, but I do know that MPI handles them directly. int MPI_Init(int *argc, const char ***argv); Is there an easy way to turn D style (string[] args) into C style? PS- MPI has it's own wrappers for the compilation of programs, mpicc. would it be within the scope of Deimos to provide a similar mpidc wrapper? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOz04NAAoJENcHIWLyQiSlF5kIANt2Pbvodt8mkQ4QAmtq4scu 7IhZZxv8vNh0JRObsXBBLLFPghtPzc22WTfqFtngMO1n8RcAULtQhrCOmlgoZBlN BL8srGW7k76UEHE8Sg+uDF/1ZX3QakzLg4fJQd8lFS1/gfOGJ4cLdXlzuxygi8u2 d6J8zBcUzwcGWslm6C/4P0cQwOHQlrIv9zKEyW4vv8439AsR3zr4aUA0mtmOp5bq U92i1RvbNICsefsJCYQTrWJ0Hh4n7M3+KYfPwUFi4Aszg5UP0MY/3e51d1miId/L hrIk+kAea6wxp8wLmUjE3LPCsKkYGdQBwoTrWkfUm/dX0GObM7x+Hy5MwRQJaa4= =A8f+ -END PGP SIGNATURE-
Re: SQL/database server capabilities
Sean, I accidentally deleted your post, and in Pan I don't know how to get it back. Yes, most of the API's support that nominal capability, but what they tell you may not be what you expect, especially with ODBC. Steve
Re: SQL/database server capabilities
On Thu, 24 Nov 2011 13:09:41 -0500, Kagamin wrote: It seems this has no connection to columns whatsoever. Whatever data you receive from server, it's type is encoded in the received data packet. One may want to match types exactly or do sensible conversions like round a float to int or parse int from string. You don't want to have count(*) return an int32 on mssql and int64 on oracle and crap up if you requested, say, int32. Cases like count() and other function results are problematic. What I am trying to do is define interfaces with a graduated approach to output binding or translation. The simplest case would be doing this entirely on auto. You'd issue a query, and get back a set of variants whose types were set up on the basis of information about 'column' types received after the execution of the query. In many cases that would be sufficient. In more complex cases you would add qualifications to the binding to specify e.g. that a specific column should translate the result to the most capable integral type, or that the received value should be dealt with in chunks, and so on. Steve
Re: [std.database]
As in the initial discussions on database interfaces, I am still of the view that such support should be provided at three levels. I also suggest that we adopt a proposal that was hinted at in the initial discussions, and think in the longer term of having components that are devoted to SQL, and those that will apply to a broader view of what comprises a database. In other words we should have std.sql and std.database. (I use std purely for illustration.) It's possibly worth mentioning that Microsoft had similar intentions years ago when they introduced OLE DB - a generalized interface to data sources. OLE DB is now being dumped. I should make it clear that what I'm working on at present are modules for xxx.sql. It has been pointed out in several postings that I don't seem to have any clear idea of the design requirements for std.database, and I admit that this is the case, though I don't think I'm alone in this. The initial discussions did not reach any well defined conclusions. If there is anyone who wants to leap into the std.database role, please volunteer. It could take me some time to get the SQL stuff in some sort of order. ODBC is a set of dialects, and the wire protocol definitions are not easy to get up-to-speed on. It seems that given licensing considerations, D support for SQL will probably need to be distributed. Some C header translations will have to go in Deimos - e.g. MySQL, some would probably be OK in Phobos, e.g. SQLite, and _maybe_ ODBC, (Would you believe that some driver and driver manager implementations have attached GPL wording to the ODBC header files!) and PostgreSQL. Having done quite a bit of work on implementations for MySQL (C API and wire protocol), and SQL Server (ODBC from Linux and Windows), I'm beginning to have some fairly clear ideas about what D components for dealing with SQL databases, using SQL directly, could look like. More detail on that separately. An immediate point that arises is that because some of the D 'header files' are derivative, and the associated D components need to link with external libraries, we're missing a place to put such components. They can't go in Phobos because of the licensing and linking considerations, and they can't go in Deimos because that is for translations of C header files only. At the same time, It seems to me that they should follow the same quite tight implementation pattern as those that can potentially go in Phobos. Someone going from say the C API version of the MySQL interface should be able to use the same, or closely similar code as when using the wire-protocol version. So one question is where should such implementations go? Another questions relates to the definition of interfaces at module level. We have interfaces that go hand-in-hand with classes built in to the language. But if I wanted to say that two sql interface modules had the same 'interface', how could this be formalized. Could it be done using contracts? I'd welcome suggestions on this. Steve
Re: Open MPI with D
Jude Young: Is there an easy way to turn D style (string[] args) into C style? Maybe something like this (not tested)? const int argc = args.length; const char** argv = array(map!toStringz(args)).ptr; Bye, bearophile
Re: Open MPI with D
On 2011-11-25 09:13, Jude Young wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, so I finally got mpi.h to compile and link with D. A few problems are left to fix, like the fact that I didn't realize that OpenMPI does not care about the types, unless you are building it... Anyways applied a temp fix and got the first program running! young@Dan-Laptop:~/bin/DlanguageBindings/OpenMPI/examples$ mpirun hello_d Hello, world, I am 0 of 1 Not great, but its a start... One thing that has been buggin me.. I don't fully understand how C handles the arguments given to the program, but I do know that MPI handles them directly. int MPI_Init(int *argc, const char ***argv); Is there an easy way to turn D style (string[] args) into C style? If you just want to forward the arguments your application received you can use _NSGetEnviron() function on Mac OS X and environ global variable on other Posix systems. There are probably similar function/variable available on Windows. -- /Jacob Carlborg
Re: Open MPI with D
Taken with modifications from std.process.execv:
import core.stdc.stdlib;
import std.string;
import std.stdio;
import std.conv;
const(char)** argsToC(in string[] argv)
{
auto _argv = cast(const(char)**)malloc((char*).sizeof * (1 + argv.length));
toAStringz(argv, _argv);
return _argv;
}
private void toAStringz(in string[] a, const(char)** az)
{
foreach(string s; a)
{
*az++ = toStringz(s);
}
*az = null;
}
void main()
{
string[] args = [foo, bla];
auto _argv = argsToC(args);
assert(to!string(_argv[0]) == foo);
assert(to!string(_argv[1]) == bla);
}
Take a look at the various execv/execvp in std.process, but be careful
since most of them use alloca to allocate on the stack.
Re: Open MPI with D
Also, execve/execvpe passes the environment as well. It should be cross-platform if I'm not mistaken.
Re: Open MPI with D
On Fri 25 Nov 2011 03:12:34 AM CST, bearophile wrote: Jude Young: Is there an easy way to turn D style (string[] args) into C style? Maybe something like this (not tested)? const int argc = args.length; const char** argv = array(map!toStringz(args)).ptr; Bye, bearophile ...where is template map? nvm, found it. algorithm.. works, with minor alteration. int argc = args.length; const char** argv = array(map!toStringz(args)).ptr; Thanks! did I highjack an existing thread, or is my program just being stupid?
Re: Open MPI with D
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 also more success!! //This wouldn't work before... - -- time (mpirun -np 5 -v hello_d) Hello, world, I am 1 of 5 Hello, world, I am 4 of 5 Hello, world, I am 2 of 5 Hello, world, I am 5 of 5 Hello, world, I am 3 of 5 real0m1.102s user0m0.112s sys 0m0.096s - Not real sure about why the spacing is like that... Another concern is about how mpirun is passing the arguments to the program... If THAT needs to be patched in the source that'll be a bitch. Another concern is about how long it takes to start... a whole second for 5 threads? 1 thread takes about .050... Is this normal for MPI? I guess I should probably check timings for other languages. Ok, now I'm looking for people who have any experience with MPI. how many of the files will need to be ported? None of the examples that I see use anything more than mpi.h. Are any of the other header files necessary? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOz2S7AAoJENcHIWLyQiSlar8IALdqT1Jt/kzZP63LLH9DI/uB cmtWfGdGBRf6QPq7s1qJDE6x6dJHmcg9TDsYi205vf320Nc4MPTYNklrQY1kqwUu TqiEe31U6+fPhgYIBfxJ2tl1sBZVDiO07z5CyUywPFCeQWAwyM8yJmDlcrERym+V xBrUs4iEBe/9JsNVafImFBxcp7Y6WxR5cy7Syog5jorDyRE93L3FfYeTdh0lE9c/ HNpO0v8VSoERS37gGlfB2kqi+3HmsH2yhroBoZ53gQM5Sh19xI5OOJJD4v359rNf vphZ1UuE/2ZRCaAmZTP1lSiY1vfojQToDbYrpUVVjnhzteL4zTTvPBB3jg+IUR4= =V2HT -END PGP SIGNATURE-
Re: moving wxd to github
Walter Bright wrote:
Now that DMD has broken the ABI on x86_64,
??
... compared with GDC, that was.
Think we discussed this earlier, it's about the
passing of structs as parameters compared with C++.
The code is passing a D string to the C++ side,
and then interpreting this C argument as a struct:
/// length-prefixed string in UTF-8 format
struct dstr {
size_t length;
const char* data;
};
This only works in 32-bit code, and not in 64-bit.
Need to use two separate .length and .ptr pairs.
It should probably pass around wxString() objects
instead, even if that's slightly less convenient...
So instead of:
static extern (C) void wxApp_SetAppName(IntPtr self, string
name);
static extern (C) IntPtr wxApp_GetAppName(IntPtr self);
public string AppName() { return cast(string) new
wxString(wxApp_GetAppName(wxobj), true); }
public void AppName(string name) { wxApp_SetAppName(wxobj, name); }
It should do:
static extern (C) void wxApp_SetAppName(IntPtr self, IntPtr
name);
static extern (C) IntPtr wxApp_GetAppName(IntPtr self);
public wxString AppName() { return wxApp_GetAppName(wxobj); }
public void AppName(wxString name) { wxApp_SetAppName(wxobj,
name); }
Then it will be more explicit *when* strings are created,
especially if any UTF conversion needs to be done by it.
--anders
Re: moving wxd to github
Andrej Mitrovic wrote: Well the cool thing is I can use wxGlide to generate C++ code, and convert that to D. I tried it just now and it seems to work, but converting everything by hand is a bit of a chore. So don't generate code, use XRC resources instead ? However even though D is C++ inspired, I just have a much easier time converting python code instead. I think this is because wxGlide puts everything into header+implementation files, and this is a chore to convert to D, whereas the equivalent python code is in one file and much shorter. Supposedly you could patch it to generate D code... https://bitbucket.org/agriggio/wxglade/src/default/codegen/ Then you wouldn't have to convert it later at all. --anders
Re: moving wxd to github
On 11/25/11, Anders F Björklund a...@algonet.se wrote: Andrej Mitrovic wrote: Well the cool thing is I can use wxGlide to generate C++ code, and convert that to D. I tried it just now and it seems to work, but converting everything by hand is a bit of a chore. So don't generate code, use XRC resources instead ? I haven't thought of that! I'm very new to wxWidgets, thanks for the tip.
Re: moving wxd to github
Gour wrote: And pick one make (GNU). That's not fully clear to me. Instead of doing separate GNUmakefile and Makefile, and synching those ? There was even a build.brf and dsss.conf, while those were in fashion... Trying to support two languages, two libraries, two+ compilers, two+ buildtools, and so on, was just no fun and not very workable ? Can you explain what do you think? Drop D1, drop Tango, and make DMD the default compiler syntax (possibly using gdmd or ldmd behind the covers, where desired) Then do a standard build system, the suggestion was GNU make and GNU bash - rather than trying to cope with several systems. Cmake is not the most elegant tool, but it works and I got confirmation that it supports dmd gdc. What do you think? It would just generate a Makefile anyway ? But if it could generate the IDE projects, then maybe it's worth pursuing... If one used standard make and shell, then one could use the standard wx-config and friends and just be done with it: http://wxwidgets.blogspot.com/2011/06/choosing-gcc-for-building-wxwidgets.html --anders
Re: moving wxd to github
On Fri, 25 Nov 2011 11:07:45 +0100 Anders F Björklund a...@algonet.se wrote: So don't generate code, use XRC resources instead ? wxD can use XRC files? It would be great, then we can use some of the builders like DialogBlocks/wxForms... Sincerely, Gour -- One who restrains his senses, keeping them under full control, and fixes his consciousness upon Me, is known as a man of steady intelligence. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: moving wxd to github
On Fri, 25 Nov 2011 08:51:19 +0100 Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 11/25/11, Gour g...@atmarama.net wrote: Huh, does it fall in the category of 'language bindings' ? :-) Or maybe I didn't get the joke? Hehe ;) Sincerely, Gour -- As the embodied soul continuously passes, in this body, from boyhood to youth to old age, the soul similarly passes into another body at death. A sober person is not bewildered by such a change. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: moving wxd to github
On Fri, 25 Nov 2011 11:24:02 +0100 Anders F Björklund a...@algonet.se wrote: Drop D1, drop Tango, and make DMD the default compiler syntax (possibly using gdmd or ldmd behind the covers, where desired) +1 It would just generate a Makefile anyway ? But if it could generate the IDE projects, then maybe it's worth pursuing... Here is the list of gnerators available in cmake: Borland Makefiles MSYS Makefiles MinGW Makefiles NMake Makefiles Unix Makefiles Visual Studio 6 Visual Studio 7 Visual Studio 7 .NET 2003 Visual Studio 8 2005 Visual Studio 8 2005 Win64 Visual Studio 9 2008 Visual Studio 9 2008 Win64 Watcom WMake CodeBlocks - MinGW Makefiles CodeBlocks - Unix Makefiles Eclipse CDT4 - MinGW Makefiles Eclipse CDT4 - NMake Makefiles Eclipse CDT4 - Unix Makefiles check: http://www.cmake.org/cmake/help/cmake2.6docs.html#section_Generators btw, I'm going to help Jens to push cmake2d upstream to be included in the official release. Sincerely, Gour -- signature.asc Description: PGP signature
Re: moving wxd to github
Gour wrote: So don't generate code, use XRC resources instead ? wxD can use XRC files? It would be great, then we can use some of the builders like DialogBlocks/wxForms... See the Xrc demo in Samples, for some example code. http://docs.wxwidgets.org/stable/wx_xrcoverview.html --anders
Re: Open MPI with D
On 11/25/11 2:13 AM, Jude Young wrote: Is there an easy way to turn D style (string[] args) into C style? Hm, I expected this would work: extern(C) int __argc; extern(C) char** __argv; The symbols do exist at least on OSX (no linker error) but they are both zero, so apparently druntime doesn't initialize them. Andrei
Re: Open MPI with D
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2011 06:27 AM, Andrei Alexandrescu wrote: On 11/25/11 2:13 AM, Jude Young wrote: Is there an easy way to turn D style (string[] args) into C style? Hm, I expected this would work: extern(C) int __argc; extern(C) char** __argv; The symbols do exist at least on OSX (no linker error) but they are both zero, so apparently druntime doesn't initialize them. Andrei Hmmm. that's something I never expected. It would be nice if that was always exposed. (and initialized) More progress with Open MPI! from what I know now, I should have it working in less than a week. barring I don't learn that I did everything wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOz5DsAAoJENcHIWLyQiSlgIcH/iFQYy0cmPhybh+zbpEifZLJ nUOe3x8AWXLCdeYISxbpbqmgS9yr04jY7y8svNPlvaCzuO8fabXFtSX4eJJCySIz UOD0i3OXLFD9kRGq/c64E+v8pfCkagPMqDYY4mz4EKeZw97Pp/szMUUw7WdI2QWo io/D/BjfGMY9u9YtvJnY++1Y4i95tOJqBYYYSFqu0/n52MmPA6aAGWkPuzMSApkS 6FJhcKbrWPHJliPqnLaUdCXfP5nvYUbdI6x/WbodC8xeWxjOzBUX9xNgEzKYTp2+ ejOou29SHDGnWdkK6iL4AwTEyAiNNOtPI9zrYkaWBITkfSd/z4CCtzI2iNOUIeA= =1IL0 -END PGP SIGNATURE-
Re: Open MPI with D
On 11/25/2011 02:27 PM, Andrei Alexandrescu wrote: On 11/25/11 2:13 AM, Jude Young wrote: Is there an easy way to turn D style (string[] args) into C style? Hm, I expected this would work: extern(C) int __argc; extern(C) char** __argv; The symbols do exist at least on OSX (no linker error) but they are both zero, so apparently druntime doesn't initialize them. Andrei If you want a reference to an externally defined variable, you need another extern and (if the variable is non-TLS) - __gshared: __gshared extern extern(C) int __argc;
Re: Open MPI with D
On Fri, 25 Nov 2011 15:55:15 +0100, Max Samukha max...@spambox.com wrote: On 11/25/2011 02:27 PM, Andrei Alexandrescu wrote: On 11/25/11 2:13 AM, Jude Young wrote: Is there an easy way to turn D style (string[] args) into C style? Hm, I expected this would work: extern(C) int __argc; extern(C) char** __argv; The symbols do exist at least on OSX (no linker error) but they are both zero, so apparently druntime doesn't initialize them. Andrei If you want a reference to an externally defined variable, you need another extern and (if the variable is non-TLS) - __gshared: __gshared extern extern(C) int __argc; It also took me terribly long to find out that one for getting environ. We could probably get rid of setErrno and getErrno which add extra C sources to druntime.
TDPL D today?
Hello! In order to be able to help in any way build D's ecosystem, I have to learn the language. :-) Picked my TDPL copy from the shelf yesterday, went through the 1st chapter, but wonder how does TDPL stand in comparison with today's D (before jumping further)? Sincerely, Gour -- In the material world, one who is unaffected by whatever good or evil he may obtain, neither praising it nor despising it, is firmly fixed in perfect knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Open MPI with D
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2011 09:15 AM, Martin Nowak wrote: On Fri, 25 Nov 2011 15:55:15 +0100, Max Samukha max...@spambox.com wrote: On 11/25/2011 02:27 PM, Andrei Alexandrescu wrote: On 11/25/11 2:13 AM, Jude Young wrote: Is there an easy way to turn D style (string[] args) into C style? Hm, I expected this would work: extern(C) int __argc; extern(C) char** __argv; The symbols do exist at least on OSX (no linker error) but they are both zero, so apparently druntime doesn't initialize them. Andrei If you want a reference to an externally defined variable, you need another extern and (if the variable is non-TLS) - __gshared: __gshared extern extern(C) int __argc; It also took me terribly long to find out that one for getting environ. We could probably get rid of setErrno and getErrno which add extra C sources to druntime. I'll have to check these out. In the meantime, More successes! =D running hello_d with 5 threads Hello, world, I am 1 of 5 Hello, world, I am 2 of 5 Hello, world, I am 5 of 5 Hello, world, I am 3 of 5 Hello, world, I am 4 of 5 running ring_d with 5 threads Process 0 sending 15 to 1, tag 201 (5 processes in ring) Process 0 sent to 1 Process 0 decremented value: 14 Process 0 decremented value: 13 Process 0 decremented value: 12 Process 0 decremented value: 11 Process 0 decremented value: 10 Process 0 decremented value: 9 Process 0 decremented value: 8 Process 0 decremented value: 7 Process 0 decremented value: 6 Process 0 decremented value: 5 Process 0 decremented value: 4 Process 0 decremented value: 3 Process 0 decremented value: 2 Process 0 decremented value: 1 Process 0 decremented value: 0 Process 0 exiting Process 1 exiting Process 2 exiting Process 3 exiting Process 4 exiting running connectivity_d with 25 threads Connectivity test on 25 processes PASSED. All of the basic examples included now work. I just need to find more examples and other things so that I can make sure that everything else is working properly. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOz7OAAAoJENcHIWLyQiSlhLcIAMkwOtJMe84H6/i63pNPwEoX 6BVGqZo9VlsFYPDuATAH1Wn9Gp2LanRwI3zm3XC+YDM2LUbb1VESA6PRzhHMEcN7 zEMApYiFhnEUNC1qauBz2TW83KfrzRLVFewOL9ot/LDHyUVKsr3BJ4H4CqrtLVv4 vrPQy6PdzgrXaTSlZwRj4P1WNwVnYud/0fwAT17Vzq85dglHFEfy0C1/bTeNO1Lu XLkpO0JiK7y6l0ep9flp803N4qv5ROpD3EgtqhZ0vx49ShW6qwuT2X6NhXgqs3xG P+UhJRgGh1z7i+LeRxdtjxfUMr4x6eqIID21rz+cXH5Po8z0YGpyskXV279zsd4= =Ap9p -END PGP SIGNATURE-
Re: Open MPI with D
On 11/25/11 8:55 AM, Max Samukha wrote: __gshared extern extern(C) int __argc; That doesn't link. Andrei
Re: TDPL D today?
On 11/25/11 9:17 AM, Gour wrote: Hello! In order to be able to help in any way build D's ecosystem, I have to learn the language. :-) Picked my TDPL copy from the shelf yesterday, went through the 1st chapter, but wonder how does TDPL stand in comparison with today's D (before jumping further)? Close and getting closer. Here's the errata: http://erdani.com/tdpl/errata/ Andrei
Re: TDPL D today?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2011 09:17 AM, Gour wrote: Hello! In order to be able to help in any way build D's ecosystem, I have to learn the language. :-) Picked my TDPL copy from the shelf yesterday, went through the 1st chapter, but wonder how does TDPL stand in comparison with today's D (before jumping further)? Sincerely, Gour Please, learn the language as you go! And post random questions to D.learn that make you look like an idiot. That's how REAL men learn a language! (can I borrow your copy...?) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOz7ZbAAoJENcHIWLyQiSlzqAIALw2rvl2SjqkTDrYA+UpxdFy X+HiXkUcvhZXBX0AU9sY6K03XOk0GvMyrEdvH2SqCvYiCtB37QuqEanKNBSajyWj 8j9+wBdTdHQkU6g3LhgbxIIlL+3+JqmkUwyaPQGYuU5fc2BxidWYHd1hjitDHOSK jH8JAr4DQkcz4qxVwEoKCdgy62AO0OOoEXytAzCfZHp7nb6DO26S12i0QrGMBlau I+zduy9nFG+7SPdOcNDbFT7DPabbWixWveznKBqtlbBAk69lzWJ/xlX7V4SdgXIv 6XCqtFJDGK45bSrfxtysTxjkC3NjR8p1+G9okZ+xDqBNu8MeeIo921QPoPYZrR4= =nKJg -END PGP SIGNATURE-
Re: Open MPI with D
On 11/25/2011 05:27 PM, Andrei Alexandrescu wrote: On 11/25/11 8:55 AM, Max Samukha wrote: __gshared extern extern(C) int __argc; That doesn't link. Andrei It links correctly on windows for me and linux doesn't have the variables defined. Are you sure they are not windows-specific?
Re: Open MPI with D
On 2011-11-25 13:27, Andrei Alexandrescu wrote: On 11/25/11 2:13 AM, Jude Young wrote: Is there an easy way to turn D style (string[] args) into C style? Hm, I expected this would work: extern(C) int __argc; extern(C) char** __argv; The symbols do exist at least on OSX (no linker error) but they are both zero, so apparently druntime doesn't initialize them. Andrei As I wrote in another message in this thread, use these: Mac OS X: extern (C) char*** _NSGetEnviron(); Posix: extern (C) extern char** environ; -- /Jacob Carlborg
Re: TDPL D today?
On Fri, 25 Nov 2011 09:28:27 -0600 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Close and getting closer. So, some things are not implemented (yet), but no obsolete ones? Here's the errata: http://erdani.com/tdpl/errata/ Thank you. Sincerely, Gour -- When your intelligence has passed out of the dense forest of delusion, you shall become indifferent to all that has been heard and all that is to be heard. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Open MPI with D
On 11/25/11 10:00 AM, Max Samukha wrote: On 11/25/2011 05:27 PM, Andrei Alexandrescu wrote: On 11/25/11 8:55 AM, Max Samukha wrote: __gshared extern extern(C) int __argc; That doesn't link. Andrei It links correctly on windows for me and linux doesn't have the variables defined. Are you sure they are not windows-specific? As I wrote, on OSX the definitions do link so they exist. Andrei
Re: TDPL D today?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 25 Nov 2011 09:38:03 -0600 Jude Young 10equa...@gmail.com wrote: Please, learn the language as you go! OK. And post random questions to D.learn that make you look like an idiot. Will do! That's how REAL men learn a language! Thanks. (can I borrow your copy...?) I'd gladly borrow you, but I'm ashamed to offer a copy without author's name on the cover. ;) Moreover, I changed it by putting it in hardcover. :-) Sincerely, Gour - -- As the embodied soul continuously passes, in this body, from boyhood to youth to old age, the soul similarly passes into another body at death. A sober person is not bewildered by such a change. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJOz8erAAoJELhxXPVStcgQ+xAQAJPVruewZaGw37EbowyL2o5o n5SYzKTHxP/Ab4YymusH/MRuRepNSuXN6QsLwjieviQXfiM7qsTmfCZZpUR0fZqK bxwxO7HK06JEsDjjk1hHGYiWRRvsEgBflvmfAlgw3rpOv7GYrGVKnpB+JJv96wKa lmMZknBlFRf7o5RW/d4X97L5FKHz4sM5wSIoGlkoB+Lsp2qwWJqgEig8SpFOj13p 8kPqJUjEDW/kzaiI4IFkTrThDZyE3ihQH4L0a+XhPxHC0CLKISRsiI5fCNEAGZ4Q Jy8b195hqZldwq8uWnXn+ArFV/mfvqekg34x8VMnASRqgA2qi7YYhit4ZpmVeRQw Ye7pDcydUSPOXWE4k9E0wWnboPmJacE3q6LvUZ4la3cFleF1YzCOqDk9a75u4d6T sz63+K+z2Rx0K6uZbETIfsUhxlZm5m0Gzn38xIGJWIl1ciKoCmx7rCRPSV5TbR0R EeYjWX/rdZgcBBnbO2nV0q7ixVWJ3oovOOzD1zltZeZqoenfClotDXi/4BWArZSB 1BM19n/Qd1frttf67dr3+25EQ25Npm/7sTtPyx4v7+mZEENq+6SEIomZFEb2bDxq 945LltLaiGyJN9LGXS7zxu2WOokCm6RKVJ6BmIvYTfEZYYuSmhYDdIMpjsXnbCqY /lk8z6z8QRCcyR9VjCKR =e25W -END PGP SIGNATURE-
Re: Open MPI with D
On 11/25/2011 06:52 PM, Andrei Alexandrescu wrote: As I wrote, on OSX the definitions do link so they exist. Andrei Are you defining the variables or referencing them? extern(C) int x; means definition and of course it will link because it is you who defines the variable. extern extern(C) int x; means declaration and won't link if there is no definition somewhere else. I know that standard libs in MinGW gcc, DMC and MSVC do define those variables. I doubt they exist in non-MinGW gcc, including the one used on OSX.
Re: [std.database]
Steve Teale Wrote: So one question is where should such implementations go? github? Another questions relates to the definition of interfaces at module level. We have interfaces that go hand-in-hand with classes built in to the language. But if I wanted to say that two sql interface modules had the same 'interface', how could this be formalized. Could it be done using contracts? I'd welcome suggestions on this. It can be done using concepts: a template which instantiates to a set of static asserts about what you want.
Re: Open MPI with D
There's an edge-case here to be aware of, if you don't reference the
symbol there won't be linker errors (at least with optlink, and this
makes sense when you think about it):
// no linker errors
extern extern(C) int x;
void main() { }
// linker errors
extern extern(C) int x;
void main() { int z = x; }
Prestate in Ada 2012
There are several changes in Ada 2012, among them there is the introduction of Contract Programming, and one of its sub-features is the Old (prestate): http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0145-2.txt?rev=1.8 A general short introduction to the differences of Ada 2012: http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf Bye, bearophile
Re: using C++ classes from D
On Fri, 25 Nov 2011 08:22:34 +0100, Martin Nowak d...@dawgfoto.de wrote: After going astray while doing C++ class bindings using smart_ptrs and ugly mixins I think I found a really neat way. It consists of a C++ header that defines a d_new template function. It will allocate it's types from the D GC while hooking the C++ type's destructor to a D finalizer. It even allows for nested scanning of C++ classes and allocating other data, e.g. arrays. To use C++ class from D one only needs to define one factory function and add the class declaration to a D source file and link in the d_new module. Currently uses boost and offers no constructor arguments, due to the dreaded forwarding problem. https://gist.github.com/1391734 martin It should actually be also possible to fake the complete C++ calling conventions using extern(C) functions. Then a mangler can be library implemented and allowing almost full access. proof of concept https://gist.github.com/1394145 martin
D Parser in D
Is there a D parser written in D? - C strings kill me. Thanks, NMS
Re: Open MPI with D
On 11/25/11 11:30 AM, Max Samukha wrote: On 11/25/2011 06:52 PM, Andrei Alexandrescu wrote: As I wrote, on OSX the definitions do link so they exist. Andrei Are you defining the variables or referencing them? extern(C) int x; means definition and of course it will link because it is you who defines the variable. extern extern(C) int x; means declaration and won't link if there is no definition somewhere else. I know that standard libs in MinGW gcc, DMC and MSVC do define those variables. I doubt they exist in non-MinGW gcc, including the one used on OSX. Oh, I see. Thanks for enlightening me. So apparently I defined those variables... Andrei
Re: Website message overhaul, pass 2
Andrei Alexandrescu seewebsiteforem...@erdani.org writes: On 11/20/11 7:09 AM, Robert Clipsham wrote: - The code sample at the top is terrible, the equivalent C is only a couple of lines longer and it doesn't show off any of what makes D better! Admittedly you're limited in what you can do here as the code needs to be fairly understandable by non-D programmers, but what's there is... Not good at all. I'd be curious how with only a couple of lines more you address in C lines of arbitrary length and proper error handling. Same goes about C++ (in addition to the speed issue) - code that does the right thing and is not very slow is quite subtle and I doubt two out of five C++ programmers know how to write it. I had one minor thought on the average line length code example. If you eliminate the initialization of lines and sumLength, it would demonstrate default initialization. - Rotating the example is a brilliant idea, particularly if powered by a continuous contest. Yah, looking forward to that. It's going to be interesting. - This is less about the message, but how about an explain this link in the corner of examples with little hints for C/C++/Java programmers, so when clicked additional comments appear in the code or bubbles appear above on hover or something, they would include small bits of text like auto can be used in place of a type to infer the type from what is being assigned... But better worded of course. Good idea. What do you think about offering equivalent code from other languages? Not necessarily all language for any given example, but if there are enough equivalents from enough other languages, it might more directly highlight the strengths of D for newbies with those backgrounds. So in this case a perl comparison wouldn't be illuminating but a C++ one would. If all the various paradigms that D supports get illustrated that way it might give a broader feeling for how D will make things easier on many fronts. Jerry
Re: Discussion on D support in gdb
Martin Nowak d...@dawgfoto.de writes: On Tue, 22 Nov 2011 04:18:47 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Maybe someone knowledgeable could chime in: http://sourceware.org/ml/gdb/2011-11/msg00066.html Andrei I think we should follow Tom Tromney's proposal to add the extensions under the GNU vendor space, i.e. prefix them with 0x41xx. Numbers hopefully don't fall under licensing issues. It should be fairly straightforward to improve gdb debugging support given that changes are accepted on either side. The GDB codebase is a slightly unfriendly environment but getting rid of 'p ((char*[2])str)[1]' would be great. I've done a bit of reading on this issue, at least with regards to D arrays. I'm not a DWARF expert, but it appears that D dynamic arrays could be represented using the existing DWARF support, without an extension. Associative arrays are another issue. The current ABI describes them an opaque type. However, for the debugger to work with them, the structure must be understood somehow by the debugger. If treating them as a void* is the right approach (it still will result in compiler incompatibility), the ABI must define functions that access AA's. And debuggers will have to call those functions to read the AA. Until then, the debugger would have to cheat to access AA's. I don't know enough about delegates to comment on the support issues there. I would volunteer to do the implementation but it would be great if someone helped with clarifying the following issues. - Can we slowly start to acquire DWARF-3/4? - Why were extensions chosen over say representing an array as two field struct? There was a comment on the ABI page that a struct is passed to functions differently from an array, and therefore debuggers wouldn't handle D arrays correctly if described that way. - We could probably use DW_TAG_GNU_template_parameter_pack for variadic template arguments. http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates Note that the C++-11 standard also provides variadic templates. Therefore DWARF probably needs to address this in some standard way if it doesn't already. I'd think that D and C++ could share the same solution.
Re: Discussion on D support in gdb
Walter Bright newshou...@digitalmars.com writes: On 11/22/2011 7:19 AM, Martin Nowak wrote: - Can we slowly start to acquire DWARF-3/4? Dwarf 2 is good enough, so why do 3/4? - Why were extensions chosen over say representing an array as two field struct? Because it is presumably harder to get a debugger to recognize a magic struct than explicitly give it a type. - There is this request by Robert Clipsham http://dwarfstd.org/ShowIssue.php?issue=100504.1. What's the state of this, it wouldn't be needed any longer. - We should contact http://www.zero-bugs.com, it is said to support the dwarf extensions and would need to be changed. - Find out who else is affected by changing the current extensions. - Fixing the D-ABI specification. Are the issues in bugzilla? Huh, I swore I had already filed a bug regarding the AA ABI. http://d.puremagic.com/issues/show_bug.cgi?id=7008 Jerry
Re: D Parser in D
On Sat, 26 Nov 2011 07:58:19 +1300, NMS nathanms...@gmail.com wrote: Is there a D parser written in D? - C strings kill me. Thanks, NMS SDC[1] has one, but it's being lazy loaded in -- that is, it's not complete. [1]:http://github.com/bhelyer/SDC
Re: Early std.crypto
On 11/22/2011 08:16 AM, Piotr Szturmaj wrote: bcs wrote: How many people in the D community have the experience and know-how to review the security of an implementation? If there are less than 2 or 3 people who can do that, can we afford to include native kernels? We can't have just one and if we have only two and one leaves for some reason the code becomes un-maintainable for lack of a reviewer. *I* wouldn't be comfortable with less than about 4-5. I know Regan Heath who wrote some crypto code for Tango. Also, I suspect that D _will_ gain more (crypto) contributors, especially after joining GCC. Wrote some crypto code is a rather weak recommendation. Depending on how you interpret it, that would recommend *me*. A better recommendation would be Mr Y gets paid by security company X to do crypto analysis or Mrs Z has published several well review papers on vulnerabilities in this kind of code. Minimum number of contributors/reviewers requirement in open-source project is at least unfortunate in my opinion. Nevertheless, I respect your thoughts. But imagine what could happen if Walter waited for contributors instead of starting D project on his own? Please realize that we do not implement every possible crypto algorithm at once. We need to start with something like hashing, then add encryption and other cryptographic primitives. I have no problem with that comment. My concern revolves around the point that the implementation of cryptographic primitives has security implications. I'm worried that we don't have the resources to demonstrate that our implementation is at least as good as the currently available implementation. I'd rather Phobos not include a given primitive than contain one of unknown quality. What I'd like to see is that the crypto package quickly contain interfaces for all the primitives we can find pre-vetted Boost licensed implementations for. At that point I would have no issue with as methodical and meticulous effort to divest ourselves of external dependencies as we can get access to the expertises needed to vet our own implementations (to the same level as the code they are replacing). Yes, I'm intentionally being paranoid here but this is security and paranoia is part of the job description darn-it.
Re: [OT] For Andrej Mitrovic, Cairo OpenGL and Windows...
I think glitz was dropped from cairo ages ago and replaced with cairo_gl. GL is supported, but it's not precompiled into the DLL on the GTK website which is where people get the Cairo DLL from.
Re: Rquest for timings
Andrea Fontana: Hmm reading code i verified that i can gain a 10% writing: imd dSquared = sqrt(dx ^^ 2 + dy ^^ 2 + dz ^^ 2); imd mag = dt / (dSquared * dSquared^^2); Around line 115. Give it a try... My version performs a sqrt and one multiplication, while your version performs one sqrt and two multiplications. On my PC my version is faster. Bye, bearophile
Re: Rquest for timings
Really? Dmd version and system? (here: dmd from git, ubuntu 11.10 64bit) ./app 5000 Your version: real0m14.674s My version: real0m13.644s Your version: imd dSquared = dx ^^ 2 + dy ^^ 2 + dz ^^ 2; imd mag = dt / (dSquared * sqrt(dSquared)); My version: imd dSquared = sqrt(dx ^^ 2 + dy ^^ 2 + dz ^^ 2); imd mag = dt / (dSquared * dSquared^^2); // That is: dt / (dSquared^^3); Probably vars evaluation works better on my example? Btw: imd dSquared = sqrt(dx*dx + dy*dy + dz*dz); imd mag = dt / (dSquared*dSquared*dSquared); real0m13.574s Il giorno ven, 25/11/2011 alle 08.14 -0500, bearophile ha scritto: Andrea Fontana: Hmm reading code i verified that i can gain a 10% writing: imd dSquared = sqrt(dx ^^ 2 + dy ^^ 2 + dz ^^ 2); imd mag = dt / (dSquared * dSquared^^2); Around line 115. Give it a try... My version performs a sqrt and one multiplication, while your version performs one sqrt and two multiplications. On my PC my version is faster. Bye, bearophile
Re: How come a thread can access another thread's stack variable?
On Fri, 25 Nov 2011 10:34:12 +0100, Christophe
trav...@phare.normalesup.org wrote:
Andrej Mitrovic , dans le message (digitalmars.D.learn:30764), a écrit :
import core.thread;
import std.stdio;
struct Foo
{
int field;
void test()
{
writeln(field: , field);
}
}
void main()
{
Foo foo;
auto thread = new Thread(foo.test);
thread.start();
thread.join();
foo.test();
}
This prints the same addresses. std.concurrency won't let you do this,
while std.parallelism uses some form of weaker isolation, and it
seems core.thread has the same weaker isolation principle.
If foo is in TLS, how come a new thread can access its members?
It could with a cast to shared, couldn't it ?
A fix would be to make Thread check the shared-ness of context pointer
of the delegate (which may have to be fixed at the compiler level).
It would, but core.thread is not supposed to do that. It's the unsafe,
pedal-to-the-metal layer, and shouldn't stop people from doing stupid
things.
Re: [OT] For Andrej Mitrovic, Cairo OpenGL and Windows...
Thank you very much, Andrej Paolo On Nov 24, 2011, at 11:44 PM, Andrej Mitrovic wrote: OK, it's actually the same samples as the ones using the C API, except they've been modified to use the OOP CairoD based on a branch that added OpenGL support. In short, the link I gave you is the one you want. On 11/24/11, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Oh wait, I've just remembered I've had a branch in CairoD (the OOP wrapper) that *did* use GL, so I likely have samples for that as well. I'll take a look..
Re: Rquest for timings
Andrea Fontana Wrote: Yes, really :-) Timings taken with DMD 2.056+, 32 bit Vista OS. Bye, bearophile
Re: Rquest for timings
bearophile bearophileh...@lycos.com writes: This is the nbody benchmark of the Shootout site: http://shootout.alioth.debian.org/u32/performance.php?test=nbody The faster version is a Fortran one, probably thanks to vector operations that allow a better SIMD vectorization. This is the C++ version: http://shootout.alioth.debian.org/u32/program.php?test=nbodylang=gppid=1 C++ version compiled with: g++ -Ofast -fomit-frame-pointer -march=native -mfpmath=sse -msse3 --std=c++0x An input parameter is n= 3_000_000 (but use a larger number if therun time is too much small, like 10 millions or more). All timings done with gdc 0.30 using dmd 2.055 and gcc 4.6.2. I built with both D and C++ enabled so the back end would be the same. jlquinn@wyvern:~/d/tests$ ~/gcc/gdc/bin/g++ -O3 -fomit-frame-pointer -march=native -lm -mfpmath=sse -msse3 --std=c++0x nbody.cc -o nbody_c++ jlquinn@wyvern:~/d/tests$ time ./nbody_c++ 5000 -0.169075164 -0.169059907 real0m10.209s user0m10.180s sys 0m0.010s First D2 version (serial): http://codepad.org/AdRSm2wP ~/gcc/gdc/bin/gdc -O3 -fomit-frame-pointer -march=native -mfpmath=sse -msse3 -frelease nbody.d -o nbody_d jlquinn@wyvern:~/d/tests$ time ./nbody_d 5000 -0.169075164 -0.169059907 real0m9.830s user0m9.820s sys 0m0.000s jlquinn@wyvern:~/d/tests$ dmd -O -release nbody.d jlquinn@wyvern:~/d/tests$ time ./nbody_d 5000 -0.169075164 -0.169059907 real0m9.828s user0m9.830s sys 0m0.000s Second D2 version, three times slower thanks to vector ops, more similar to the Fortran version: http://codepad.org/7O3mz9en ~/gcc/gdc/bin/gdc -O3 -fomit-frame-pointer -march=native -mfpmath=sse -msse3 -frelease nbody2.d -o nbody2_d jlquinn@wyvern:~/d/tests$ time ./nbody2_d 5000 -0.169075164 -0.169059907 real0m26.805s user0m26.760s sys 0m0.020s jlquinn@wyvern:~/d/tests$ dmd -O -release nbody2.d jlquinn@wyvern:~/d/tests$ time ./nbody2_d 5000 -0.169075164 -0.169059907 real0m26.777s user0m26.760s sys 0m0.000s Is someone willing to take two (or more) timings using LDC 2 compiler (I have LDC1 only, beside DMD)? I'd like to know how much time it takes to run the first D version *compared* to the C++ version :-) If you time the second D2 version too, then it's better. Bye and thank you, bearophile So, the upshot seems like DMD and GDC generate similar code for this test. And both D compilers generate slightly faster code than the C++ version, therefore the D front end is doing a slightly better optimization job, or your first version is slightly more efficient code. Jerry
Re: [OT] For Andrej Mitrovic, Cairo OpenGL and Windows...
No problem. Are you going to distribute the DLL from somewhere? Btw, is this a private company work or is it a public effort? I'm just wondering what We means when you say We are currently in the process of building...
[Issue 5899] auto-return function cannot match 'null' with reference type.
http://d.puremagic.com/issues/show_bug.cgi?id=5899 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-11-25 00:29:00 PST --- https://github.com/D-Programming-Language/dmd/commit/31a3e406938cef17c8c6354ac5de70ad07707027 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
http://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #15 from bearophile_h...@eml.cc 2011-11-25 01:04:35 PST --- A good signature for sum(): sum(sequence[, dim=0[, start]]) In Fortran's sum() 'dim' is an optional value that defaults to 0 (well to the first index of an array, that is 0 in D), it specifies what dimension to perfom the sum to. On default it acts like the Python sum(). In Fortran you often have arrays of vectors (or arrays of tuples in D), and Fortran supports vector operations similar to D ones, so: VA = [[1,2,3], [4,5,6]] sum(VA)== [5, 7, 9] sum(VA, 0) == [5, 7, 9] sum(VA, 1) == [6, 15] sum(VA, x) == Error if x 1 Example usage, points is an array of double[3] that represent 3D points: totalDistance = sqrt(sum(points[] ^^ 2, dim=0)); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7004] New: Iterating tuple with index which explicitly typed as size_t causes error
http://d.puremagic.com/issues/show_bug.cgi?id=7004
Summary: Iterating tuple with index which explicitly typed as
size_t causes error
Product: D
Version: D1 D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2011-11-25 01:33:33 PST ---
void f(A...)(A args)
{
foreach (i, e; args){}// OK
foreach (uint i, e; args){} // OK
foreach (size_t i, e; args){} // NG
}
void main()
{
f(1, 3.14);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7004] Iterating tuple with index which explicitly typed as size_t causes an error
http://d.puremagic.com/issues/show_bug.cgi?id=7004 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch Summary|Iterating tuple with index |Iterating tuple with index |which explicitly typed as |which explicitly typed as |size_t causes error |size_t causes an error --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-11-25 01:44:29 PST --- D2 patch: https://github.com/D-Programming-Language/dmd/pull/533 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 259] Comparing signed to unsigned does not generate an error
http://d.puremagic.com/issues/show_bug.cgi?id=259 --- Comment #23 from bearophile_h...@eml.cc 2011-11-25 02:32:32 PST --- I think Walter is willing to accept that patch if someone improves the patch to remove some of its false positives. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 259] Comparing signed to unsigned does not generate an error
http://d.puremagic.com/issues/show_bug.cgi?id=259
--- Comment #24 from Don clugd...@yahoo.com.au 2011-11-25 04:05:29 PST ---
It seems wrong to me that:
if (-1 2u) {...}
fails to compile. Both are in the range -int.max .. int.max, so they can safely
be compared using signed comparison.
The problems with mixed sign are when one operand can be in the range
-int.max..0 and the other can be in the range int.max+1u..uint.max. If at least
one of the operands is in the polysemous range 0..int.max, there should be no
problem.
But, the patch as it stands allows a polysemous-ranged int to be compared with
a uint, but does not allow a polysemous-range uint to be compared with an int.
At present the spec doesn't give any reason for unsigned to be treated from
signed.
The problem is the silly C promotion rule that converts both operands to
unsigned (instead, it should generate an error). In any existing C code that
works, it works because the signed operand is in the polysemous range. Of
course there could be code which relies on (-12u) being false. But surely such
code is broken.
Do we really need to retain backwards compatibility with broken C code?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 259] Comparing signed to unsigned does not generate an error
http://d.puremagic.com/issues/show_bug.cgi?id=259 --- Comment #25 from bearophile_h...@eml.cc 2011-11-25 04:26:23 PST --- (In reply to comment #24) Thank you Don. Of course there could be code which relies on (-12u) being false. But surely such code is broken. I don't like this is in D. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7005] New: extern(C) mangling should always be flat
http://d.puremagic.com/issues/show_bug.cgi?id=7005
Summary: extern(C) mangling should always be flat
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: d...@dawgfoto.de
--- Comment #0 from d...@dawgfoto.de 2011-11-25 06:13:05 PST ---
template foo()
{
extern(C) void bar(int i);
}
pragma(msg, foo!().bar.mangleof);
// is: _D4bug38__T3fooZ3barUiZv should be: bar
related:
http://d.puremagic.com/issues/show_bug.cgi?id=6132
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6973] static assert(isOutputRange!(OutputRange!int, int)) is false
http://d.puremagic.com/issues/show_bug.cgi?id=6973 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-11-25 07:31:05 PST --- https://github.com/D-Programming-Language/phobos/pull/330 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7003] no tuple expansion for c++ mangling
http://d.puremagic.com/issues/show_bug.cgi?id=7003 --- Comment #1 from d...@dawgfoto.de 2011-11-25 08:23:44 PST --- Actually the template should not appear in the name mangling. Until http://d.puremagic.com/issues/show_bug.cgi?id=7005 is fixed it makes no sense to fix this Bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3733] Overloading on 'this' modifiers fails with implicit 'this'
http://d.puremagic.com/issues/show_bug.cgi?id=3733 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #3 from Kenji Hara k.hara...@gmail.com 2011-11-25 09:29:19 PST --- https://github.com/D-Programming-Language/dmd/pull/534 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5933] Cannot retrieve the return type of an auto-return member function
http://d.puremagic.com/issues/show_bug.cgi?id=5933 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch Platform|Other |All OS/Version|Mac OS X|All --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-11-25 10:56:34 PST --- https://github.com/D-Programming-Language/dmd/pull/535 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5288] auto return: forward ref error when using it with recursive functions
http://d.puremagic.com/issues/show_bug.cgi?id=5288
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Platform|Other |All
OS/Version|Linux |All
--- Comment #3 from Kenji Hara k.hara...@gmail.com 2011-11-25 11:12:06 PST ---
There is mutually recursive call as a slightly more complex case.
From http://d.puremagic.com/issues/show_bug.cgi?id=2810#c8
auto foo()
{
bar();
return 1;
}
auto bar()
{
foo();
return 1;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7006] New: std.math.pow (integral, integral) crashes on negative exponents
http://d.puremagic.com/issues/show_bug.cgi?id=7006 Summary: std.math.pow (integral, integral) crashes on negative exponents Product: D Version: D2 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: timon.g...@gmx.ch --- Comment #0 from timon.g...@gmx.ch 2011-11-25 13:12:07 PST --- It seems to be by design: if (n0) return x/0; // Only support positive powers But that does not make any sense. The results are well-defined if x!=0. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7007] New: [] should have a type of its own
http://d.puremagic.com/issues/show_bug.cgi?id=7007
Summary: [] should have a type of its own
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2011-11-25 13:20:47 PST ---
Now that null has an own type (issue 5416), typeof([]) == void[] is
inconsistent.
Consider:
void foo(int[] x){}
void bar(T)(T x){foo(x);}
void main(){
foo(null); // ok
foo([]); // ok
bar(null); // ok!
bar([]); // fail
}
This example should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7008] New: Associative array ABI is under-specified
http://d.puremagic.com/issues/show_bug.cgi?id=7008 Summary: Associative array ABI is under-specified Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: jlqu...@optonline.net --- Comment #0 from Jerry Quinn jlqu...@optonline.net 2011-11-25 14:25:09 PST --- The current ABI describes associative arrays as an opaque type. However, for a debugger to work with them, it must understand the structure. For 2 compilers to be able to generate compatible code, they must agree on the structure. Currently the ABI specifies an AA as an opaque implementation-defined type. This means that multiple compilers will not be able to guarantee compatibility since the AA ABI is not specified. Also, debuggers must refer to the source code of the compiler druntime in order to know how to work with the contents of an AA. Specifying C functions to manipulate the opaque pointer solves the debugger issue, but not the issue of ensuring compatibility across compilers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5409] Disallow (!x y)
http://d.puremagic.com/issues/show_bug.cgi?id=5409
--- Comment #6 from bearophile_h...@eml.cc 2011-11-25 15:55:36 PST ---
One more example found in the Doom3 sources:
http://www.viva64.com/en/b/0120/
#define BIT( num ) ( 1 ( num ) )
const int BUTTON_ATTACK = BIT(0);
void idTarget_WaitForButton::Think( void ) {
...
if ( player
( !player-oldButtons BUTTON_ATTACK )
( player-usercmd.buttons BUTTON_ATTACK ) ) {
...
}
I hope people like Kenji Hara will create a patch to fix this situation in D
language.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7004] Iterating tuple with index which explicitly typed as size_t causes an error
http://d.puremagic.com/issues/show_bug.cgi?id=7004 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-11-25 16:09:43 PST --- https://github.com/D-Programming-Language/dmd/commit/81842ad6687d4c114bdb6d4dddf0e75778c016b3 https://github.com/D-Programming-Language/dmd/commit/4d1146b65d8a21e787c1aa77adedd3a15b49bf2f -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6272] Named import in functions problem
http://d.puremagic.com/issues/show_bug.cgi?id=6272
--- Comment #4 from bearophile_h...@eml.cc 2011-11-25 16:27:19 PST ---
This seems a related problem:
void main() {
import std.algorithm;
auto data = new int[10];
sort(data); // OK
data.sort(); // Error: undefined identifier module temp.sort
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7009] New: countChars, removeChars
http://d.puremagic.com/issues/show_bug.cgi?id=7009
Summary: countChars, removeChars
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-11-25 16:34:03 PST ---
For uniformity with the other string functions I think std.string.countchars,
std.string.removechars need a capital letter in the middle:
import std.string: countChars, removeChars;
void main() {
string s = hello;
assert(s.countChars(l) == 2);
assert(s.removeChars(l) == heo);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4563] [module system] Error messages for missing package or missing name
http://d.puremagic.com/issues/show_bug.cgi?id=4563
--- Comment #3 from bearophile_h...@eml.cc 2011-11-25 16:36:00 PST ---
Now the situation is worse (DMD 2.057head):
import std.math: foo;
void main() {}
Gives:
test.d(1): Error: import __anonymous foo not found
test.d(1): Error: alias test.foo recursive alias declaration
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7010] New: Purity of map and filter
http://d.puremagic.com/issues/show_bug.cgi?id=7010
Summary: Purity of map and filter
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-11-25 16:39:07 PST ---
There are some important cases where the purity inference of
functions/delegates is not working well enough (DMD 2.057head):
import std.algorithm: map, filter;
int foo(immutable int x) pure nothrow {
return 1;
}
void main() pure {
immutable data = [1, 2, 3];
auto m1 = map!((x){ return 1; })(data); // OK
auto m2 = map!((int x){ return 1; })(data); // OK
auto m3 = map!q{ 1 }(data); // error, map is not pure
auto m4 = map!foo(data);// error, map is not pure
//
auto f1 = filter!((x){ return 1; })(data); // OK
auto f2 = filter!((int x){ return 1; })(data); // OK
auto f3 = filter!q{ 1 }(data); // error, filter is not pure
auto f4 = filter!foo(data);// error, filter is not pure
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7011] New: No line number error for vector power
http://d.puremagic.com/issues/show_bug.cgi?id=7011
Summary: No line number error for vector power
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-11-25 16:41:52 PST ---
This code doesn't compile and its error message doesn't even tell the line
number:
void main() {
auto a = [1, 2, 3];
a[] ^^= 2;
}
DMD 2.057head gives:
Error: must import std.math to use ^^ operator
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7012] New: Pure vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=7012
Summary: Pure vector operations
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-11-25 16:44:15 PST ---
I think vector ops need to become pure to allow code like:
void main() pure nothrow {
int[3] a = [1, 2, 2];
int[3] b = [10, 20, 20];
immutable int[3] c = a[] + b[];
}
DMD 2.057head gives:
test.d(4): Error: cannot implicitly convert expression (a[] + b[]) of type
int[] to const(immutable(int)[])
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3971] Syntax semantics for array assigns
http://d.puremagic.com/issues/show_bug.cgi?id=3971
--- Comment #22 from bearophile_h...@eml.cc 2011-11-25 16:54:31 PST ---
In DMD 2.057head this code fails still:
void main() {
int[3] a = [1, 2, 3];
int[3] b = [10, 20, 30];
auto c[] = a[] + b[]; // no identifier for declarator c[]
}
void main() pure nothrow {
int[3] a = [1, 2, 2];
int[3] b = [10, 20, 20];
const c = a[] + b[]; // Error: Array operation a[] + b[] not implemented
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7013] New: Mutable interface for BigInts
http://d.puremagic.com/issues/show_bug.cgi?id=7013 Summary: Mutable interface for BigInts Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2011-11-25 16:52:13 PST --- When multi-precision numbers become large or quite large, the time spent managing their memory risk becoming an issue. To improve this situation the GNU multiprecision integer library allows for mutable numbers, that allow in-place modification. There was a discussion about offering a mutable interface for the General Multiprecision PYthon project (GMPY) numbers too (see Mutability... but not for now): http://gmpy.sourceforge.net/ So maybe it's useful to add a mutable interface to Phobos bigints. A simple way to do it is to add a mutable attribute that supports just few in-place operations like += -= *= /= ^^= = |= (but not other operations like == that don't need mutability, to keep the situation semantically more clean): auto x = BigInt(...); x.mutable += BigInt(...); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7014] New: Better union initialization syntax
http://d.puremagic.com/issues/show_bug.cgi?id=7014
Summary: Better union initialization syntax
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-11-25 17:01:51 PST ---
After using several unions for a while in D, I think the syntax to initialize
fields of unions is not handy enough. An idea from GNU-C:
import std.stdio;
union Foo { int i; double d; };
void main() {
int x;
double y;
Foo u = void;
auto u1 = cast(Foo)x;
writeln(typeof(u1).stringof);
auto u2 = cast(Foo)y; // Error: e2ir: cannot cast y of type double to type
Foo
writeln(typeof(u2).stringof);
}
See:
http://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html#Cast-to-Union
But I don't like that GNU-C idea, a problem with cast() is that it's not
precise enough, if there are two fields like this, what is a good way to assign
's' or 'u' using a cast()?
union Foo { int s; uint u; };
So I'd like a more explicit syntax.
A solution using named arguments seems good:
union Foo { int s; uint u; };
void bar(Foo f) {}
void main() {
bar(Foo(u:5));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7015] New: ^^ and ^^= vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=7015
Summary: ^^ and ^^= vector operations
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-11-25 17:05:12 PST ---
While writing some D code that uses vectors and the desire to find distances
among them, I'd like this vector operation to be supported:
void main() {
int[] a = [1, 2, 3];
int[] b = a[] ^^ 2;
}
DMD 2.057head gives:
test.d(3): Error: Array operation a[] ^^ 2 not implemented
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7016] New: local import does not create -deps dependency
http://d.puremagic.com/issues/show_bug.cgi?id=7016
Summary: local import does not create -deps dependency
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com
--- Comment #0 from Vladimir Panteleev thecybersha...@gmail.com 2011-11-25
21:19:34 PST ---
a.d : import b; void main() { f(); }
b.d : int f() { import c; return i; }
c.d : int i = 42;
The command
$ dmd -deps=a.deps -o- a.d
creates:
a (a.d) : public : object
(C:\\Soft\\dmd2d\\windows\\bin\\..\\..\\import\\druntime\\object.di)
b (b.d) : public : object
(C:\\Soft\\dmd2d\\windows\\bin\\..\\..\\import\\druntime\\object.di)
a (a.d) : public : b (b.d)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7017] New: Pure inference makes inconsistent result
http://d.puremagic.com/issues/show_bug.cgi?id=7017
Summary: Pure inference makes inconsistent result
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2011-11-25 22:23:44 PST ---
Pure/nothrow/@safe inference with template function is shallow.
It does not affect to nested non-template struct member functions.
But in following code, map template function inferred as pure in some cases.
This is pure inference bug.
template map(fun...) if (fun.length = 1)
{
auto map()
{
struct Result {
this(int dummy){} // impure member function
}
return Result(0); // impure call
}
}
int foo(immutable int x) pure nothrow { return 1; }
void main() pure
{
int bar(immutable int x) pure nothrow { return 1; }
static assert(!__traits(compiles, map!((){})())); // should pass, but
fails
static assert(!__traits(compiles, map!q{ 1 }())); // pass, OK
static assert(!__traits(compiles, map!foo())); // pass, OK
static assert(!__traits(compiles, map!bar())); // should pass, but
fails
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7010] Purity of map and filter
http://d.puremagic.com/issues/show_bug.cgi?id=7010 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Component|DMD |Phobos --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-11-25 22:39:24 PST --- The instantiation of map function given a delegate literal should not be inferred as pure, it is compiler bug. I've separated the issue into bug 7017. Then this issue is now purely Phobos enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7017] Pure inference makes inconsistent result
http://d.puremagic.com/issues/show_bug.cgi?id=7017 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-11-25 22:51:52 PST --- https://github.com/D-Programming-Language/dmd/pull/536 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7011] No line number error for vector power
http://d.puremagic.com/issues/show_bug.cgi?id=7011 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||diagnostic, patch Platform|x86 |All OS/Version|Windows |All --- Comment #1 from Kenji Hara k.hara...@gmail.com 2011-11-25 23:42:57 PST --- https://github.com/D-Programming-Language/dmd/pull/537 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
