DIP80: phobos additions
Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss
compiled program error
While developing with D (DMD64 D Compiler v2.067.0 on MacOS
10.10.3) I had a program with an unexpected behaviour
and I reduced it to the minimal form below. The error as
indicated in the comment is that the function call pvi_calc
changes int_1 when I think it should not. The result copied below.
I hope this helps. Kind regards
John Nixon
import std.stdio;
int n,cp;
double[] pvi,int_1,int_2;
void pvi_centre(const int centre){
int_1=pvi_calc(centre);
writeln(int_1 = ,int_1);
int_2=pvi_calc(n-1-centre);//pvi_calc is changing int_1!
writeln(int_1 = ,int_1);
return;}
double[] pvi_calc(const int n1){
for(int i=0;i=n1;++i)pvi[i]= 1;
return pvi;}
int main(){
n=10;
pvi.length=n;
int_1.length=int_2.length=n;
pvi_centre(cp);
return 0;}
~
int_1 = [1, nan, nan, nan, nan, nan, nan, nan, nan, nan]
int_1 = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
Re: Honey, I shrunk the build times
On Sunday, 7 June 2015 at 08:59:46 UTC, Iain Buclaw wrote: I wouldn't have thought that not moving to 2.067 would be a hold-up (there is nothing in that release that blocks building DDMD as it is *now*). The biggest problem is that releasing a ddmd which is compiled with dmd is unacceptable, because it incurs too large a performance hit (~20% IIRC), so we need either ldc or gdc to be at 2.067 so that we can use that to compile the release build of ddmd. But I have been promised time and again that there will be more effort (infrastructure?) put in to help get LDC and GDC integrated into the testing process for all new PRs. That would be good, though I don't know what the situation with that is. However, I think that Daniel's top priority at this point is getting the frontend to the point that it's backend-agnostic and thus identical for all three backends, which should greatly help in having gdc and ldc keep up with dmd. That obviously wouldn't obviate the need for testing gdc and ldc, but it would reduce the effort to update them and maintain them. - Jonathan M Davis
Re: Honey, I shrunk the build times
On 6/7/15 2:36 AM, Jacob Carlborg wrote: On 2015-06-07 06:30, Andrei Alexandrescu wrote: Thanks for asking. The situation before went like this: to build libphobos2.a, the command would go like this (simplified to just a few files and flags: dmd -oflibphobos2.a std/datetime.d std/conv.d std/algorithm/comparison.d std/algorithm/iteration.d So all modules would go together in one command to build the library. With the package-at-a-time approach, we build one directory at a time like this: I'm wondering if the impovements would have been larger if Phobos had a more tree structure for the modules rather than a fairly flat structure. Affirmative. Currently the duration of the build is determined by the critical path, which mainly consists of building std/*.d. -- Andrei
Re: compiled program error
On Sunday, 7 June 2015 at 18:59:00 UTC, John Nixon wrote:
While developing with D (DMD64 D Compiler v2.067.0 on MacOS
10.10.3) I had a program with an unexpected behaviour
and I reduced it to the minimal form below. The error as
indicated in the comment is that the function call pvi_calc
changes int_1 when I think it should not. The result copied
below.
I hope this helps. Kind regards
John Nixon
import std.stdio;
int n,cp;
double[] pvi,int_1,int_2;
void pvi_centre(const int centre){
int_1=pvi_calc(centre);
writeln(int_1 = ,int_1);
int_2=pvi_calc(n-1-centre);//pvi_calc is changing int_1!
writeln(int_1 = ,int_1);
return;}
double[] pvi_calc(const int n1){
for(int i=0;i=n1;++i)pvi[i]= 1;
return pvi;}
int main(){
n=10;
pvi.length=n;
int_1.length=int_2.length=n;
pvi_centre(cp);
return 0;}
~
int_1 = [1, nan, nan, nan, nan, nan, nan, nan, nan, nan]
int_1 = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
There is only one pvi array at all. So, pvi_calc function
modifying that only one, and returns it back.
When you first call pvi_calc, int_1 points to pvi array. When you
call it second time, int_2 points to same pvi array again.
Since both of them points to same array, value of int_1 (actually
value of pvi array) changes.
std.experimental.safeint.d
SafeInt!T is an integer wrapper struct with an explicit NaN value build on top of core.checkedint. Features: * checks if assigned values can be actually stored * for SafeInt!u(T) NaN is T.max * for SafeInt!T NaN is T.min * SafeInt!T.opBinary(+,-,%,*,/) return SafeInt!T if value can not be store by SafeInt!T returned value is SafeInt!T.nan * should be pretty much a act as any (u)integer type Additionally, the module contains safe ==,!=,,=,,= comparisons functions assert(-1 == uint.max); // this is wrongfully true assert(notEqual(-1, uint.max)); // this asserts correctly true
Re: std.experimental.safeint.d
PR: https://github.com/D-Programming-Language/phobos/pull/3389
Re: compiled program error
On Sunday, 7 June 2015 at 19:05:16 UTC, Adam D. Ruppe wrote:
On Sunday, 7 June 2015 at 18:59:00 UTC, John Nixon wrote:
double[] pvi,int_1,int_2;
int_1=pvi_calc(centre);
int_2=pvi_calc(n-1-centre);//pvi_calc is changing int_1!
double[] pvi_calc(const int n1){
return pvi;}
These are the relevant lines: pvi_calc writes to a global array
(pvi) then returns it.
So the first two lines are just setting int_1 and int_2 both to
pvi, the same thing. So since they all reference the same
array, writing to any of them changes all of them.
You'll probably want to move double[] pvi to inside pvi_calc so
it becomes a new copy, or at least `return pvi.dup;` instead of
just `return pvi;`
Thank you for your concise reply. I had forgotten the distinction
between arrays and slices that is described in Ali Chehreli's
book Programming in D.
John Nixon
Re: Code behaves incorrectly if it is compiled in std.functional
On 06/06/2015 08:10 AM, ketmar wrote: if `auto` can play a role of type placeholder There is no such thing as a type placeholder.
Re: DIP80: phobos additions
On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss Yes, it's a great DIP's discussion. I just for the expansion of Phobos! You also need to consider Hana to copy some very useful elements in the Phobos: http://ldionne.com/hana/
Re: Code behaves incorrectly if it is compiled in std.functional
On 06/06/2015 08:06 AM, ketmar wrote:
On Sat, 06 Jun 2015 00:28:51 +0200, Timon Gehr wrote:
On 06/05/2015 02:33 PM, ketmar wrote:
i agree, i think it was a keyword used 'cause it was already used in C.
but it's meaning is completely redefined in D.
The meaning is exactly the same. It's the default storage class.
then i'll fill a bug about `auto auto` and will reopen it until it's
fixed.
This is valid C:
int main(){
const auto int x=2;
return 0;
}
This is not valid C:
int main(){
auto auto int x=2;
return 0;
}
What is the problem?
Re: Make dub part of the standard dmd distribution
On 2015-06-07 17:27, Nick Sabalausky wrote: Even if that stuff isn't currently known to code.dlang.org, it'd all be easy for it to obtain: $ mkdir some_temp cd some_temp $ git clone package_URL dir cd dir $ dmd (flags dub already knows) -v | grep import Would only need to do that when it detects a new version tag (which it already detects). So the registry basically needs to compile all packages? Isn't it better to compile and upload packages then? -- /Jacob Carlborg
Re: rvalue references
On Sat, 06 Jun 2015 14:05:54 -0400, Namespace rswhi...@gmail.com wrote: Finally all green! Now we need a review. You're my hero. Bit
Re: Code behaves incorrectly if it is compiled in std.functional
On 06/07/15 18:49, Timon Gehr via Digitalmars-d wrote:
This is valid C:
int main(){
const auto int x=2;
return 0;
}
This is not valid C:
int main(){
auto auto int x=2;
return 0;
}
What is the problem?
The problem is the apparently common misunderstanding that
'auto' is a thing in D. It is not; it's just a grammar hack.
The (very simplified) rule for declarations in C/C++/D is
storage_class type lhs = rhs
In C, you can omit the /storage_class/ and it then defaults to
'auto'. Obviously, the 'auto' keyword is redundant and nobody
actually uses it.
In D, you can omit the /type/ and it's then propagated from the
/rhs/ expression. The compiler already knows the type that 'rhs'
evaluates to.
But you can not omit both the /type/ and the /storage_class/ as
'lhs=rhs' would be indistinguishable from an assignment. In some
contexts for the compiler, but, more importantly, for the human.
Hence 'auto lhs = rhs'.
[The exceptions are either because of backward C compatibility
(function args) or no need for such compatibility (foreach)]
Still, 'auto' isn't as bad as 'static', which D redefined to mean
something different than in C/C++, and did this so subtly that
the C version will still compile, giving unexpected results without
even a warning.
artur
Re: compiled program error
On Sunday, 7 June 2015 at 18:59:00 UTC, John Nixon wrote:
double[] pvi,int_1,int_2;
int_1=pvi_calc(centre);
int_2=pvi_calc(n-1-centre);//pvi_calc is changing int_1!
double[] pvi_calc(const int n1){
return pvi;}
These are the relevant lines: pvi_calc writes to a global array
(pvi) then returns it.
So the first two lines are just setting int_1 and int_2 both to
pvi, the same thing. So since they all reference the same array,
writing to any of them changes all of them.
You'll probably want to move double[] pvi to inside pvi_calc so
it becomes a new copy, or at least `return pvi.dup;` instead of
just `return pvi;`
Re: Honey, I shrunk the build times
On Sun, 07 Jun 2015 11:01:19 +0200, Iain Buclaw via Digitalmars-d wrote: On 7 June 2015 at 10:51, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 07 Jun 2015 08:24:23 +, Temtaime wrote: It's really bad solution. Are you building phobos 1000 times a day so 5 seconds is really long for you ? Separate compilation prevents compiler from inlining everything. how is that? even if we left lto aside, compiler needs module source anyway. if one will use full .d files instead of .di, nothing can prevent good compiler from inlining. Semantic analysis is done lazily. No AST, no inline. but everything one need to do semantic is already there. it's just calls to `semantic` are absent. with some imaginary --aggressive-inline option compiler can do more semantic calls and inline things properly. sure, that will slow down compilation, but that's why it should be done as opt-in feature. signature.asc Description: PGP signature
Re: Code behaves incorrectly if it is compiled in std.functional
On Sunday, 7 June 2015 at 05:02:47 UTC, ketmar wrote: On Sat, 06 Jun 2015 18:49:00 +, Marc Schütz wrote: On Saturday, 6 June 2015 at 15:12:38 UTC, ketmar wrote: what should i check to see what is *really* allowed, why two storage classes allowed with one combination and not allowed with another? Well, you can look at the compiler's source... But I'm sure this is not the answer you wanted ;-) sure. now i'm completely lost. i shouldn't use DMD to find out things, yet i have to use DMD to find out things. Im my defense, you asked what _is_ really allowed, not what _should_ be allowed... ok, let's be serious. what i'm trying to say is that there should be not only grammar with comments inside it here and there, but the document that explains what is what, what's compatible with what and so on. the specs in the meaning that one can point to it and say: this is how it is supposed to be. now fix your code. or now let's fix the compiler. the specs where no undefined behavior words are used, and no it's left to compiler implementer to decide. (but look at DMDFE source is allowed ;-). Brian Schott did a lot of work finding inconsistencies and ambiguities in the grammar, and I believe his DConf talk was partially about it.
Re: Simple http client Dlang library
On Sunday, 7 June 2015 at 06:43:25 UTC, Ilya Yaroshenko wrote: Этот сайт не принимает визиты россиян. This site does not accept visits of Russians. Ta strona nie akceptuje odwiedzin Rosjan. So, I have 5 nationalities (including Polish). And many Russians have Polish nationality too (but they don't know about it). You hate my country. Hmm... IT IS SO FUNNY =) Getting angry of somebody is NOT my purpose. This was a residue of my youthful rebelion against everything. I didn't know this script is still on my site. I had to spend an hour to find those lines and remove them from the stats engine script and I'm realy sorry about this incident.
Re: Simple http client Dlang library
On Sunday, 7 June 2015 at 05:29:30 UTC, ketmar wrote: On Sat, 06 Jun 2015 22:20:19 +, kryszczyniak wrote: Hello! I've created AllUCanGET, a very simple D2 http client library which you could use instead of std.net.curl module to make http connections. You can find the library with more information here: a href=http://allucanget.diaboli.pl/;http://allucanget.diaboli.pl//a. nice work, but... no sources? that means no win64 support, no gdc support, no ldc support, no freebsd support too, i believe... For now, no sources. The author is the last person who wants to use the app ;) I'm D beginner. I'll publish sources when I clean them first.
Re: Eponymous/anonymous mixin templates
On 06/07/15 11:05, Jeffrey Tsang via Digitalmars-d wrote:
I use a mixin template to define exactly one symbol, and at instantiation I
wish to use that symbol immediately, once.
AFAICT you're asking for the commented-out line in
auto Tmpl() = l;
void main(string[] argv) {
auto l = argv.length;
mixin Tmpl!() a;
assert(a.Tmpl==l);
//assert(a==l);
}
to work. That would probably be enough, make sense and have
no serious backward compat issues.
artur
Re: Honey, I shrunk the build times
On Sunday, 7 June 2015 at 08:34:50 UTC, weaselcat wrote: On Sunday, 7 June 2015 at 08:24:24 UTC, Temtaime wrote: Separate compilation prevents compiler from inlining everything. only bad compilers All existing compilers AFAIK. There is no point in discussing theoretical advanced enough compiler when considering actions done right now. Good compiler should be able to work as caching daemon and never need separate object files at all. So we should completely ban it by that logic. In practice creating library per package is decent compromise that works good right now, even if it is consistently imperfect.
Re: Honey, I shrunk the build times
On Sunday, 7 June 2015 at 10:11:26 UTC, Dicebot wrote: On Sunday, 7 June 2015 at 08:34:50 UTC, weaselcat wrote: On Sunday, 7 June 2015 at 08:24:24 UTC, Temtaime wrote: Separate compilation prevents compiler from inlining everything. only bad compilers All existing compilers AFAIK. There is no point in discussing theoretical advanced enough compiler when considering actions done right now. right off the top of my head, I know ghc and rustc have zero issue with this or are we only referring to D compilers?
Re: Is it possible to add items to the arrays and hashes at compile time?
On Sunday, 7 June 2015 at 12:30:12 UTC, Dennis Ritchie wrote:
Does D the ability to add items to arrays and hashes at compile
time?
For example, how do I do it in compile time?:
int[][int][int] hash;
hash[4][6] ~= [34, 65];
hash[5][7] ~= [4, 78, 21];
try using a pure function + static e.g.
int[][int][int] somePureDefaultHash() pure
{
... //initialise it here
}
...
static hash = somePureDefaultHash();
Re: Simple http client Dlang library
On Sunday, 7 June 2015 at 13:17:01 UTC, kryszczyniak wrote: On Sunday, 7 June 2015 at 06:43:25 UTC, Ilya Yaroshenko wrote: Этот сайт не принимает визиты россиян. This site does not accept visits of Russians. Ta strona nie akceptuje odwiedzin Rosjan. So, I have 5 nationalities (including Polish). And many Russians have Polish nationality too (but they don't know about it). You hate my country. Hmm... IT IS SO FUNNY =) Getting angry of somebody is NOT my purpose. This was a residue of my youthful rebelion against everything. I didn't know this script is still on my site. I had to spend an hour to find those lines and remove them from the stats engine script and I'm realy sorry about this incident. OK, I am sorry too.
Re: Proposal for new dlang.org fonts
On Friday, 5 June 2015 at 23:10:33 UTC, Andrei Alexandrescu wrote: Take a look at https://github.com/D-Programming-Language/dlang.org/pull/1009. Preview: http://erdani.com/d/phobos-prerelease/ Destroy. Andrei A bit OT. What's up with the -moz-hypens? Looks better without it. https://imgur.com/AIFXmch
Re: Reggae binary backend: build your project with a D compiled executable
The interface can follow that of vibe:
--- build.d ---
import std.experimental.build;
Build myBuild(){ ... }
mixin BuildMain!(myBuild);
---
Then
$ rdmd build.d
- compile and run the script, which builds the project by default
$ rdmd build.d -ninja
- the script run with -ninja switch only generates ninja scipt
$ rdmd build.d -make
- same, but generates make script
$ rdmd --build-only build.d
- compiles the script, which can then be run with whatever
switches you want
[Issue 14656] auto of auto ref spills over to other function
https://issues.dlang.org/show_bug.cgi?id=14656 Daniel Kozak kozz...@gmail.com changed: What|Removed |Added CC||kozz...@gmail.com --- Comment #2 from Daniel Kozak kozz...@gmail.com --- problem is that auto does not affect type mangling, so when type is lookup in table it will return wrong type. To fix it we must make it ilegal to use auto int or change type mangling. --
Re: Simple http client Dlang library
On 7 June 2015 at 15:18, kryszczyniak via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Sunday, 7 June 2015 at 05:29:30 UTC, ketmar wrote: On Sat, 06 Jun 2015 22:20:19 +, kryszczyniak wrote: Hello! I've created AllUCanGET, a very simple D2 http client library which you could use instead of std.net.curl module to make http connections. You can find the library with more information here: a href=http://allucanget.diaboli.pl/;http://allucanget.diaboli.pl//a. nice work, but... no sources? that means no win64 support, no gdc support, no ldc support, no freebsd support too, i believe... For now, no sources. The author is the last person who wants to use the app ;) I'm D beginner. I'll publish sources when I clean them first. The good thing about releasing source is that people will clean them for you! (If there's interest)
Re: Make dub part of the standard dmd distribution
On 06/06/2015 09:16 AM, Jacob Carlborg wrote: On 2015-06-05 15:17, Steven Schveighoffer wrote: The source of the package does. code.dlang.org can create this automatically. I see two problems with this: 1. Does the registry (code.dlang.org) really know which files a Dub package contains? I would guess the registry mostly contains information where to find the source for a package, i.e. GitHub Rubygems, for example, on the other hand would be able to do this because a Ruby gem (package) is ZIP archive with all the sources for the package included. Also, when building a gem the package description is compiled, that is, all shell globs are expanded to locate all files. 2. It's possible to have a file with a completely different module name in D Even if that stuff isn't currently known to code.dlang.org, it'd all be easy for it to obtain: $ mkdir some_temp cd some_temp $ git clone package_URL dir cd dir $ dmd (flags dub already knows) -v | grep import Would only need to do that when it detects a new version tag (which it already detects).
Re: Reggae binary backend: build your project with a D compiled executable
On Sunday, 7 June 2015 at 07:00:18 UTC, Atila Neves wrote: I'm currently considering (because of dmd, druntime and phobos) how to strip it down to its bare essentials and have a core set of source files that only knows how to build D code, i.e. no C/C++, no dub, no make/ninja. Why strip?
Re: Honey, I shrunk the build times
On 6/7/15 1:24 AM, Temtaime wrote: It's really bad solution. No. Are you building phobos 1000 times a day so 5 seconds is really long for you ? Yes. Andrei
Re: Honey, I shrunk the build times
On 06/07/2015 12:30 AM, Andrei Alexandrescu wrote: parallel processing almost always ends up doing more work - some of which is wasteful, but in the end it wins. It's counterintuitive sometimes. It just means you're taking more system resources, which yea, can naturally be faster as long as those resources aren't already in use. Get more people assembling gizmos and you'll reach your quota faster even with a little bit of coordination overhead.
Re: Honey, I shrunk the build times
C style per-module separate compilation sux != splitting the library into smaller meaningful static libraries sux It was all discussed and nailed down so many times but old habits never die easy.
Re: Reggae binary backend: build your project with a D compiled executable
On Sunday, 7 June 2015 at 12:06:52 UTC, Kagamin wrote: On Sunday, 7 June 2015 at 07:00:18 UTC, Atila Neves wrote: I'm currently considering (because of dmd, druntime and phobos) how to strip it down to its bare essentials and have a core set of source files that only knows how to build D code, i.e. no C/C++, no dub, no make/ninja. Why strip? I meant strip in a general sense, not in the sense of stripping symbols. Atila
Re: Constructor inheritance? Why not?
On Monday, 8 June 2015 at 03:35:52 UTC, Jonathan M Davis wrote: On Monday, 8 June 2015 at 02:39:22 UTC, Tofu Ninja wrote: Is there any reason why constructors are not inherited? All other methods are inherited, why not constructors? They're not polymorphic, and it doesn't make sense to call a base class constructor on a derived class. I think that I heard somewhere that C++11 added some sort of constructor inheritance, so maybe there's something we could do that would make sense, but in general, I don't see how the concept makes any sense at all. Construction is intimately tied to the type being constructed. It's as non-generic as you can get. - Jonathan M Davis Their are plenty of examples where you would want a constructor to be inherited, exceptions being a good one. Currently if you have a base class with a constructor that you want all the sub classes to have as well, you simply have to just copy past them all over the place.
Re: DIP80: phobos additions
On 8/06/2015 4:05 p.m., Manu via Digitalmars-d wrote: On 8 June 2015 at 13:54, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/06/2015 3:48 p.m., Manu via Digitalmars-d wrote: On 8 June 2015 at 13:08, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/06/2015 2:50 p.m., Tofu Ninja wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss Would love some kind of color implementation in Phobos, simple linear algebra(vectors, matrices), image manipulation. https://github.com/D-Programming-Language/phobos/pull/2845 He Manu, hows it going? I've kinda just been working on it on the side for my own use. I wasn't happy with the layout, and restructured it a lot. If there's an active demand for it, I'll give it top priority...? Like I said its a blocker for an image library. There's no point implementing an image library with a half baked color definition meant for phobos. Yeah, that's fine. Is there an initiative for a phobos image library? I have said before that I'm dubious about it's worth; the trouble with an image library is that it will be almost impossible to decide on API, whereas a colour is fairly unambiguous in terms of design merits. I agree that it is. But we will need to move past this for the betterment of our ecosystem. Without it we will suffer too much. As it is, Devisualization.Image will have a new interface once std.image.color is pulled. So it'll be a contender for std.image. The long term issue is that we cannot really move forward with anything related to GUI or game development into phobos without it. So preferably we can get it into phobos by the end of the year :) Yeah, I agree it's a sore missing point, which is why I started working on it ;) ... I'll make it high priority. I recently finished up various work on premake5, so I can work on this now. Sounds good, I was getting worried that you had stopped altogether.
Re: DIP80: phobos additions
On 8/06/2015 4:34 p.m., Tofu Ninja wrote: On Monday, 8 June 2015 at 04:22:56 UTC, Mike wrote: On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote: Personally I would just be happy with a d wrapper for something like freeimage being included. That's what Deimos is for (https://github.com/D-Programming-Deimos/FreeImage). Mike I guess I meant to use it as a base for image loading and storing and to build some kind of d image lib on top of it. I see no point in us trying to implement all the various image formats if we try to make a image lib for phobos. Atleast my idea behind Devisualization.Image was mostly this. The implementation can be swapped out with another easily. But the actual interface used is well made. So while a Phobos image library might have a few formats such as PNG, it probably wouldn't include a vast array of them. So then its just a matter of allowing 3rd party libraries to add them transparently.
Re: DIP80: phobos additions
On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss Would love some kind of color implementation in Phobos, simple linear algebra(vectors, matrices), image manipulation.
Re: Constructor inheritance? Why not?
On Monday, 8 June 2015 at 04:16:14 UTC, Tofu Ninja wrote: Their are plenty of examples where you would want a constructor to be inherited, exceptions being a good one. Currently if you have a base class with a constructor that you want all the sub classes to have as well, you simply have to just copy past them all over the place. In most cases, you need to create a new constructor, because it's a different type with different data, even if some of the constructor parameters might be the same. Exceptions are a rare case where the constructors are frequently the same, because frequently with exceptions all you care about is the type itself, not additional data. But that's far from normal. Certainly, if there's any kind of constructor inheritance, I think that it needs to be explicit, because otherwise, you'll accidentally end up with constructors that you don't even know you have. But while it might be nice to avoid boilerplate in exception code, I question that it's worth much in the general case, because it's only useful when you don't have additional data that needs to be passed to the constructor of a derived class. Regardless, we're talking about syntactic sugar here. Maybe it's worth adding. Maybe not. But the primary reasons that we don't have it are because the languages before us didn't it (meaning that we're less likely to have thought of it), and because it's not actually needed, so we can get by fine without it. But the type of inheritance that you're talking about with constructors is fundamentally different from the type of inheritance that you get with other functions, so I don't think that the fact that we have class inheritance makes it at all obvious that we would have constructor inheritance or even that we should have it. Really, it's just a question of whether this particular bit of syntactic sugar is worth adding (which is debatable). It's not something fundamental about how class inheritance and polymorphism work. I expect that if someone came up with a good DIP for this and implemented a PR for it that they'd stand a reasonable chance of getting it into the language, but it's not exactly something that folks have been screaming for. - Jonathan M Davis
Re: DIP80: phobos additions
On Monday, 8 June 2015 at 04:22:56 UTC, Mike wrote: On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote: Personally I would just be happy with a d wrapper for something like freeimage being included. That's what Deimos is for (https://github.com/D-Programming-Deimos/FreeImage). Mike I guess I meant to use it as a base for image loading and storing and to build some kind of d image lib on top of it. I see no point in us trying to implement all the various image formats if we try to make a image lib for phobos.
Re: DIP80: phobos additions
On Monday, 8 June 2015 at 04:22:56 UTC, Mike wrote: On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote: Personally I would just be happy with a d wrapper for something like freeimage being included. That's what Deimos is for (https://github.com/D-Programming-Deimos/FreeImage). Yeah. After the problems with linking in curl, I think that we more or less decided that including stuff in Phobos which has to link against 3rd party libraries isn't a great idea. Maybe we'll end up doing it again, but in general, it just makes more sense for those to be done as 3rd party libraries and put in code.dlang.org. - Jonathan M Davis
Re: DIP80: phobos additions
On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss I think a std.bindings or something similar for ubiquitous C libraries would go a long way - _quality_(not just a wrapper) SDL, OpenGL, etc bindings. D is very attractive to game developers, I think with a little push it would get a lot of traction from this.
Re: DIP80: phobos additions
On 8/06/2015 3:53 p.m., Manu via Digitalmars-d wrote: On 8 June 2015 at 13:15, weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss I think a std.bindings or something similar for ubiquitous C libraries would go a long way - _quality_(not just a wrapper) SDL, OpenGL, etc bindings. D is very attractive to game developers, I think with a little push it would get a lot of traction from this. I've been humoring the idea of porting my engine to D. It's about 15 years of development, better/cleaner than most proprietary engines I've used at game studios. I wonder if there would be interest in this? Problem is, I need all the cross compilers to exist before I pull the plug on the C code... a game engine is no good if it's not portable to all the consoles under the sun. That said, I think it would be a good case-study to get the cross compilers working against. I'm definitely interested. Imagine getting something like that into phobos! Would be utterly amazing for us. Or atleast parts of it, once D-ified. Although might be worth doing tests using e.g. ldc to see how many platforms you can actually get working. Then perhaps an acceptance criteria before you port it?
Re: DIP80: phobos additions
On 8/06/2015 4:12 p.m., Manu via Digitalmars-d wrote: On 8 June 2015 at 13:59, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/06/2015 3:53 p.m., Manu via Digitalmars-d wrote: On 8 June 2015 at 13:15, weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss I think a std.bindings or something similar for ubiquitous C libraries would go a long way - _quality_(not just a wrapper) SDL, OpenGL, etc bindings. D is very attractive to game developers, I think with a little push it would get a lot of traction from this. I've been humoring the idea of porting my engine to D. It's about 15 years of development, better/cleaner than most proprietary engines I've used at game studios. I wonder if there would be interest in this? Problem is, I need all the cross compilers to exist before I pull the plug on the C code... a game engine is no good if it's not portable to all the consoles under the sun. That said, I think it would be a good case-study to get the cross compilers working against. I'm definitely interested. Imagine getting something like that into phobos! Would be utterly amazing for us. Or atleast parts of it, once D-ified. I can't really see a place for many parts in phobos... large parts of it are hardware/platform abstraction; would depend on many system library bindings present in phobos. Although might be worth doing tests using e.g. ldc to see how many platforms you can actually get working. Then perhaps an acceptance criteria before you port it? Yeah, it's a lot of work to do unit tests for parallel runtime systems that depend almost exclusively on user input or large bodies of external data... and where many of the outputs don't naturally feedback for analysis (render output, audio output). I can see a unit test framework being more code than most parts of the engine ;) .. not that it would be bad (it would be awesome!), I just can't imagine a simple/acceptable design. The thing I'm most happy about with Fuji is how relatively minimal it is (considering its scope and capability). They would have to be manual tests. So e.g. throws exceptions happily and uses threads kind of thing. But where you load it up and run it. It could help the ldc and gdc guys know what is still missing for this use case.
Re: DIP80: phobos additions
On Monday, 8 June 2015 at 04:05:23 UTC, Manu wrote: Yeah, that's fine. Is there an initiative for a phobos image library? I have said before that I'm dubious about it's worth; the trouble with an image library is that it will be almost impossible to decide on API, whereas a colour is fairly unambiguous in terms of design merits. Personally I would just be happy with a d wrapper for something like freeimage being included.
Re: DIP80: phobos additions
On Monday, 8 June 2015 at 04:21:45 UTC, Tofu Ninja wrote: Personally I would just be happy with a d wrapper for something like freeimage being included. That's what Deimos is for (https://github.com/D-Programming-Deimos/FreeImage). Mike
Re: DIP80: phobos additions
On 8 June 2015 at 13:08, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/06/2015 2:50 p.m., Tofu Ninja wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss Would love some kind of color implementation in Phobos, simple linear algebra(vectors, matrices), image manipulation. https://github.com/D-Programming-Language/phobos/pull/2845 He Manu, hows it going? I've kinda just been working on it on the side for my own use. I wasn't happy with the layout, and restructured it a lot. If there's an active demand for it, I'll give it top priority...?
[Issue 14663] New: shared library test - link_linkdep - segfaults on FreeBSD 10
https://issues.dlang.org/show_bug.cgi?id=14663 Issue ID: 14663 Summary: shared library test - link_linkdep - segfaults on FreeBSD 10 Product: D Version: unspecified Hardware: x86_64 OS: FreeBSD Status: NEW Severity: major Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: issues.dl...@jmdavisprog.com Running the druntime unit tests with the current dmd/druntime master (post 2.067) on FreeBSD 10 results in Testing link Testing load Testing linkD Testing linkDR Testing loadDR Testing host Testing finalize Testing link_linkdep Makefile:28: recipe for target 'obj/freebsd/64/link_linkdep.done' failed gmake[1]: *** [obj/freebsd/64/link_linkdep.done] Segmentation fault gmake[1]: Leaving directory '/usr/home/jmdavis/Programming/github/druntime/test/shared' posix.mak:206: recipe for target 'test/shared/.run' failed gmake: *** [test/shared/.run] Error 2 I don't know if FreeBSD 9 has the same problem, but clearly FreeBSD 8 does not, because that's what the autotester is running, and it's passing. So, something changed in either FreeBSD 9 or 10 to make it so that this test doesn't work anymore. I'll see if I can figure something out, but I'm not at all familiar with how the shared library code works or what exactly is being tested. --
Re: simple template constraint - compile error.
On Monday, 8 June 2015 at 04:02:26 UTC, WhatMeWorry wrote: Why would a working function call stop working just because a constraint was added to the function? because T is float... which isn't a dynamic array, so the constraint doesn't match. Just remove the [] after T[] in your signature and you should be ok.
[Issue 14662] New: __FILE__ template parameter becomes relative just by changing compilation directory
https://issues.dlang.org/show_bug.cgi?id=14662
Issue ID: 14662
Summary: __FILE__ template parameter becomes relative just by
changing compilation directory
Product: D
Version: D2
Hardware: x86
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: timothee.co...@gmail.com
I was getting quite obscure linker errors in a project. I reduced it to this:
__FILE__ generates sometimes relative paths even though all files and '-I'
paths are given as absolute paths, depending on the directory in which 'dmd' is
launched.
/mydir/fun1.d:
import fun2;
void test(){ test2(); }
/mydir/fun2.d:
void test2(string file=__FILE__)(){
if(false) test2();
}
-
cd /mydir/
dmd -of/tmp/fun1.o -c -I/mydir/ /mydir/fun1.d nm /tmp/fun1.o |ddemangle
|grep test2
S pure nothrow @nogc @safe void fun2.test2!(/mydir/fun1.d).test2()
S pure nothrow @nogc @safe void fun2.test2!(fun2.d).test2()
-
cd / #or anywhere else
dmd -of/tmp/fun1.o -c -I/mydir/ /mydir/fun1.d nm /tmp/fun1.o |ddemangle
|grep test2
S pure nothrow @nogc @safe void fun2.test2!(/mydir/fun1.d).test2()
S pure nothrow @nogc @safe void fun2.test2!(/mydir/fun1.d).test2()
The difference is: 'test2!(/mydir/fun1.d)' vs 'test2!(fun2.d)'
I believe 'test2!(fun2.d)' is wrong.
Maybe related:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/exclude_current_directory_from_search_path_in_dmd_69919.html
exclude current directory from search path in dmd ? (which i asked on the
forum but didn't get answer to)
--
Re: DIP80: phobos additions
On Monday, 8 June 2015 at 03:48:14 UTC, Manu wrote: I've kinda just been working on it on the side for my own use. I wasn't happy with the layout, and restructured it a lot. If there's an active demand for it, I'll give it top priority...? I'm interested in this library as well. Mike
Looking to remove the Page wiki buttons
The click rate on the Page wiki buttons linking to one wiki page per phobos page seems to be 0%. Any significant wiki pages in existence? -- Andrei
Re: Constructor inheritance? Why not?
On Monday, 8 June 2015 at 02:39:22 UTC, Tofu Ninja wrote: Is there any reason why constructors are not inherited? All other methods are inherited, why not constructors? They're not polymorphic, and it doesn't make sense to call a base class constructor on a derived class. I think that I heard somewhere that C++11 added some sort of constructor inheritance, so maybe there's something we could do that would make sense, but in general, I don't see how the concept makes any sense at all. Construction is intimately tied to the type being constructed. It's as non-generic as you can get. - Jonathan M Davis
Re: DIP80: phobos additions
On 8/06/2015 2:50 p.m., Tofu Ninja wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss Would love some kind of color implementation in Phobos, simple linear algebra(vectors, matrices), image manipulation. https://github.com/D-Programming-Language/phobos/pull/2845 He Manu, hows it going? Gl3n should be a candidate as it is old code and good one at that. https://github.com/Dav1dde/gl3n But it seems like it is no longer maintained. Can anyone contact the author regarding license to boost? Image manipulation blocked by color.
Re: DIP80: phobos additions
On 8 June 2015 at 13:15, weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss I think a std.bindings or something similar for ubiquitous C libraries would go a long way - _quality_(not just a wrapper) SDL, OpenGL, etc bindings. D is very attractive to game developers, I think with a little push it would get a lot of traction from this. I've been humoring the idea of porting my engine to D. It's about 15 years of development, better/cleaner than most proprietary engines I've used at game studios. I wonder if there would be interest in this? Problem is, I need all the cross compilers to exist before I pull the plug on the C code... a game engine is no good if it's not portable to all the consoles under the sun. That said, I think it would be a good case-study to get the cross compilers working against.
Re: DIP80: phobos additions
On 8/06/2015 3:48 p.m., Manu via Digitalmars-d wrote: On 8 June 2015 at 13:08, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/06/2015 2:50 p.m., Tofu Ninja wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss Would love some kind of color implementation in Phobos, simple linear algebra(vectors, matrices), image manipulation. https://github.com/D-Programming-Language/phobos/pull/2845 He Manu, hows it going? I've kinda just been working on it on the side for my own use. I wasn't happy with the layout, and restructured it a lot. If there's an active demand for it, I'll give it top priority...? Like I said its a blocker for an image library. There's no point implementing an image library with a half baked color definition meant for phobos. The long term issue is that we cannot really move forward with anything related to GUI or game development into phobos without it. So preferably we can get it into phobos by the end of the year :)
Re: DIP80: phobos additions
On 8 June 2015 at 13:54, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/06/2015 3:48 p.m., Manu via Digitalmars-d wrote: On 8 June 2015 at 13:08, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/06/2015 2:50 p.m., Tofu Ninja wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss Would love some kind of color implementation in Phobos, simple linear algebra(vectors, matrices), image manipulation. https://github.com/D-Programming-Language/phobos/pull/2845 He Manu, hows it going? I've kinda just been working on it on the side for my own use. I wasn't happy with the layout, and restructured it a lot. If there's an active demand for it, I'll give it top priority...? Like I said its a blocker for an image library. There's no point implementing an image library with a half baked color definition meant for phobos. Yeah, that's fine. Is there an initiative for a phobos image library? I have said before that I'm dubious about it's worth; the trouble with an image library is that it will be almost impossible to decide on API, whereas a colour is fairly unambiguous in terms of design merits. The long term issue is that we cannot really move forward with anything related to GUI or game development into phobos without it. So preferably we can get it into phobos by the end of the year :) Yeah, I agree it's a sore missing point, which is why I started working on it ;) ... I'll make it high priority. I recently finished up various work on premake5, so I can work on this now.
[Issue 11413] FreeBSD libphobos2.a not updated in 2.064 betas
https://issues.dlang.org/show_bug.cgi?id=11413 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added Status|NEW |RESOLVED CC||issues.dl...@jmdavisprog.co ||m Resolution|--- |FIXED --- Comment #1 from Jonathan M Davis issues.dl...@jmdavisprog.com --- I don't know if this was really fixed, but I don't see how it matters at this point, since the last release was 2.067. So, I'm closing it as fixed. --
Re: DIP80: phobos additions
On 8 June 2015 at 13:59, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/06/2015 3:53 p.m., Manu via Digitalmars-d wrote: On 8 June 2015 at 13:15, weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss I think a std.bindings or something similar for ubiquitous C libraries would go a long way - _quality_(not just a wrapper) SDL, OpenGL, etc bindings. D is very attractive to game developers, I think with a little push it would get a lot of traction from this. I've been humoring the idea of porting my engine to D. It's about 15 years of development, better/cleaner than most proprietary engines I've used at game studios. I wonder if there would be interest in this? Problem is, I need all the cross compilers to exist before I pull the plug on the C code... a game engine is no good if it's not portable to all the consoles under the sun. That said, I think it would be a good case-study to get the cross compilers working against. I'm definitely interested. Imagine getting something like that into phobos! Would be utterly amazing for us. Or atleast parts of it, once D-ified. I can't really see a place for many parts in phobos... large parts of it are hardware/platform abstraction; would depend on many system library bindings present in phobos. Although might be worth doing tests using e.g. ldc to see how many platforms you can actually get working. Then perhaps an acceptance criteria before you port it? Yeah, it's a lot of work to do unit tests for parallel runtime systems that depend almost exclusively on user input or large bodies of external data... and where many of the outputs don't naturally feedback for analysis (render output, audio output). I can see a unit test framework being more code than most parts of the engine ;) .. not that it would be bad (it would be awesome!), I just can't imagine a simple/acceptable design. The thing I'm most happy about with Fuji is how relatively minimal it is (considering its scope and capability).
[Issue 14661] New: Error executing command build: Unknown dependency: ddox when building website
https://issues.dlang.org/show_bug.cgi?id=14661 Issue ID: 14661 Summary: Error executing command build: Unknown dependency: ddox when building website Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: regression Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com CC: slud...@outerproduct.org When trying a clean build of dlang.org today, I'm getting the following error: DFLAGS=-conf=/tmp/.stable_dmd-2.067.1/dmd2/linux/bin64/dmd.conf ../dub-0.9.23/bin/dub build --nodeps --root=dpl-docs \ --compiler=/tmp/.stable_dmd-2.067.1/dmd2/linux/bin64/dmd Error executing command build: Unknown dependency: ddox make: *** [dpl-docs] Error 2 This appears to be a regression as I don't remember seeing this error before, but I haven't noticed it probably because it only manifests when trying a clean build. --
[Issue 14548] std.stdio.File should have sync() method (fsync/FlushFileBuffers wrapper)
https://issues.dlang.org/show_bug.cgi?id=14548 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/a5e1ae418aca2f3e9dc9854ffd71976c0139f440 fix Issue 14548 - std.stdio.File should have sync() method (fsync/FlushFileBuffers wrapper) https://github.com/D-Programming-Language/phobos/commit/4567cf6c751a7b2367f5d4a43a103f0f13c7c0cf Merge pull request #3258 from CyberShadow/pull-20150505-180120-std-stdio-sync fix Issue 14548 - std.stdio.File should have sync() method (fsync/FlushF... --
[Issue 14548] std.stdio.File should have sync() method (fsync/FlushFileBuffers wrapper)
https://issues.dlang.org/show_bug.cgi?id=14548 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: DIP80: phobos additions
On Sunday, 7 June 2015 at 18:27:16 UTC, Robert burner Schadek wrote: Phobos is awesome, the libs of go, python and rust only have better marketing. As discussed on dconf, phobos needs to become big and blow the rest out of the sky. http://wiki.dlang.org/DIP80 lets get OT, please discuss can we discuss the downside of making phobos huge? I actively avoid adding phobos libs to my projects because it bloats my binaries and increases compile times by massive amounts.
Re: Honey, I shrunk the build times
On Sunday, 7 June 2015 at 08:24:24 UTC, Temtaime wrote: Separate compilation prevents compiler from inlining everything. only bad compilers
Re: Honey, I shrunk the build times
On Sunday, 7 June 2015 at 08:12:11 UTC, weaselcat wrote: you'd think with dmd's module system achieving compiler-level parallelism wouldn't be so difficult. IIRC, Walter stated that he wanted to add it but decided that it would be too much of a pain to do in C++ and is waiting for us to fully switch to ddmd before tackling that problem. Similarly, Daniel Murphy has ideas on how to improve CTFE (which would vastly help compilation speeds), but it would be so much easier to do in D that he put it off until we switch to ddmd. It would surprise me if there are other speed improvements that have been put off, simply because they'd be easier to implement in D than C++. So, I expect that there's a decent chance that we'll be able to better leverage the design of the language to improve its compilation speed once we've officially switched the reference compiler to D (and we'll probably get there within a release or two; the main hold-up is how long it'll take gdc and ldc to catch up with 2.067). - Jonathan M Davis
Re: Honey, I shrunk the build times
On Sun, 07 Jun 2015 08:24:23 +, Temtaime wrote: It's really bad solution. Are you building phobos 1000 times a day so 5 seconds is really long for you ? Separate compilation prevents compiler from inlining everything. how is that? even if we left lto aside, compiler needs module source anyway. if one will use full .d files instead of .di, nothing can prevent good compiler from inlining. signature.asc Description: PGP signature
Re: Honey, I shrunk the build times
On 7 June 2015 at 10:34, weaselcat via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 7 June 2015 at 08:24:24 UTC, Temtaime wrote: Separate compilation prevents compiler from inlining everything. only bad compilers The way dmd does it, it's almost the same as compiling all object files at once, but only emitting code for one. Then times that by 134 modules and you understand why dmd uses a better together strategy for compilation.
Re: Honey, I shrunk the build times
On 7 June 2015 at 10:51, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sun, 07 Jun 2015 08:24:23 +, Temtaime wrote: It's really bad solution. Are you building phobos 1000 times a day so 5 seconds is really long for you ? Separate compilation prevents compiler from inlining everything. how is that? even if we left lto aside, compiler needs module source anyway. if one will use full .d files instead of .di, nothing can prevent good compiler from inlining. Semantic analysis is done lazily. No AST, no inline.
Re: Honey, I shrunk the build times
On 7 June 2015 at 10:49, Jonathan M Davis via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 7 June 2015 at 08:12:11 UTC, weaselcat wrote: you'd think with dmd's module system achieving compiler-level parallelism wouldn't be so difficult. IIRC, Walter stated that he wanted to add it but decided that it would be too much of a pain to do in C++ and is waiting for us to fully switch to ddmd before tackling that problem. Similarly, Daniel Murphy has ideas on how to improve CTFE (which would vastly help compilation speeds), but it would be so much easier to do in D that he put it off until we switch to ddmd. It would surprise me if there are other speed improvements that have been put off, simply because they'd be easier to implement in D than C++. So, I expect that there's a decent chance that we'll be able to better leverage the design of the language to improve its compilation speed once we've officially switched the reference compiler to D (and we'll probably get there within a release or two; the main hold-up is how long it'll take gdc and ldc to catch up with 2.067). I wouldn't have thought that not moving to 2.067 would be a hold-up (there is nothing in that release that blocks building DDMD as it is *now*). But I have been promised time and again that there will be more effort (infrastructure?) put in to help get LDC and GDC integrated into the testing process for all new PRs.
Eponymous/anonymous mixin templates
I've been doing some fun template metaprogramming recently for a few projects, and I have to say the expressive power of mixin templates is quite staggering. I've noticed a strongly recurring pattern in my usage (mostly trying to get compile-time templated code generation, parser from template args for input spec for example): A lot of the time, I use a mixin template to define exactly one symbol, and at instantiation I wish to use that symbol immediately, once. This has a strong connection with both the eponymous template trick and anonymous expressions, and essentially is a combination of both - a templated anon expression looked up at instantiation site. Currently, the standard workaround is defining a dummy name within the mixin template to do the work. The point of the eponymous trick is of course, to avoid this namespace pollution, or at least brainspace pollution. The easiest solution I can think of is to create a second type of MixinExpression: mixin ( MixinTemplateName TemplateArguments_opt ) which extends the existing string mixin syntax. This expression gets rewritten into the symbol declared as the MixinTemplateName, along the lines of the eponymous trick alias, which is instantiated as a mixin. The mixin template contents are otherwise not imported into scope. The only hypothetical ambiguity is if the mixin template itself resolves to a string literal, whether the result is to be compiled or not. However, it requires explicitly naming a mixin template, which is categorically different from a string, and to me it's completely safe to treat the result of the expression as a literal string symbol. With this, an extended request/alternate solution would be to allow writing eponymous mixin templates as well, in the same way normal eponymous templates are. What this looks to me is effectively making mixin a modifier keyword on templates in general, to bind at instantiation site rather than declaration site, and following all the logical consequences. Current TemplateMixins naturally become general instantiation imports, like using a normal template in a noop.
Re: Scaling rdmd up: build package at a time
On 2015-06-06 23:24, Atila Neves wrote: I don't think I understand. Where would these object files come from unless you're doing per-module compilation, C-style? What I've already implemented is variant 1 mentioned before. If you compile multiple files with DMD without linking it will produce multiple object files: $ ls bar.d foo.d $ dmd -c bar.d foo.d $ ls bar.d bar.o foo.d foo.o -- /Jacob Carlborg
Re: Scaling rdmd up: build package at a time
On 2015-06-06 23:41, Andrei Alexandrescu wrote: Doesn't work because no separate object file per source is being produced. -- Andrei They're produced if you don't link. -- /Jacob Carlborg
Re: Honey, I shrunk the build times
On 2015-06-07 06:30, Andrei Alexandrescu wrote: Thanks for asking. The situation before went like this: to build libphobos2.a, the command would go like this (simplified to just a few files and flags: dmd -oflibphobos2.a std/datetime.d std/conv.d std/algorithm/comparison.d std/algorithm/iteration.d So all modules would go together in one command to build the library. With the package-at-a-time approach, we build one directory at a time like this: I'm wondering if the impovements would have been larger if Phobos had a more tree structure for the modules rather than a fairly flat structure. -- /Jacob Carlborg
Re: Lets talk about fibers
On Saturday, 6 June 2015 at 18:49:30 UTC, Shachar Shemesh wrote: Since we are talking about several tens of thousands of threads, each random fluctuation in the load resulted in the Using an unlikely workload that the kernel has not been designed and optimized for is in general a bad idea. Especially on a generic scheduler that has no knowledge of the nature of the workload and therefore is (or should be) designed to avoid worst case starvation scenarios.
Re: DIP80: phobos additions
On Monday, 8 June 2015 at 00:05:58 UTC, weaselcat wrote: I actively avoid adding phobos libs to my projects because it bloats my binaries and increases compile times by massive amounts. Me too... but that's not actually a problem of huge library. It is more a problem of an interconnected library - if you write independent modules an import should only pull them with little from other ones. There's a difference with classes because of Object.factory, all of them are pulled in, but modules with functions, structs, and templates are cool, shouldn't be a problem.
Re: DIP80: phobos additions
On Monday, 8 June 2015 at 00:05:58 UTC, weaselcat wrote: can we discuss the downside of making phobos huge? I actively avoid adding phobos libs to my projects because it bloats my binaries and increases compile times by massive amounts. Andrei has already stated that we are definitely going to make Phobos large. We are _not_ going for the minimalistic approach, and pretty much no other language is at this point either. So, Phobos _will_ continue to grow in size. Now, as Adam points out, we can should do a better job of making it so that different pieces of Phobos don't depend on each other if they don't need to, but it's a given at this point that Phobos is only going to get larger. And if unnecessary dependencies are kept to a minimum, then it really shouldn't hurt your compilation times (and I'm sure that we'll have further compiler improvements in that area anyway). - Jonathan M Davis
Re: Simple http client Dlang library
Этот сайт не принимает визиты россиян. This site does not accept visits of Russians. Ta strona nie akceptuje odwiedzin Rosjan. So, I have 5 nationalities (including Polish). And many Russians have Polish nationality too (but they don't know about it). You hate my country. Hmm... IT IS SO FUNNY =)
Re: Simple http client Dlang library
On Sunday, 7 June 2015 at 06:43:25 UTC, Ilya Yaroshenko wrote: Этот сайт не принимает визиты россиян. This site does not accept visits of Russians. Ta strona nie akceptuje odwiedzin Rosjan. So, I have 5 nationalities (including Polish). And many Russians have Polish nationality too (but they don't know about it). You hate my country. Hmm... IT IS SO FUNNY =) ... and my military propaganda: http://www.youtube.com/watch?v=pPCXiyo-3L8
Re: Reggae binary backend: build your project with a D compiled executable
On Sunday, 7 June 2015 at 02:04:33 UTC, Mike wrote: On Saturday, 6 June 2015 at 20:07:22 UTC, Atila Neves wrote: Original discussion: http://forum.dlang.org/post/ranqlmrjornlvopsu...@forum.dlang.org Now, with the `-b binary` option, reggae creates an executable called build in the build directory (i.e. wherever the CWD was when calling the tool) that knows how to build the project. If needed, there is no longer a dependency on make or ninja. I haven't tested it extensively, but it does pass all the other tests I wrote for make and ninja, so it looks good. I like what you're doing with reggae, and I salute the work. I will reiterate my suggestion to consider making Reggae a simple package import so this build functionality can be used in anyone's D program, including the Reggae tool. We already have the ability to generate a binary with the compiler, so the binary backend seems a little redundant. You have all the great features one would need: Targets, dependencies, flags, build driver, etc... so it seems plausible to move some of your driver code to the payload/reggae package to make one's task of building a custom driver trivial. I don't suggest making a libreggae library as a separate repository from the Reggae tool, but rather simply do the refactoring to make payload/reggae folder importable from any D program, including the Reggae tool itself. I'll think about it. I don't think it's that easy, but I might be wrong. I had to solve all sorts of interesting problems to get a build description in D to work at all, but who knows, it might be simpler than Im making it out to be. I'm currently considering (because of dmd, druntime and phobos) how to strip it down to its bare essentials and have a core set of source files that only knows how to build D code, i.e. no C/C++, no dub, no make/ninja. That way just the small core can be distributed which can bootstrap itself and then build D code. I'm still figuring it out. Atila
Re: Reggae binary backend: build your project with a D compiled executable
On Sunday, 7 June 2015 at 05:30:56 UTC, ketmar wrote: On Sat, 06 Jun 2015 20:07:20 +, Atila Neves wrote: Original discussion: http://forum.dlang.org/post/ranqlmrjornlvopsu...@forum.dlang.org Now, with the `-b binary` option, reggae creates an executable called build in the build directory (i.e. wherever the CWD was when calling the tool) that knows how to build the project. If needed, there is no longer a dependency on make or ninja. I haven't tested it extensively, but it does pass all the other tests I wrote for make and ninja, so it looks good. Atila wow. now i'm really thinking about migrating to Reggae! ;-) Cool. :) The binary backend isn't very good (it's probably as slow as make); I did the simplest thing that would work. I want to eventually optimise it so it's competitive with ninja and tup. But to do that I need to measure, and to do that I need to write the tup backend and a program to generate a synthetic project with thousands of files. Atila Atila
Re: Simple http client Dlang library
On Sunday, 7 June 2015 at 07:28:23 UTC, ketmar wrote: On Sun, 07 Jun 2015 06:28:22 +, Ilya Yaroshenko wrote: fascists a great explanation of why people don't want such visits. instead of writing a personal email, you trying to start flamefest in NG. This explanation is substitution of causality.
Re: Honey, I shrunk the build times
On Sunday, 7 June 2015 at 05:25:21 UTC, ketmar wrote: On Sat, 06 Jun 2015 22:08:47 -0700, Andrei Alexandrescu wrote: On 6/6/15 10:00 PM, Rikki Cattermole wrote: On 7/06/2015 4:55 p.m., ketmar wrote: On Sat, 06 Jun 2015 21:30:02 -0700, Andrei Alexandrescu wrote: so in the end, after endless talking how separate compilation sux and everyone should do one-step combined compilation, separate compilation wins. it's funny how i'm always right in the end. Nobody is always right. But your way of thinking can be attractive if you like being evil. I'm evil :) There might be a bit of misunderstanding on what that change does. -- Andrei it utilizes partial separate compilation to earn speed using parallel builds. the thing alot of people talking of before: separate compilation can use multicores with ease, while one-step-all compilation can't without significant changes in compiler internals. you'd think with dmd's module system achieving compiler-level parallelism wouldn't be so difficult. I guess it stems from dmd being before the free lunch ended.
Re: Honey, I shrunk the build times
It's really bad solution. Are you building phobos 1000 times a day so 5 seconds is really long for you ? Separate compilation prevents compiler from inlining everything.
Re: Honey, I shrunk the build times
On Sun, Jun 07, 2015 at 05:00:58PM +1200, Rikki Cattermole via Digitalmars-d wrote: On 7/06/2015 4:55 p.m., ketmar wrote: On Sat, 06 Jun 2015 21:30:02 -0700, Andrei Alexandrescu wrote: so in the end, after endless talking how separate compilation sux and everyone should do one-step combined compilation, separate compilation wins. it's funny how i'm always right in the end. Nobody is always right. [...] Nobody is always right. I am Nobody. :-P T -- Nobody is perfect. I am Nobody. -- pepoluan, GKC forum
Re: Simple http client Dlang library
fascists
Re: Simple http client Dlang library
Этот сайт не принимает визиты россиян. This site does not accept visits of Russians. Ta strona nie akceptuje odwiedzin Rosjan. I hope author just don't know about that, otherwise it's a shame.
Re: Honey, I shrunk the build times
On Sunday, 7 June 2015 at 04:30:02 UTC, Andrei Alexandrescu wrote: [...] This is key to scalability, too. Now, the baseline numbers were without std.experimental.allocator. Recall the baseline time on my laptop was 4.93s. I added allocator, boom, 5.08s - sensible degradation. However, after I merged the per-package builder I got the same 4.01 seconds. Ah, okay. So, you essentially did what you were talking about doing for rdmd. I don't think that it's an approach that would have occurred to me, but I'm certainly in favor of a faster build. - Jonathan M Davis
[Issue 14660] New: std.range.choose() is not CTFE'able
https://issues.dlang.org/show_bug.cgi?id=14660 Issue ID: 14660 Summary: std.range.choose() is not CTFE'able Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com The trouble is caused by the use of the void[] buffer, which is cast to the right type, and the cast fails in CTFE. --
Re: Simple http client Dlang library
On Sun, 07 Jun 2015 06:28:22 +, Ilya Yaroshenko wrote: fascists a great explanation of why people don't want such visits. instead of writing a personal email, you trying to start flamefest in NG. signature.asc Description: PGP signature
Re: Reggae binary backend: build your project with a D compiled executable
On Sun, 07 Jun 2015 07:02:49 +, Atila Neves wrote: The binary backend isn't very good (it's probably as slow as make); I did the simplest thing that would work. I want to eventually optimise it so it's competitive with ninja and tup. But to do that I need to measure, and to do that I need to write the tup backend and a program to generate a synthetic project with thousands of files. yet it's a good start anyway. i'm not using make, and don't want to install another build tool too. so binary that doesn't require any other tool is great addition. signature.asc Description: PGP signature
[Issue 14604] cannot resolve forward reference when opDispatch results in a template
https://issues.dlang.org/show_bug.cgi?id=14604 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4726 --
[Issue 14603] cannot alias an expression when opDispatch results in a template
https://issues.dlang.org/show_bug.cgi?id=14603 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4726 --
Re: DIP80: phobos additions
On Monday, 8 June 2015 at 01:39:33 UTC, Jonathan M Davis wrote: On Monday, 8 June 2015 at 00:05:58 UTC, weaselcat wrote: can we discuss the downside of making phobos huge? I actively avoid adding phobos libs to my projects because it bloats my binaries and increases compile times by massive amounts. Andrei has already stated that we are definitely going to make Phobos large. We are _not_ going for the minimalistic approach, and pretty much no other language is at this point either. So, Phobos _will_ continue to grow in size. Now, as Adam points out, we can should do a better job of making it so that different pieces of Phobos don't depend on each other if they don't need to, but it's a given at this point that Phobos is only going to get larger. And if unnecessary dependencies are kept to a minimum, then it really shouldn't hurt your compilation times (and I'm sure that we'll have further compiler improvements in that area anyway). - Jonathan M Davis I wasn't arguing against a large library(in fact, I prefer it.) I just think the effort should be put towards making phobos more modular before adding more stuff on top of it and making the problem worse. bye,
[Issue 14661] Error executing command build: Unknown dependency: ddox when building website
https://issues.dlang.org/show_bug.cgi?id=14661 --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- If I remove the --nodeps switch, I get: dtest@k3:~/Digger/repo/dlang.org$ DFLAGS=-conf=/tmp/.stable_dmd-2.067.1/dmd2/linux/bin64/dmd.conf ../dub-0.9.23/bin/dub build --root=dpl-docs --compiler=/tmp/.stable_dmd-2.067.1/dmd2/linux/bin64/dmd Fetching memutils 0.3.1 (getting selected version)... Placing memutils 0.3.1 to /home/dtest/.dub/packages/... Fetching ddox 0.10.6 (getting selected version)... Placing ddox 0.10.6 to /home/dtest/.dub/packages/... Fetching vibe-d 0.7.23 (getting selected version)... Placing vibe-d 0.7.23 to /home/dtest/.dub/packages/... Fetching libevent 2.0.1+2.0.16 (getting selected version)... Placing libevent 2.0.1+2.0.16 to /home/dtest/.dub/packages/... Fetching openssl 1.1.4+1.0.1g (getting selected version)... Placing openssl 1.1.4+1.0.1g to /home/dtest/.dub/packages/... Fetching libev 5.0.0+4.04 (getting selected version)... Placing libev 5.0.0+4.04 to /home/dtest/.dub/packages/... Fetching libasync 0.7.1 (getting selected version)... Placing libasync 0.7.1 to /home/dtest/.dub/packages/... Error executing command build: no package file was found, expected one of the following: [immutable(FilenameAndFormat)(dub.json, json), immutable(FilenameAndFormat)(package.json, json)] dtest@k3:~/Digger/repo/dlang.org$ There is definitely a dub.json file under dpl-docs. I have no idea what it's complaining about. --
Constructor inheritance? Why not?
Is there any reason why constructors are not inherited? All other methods are inherited, why not constructors?
