Re: Common makefile (gasp) stuff
On Wednesday, 14 January 2015 at 04:29:57 UTC, Paul O'Neil wrote: I put off some documentation updates a few months ago because it wasn't worth the investment yet to figure out how to build the website. The wiki pages appeared to be about building the compiler, which I didn't realize I should be interested in. This barrier is too high. I know the feeling. I finally figured out how to get a single ddoc file to html so I could help update the documentation. I added a few notes to the dlang.org CONTRIBUTING.md [1] file a while back to help other users with that. It's probably not very noticeable there, but I don't understand the build process well enough to do a proper job. [1] https://github.com/D-Programming-Language/dlang.org/blob/master/CONTRIBUTING.md Why does documentation need to be "built" anyway. I understand the autogenerated stuff from the source code, but not the website. Would it be better to wikify it, somehow, in GitHub pages? Mike
Re: rdmd Broken
On Wednesday, 14 January 2015 at 01:18:11 UTC, Chuck Allison wrote: Hi all, I have no idea what happened, but rdmd gives me the strangest error: /usr/local/bin/dmd: failed to launch executable at /Library/Compilers/dmd2/osx/bin/dmd.Failed: I uninstalled dmd (using Jacob Carlsberg's uninstall shell script) and reinstalled 2.066 on Mac os x (yosemite) and this error persists. dmd works fine, but rdmd is bad. Any ideas on what's wrong? Thanks, Chuck Allison These things are pretty much always caused by leftovers from previous installations or misconfigured dmd.conf P.S. homebrew has up-to-date dmd etc.
Re: Common makefile (gasp) stuff
"Andrei Alexandrescu" wrote in message news:m94vfk$2gdh$1...@digitalmars.com... Hmmm... I wonder why the distinction. OS detection is required to build successfully, a rebase shortcut is not. The problem is basic code duplication with its known liabilities. I'm looking at stuff like this: Three's a charm. That code is relatively verbose (required newlines). I trust it doesn't need updates often, but it occupies real estate in a readily accessible position (beginning of file). The real issue here is that acquiescing to such duplication discourages attempts at uniformization before they occur. I'm thinking of simpler, clearer naming conventions and uniform ways of doing the same things (such as unittesting or documentation). The problem here is really that make sucks, right? And makefiles suck. Maybe we should start seriously looking at replacing them with D scripts. Getting back to REBASE (https://github.com/D-Programming-Language/dlang.org/blob/master/posix.mak#L37), it greatly simplifies my building the entire website in a way I trust is nice: make rebase -j && make clean && make rsync -j (Sadly make clean is necessary because of dub, which makes the process take a lot longer than it should; with luck, somebody will improve on that soon.) Now "make rebase" is really useful for druntime and phobos as well. But between duplicating more code or just doing it by hand, one may as well give up and choose the latter. Honestly I don't think automating rebase is a good idea, because it discourages actually learning how to do it. eg if all you're trying to do is get the current branch rebased on top of upstream's master, you can do this: git pull upstream master --rebase I'd also like to define "make rebase-dirty" based on this: REBASE_DIRTY = MYBRANCH=`git rev-parse --abbrev-ref HEAD` &&\ git stash &&\ git co master &&\ git pull --ff-only upstream master &&\ git co $$MYBRANCH &&\ git rebase master &&\ git stash pop which is useful because it lets me rebase on top of work in progress. Again the prospect of duplicating this other macro across 3-4 projects is fairly unattractive. I've managed to get by fine with using shell scripts for stuff like this.
Re: Why exceptions for error handling is so important
Just to be clear on this. Sandy Bridge and later have 16 x 256 bits registers. There is really no reason for an optimizing compiler to not just stuff the whole exception value into 1 or 2 of those in most cases where it has full control. In the rare case where that is not enough, or possible, stuff it into a fixed TLS buffer (or a similar arrangement) and clear a signal value in that buffer when the exception is caught.
Re: no size yet for forward reference for nested structures
qqiang: I've googled and found no straightforward solution to this issue. The how can I modify my code to eliminate this error? Your code gives me a different error (Error: PowerHeap!int is used as a type). What if you replace the SList with a dynamic array? Bye, bearophile
Re: no size yet for forward reference for nested structures
First a reminder that this sort of question is more suitable to the
D.learn newsgroup.
On 01/13/2015 10:41 PM, qqiang wrote:
> The following code:
> ```D
> template PowerHeap(T) {
> import std.container : SList;
>
> private alias PowerForest = SList!PowerNode;
>
> private final class PowerNode {
> ...
> }
>
> final class PowerHead {
> ...
> }
> }
>
> unittest {
> PowerHeap!int h;
> }
> ```
I started with your code and produced the following one:
template PowerHeap(T) {
import std.container : SList;
private alias PowerForest = SList!PowerNode;
private final class PowerNode {
// ...
}
final class PowerHead {
// ...
}
}
unittest {
PowerHeap!int h;// <-- Compilation error here
}
void main()
{}
> failed to compile and get the error: PowerHeap!int.PowerNode: no size
> yet for forward reference.
What compiler and version are you using? I received a different error
with the git head dmd:
Error: PowerHeap!int is used as a type
The compiler is right, PowerHeap!int is a template instantiation that
wraps a number of definitions. Did you mean one of those? The following
compiles:
unittest {
PowerHeap!int.PowerHead h;// <-- now compiles
}
> I've googled and found no straightforward solution to this issue. The
> how can I modify my code to eliminate this error?
Please provide exact code so that... Oh, wait! I've just noticed that
your error message has PowerHeap!int.PowerNode in it. Let me try with that:
unittest {
PowerHeap!int.PowerNode h;// <-- this compiles as well
}
Yeah, please provide exact code. :)
Ali
Re: Common makefile (gasp) stuff
On Wednesday, 14 January 2015 at 07:55:31 UTC, Mike wrote: Would it be better to wikify it, somehow, in GitHub pages? I think wiki is the wrong term here. I mean, is there a way to leverage Markdown (or some other markup language) with GitHub's source code management features to make it easier for contributors to fork, edit in their browser, verify in their repository, and create pull requests without having to build with a compiler? Mike
Re: Common makefile (gasp) stuff
On Tue, 2015-01-13 at 15:20 -0800, Andrei Alexandrescu via Digitalmars-d wrote: > Hey folks, > > > Over the time a number of stuff has become quite duplicated across our > makefiles for dmd, druntime, and phobos. Are these three separate things with separate builds, or are they three components of the same system? What is the relationship between these three, LDC and GDC? > These include fetching OS and model but (newer) general-purpose macros > for e.g. rebasing repos, see > https://github.com/D-Programming-Language/dlang.org/blob/master/posix.mak#L37. > > I think it's time to reduce clutter and duplication by migrating such > common stuff into one common.mak file. Question is, where should that > file sit? One candidate is tools/ but it's not really a tool. Another > candidate is dmd/src/ because that would be the first thing anyone > depends on. > > Ideas? Are all three things in the same Git repository? Can I clone the three independently or do I have to have them all? Can any of them be built without building the other or does a DMD build require a new druntime and phobos build. Basically what I am trying to say here is that I suspect the extraction of commonality is going to create an inappropriate coupling. The solution is to have the common material as a fourth thing that can be brought in to any or all of the three. With SCons and Waf this is achieved by having a tool, easy simple and keeps the coupling low. I haven't used Make in 12 years, so I have no idea what it can do these days, But unless you mandate GNU Make, I suspect it is going to be awful trying to build across Windows, OSX, Debian, Arch, Fedora, FreeBSD, OpenBSD, etc. without hacking (in the worst sense). -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: More recent work on GC
On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/immix-pldi-2008.pdf (this has been mentioned before) Andrei Thanks for the heads up.
Re: Common makefile (gasp) stuff
On 1/14/15 12:29 AM, Daniel Murphy wrote: The problem here is really that make sucks, right? And makefiles suck. Maybe we should start seriously looking at replacing them with D scripts. I agree that make sucks etc. but duplication sucks more (and would suck regardless of what tool we use). Here we do have a simple method (include files) that is suitable for addressing that. I'd assume we'd use something similar with whichever tool we'd use. Honestly I don't think automating rebase is a good idea, because it discourages actually learning how to do it. eg if all you're trying to do is get the current branch rebased on top of upstream's master, you can do this: git pull upstream master --rebase Great. As an aside I just ran that and got: error: unknown option `rebase' usage: ... Whether it's a command or a couple, that doesn't change the fact that I need to run the same command four times, and in parallel if at all possible. It's a perfect candidate for automation, and I haven't seen an argument the makefile isn't a good place for that. I'd also like to define "make rebase-dirty" based on this: REBASE_DIRTY = MYBRANCH=`git rev-parse --abbrev-ref HEAD` &&\ git stash &&\ git co master &&\ git pull --ff-only upstream master &&\ git co $$MYBRANCH &&\ git rebase master &&\ git stash pop which is useful because it lets me rebase on top of work in progress. Again the prospect of duplicating this other macro across 3-4 projects is fairly unattractive. I've managed to get by fine with using shell scripts for stuff like this. Do you need to upload the dlang.org website quickly and without error? Overall I have difficulty understanding counterarguments. Challenge: "We should eliminate some unpleasant duplication." Response: "Make sucks. Make includes are unreliable for mythical unexplained reasons. You don't know git. You should do scripts instead." The response just doesn't follow. Care to clarify what you think we should be doing here? Andrei
Re: Common makefile (gasp) stuff
One thought because of somethings being said, dmd-fe is being converted to D. Which means to compile dmd you need a D compiler already. We could make all the build scripts, D instead. It would mean one less external to D ecosystem dependency. But it could easily be a nightmare.
Re: Common makefile (gasp) stuff
"Andrei Alexandrescu" wrote in message news:m95ds3$2vm4$1...@digitalmars.com... I agree that make sucks etc. but duplication sucks more (and would suck regardless of what tool we use). Here we do have a simple method (include files) that is suitable for addressing that. I'd assume we'd use something similar with whichever tool we'd use. I don't mind using include files, I mind adding more dependencies between projects. Great. As an aside I just ran that and got: error: unknown option `rebase' usage: ... Maybe it's 'git pull --rebase upstream master', I didn't try it and I don't type it manually very often because I have a script to do this. Whether it's a command or a couple, that doesn't change the fact that I need to run the same command four times, and in parallel if at all possible. It's a perfect candidate for automation, and I haven't seen an argument the makefile isn't a good place for that. I guess we have different usage patterns, which isn't really a surprise. Anyway putting rebase in the makefile is a secondary issue, that's probably not worth discussing now. > I've managed to get by fine with using shell scripts for stuff like > this. Do you need to upload the dlang.org website quickly and without error? Do enough people need to that it warrants being in the makefile instead of a local shell script? Does everyone do it the same way? Overall I have difficulty understanding counterarguments. Challenge: "We should eliminate some unpleasant duplication." Response: "Make sucks. Make includes are unreliable for mythical unexplained reasons. You don't know git. You should do scripts instead." The response just doesn't follow. Care to clarify what you think we should be doing here? Apologies for not being clear. Challenge: "We should eliminate some unpleasant duplication." Response: "We should avoid adding more dependencies between projects at all costs."
Re: Why exceptions for error handling is so important
That post, to me, only reinforces how much better using exceptions is. Atila They posted recently a blog post about error handling in Go. https://blog.golang.org/errors-are-values -- Paulo
Re: What is the D plan's to become a used language?
On Tuesday, 13 January 2015 at 23:40:32 UTC, Martin Nowak wrote: On Friday, 19 December 2014 at 16:45:40 UTC, Ola Fosheim Grøstad wrote: Yes, but it would be easy to define some focused goals for each release and refuse to touch stuff that belongs to a later release. E.g. http://wiki.dlang.org/Agenda That's a good start, but it is too vague. You need to design ahead so that you don't start on the release without having measurable goals and milestones. "c++ and gc" is not measurable. You need to map out future releases and dependencies between features. Then you need to evaluate what went "wrong" in the last release, and what was added to the last release, but not in the plan and why. The "Agenda" is loosing its authority as a plan if it is not evaluated. Without evaluation you can basically ignore it?
Re: no size yet for forward reference for nested structures
On Wednesday, 14 January 2015 at 08:31:13 UTC, Ali Çehreli wrote:
First a reminder that this sort of question is more suitable to
the D.learn newsgroup.
On 01/13/2015 10:41 PM, qqiang wrote:
> The following code:
> ```D
> template PowerHeap(T) {
> import std.container : SList;
>
> private alias PowerForest = SList!PowerNode;
>
> private final class PowerNode {
> ...
> }
>
> final class PowerHead {
> ...
> }
> }
>
> unittest {
> PowerHeap!int h;
> }
> ```
I started with your code and produced the following one:
template PowerHeap(T) {
import std.container : SList;
private alias PowerForest = SList!PowerNode;
private final class PowerNode {
// ...
}
final class PowerHead {
// ...
}
}
unittest {
PowerHeap!int h;// <-- Compilation error here
}
void main()
{}
> failed to compile and get the error: PowerHeap!int.PowerNode:
no size
> yet for forward reference.
What compiler and version are you using? I received a different
error with the git head dmd:
Error: PowerHeap!int is used as a type
The compiler is right, PowerHeap!int is a template
instantiation that wraps a number of definitions. Did you mean
one of those? The following compiles:
unittest {
PowerHeap!int.PowerHead h;// <-- now compiles
}
> I've googled and found no straightforward solution to this
issue. The
> how can I modify my code to eliminate this error?
Please provide exact code so that... Oh, wait! I've just
noticed that your error message has PowerHeap!int.PowerNode in
it. Let me try with that:
unittest {
PowerHeap!int.PowerNode h;// <-- this compiles as well
}
Yeah, please provide exact code. :)
Ali
Thanks for your reminder.
I'm sorry that I've provided wrong code. This is the exact code:
---
template PowerHeap(T) {
import std.container : SList;
private alias PowerForest = SList!PowerNode;
private final class PowerNode {
private {
T payload_;
uint rank_;
PowerForest children_;
}
}
final class PowerHeap {
private {
PowerNode top_;
PowerForest forest_;
uint size_;
}
}
}
unittest {
PowerHeap!int h;
}
--
My compiler is v2.066.1
Re: no size yet for forward reference for nested structures
On Wednesday, 14 January 2015 at 08:31:08 UTC, bearophile wrote:
qqiang:
I've googled and found no straightforward solution to this
issue. The how can I modify my code to eliminate this error?
Your code gives me a different error (Error: PowerHeap!int is
used as a type).
What if you replace the SList with a dynamic array?
Bye,
bearophile
Thanks for your reply.
I'm sorry that I've provided wrong code. This is the exact code:
---
template PowerHeap(T) {
import std.container : SList;
private alias PowerForest = SList!PowerNode;
private final class PowerNode {
private {
T payload_;
uint rank_;
PowerForest children_;
}
}
final class PowerHeap {
private {
PowerNode top_;
PowerForest forest_;
uint size_;
}
}
}
unittest {
PowerHeap!int h;
}
--
My compiler is v2.066.1
Re: Why exceptions for error handling is so important
On Tue, 13 Jan 2015 11:56:00 + Paulo Pinto via Digitalmars-d wrote: > They posted recently a blog post about error handling in Go. > > https://blog.golang.org/errors-are-values great article! it clearly shows how NOT to do error handling and why exceptions are far superior. signature.asc Description: PGP signature
Re: What is the D plan's to become a used language?
On Wednesday, 14 January 2015 at 05:10:05 UTC, Joakim wrote: I don't think it's that unusual for a native compiled language: can you find C++ snippets to write tweets? I doubt it. A compiled languages is just not the tool people usually grab to write such things. D would like to break out of that box and be such a language, but it's probably not going to have a bunch of code written for small jobs like that yet. I kinda agree, except: «twitcurl is a pure C++ library for twitter APIs. twitcurl uses cURL for handling HTTP requests and responses.» https://code.google.com/p/twitcurl/ https://dev.twitter.com/overview/api/twitter-libraries And Go has two twitter libraries... There were a lot more people doing cute stuff like that for D1, I think. It will probably come when D2 is more stable.
Re: no size yet for forward reference for nested structures
On Wed, 14 Jan 2015 10:41:07 +
qqiang via Digitalmars-d wrote:
> template PowerHeap(T) {
> import std.container : SList;
>
> private alias PowerForest = SList!PowerNode;
>
> private final class PowerNode {
> private {
> T payload_;
> uint rank_;
> PowerForest children_;
> }
> }
>
> final class PowerHeap {
> private {
> PowerNode top_;
> PowerForest forest_;
> uint size_;
> }
> }
> }
>
> unittest {
> PowerHeap!int h;
> }
there is a circular dependency in your data structures. you're defining
`PowerNode` in the terms of... `PowerNode`. this won't work.
your `PowerForest` definition depends of complete `PowerNode`
definition, but `PowerNode` definition depends of complete
`PowerForest` definition.
don't do that.
signature.asc
Description: PGP signature
Re: Common makefile (gasp) stuff
On 1/14/15 2:09 AM, Daniel Murphy wrote: "Andrei Alexandrescu" wrote in message news:m95ds3$2vm4$1...@digitalmars.com... I agree that make sucks etc. but duplication sucks more (and would suck regardless of what tool we use). Here we do have a simple method (include files) that is suitable for addressing that. I'd assume we'd use something similar with whichever tool we'd use. I don't mind using include files, I mind adding more dependencies between projects. Why? Druntime depends on dmd. Phobos depends on dmd and druntime. Dlang.org and tools depend on dmd, druntime, and phobos. It's a fact of life. Great. As an aside I just ran that and got: error: unknown option `rebase' usage: ... Maybe it's 'git pull --rebase upstream master', I didn't try it and I don't type it manually very often because I have a script to do this. Whether it's a command or a couple, that doesn't change the fact that I need to run the same command four times, and in parallel if at all possible. It's a perfect candidate for automation, and I haven't seen an argument the makefile isn't a good place for that. I guess we have different usage patterns, which isn't really a surprise. Anyway putting rebase in the makefile is a secondary issue, that's probably not worth discussing now. > I've managed to get by fine with using shell scripts for stuff like > this. Do you need to upload the dlang.org website quickly and without error? Do enough people need to that it warrants being in the makefile instead of a local shell script? Does everyone do it the same way? Yes. Currently I'm the site build master by default. In the near future there'll be several. I'd rather have anyone run a simple command than telling them to write their scripts. So if next month I transfer this responsibility to Martin, I can tell: "to update dlang.org, run 'make rebase -j && make rsync -j'" as opposed to "yeah, I have some scripts somewhere, do your own or let me email them to you". I don't really understand your position here. It's like you reject robust automation over tribal knowledge and folklore. Overall I have difficulty understanding counterarguments. Challenge: "We should eliminate some unpleasant duplication." Response: "Make sucks. Make includes are unreliable for mythical unexplained reasons. You don't know git. You should do scripts instead." The response just doesn't follow. Care to clarify what you think we should be doing here? Apologies for not being clear. Challenge: "We should eliminate some unpleasant duplication." Response: "We should avoid adding more dependencies between projects at all costs." Why? As an aside, "at all costs" is suspicious in many contexts. Andrei
Re: Why exceptions for error handling is so important
On Tuesday, 13 January 2015 at 20:58:43 UTC, deadalnix wrote: On Tuesday, 13 January 2015 at 19:36:31 UTC, Marc Schütz wrote: On Monday, 12 January 2015 at 23:01:53 UTC, Ola Fosheim Grøstad wrote: On Monday, 12 January 2015 at 22:06:32 UTC, deadalnix wrote: No, Exception are a bail out mechanism. It is the, I have no idea what to do about this mechanism. The way it is done in C++, yes. If you put aside performance concerns, exceptions for control flow also tend to make many code path implicit and makes for very unreadable/unmaintainable code. But exceptions are control flow. There is no such thing as normalized control flow, all state changes implies "control flow". Think in terms of a state machine. You could just remove all variables and only have a big state machine (assuming finite dimensions). Every single state transition implies flow of control. The control flow you see in the source code is just the programmer's "rendition" of control flow. Exceptions is a mechanism for getting cluttering resolution out of that rendition to make the code more readable and maintainable. The goal is to retain the meat of the computation and remove the noise. Or to put it differently, there are many ways to write the same function. Good use of exceptions removes the clutter and leaves the things you care about visible. It's a mechanism, not a moral issue or a religion. So there is nothing wrong with throwing HTTPStatus(409) or HTTPStatus(201), even though it returns state to the environment. If that means the code is more maintainable and more likely to be correct, then that is good use of the mechanism. I usually don't do this, but I really need to post a "+1" here: +1 Too bad you chose to do this on a bad strawmman. Your claims: - Exceptions are for "I have no idea what to do about this" situations. - "exceptions for control flow [...] makes for very unreadable/unmaintainable code" Ola's answer directly addresses these claims and provides a counter-example (in the last paragraph), which I happen to agree with. => Not a strawman.
Re: Why exceptions for error handling is so important
On Wednesday, 14 January 2015 at 10:37:31 UTC, Atila Neves wrote: That post, to me, only reinforces how much better using exceptions is. Atila They posted recently a blog post about error handling in Go. https://blog.golang.org/errors-are-values -- Paulo Agree, on the other hand is another example of the mindset. -- Paulo
Re: Why exceptions for error handling is so important
On Wednesday, 14 January 2015 at 00:24:41 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 13 January 2015 at 23:58:53 UTC, deadalnix wrote: http://dlang.org/phobos/core_thread.html#.Thread.join I don't see the problem. I'm suggesting value semantics, it can be copied. Without addressing anything else: You want moving here, not copying.
Re: Common makefile (gasp) stuff
"Andrei Alexandrescu" wrote in message news:m95i3q$1t6$1...@digitalmars.com... > I don't mind using include files, I mind adding more dependencies > between projects. Why? Druntime depends on dmd. Phobos depends on dmd and druntime. Dlang.org and tools depend on dmd, druntime, and phobos. It's a fact of life. Druntime, phobos and dlang.org don't (currently) depend on dmd's source.
Re: Why exceptions for error handling is so important
On Wednesday, 14 January 2015 at 11:20:49 UTC, Marc Schütz wrote: Without addressing anything else: You want moving here, not copying. How can you move a value, it has no identity? (Not that I really care much for Thread.join(). How many actually use it?)
[std.traits] Detect complex numbers
There is "isFloatingPointType!T" to find out whether type T is
one of the floating point types but I could not find anything
equivalent for complex numbers (cdouble, cfloat, creal) in Phobos
2.066 (which I installed with MacPorts for the record). Am I
missing something?
My goal was to detect types suitable as scalars in a linear
algebra context. I had to do it by hand:
enum bool supportedScalar(T) = is(ScalarTypeOf!T) &&
!isAggregateType!T;
private {
alias ScalarTypeList = TypeTuple!(float, double, real,
cfloat, cdouble, creal);
template ScalarTypeOf(T) {
static if (is(AliasThisTypeOf!T AT) && !is(AT[] == AT))
alias X = ScalarTypeOf!AT;
else
alias X = OriginalType!T;
static if (staticIndexOf!(Unqual!X, ScalarTypeList) >= 0)
alias ScalarTypeOf = X;
else
static assert(0, T.stringof~" is not a floating point
type");
}
}
Re: [std.traits] Detect complex numbers
I forgot to mention the obvious: I simply parroted the code in std.traits!
Re: [std.traits] Detect complex numbers
On Wednesday, 14 January 2015 at 13:38:05 UTC, Luc Bourhis wrote:
There is "isFloatingPointType!T" to find out whether type T is
one of the floating point types but I could not find anything
equivalent for complex numbers (cdouble, cfloat, creal) in
Phobos 2.066 (which I installed with MacPorts for the record).
Am I missing something?
My goal was to detect types suitable as scalars in a linear
algebra context. I had to do it by hand:
enum bool supportedScalar(T) = is(ScalarTypeOf!T) &&
!isAggregateType!T;
private {
alias ScalarTypeList = TypeTuple!(float, double, real,
cfloat, cdouble, creal);
template ScalarTypeOf(T) {
static if (is(AliasThisTypeOf!T AT) && !is(AT[] == AT))
alias X = ScalarTypeOf!AT;
else
alias X = OriginalType!T;
static if (staticIndexOf!(Unqual!X, ScalarTypeList) >= 0)
alias ScalarTypeOf = X;
else
static assert(0, T.stringof~" is not a floating point
type");
}
}
It doesn't answer your question as such, but you should take a
look at:
http://dlang.org/phobos/std_complex.html
Re: The ANSI character set is very important for operating MSSQL, if no conversion,will attract more C# users
On Tuesday, 13 January 2015 at 16:47:33 UTC, FrankLike wrote: The ANSI character set is very important for operating MSSQL, if no conversion, will expand the scope of D users, that can attract more C# users. MSSQL supports UCS2 (16 bit unicode) for nvarchar and you should be able to set the connection to UTF-8.
Re: [std.traits] Detect complex numbers
It doesn't answer your question as such, but you should take a look at: http://dlang.org/phobos/std_complex.html The planned obsolescence of cdouble and consort is another issue I wanted to raise actually but better do it in a dedicated thread.
Re: rdmd Broken
On 2015-01-14 02:18, Chuck Allison wrote: Hi all, I have no idea what happened, but rdmd gives me the strangest error: /usr/local/bin/dmd: failed to launch executable at /Library/Compilers/dmd2/osx/bin/dmd.Failed: I uninstalled dmd (using Jacob Carlsberg's uninstall shell script) and reinstalled 2.066 on Mac os x (yosemite) and this error persists. dmd works fine, but rdmd is bad. I don't recognize /Library/Compilers/dmd2 at all. It's not from a tool/script I have created. If you're referring to me :). How did you install it? -- /Jacob Carlborg
Re: rdmd Broken
On 2015-01-14 02:18, Chuck Allison wrote: Hi all, I have no idea what happened, but rdmd gives me the strangest error: /usr/local/bin/dmd: failed to launch executable at /Library/Compilers/dmd2/osx/bin/dmd.Failed: I uninstalled dmd (using Jacob Carlsberg's uninstall shell script) and reinstalled 2.066 on Mac os x (yosemite) and this error persists. dmd works fine, but rdmd is bad. BTW, DVM [1] is a great tool for installing DMD on all platforms. It supports having multiple version installed at the same time. The you can easily switch between them. [1] https://github.com/jacob-carlborg/dvm -- /Jacob Carlborg
Re: no size yet for forward reference for nested structures
On 01/14/2015 02:53 AM, ketmar via Digitalmars-d wrote:
> On Wed, 14 Jan 2015 10:41:07 +
> qqiang via Digitalmars-d wrote:
>
>> template PowerHeap(T) {
>> import std.container : SList;
>>
>> private alias PowerForest = SList!PowerNode;
>>
>> private final class PowerNode {
>> private {
>> T payload_;
>> uint rank_;
>> PowerForest children_;
>> }
>> }
>>
>> final class PowerHeap {
>> private {
>> PowerNode top_;
>> PowerForest forest_;
>> uint size_;
>> }
>> }
>> }
>>
>> unittest {
>> PowerHeap!int h;
>> }
> there is a circular dependency in your data structures. you're defining
> `PowerNode` in the terms of... `PowerNode`. this won't work.
>
> your `PowerForest` definition depends of complete `PowerNode`
> definition, but `PowerNode` definition depends of complete
> `PowerForest` definition.
>
> don't do that.
>
Reduced:
import std.container;
class Node
{
SList!Node children;
}
void main()
{}
Error: class deneme.Node no size yet for forward reference
I wonder why an SList of a reference type requires the size of the
elements? The following compiles but is that a pointer to a class
variable or a class object? How can we even use the 'children' member?
SList!(Node*) children;
Ali
Re: Common makefile (gasp) stuff
On 2015-01-14 00:20, Andrei Alexandrescu wrote: Hey folks, Over the time a number of stuff has become quite duplicated across our makefiles for dmd, druntime, and phobos. These include fetching OS and model but (newer) general-purpose macros for e.g. rebasing repos, see https://github.com/D-Programming-Language/dlang.org/blob/master/posix.mak#L37. I think it's time to reduce clutter and duplication by migrating such common stuff into one common.mak file. Question is, where should that file sit? One candidate is tools/ but it's not really a tool. Another candidate is dmd/src/ because that would be the first thing anyone depends on. Oh God, please no. I really, really hate that the makefiles are are looking in folders outside of the repositories. Ideas? If you really want to do something like this I would recommend creating a new repository, acting like a super repository, including the other repositories as submodules. Then you can create a new makefile that builds everything. Although, I still don't want the makefiles in the existing repositories be dependent on the new repository. -- /Jacob Carlborg
Re: no size yet for forward reference for nested structures
On Wed, 14 Jan 2015 07:09:44 -0800
Ali Çehreli via Digitalmars-d wrote:
> Reduced:
>
> import std.container;
>
> class Node
> {
> SList!Node children;
> }
>
> void main()
> {}
>
> Error: class deneme.Node no size yet for forward reference
>
> I wonder why an SList of a reference type requires the size of the
> elements? The following compiles but is that a pointer to a class
> variable or a class object? How can we even use the 'children' member?
>
> SList!(Node*) children;
i don't know: i've never used `std.container` anyway. ;-)
signature.asc
Description: PGP signature
Re: The ANSI character set is very important for operating MSSQL, if no conversion,will attract more C# users
On Wednesday, 14 January 2015 at 13:44:39 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 13 January 2015 at 16:47:33 UTC, FrankLike wrote: The ANSI character set is very important for operating MSSQL, if no conversion, will expand the scope of D users, that can attract more C# users. MSSQL supports UCS2 (16 bit unicode) for nvarchar and you should be able to set the connection to UTF-8. ' set the connection to UTF-8'? MSSQL? How to do? But I only know it ok in mySql. Thank you.
Re: The ANSI character set is very important for operating MSSQL, if no conversion,will attract more C# users
On Wednesday, 14 January 2015 at 15:37:20 UTC, FrankLike wrote: On Wednesday, 14 January 2015 at 13:44:39 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 13 January 2015 at 16:47:33 UTC, FrankLike wrote: The ANSI character set is very important for operating MSSQL, if no conversion, will expand the scope of D users, that can attract more C# users. MSSQL supports UCS2 (16 bit unicode) for nvarchar and you should be able to set the connection to UTF-8. ' set the connection to UTF-8'? MSSQL? How to do? But I only know it ok in mySql. Thank you. Just search for it. https://www.google.no/?q=mssql%20connection%20utf-8 First hit: http://stackoverflow.com/questions/1322421/php-sql-server-how-to-set-charset-for-connection
Re: More recent work on GC
On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf Interesting. non-exact GC but with about the same performance. The bad part for D would be, that this GC collects periodically, so even if you don't use GC'ed memory it will be invoked :-/ On the other hand it stops the world more often, but only for much shorter time - at least in interactive programms a better choice I think.
Re: The ANSI character set is very important for operating MSSQL, if no conversion,will attract more C# users
On Wednesday, 14 January 2015 at 15:56:14 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 14 January 2015 at 15:37:20 UTC, FrankLike wrote: On Wednesday, 14 January 2015 at 13:44:39 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 13 January 2015 at 16:47:33 UTC, FrankLike wrote: The ANSI character set is very important for operating MSSQL, if no conversion, will expand the scope of D users, that can attract more C# users. MSSQL supports UCS2 (16 bit unicode) for nvarchar and you should be able to set the connection to UTF-8. ' set the connection to UTF-8'? MSSQL? How to do? But I only know it ok in mySql. Thank you. Just search for it. https://www.google.no/?q=mssql%20connection%20utf-8 First hit: http://stackoverflow.com/questions/1322421/php-sql-server-how-to-set-charset-for-connection Not a good idea.
Re: Common makefile (gasp) stuff
On Tuesday, 13 January 2015 at 23:20:13 UTC, Andrei Alexandrescu
wrote:
Hey folks,
Over the time a number of stuff has become quite duplicated
across our makefiles for dmd, druntime, and phobos.
These include fetching OS and model but (newer) general-purpose
macros for e.g. rebasing repos, see
https://github.com/D-Programming-Language/dlang.org/blob/master/posix.mak#L37.
I think it's time to reduce clutter and duplication by
migrating such common stuff into one common.mak file. Question
is, where should that file sit? One candidate is tools/ but
it's not really a tool. Another candidate is dmd/src/ because
that would be the first thing anyone depends on.
Ideas?
Andrei
IMO helpers (such as git helpers) are not part of the build
process, so they should not be part of the build files. Few
people care about make rebase. I'm not saying we should delete
them (they obviously are useful to you), but moving them to tools
might be a good start.
For druntime / phobos build... That's really a shame we don't
have a standard D tool to build D code, cross platform.
If we had, not only would we promote an even saner image of our
tooling ('hey look, dogfooding'), we won't have to solve the same
problems over and over again, so both druntime / phobos and the
tool would benefit from this, but ofc it will require some
initial work.
If someone wants to get this project started, I have a suggestion
for the name: dub
Okay, sarcasms appart, would that be a possibility for us to
switch to dub in the long run ? I'm not sure dub is ready for
that ATM, but I'm confident it could be made ready without much
work.
Re: Common makefile (gasp) stuff
On Wed, Jan 14, 2015 at 04:27:10PM +0100, Jacob Carlborg via Digitalmars-d wrote: > On 2015-01-14 00:20, Andrei Alexandrescu wrote: [...] > >I think it's time to reduce clutter and duplication by migrating such > >common stuff into one common.mak file. Question is, where should that > >file sit? One candidate is tools/ but it's not really a tool. Another > >candidate is dmd/src/ because that would be the first thing anyone > >depends on. > > Oh God, please no. I really, really hate that the makefiles are are > looking in folders outside of the repositories. +1. Makefiles that reference paths outside the repo are really really evil. They only ever work for the specific setup the author has, and breaks for everybody else. > >Ideas? > > If you really want to do something like this I would recommend > creating a new repository, acting like a super repository, including > the other repositories as submodules. Then you can create a new > makefile that builds everything. Although, I still don't want the > makefiles in the existing repositories be dependent on the new > repository. [...] +1, this is a much better approach than introducing yet more extra-repo hard-coded paths into the makefiles. There are too many of those already. T -- Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson
Re: The ANSI character set is very important for operating MSSQL, if no conversion,will attract more C# users
On Wednesday, 14 January 2015 at 16:44:35 UTC, FrankLike wrote: Not a good idea. What is not a good idea? The default collation differs based on the OS settings AFAIK. In western countries it probably is ISO8859-1 (not a windows code page, but close). Unicode data is UCS2LE (little endian), but if you get the settings right the client library should allow you to use UTF-8.
Re: Common makefile (gasp) stuff
On Wed, Jan 14, 2015 at 02:58:02AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > On 1/14/15 2:09 AM, Daniel Murphy wrote: [...] > >Do enough people need to that it warrants being in the makefile > >instead of a local shell script? Does everyone do it the same way? > > Yes. > > Currently I'm the site build master by default. In the near future > there'll be several. I'd rather have anyone run a simple command than > telling them to write their scripts. > > So if next month I transfer this responsibility to Martin, I can tell: > "to update dlang.org, run 'make rebase -j && make rsync -j'" as > opposed to "yeah, I have some scripts somewhere, do your own or let me > email them to you". > > I don't really understand your position here. It's like you reject > robust automation over tribal knowledge and folklore. What stops us from adding said scripts to the dlang.org repo? Or tools, for that matter, which is probably more appropriate. Not everything needs to be shoehorned into the makefiles. > >>Overall I have difficulty understanding counterarguments. > >> > >>Challenge: "We should eliminate some unpleasant duplication." > >> > >>Response: "Make sucks. Make includes are unreliable for mythical > >>unexplained reasons. You don't know git. You should do scripts > >>instead." > >> > >>The response just doesn't follow. Care to clarify what you think we > >>should be doing here? > > > >Apologies for not being clear. > > > >Challenge: "We should eliminate some unpleasant duplication." > > > >Response: "We should avoid adding more dependencies between projects > >at all costs." > > Why? As an aside, "at all costs" is suspicious in many contexts. Because it imposes a specific external directory structure which the casual user has no idea about. This stuff is documented nowhere currently -- I had to read the makefiles to figure it out for myself; not many people have that much patience. It makes the whole thing more fragile because as soon as one or more repos go out-of-sync (not on github, but in the user's local clones, which can happen very easily) things can break horribly without any warning. I'm astonished this has to be spelled out in, of all places, a D forum. Surely, of all people, we D people must be all too familiar with exactly why things like #include <../../../mylib/mymod/myheader.h> are evil? I mean, why else would we have D modules rather than continue this glorious C heritage? Yet here we're proposing to add the equivalent of such out-of-tree #include's to our makefiles *and* we're straining to find reasons why we shouldn't do it? I'm at a loss of words to describe the cognitive dissonance here. T -- Creativity is not an excuse for sloppiness.
Re: More recent work on GC
On Wednesday, 14 January 2015 at 16:09:06 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: On my reading list: http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf Interesting. non-exact GC but with about the same performance. The bad part for D would be, that this GC collects periodically, so even if you don't use GC'ed memory it will be invoked :-/ You could still GC.disable(); /* realtime work here */ GC.enable(); of course
Re: Why exceptions for error handling is so important
On Wednesday, 14 January 2015 at 11:17:52 UTC, Marc Schütz wrote: Your claims: - Exceptions are for "I have no idea what to do about this" situations. - "exceptions for control flow [...] makes for very unreadable/unmaintainable code" Ola's answer directly addresses these claims and provides a counter-example (in the last paragraph), which I happen to agree with. => Not a strawman. Being precise is important. The example presented (ie throwing a exception signaling a http code) is a good one and never contradict what I said. It is an example "I have no idea what to do about this". The code throwing the exception is faced with a situation where it cannot continue (assuming this code is expected to generate a webpage or something like that) but at the same time, is not in a position to perform the custom http so it is bailing out. It is signaling to higher level "I would have liked to return this http code, but have no idea how to do so and so I'm giving up." Now I see how you can consider this as a control flow, but it is vastly different from usual control flow (loops, branches, calls, ...). It is vastly different. You have no idea where you send your program into. In fact, you may not even be in in the framework that can make sens of this exception, you have no idea. Conversely, the framwork that is catching this exception have no idea where it came from, and it do not care either. It simply know that the page failed to render and that instead it should return a specific error code.
Re: Why exceptions for error handling is so important
On Wednesday, 14 January 2015 at 07:49:09 UTC, Ola Fosheim Grøstad wrote: Then you can't catch by super class. This is not going to fly. I said value. Use bitmasks. Class hierarchies don't work very well. Once again, no specifics. You write that paragraph like there is some logical links between elements in it, but there is none. If you cannot follow the logic... Where did you get lost? I was not lost. I know how to recognize a non sequitur when I read one. The only things that is sure here is that it is going to make the non exception path slower. Without specific we can say anything else than that. ? You essentially have two options: 1. A single branch on return. 2. Multiple return paths. 2a) returning to the calling function 2b) using a landing pad (current solution) It's a good thing that you can do all of these in D already. It won't help with register pressure. Having a pointer to an exception object in a register is equivalent to having a pointer to a TLS memory area in a register. TLS is in a register already. You only need this when you are using static TLS variable, which is not that common in practice. The change would makes this required all over the place. it can be optimized away so you don't need TLS if you don't span over non-D code. Without specifics, it is another instance of the sufficiently smart compiler running gag. This does not take a very smart compiler. You can use heuristics, such as ones using the function signature. It is a known fact that a sufficiently smart compiler will use heuristic. It is also fairly obvious that this heuristic will use function signature. You don't make things faster by making the calling convention easier. There is chance that this is gonna fly any better than a flat iron. ? Of course you make it faster by allowing the compiler to use it's own calling conventions. Making a new calling convention is not going to magically make things faster. If the calling convention need to do more, it is certainly going to make things slower. Hopefully, function calls are not common at all, so that shouldn't be a problem.
Re: Why exceptions for error handling is so important
On Wednesday, 14 January 2015 at 17:45:28 UTC, deadalnix wrote: It is an example "I have no idea what to do about this". The code throwing the exception is faced with a situation where it cannot continue (assuming this code is expected to generate a webpage or something like that) but at the same time, is not in a position to perform the custom http so it is bailing out. No, "201" means success, resource created, and "409" means that it was not carried out because of conflict in the request. However, these may be meaningful responses to the client based on the input, like "204" no content. So it is output. Throwing an exception is just an efficient way to abort all resources and queries that may be in progress and return a status to the client in a clean fashion when you don't need a text body. Just a mechanism. And it makes sense if used consistently.
Re: More recent work on GC
On Wed, Jan 14, 2015 at 05:37:41PM +, John Colvin via Digitalmars-d wrote: > On Wednesday, 14 January 2015 at 16:09:06 UTC, Dominikus Dittes Scherkl > wrote: > >On Wednesday, 14 January 2015 at 06:15:09 UTC, Andrei Alexandrescu wrote: > >>On my reading list: > >> > >>http://research.microsoft.com/pubs/230708/conservative-gc-oopsla-2014.pdf Fascinating! This paper seems to be describing a *partially* compacting/copying GC. That's a very clever way of circumventing the constraints imposed by a conservative GC, which D can't around with due to interfacing with C. IOW, if a D program just so happens to have no unambiguous references, then the GC will effectively become a fully compacting/copying GC. If there are some ambiguous references, then it "gracefully degrades" into a non-compacting/copying conservative GC. Looking forward to see what will come of this! > >Interesting. non-exact GC but with about the same performance. The > >bad part for D would be, that this GC collects periodically, so even > >if you don't use GC'ed memory it will be invoked :-/ > > You could still GC.disable(); /* realtime work here */ GC.enable(); of > course Recently in one of my projects I found that I can gain a huge performance improvement just by calling GC.disable() at the beginning of the program and never calling GC.enable() again, but instead manually calling GC.collect() at strategic points in the code. Obviously, YMMV, but I managed to get a 40% performance improvement, which is pretty big for such a relatively simple change. T -- What do you call optometrist jokes? Vitreous humor.
Re: Why exceptions for error handling is so important
On Wednesday, 14 January 2015 at 17:53:54 UTC, deadalnix wrote: Once again, no specifics. How is a bitmask (e.g. a set) not specific? I was not lost. I know how to recognize a non sequitur when I read one. Then you should also be able to explain where you got lost. 1. A single branch on return. 2. Multiple return paths. 2a) returning to the calling function 2b) using a landing pad (current solution) It's a good thing that you can do all of these in D already. This is about what the compiler does, not what you can do in D. So no. You cannot have multiple return paths (like returning to the returnaddress+OFFSET) or branch implicitly based on the carry flag upon return. You only need this when you are using static TLS variable, which is not that common in practice. The change would makes this required all over the place. That's the point. To have a buffer in TLS so that you don have to do transient heap allocations (allocation directly followed by deallocation of same object). Making a new calling convention is not going to magically make things faster. If the calling convention need to do more, it is certainly going to make things slower. One needs a calling convention to ensure that the backend puts the exception signal in the right register or to do offset return. Or to free up more registers. Haskell has a register heavy calling convention to speed up Haskell code. So it is not certainly going to make things slower. Clearing a flag/register will most likely fill in a bubble in the pipeline. A predicted non-branching branch instruction is fairly cheap. Hopefully, function calls are not common at all, so that shouldn't be a problem. ?
Re: Rectangular multidimensional arrays for D
It might make sense to take a look at Armadillo (another C++ linear algebra library) for inspiration on multidimensional arrays.
Re: Why exceptions for error handling is so important
On Tue, Jan 13, 2015 at 8:26 PM, deadalnix via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Wednesday, 14 January 2015 at 02:40:20 UTC, Jeremy Powers via > Digitalmars-d wrote: > >> >>> http://www.artima.com/intv/handcuffs.html >>> >>> The best sum up of checked exception you'll find. >>> >>> >> False. >> >> Unless you mean 'the best sum up of the problems people have with checked >> exceptions' - it gives a good description of how use of checked exceptions >> often goes wrong. >> >> > Full stop. I made that mistake myself various time, so I can talk from > experience here. > > This is a completely wrong mindset. If people have problem with checked > exception, then there IS a problem with checked exception, not people. You > won't be able to change people, so you'd better focus on changing checked > exceptions. > You are completely right. Let me rephrase: The article gives a good overview of the places where checked exceptions are weak, and where people have problems with them. The things it mentions have best-practice work arounds (or are actually features), and do not invalidate all the usefulness that checked exceptions provide. It would be great if there were some other scheme instead of checked exceptions, or a slightly different design of them, if it gave me the same advantages without the issues. Unfortunately I have not seen one yet.
Re: no size yet for forward reference for nested structures
On 01/14/2015 07:39 AM, ketmar via Digitalmars-d wrote:
On Wed, 14 Jan 2015 07:09:44 -0800
Ali Çehreli via Digitalmars-d wrote:
Reduced:
import std.container;
class Node
{
SList!Node children;
}
void main()
{}
Error: class deneme.Node no size yet for forward reference
I wonder why an SList of a reference type requires the size of the
elements? The following compiles but is that a pointer to a class
variable or a class object? How can we even use the 'children' member?
SList!(Node*) children;
i don't know: i've never used `std.container` anyway. ;-)
It looks like this came up not too long ago:
http://forum.dlang.org/thread/akkrerlsjutdfmzsw...@forum.dlang.org#post-akkrerlsjutdfmzswsbo:40forum.dlang.org
I think this is a bug but I will wait for others to confirm.
Ali
Re: Why exceptions for error handling is so important
On Wed, Jan 14, 2015 at 3:16 AM, Paulo Pinto via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Wednesday, 14 January 2015 at 10:37:31 UTC, Atila Neves wrote: > >> That post, to me, only reinforces how much better using exceptions is. >> >> Atila >> >> They posted recently a blog post about error handling in Go. >>> >>> https://blog.golang.org/errors-are-values >>> >>> -- >>> Paulo >>> >> > Agree, on the other hand is another example of the mindset. > It is interesting to me that as people come up with ways to make error-code handling better it starts looking very much like exceptions.
Re: Why exceptions for error handling is so important
On Wed, Jan 14, 2015 at 10:56:39AM -0800, Jeremy Powers via Digitalmars-d wrote: > On Wed, Jan 14, 2015 at 3:16 AM, Paulo Pinto via Digitalmars-d < > digitalmars-d@puremagic.com> wrote: > > > On Wednesday, 14 January 2015 at 10:37:31 UTC, Atila Neves wrote: > > > >> That post, to me, only reinforces how much better using exceptions > >> is. > >> > >> Atila > >> > >> They posted recently a blog post about error handling in Go. > >>> > >>> https://blog.golang.org/errors-are-values > >>> > >>> -- > >>> Paulo > >>> > >> > > Agree, on the other hand is another example of the mindset. > > > > It is interesting to me that as people come up with ways to make > error-code handling better it starts looking very much like > exceptions. +1. T -- Meat: euphemism for dead animal. -- Flora
Re: Walter's DConf 2014 Talks - Topics in Finance
On Tuesday, 23 December 2014 at 03:07:10 UTC, Laeeth Isharc wrote: It would certainly be nice to have matrices, but I also don't think it would be right to say D is dead in water here because it is so far behind. It also seems like the cost of writing such a library is v small vs possible benefit. I have a longer horizon than the HFT guys, but I still have quite a demand for high performance computing when backtesting a quantitative strategy. A backtest will typically involve 1) Put some data in a database 2) Apply statistical models to appropriate data 3) Create forecast distribution 4) Optimize portfolio given forecast 5) Repeat 2:4 in each period and calculate performance of strategy The biggest limiting factor to implementing it in D is a mature math/stats library (I understand SciD is a thing, but I have not tried it). Most optimization packages are written in C and could probably be called in D (haven't tried, but I imagine). There's a mysql module for D, though I think python has much better options here (I have been pretty impressed with blaze). Python's Pandas is also pretty helpful, but as it is built upon numpy, something equivalent would need to built upon a matrix library in D. I think it would also be helpful for bindings to Julia and C++ (so I can use MC Stan or Quantlib). I think the pyd project is pretty important. Might be good to write up an example using it for a finance application.
Re: Common makefile (gasp) stuff
On 1/14/15 3:29 AM, Daniel Murphy wrote: "Andrei Alexandrescu" wrote in message news:m95i3q$1t6$1...@digitalmars.com... > I don't mind using include files, I mind adding more dependencies > between projects. Why? Druntime depends on dmd. Phobos depends on dmd and druntime. Dlang.org and tools depend on dmd, druntime, and phobos. It's a fact of life. Druntime, phobos and dlang.org don't (currently) depend on dmd's source. I see your point, though I'll note that DMD everywhere defaults to ../dmd/src/dmd (and that's a huge improvement from the time is was defined as just dmd). But granted setting it in the command line would make those independent of the dmd location. So the question is - is there a place that's common to all? Andrei
Re: Common makefile (gasp) stuff
On 1/14/15 9:01 AM, H. S. Teoh via Digitalmars-d wrote: On Wed, Jan 14, 2015 at 04:27:10PM +0100, Jacob Carlborg via Digitalmars-d wrote: On 2015-01-14 00:20, Andrei Alexandrescu wrote: [...] I think it's time to reduce clutter and duplication by migrating such common stuff into one common.mak file. Question is, where should that file sit? One candidate is tools/ but it's not really a tool. Another candidate is dmd/src/ because that would be the first thing anyone depends on. Oh God, please no. I really, really hate that the makefiles are are looking in folders outside of the repositories. +1. Makefiles that reference paths outside the repo are really really evil. They only ever work for the specific setup the author has, and breaks for everybody else. Currently there must be a place where druntime finds dmd for building purposes. Also phobos needs to find druntime. Also dlang.ord needs to find the source of both phobos and druntime. There's no specific setup of one person as much as a boring: /some/dir/ dmd druntime phobos dlang.org tools I have a hard time making it any simpler. Ideas? If you really want to do something like this I would recommend creating a new repository, acting like a super repository, including the other repositories as submodules. Then you can create a new makefile that builds everything. Although, I still don't want the makefiles in the existing repositories be dependent on the new repository. [...] +1, this is a much better approach than introducing yet more extra-repo hard-coded paths into the makefiles. There are too many of those already. Where would that super-repo sit? Andrei
Re: More recent work on GC
On Wednesday, 14 January 2015 at 18:01:22 UTC, H. S. Teoh via Digitalmars-d wrote: Recently in one of my projects I found that I can gain a huge performance improvement just by calling GC.disable() at the beginning of the program and never calling GC.enable() again, but instead manually calling GC.collect() at strategic points in the code. Obviously, YMMV, but I managed to get a 40% performance improvement, which is pretty big for such a relatively simple change. Interesting that you need to disable to get the effect. That mean our heuristic for the GC collection to kick in sucks quite badly.
Re: Common makefile (gasp) stuff
On 1/14/15 9:36 AM, H. S. Teoh via Digitalmars-d wrote: What stops us from adding said scripts to the dlang.org repo? Or tools, for that matter, which is probably more appropriate. Not everything needs to be shoehorned into the makefiles. As I explained in my previous message it's a sensible solution. -- Andrei
Re: Common makefile (gasp) stuff
On 1/14/15 8:50 AM, Mathias LANG wrote:
IMO helpers (such as git helpers) are not part of the build process, so
they should not be part of the build files. Few people care about make
rebase. I'm not saying we should delete them (they obviously are useful
to you), but moving them to tools might be a good start.
This is about scaling up and passing responsibility around. I could
write a script and then tell whoever maintains dlang.org "first run that
script then run make" etc.
With make it turns out it's dead simple to get parallel rebase going:
REBASE = git pull upstream master --rebase
rebase: rebase-dlang rebase-dmd rebase-druntime rebase-phobos
rebase-dlang: ; $(REBASE)
rebase-dmd: ; cd $(DMD_DIR) && $(REBASE)
rebase-druntime: ; cd $(DRUNTIME_DIR) && $(REBASE)
rebase-phobos: ; cd $(PHOBOS_DIR) && $(REBASE)
So I'm done in 6 lines and it's parallel automatically, no code needed.
With zsh I'd probably go (untested)...
===
#/bin/zsh
set -e
function rebase() {
( cd $1 && git pull upstream master --rebase )
}
rebase . &&
rebase ../dmd &&
rebase ../druntime &&
rebase ../phobos &&
wait
===
But wait, there's less. The script:
* does not return nonzero if either subtask fails - and doing so needs
e.g. temporary files and takes extra code. So I need to carefully look
at the textual garbled output to make sure it all works.
* does not accept setting variables DMD_DIR etc. It can be made to, but
that's yet more code.
* cannot run serially if I want to debug something, only parallel. It
can be made do, but that's again more code!
So we're looking at an ideological response "don't use make, make sucks"
to a pragmatic matter - I want to get work done, and we shouldn't use
inferior/more intensive technical solutions on an ideological basis
alone. I agree make sucks! But that doesn't suddenly eliminate my common
sense.
For druntime / phobos build... That's really a shame we don't have a
standard D tool to build D code, cross platform.
If we had, not only would we promote an even saner image of our tooling
('hey look, dogfooding'), we won't have to solve the same problems over
and over again, so both druntime / phobos and the tool would benefit
from this, but ofc it will require some initial work.
If someone wants to get this project started, I have a suggestion for
the name: dub
Okay, sarcasms appart, would that be a possibility for us to switch to
dub in the long run ? I'm not sure dub is ready for that ATM, but I'm
confident it could be made ready without much work.
I'd be glad to switch to dub but I confess at this time I can't invest
the time. I'm already spread too thin.
Andrei
Re: Common makefile (gasp) stuff
On 1/14/15 9:36 AM, H. S. Teoh via Digitalmars-d wrote: I'm astonished this has to be spelled out in, of all places, a D forum. Surely, of all people, we D people must be all too familiar with exactly why things like #include <../../../mylib/mymod/myheader.h> are evil? I think that would be applying one canned lesson to a situation where it doesn't quite apply. -- Andrei
Re: Common makefile (gasp) stuff
On 1/14/15 9:36 AM, H. S. Teoh via Digitalmars-d wrote: Because it imposes a specific external directory structure which the casual user has no idea about. I think that's a given already and has been for a long time. -- Andrei
Re: Common makefile (gasp) stuff
On 1/14/15 9:36 AM, H. S. Teoh via Digitalmars-d wrote: What stops us from adding said scripts to the dlang.org repo? Or tools, for that matter, which is probably more appropriate. Oh, I just figured that would make everything dependent on dlang.org. That would be a new dependency :o). -- Andrei
Re: Common makefile (gasp) stuff
On Wed, Jan 14, 2015 at 11:50:39AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 1/14/15 9:01 AM, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Jan 14, 2015 at 04:27:10PM +0100, Jacob Carlborg via Digitalmars-d
> >wrote:
> >>On 2015-01-14 00:20, Andrei Alexandrescu wrote:
> >[...]
> >>>I think it's time to reduce clutter and duplication by migrating
> >>>such common stuff into one common.mak file. Question is, where
> >>>should that file sit? One candidate is tools/ but it's not really a
> >>>tool. Another candidate is dmd/src/ because that would be the first
> >>>thing anyone depends on.
> >>
> >>Oh God, please no. I really, really hate that the makefiles are are
> >>looking in folders outside of the repositories.
> >
> >+1. Makefiles that reference paths outside the repo are really really
> >evil. They only ever work for the specific setup the author has, and
> >breaks for everybody else.
>
> Currently there must be a place where druntime finds dmd for building
> purposes. Also phobos needs to find druntime. Also dlang.ord needs to
> find the source of both phobos and druntime.
>
> There's no specific setup of one person as much as a boring:
>
> /some/dir/
> dmd
> druntime
> phobos
> dlang.org
> tools
>
> I have a hard time making it any simpler.
I think you're missing the point. The problem is not that a specific
setup is required. The problem is that the user has to (1) know exactly
what this setup is, and (2) set it up *manually*. The first point is a
dire lack of documentation, the second point begs the question "why
require the user to do this when we can do this for them?". I.e., via
submodules, see below.
Not to mention, your proposed setup does not match dlang.org's
makefile's idea of what the setup should be. (For example, it generates
html files in dlang.org/web whereas the Phobos makefile generates html
files in phobos/../web, which appears to suggest that
{dmd,druntime,phobos} ought to be nested inside dlang.org instead of
being siblings as you have shown.) If even you can't keep things
consistent with what's in dlang.org's makefiles, what hope do the rest
of us have, let alone a casual user who's only tentatively interested in
D?
> >>>Ideas?
> >>
> >>If you really want to do something like this I would recommend
> >>creating a new repository, acting like a super repository, including
> >>the other repositories as submodules. Then you can create a new
> >>makefile that builds everything. Although, I still don't want the
> >>makefiles in the existing repositories be dependent on the new
> >>repository.
> >[...]
> >
> >+1, this is a much better approach than introducing yet more extra-repo
> >hard-coded paths into the makefiles. There are too many of those
> >already.
>
> Where would that super-repo sit?
[...]
Huh?? What do you mean, where it would sit? If you set up a
"super-repo", it would look something like this:
dlang/ # root git repo
dmd/# git submodule referencing the dmd repo
druntime/ # git submodule referencing the druntime repo
phobos/ # git submodule referencing the phobos repo
dlang.org/ # git submodule referencing the dlang.org repo
Then checking out this new dlang repo (with the requisite git flags)
will create the above structure for you, including clone all the
sub-repos. *This* is what will address point (2) that I raised earlier:
the user shouldn't need to manually setup some arbitrary directory
structure for you -- automate this with git submodules instead!
Having such a super-repo will also solve the problem of git bisecting
earlier toolchain releases -- because the super-repo references the
sub-repos by SHA hashes, which are history-tracked by git, so we could
set it up so that each commit of the super-repo corresponds with a valid
version set of dmd/druntime/phobos. Then you could checkout a specific
commit of the super-repo and update git submodules, and you'll get a
snapshot of the entire toolchain as it stood at the time of the commit.
If we do this right, we could even have the autotester update the
super-repo automatically upon successful completion of the test suite
for the entire toolchain.
And ideally, stuff common to multiple subrepos should be in this
"super-repo", such as the stuff you're trying to factor out right now.
Including the master makefile that will build everything WITHOUT needing
to reference out-of-tree paths. And ideally, any out-of-tree references
needed by the subrepos will be via configurable parameters (e.g. $(DMD),
$(DRUNTIME_PATH), etc.), which the master makefile can set to the
correct values, so the subrepos don't have to know or hardcode where the
exact out-of-tree location ought to be.
Such a super-repo will also make release management easier: instead of
manually managing release tags in each of dmd/druntime/phobos, we can
tag the super-repo, which encapsulates the exact set of
dm
Re: Common makefile (gasp) stuff
On 1/14/15 12:18 PM, H. S. Teoh via Digitalmars-d wrote: If you set up a "super-repo", it would look something like this: dlang/ # root git repo dmd/# git submodule referencing the dmd repo druntime/ # git submodule referencing the druntime repo phobos/ # git submodule referencing the phobos repo dlang.org/ # git submodule referencing the dlang.org repo Then checking out this new dlang repo (with the requisite git flags) will create the above structure for you, including clone all the sub-repos. *This* is what will address point (2) that I raised earlier: the user shouldn't need to manually setup some arbitrary directory structure for you -- automate this with git submodules instead! Agreed. Ah, this is getting interesting, thanks. So I've wanting to look into submodules for a while now but have been discouraged by the bad press they seem to be getting: https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ http://ayende.com/blog/4746/the-problem-with-git-submodules http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/ http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/ (though I have no idea whether what's relevant for puppet is relevant to us) Having such a super-repo will also solve the problem of git bisecting earlier toolchain releases -- because the super-repo references the sub-repos by SHA hashes, which are history-tracked by git, so we could set it up so that each commit of the super-repo corresponds with a valid version set of dmd/druntime/phobos. Then you could checkout a specific commit of the super-repo and update git submodules, and you'll get a snapshot of the entire toolchain as it stood at the time of the commit. If we do this right, we could even have the autotester update the super-repo automatically upon successful completion of the test suite for the entire toolchain. And ideally, stuff common to multiple subrepos should be in this "super-repo", such as the stuff you're trying to factor out right now. Including the master makefile that will build everything WITHOUT needing to reference out-of-tree paths. And ideally, any out-of-tree references needed by the subrepos will be via configurable parameters (e.g. $(DMD), $(DRUNTIME_PATH), etc.), which the master makefile can set to the correct values, so the subrepos don't have to know or hardcode where the exact out-of-tree location ought to be. Such a super-repo will also make release management easier: instead of manually managing release tags in each of dmd/druntime/phobos, we can tag the super-repo, which encapsulates the exact set of dmd/druntime/phobos commits for that release. I hear you but The Internet says submodules are a kind of a bummer. Andrei
auto return for some recursive functions in C++11
According to Wikipedia:
http://en.wikipedia.org/wiki/C%2B%2B14#Function_return_type_deduction
C++14 is able to compile code like this:
auto correct(int i) {
if (i == 1)
return i;
else
return correct(i - 1) + i;
}
But not like this:
auto correct(int i) {
if (i != 1)
return correct(i - 1) + i;
else
return i;
}
D isn't able to compile both. Is it a good idea to allow the
first function in D too?
Bye,
bearophile
Re: auto return for some recursive functions in C++11
On Wed, 14 Jan 2015 22:29:08 +
bearophile via Digitalmars-d wrote:
> According to Wikipedia:
> http://en.wikipedia.org/wiki/C%2B%2B14#Function_return_type_deduction
>
> C++14 is able to compile code like this:
>
>
> auto correct(int i) {
> if (i == 1)
> return i;
> else
> return correct(i - 1) + i;
> }
>
>
> But not like this:
>
> auto correct(int i) {
> if (i != 1)
> return correct(i - 1) + i;
> else
> return i;
> }
>
>
> D isn't able to compile both. Is it a good idea to allow the
> first function in D too?
>
> Bye,
> bearophile
i'm pretty sure that D *SHOULD* compile the first sample. the spec says
that return type for `auto` function is taken from the first `return`
operator parser met. so for the second `return` the return type is
already known.
i think that this is not just "let it compile", but a bug in compiler.
something should be fixed: either compiler or specs.
signature.asc
Description: PGP signature
Re: auto return for some recursive functions in C++11
ketmar: the spec says that return type for `auto` function is taken from the first `return` operator parser met. so for the second `return` the return type is already known. Do you mean the C++14 spec or the D spec? The D specs I see are (from: http://dlang.org/function.html ): Auto Functions Auto functions have their return type inferred from any ReturnStatements in the function body. An auto function is declared without a return type. If it does not already have a storage class, use the auto storage class. If there are multiple ReturnStatements, the types of them must be implicitly convertible to a common type. If there are no ReturnStatements, the return type is inferred to be void. Bye, bearophile
Re: Common makefile (gasp) stuff
On Wednesday, 14 January 2015 at 20:07:12 UTC, Andrei
Alexandrescu wrote:
On 1/14/15 8:50 AM, Mathias LANG wrote:
IMO helpers (such as git helpers) are not part of the build
process, so
they should not be part of the build files. Few people care
about make
rebase. I'm not saying we should delete them (they obviously
are useful
to you), but moving them to tools might be a good start.
This is about scaling up and passing responsibility around. I
could write a script and then tell whoever maintains dlang.org
"first run that script then run make" etc.
With make it turns out it's dead simple to get parallel rebase
going:
REBASE = git pull upstream master --rebase
rebase: rebase-dlang rebase-dmd rebase-druntime rebase-phobos
rebase-dlang: ; $(REBASE)
rebase-dmd: ; cd $(DMD_DIR) && $(REBASE)
rebase-druntime: ; cd $(DRUNTIME_DIR) && $(REBASE)
rebase-phobos: ; cd $(PHOBOS_DIR) && $(REBASE)
So I'm done in 6 lines and it's parallel automatically, no code
needed. With zsh I'd probably go (untested)...
===
#/bin/zsh
set -e
function rebase() {
( cd $1 && git pull upstream master --rebase )
}
rebase . &&
rebase ../dmd &&
rebase ../druntime &&
rebase ../phobos &&
wait
===
But wait, there's less. The script:
* does not return nonzero if either subtask fails - and doing
so needs e.g. temporary files and takes extra code. So I need
to carefully look at the textual garbled output to make sure it
all works.
* does not accept setting variables DMD_DIR etc. It can be made
to, but that's yet more code.
* cannot run serially if I want to debug something, only
parallel. It can be made do, but that's again more code!
So we're looking at an ideological response "don't use make,
make sucks" to a pragmatic matter - I want to get work done,
and we shouldn't use inferior/more intensive technical
solutions on an ideological basis alone. I agree make sucks!
But that doesn't suddenly eliminate my common sense.
For druntime / phobos build... That's really a shame we don't
have a
standard D tool to build D code, cross platform.
If we had, not only would we promote an even saner image of
our tooling
('hey look, dogfooding'), we won't have to solve the same
problems over
and over again, so both druntime / phobos and the tool would
benefit
from this, but ofc it will require some initial work.
If someone wants to get this project started, I have a
suggestion for
the name: dub
Okay, sarcasms appart, would that be a possibility for us to
switch to
dub in the long run ? I'm not sure dub is ready for that ATM,
but I'm
confident it could be made ready without much work.
I'd be glad to switch to dub but I confess at this time I can't
invest the time. I'm already spread too thin.
Andrei
So a dub file for phobos is needed? And maybe druntime too? I'll
see what I can do.
Re: auto return for some recursive functions in C++11
On Wed, 14 Jan 2015 23:07:57 + bearophile via Digitalmars-d wrote: > ketmar: > > > the spec says that return type for `auto` function is taken > > from the first `return` operator parser met. so for the > > second `return` the return type is already known. > > Do you mean the C++14 spec or the D spec? D spec. i'm not really interested in C++ progress, and certainly not that much that i'll read any of it's specs. > The D specs I see are (from: http://dlang.org/function.html ): > > > > Auto Functions > > > > Auto functions have their return type inferred from any > > ReturnStatements in the function body. > > > > An auto function is declared without a return type. If it does > > not > > already have a storage class, use the auto storage class. > > > > If there are multiple ReturnStatements, the types of them must > > be > > implicitly convertible to a common type. If there are no > > ReturnStatements, the return type is inferred to be void. i bet that i read somewhere in specs that return type for `auto` function is defined by first `return` parser sees. yet strangely i can't find it right now. maybe that was changed recently, but i'm almost sure that this is not false memory of mine. signature.asc Description: PGP signature
Re: Common makefile (gasp) stuff
On 1/14/15 3:14 PM, Rikki Cattermole wrote: So a dub file for phobos is needed? And maybe druntime too? I'll see what I can do. That would be very interesting, thanks. Prolly druntime is easiest - one less dependency. Please share all discoveries you make with the core team here. -- Andrei
Re: NaCl/Emscripten
On Wednesday, 14 January 2015 at 03:11:41 UTC, Janus wrote: On Sunday, 11 January 2015 at 01:33:25 UTC, Ola Fosheim Grøstad wrote: On Sunday, 11 January 2015 at 01:05:59 UTC, Manu via Digitalmars-d wrote: With asm.js you are also stuck with a fixed size heap The heap can grow now, see https://github.com/kripken/emscripten/blob/master/ChangeLog.markdown#v1251-1012014 Thanks, I've read the source code now. It involves creating a new array, then copying the old array into the new one. And it probably needs the experimental Ecmascript 7 ArrayBuffer.transfer() function to be fast. So clearly something that only can run when waiting for something (like between levels in a game). Chrome runs it pretty fast though, sometimes faster than Firefox. Yes, not if the code is ASM.js, but still good even then.
Re: Common makefile (gasp) stuff
On 15/01/2015 12:24 p.m., Andrei Alexandrescu wrote: On 1/14/15 3:14 PM, Rikki Cattermole wrote: So a dub file for phobos is needed? And maybe druntime too? I'll see what I can do. That would be very interesting, thanks. Prolly druntime is easiest - one less dependency. Please share all discoveries you make with the core team here. -- Andrei Phobos is done (2.066 branch). I'll submit PR when soon. Oh there will also be atleast two fixes. Somebody forgot to add some version statements in linux/osx only code and since I'm lazy no way I'm specifying every single file to dub.
Re: auto return for some recursive functions in C++11
On Wednesday, 14 January 2015 at 22:37:22 UTC, ketmar via
Digitalmars-d wrote:
On Wed, 14 Jan 2015 22:29:08 +
bearophile via Digitalmars-d
wrote:
According to Wikipedia:
http://en.wikipedia.org/wiki/C%2B%2B14#Function_return_type_deduction
C++14 is able to compile code like this:
auto correct(int i) {
if (i == 1)
return i;
else
return correct(i - 1) + i;
}
But not like this:
auto correct(int i) {
if (i != 1)
return correct(i - 1) + i;
else
return i;
}
D isn't able to compile both. Is it a good idea to allow the
first function in D too?
Bye,
bearophile
i'm pretty sure that D *SHOULD* compile the first sample. the
spec says
that return type for `auto` function is taken from the first
`return`
operator parser met. so for the second `return` the return type
is
already known.
i think that this is not just "let it compile", but a bug in
compiler.
something should be fixed: either compiler or specs.
Well, the error the compiler prints is:
Error: forward reference to inferred return type of function call
'correct'
I played with it a bit and it seems to deduce a common type from
all the return statements, which would be more in the style of D
anyways (take type deduction for arrays). For example, the
following code prints "float" rather than "int":
import std.stdio;
auto one(int i)
{
if(i > 0)
return cast(int)i;
else
return cast(float)i;
}
void main()
{
writeln(typeid(typeof(one(10;
}
Re: auto return for some recursive functions in C++11
Xinok: I played with it a bit and it seems to deduce a common type from all the return statements, Right, this works according to the D specs (but this is different from the feature I have suggested in the original post). Bye, bearophile
Re: auto return for some recursive functions in C++11
On Wednesday, 14 January 2015 at 22:29:09 UTC, bearophile wrote:
According to Wikipedia:
http://en.wikipedia.org/wiki/C%2B%2B14#Function_return_type_deduction
C++14 is able to compile code like this:
auto correct(int i) {
if (i == 1)
return i;
else
return correct(i - 1) + i;
}
...
According to the wiki link:
"If multiple return expressions are used in the function's
implementation, then they must all deduce the same type."
So this will NOT work:
auto Correct(int i) {
if (i == 1){
return (int)5;
}else{
return (float)10;
}
}
Error:
prog.cpp: In function 'auto Correct(int)':
prog.cpp:8:19: error: inconsistent deduction for 'auto': 'int'
and then 'float'
return (float)10;
^
So could you please tell me a good use case to for using "return
type deduction"?
Matheus.
Re: auto return for some recursive functions in C++11
On Thu, 15 Jan 2015 00:05:30 +
Xinok via Digitalmars-d wrote:
> Well, the error the compiler prints is:
>
> Error: forward reference to inferred return type of function call
> 'correct'
>
> I played with it a bit and it seems to deduce a common type from
> all the return statements, which would be more in the style of D
> anyways (take type deduction for arrays). For example, the
> following code prints "float" rather than "int":
>
> import std.stdio;
>
> auto one(int i)
> {
> if(i > 0)
> return cast(int)i;
> else
> return cast(float)i;
> }
>
> void main()
> {
> writeln(typeid(typeof(one(10;
> }
i remember that there was some discussion about this, but it's all i
can remember about it. ;-)
there were some inconsistencies with deducing return type, AFAIR, but i
don't remember if it leads to some fixes or not. if ony i wasn't so
lazy and take some notes...
signature.asc
Description: PGP signature
Re: auto return for some recursive functions in C++11
Xinok:
auto one(int i)
{
if(i > 0)
return cast(int)i;
else
return cast(float)i;
}
With recent D2 compilers I suggest you to get used to write code
like that like this:
auto one(int i)
{
if(i > 0)
return int(i);
else
return float(i);
}
It's better to minimize the usage of cast().
Bye,
bearophile
Re: Common makefile (gasp) stuff
On 15/01/2015 1:15 p.m., Mathias LANG wrote: On Wednesday, 14 January 2015 at 23:58:45 UTC, Rikki Cattermole wrote: On 15/01/2015 12:24 p.m., Andrei Alexandrescu wrote: On 1/14/15 3:14 PM, Rikki Cattermole wrote: So a dub file for phobos is needed? And maybe druntime too? I'll see what I can do. That would be very interesting, thanks. Prolly druntime is easiest - one less dependency. Please share all discoveries you make with the core team here. -- Andrei Phobos is done (2.066 branch). I'll submit PR when soon. Oh there will also be atleast two fixes. Somebody forgot to add some version statements in linux/osx only code and since I'm lazy no way I'm specifying every single file to dub. excludedSourceFiles accept patterns and platform suffixes. I'm using it for std.metastrings. Not really a loss since the distributed version doesn't include it (also doesn't compile). In the case of the version statements? Its two line additions in total. They definitely should be there considering.
Re: Common makefile (gasp) stuff
On Wednesday, 14 January 2015 at 23:58:45 UTC, Rikki Cattermole wrote: On 15/01/2015 12:24 p.m., Andrei Alexandrescu wrote: On 1/14/15 3:14 PM, Rikki Cattermole wrote: So a dub file for phobos is needed? And maybe druntime too? I'll see what I can do. That would be very interesting, thanks. Prolly druntime is easiest - one less dependency. Please share all discoveries you make with the core team here. -- Andrei Phobos is done (2.066 branch). I'll submit PR when soon. Oh there will also be atleast two fixes. Somebody forgot to add some version statements in linux/osx only code and since I'm lazy no way I'm specifying every single file to dub. excludedSourceFiles accept patterns and platform suffixes.
Re: auto return for some recursive functions in C++11
On Thursday, 15 January 2015 at 00:13:38 UTC, MattCoder wrote: So could you please tell me a good use case to for using "return type deduction"? Templates.
Re: auto return for some recursive functions in C++11
On Thu, 15 Jan 2015 00:24:07 + via Digitalmars-d wrote: > On Thursday, 15 January 2015 at 00:13:38 UTC, MattCoder wrote: > > So could you please tell me a good use case to for using "return > > type deduction"? > > Templates. and returning voldemort types. signature.asc Description: PGP signature
Re: auto return for some recursive functions in C++11
On Thursday, 15 January 2015 at 00:24:09 UTC, Ola Fosheim Grøstad wrote: On Thursday, 15 January 2015 at 00:13:38 UTC, MattCoder wrote: So could you please tell me a good use case to for using "return type deduction"? Templates. Thanks! - In fact after posting I took a look and found this: http://stackoverflow.com/questions/15737223/when-should-i-use-c14-automatic-return-type-deduction Matheus.
Re: Common makefile (gasp) stuff
On 15/01/2015 12:24 p.m., Andrei Alexandrescu wrote:
On 1/14/15 3:14 PM, Rikki Cattermole wrote:
So a dub file for phobos is needed? And maybe druntime too? I'll see
what I can do.
That would be very interesting, thanks. Prolly druntime is easiest -
one less dependency. Please share all discoveries you make with the core
team here. -- Andrei
Druntime and phobos now can be built and even more importantly you can
have druntime as a dependency to phobos. In fact it is.
Phobos supports being built as a dynamic library (there is a
configuration for for it).
So if you want to switch to dynamic library at any time its as simple as
adding:
"subConfigurations": {
"phobos": "dynamicLibrary"
}
I'm pretty sure anyway.
Because of the current state of assembly files, we really need to sort
it out. I understand that not all things are really possible in an
inline assembler. But at the very least we should be able to compile the
damn thing.
Dub can run external processes but its best to leave it up to the end
dev to run the c/assembly generation. When they want it regenerated.
I think its best we commit most of the binary outputs.
Mostly c/assembly generation. Not the D stuff.
I've added information to the README on how to build based upon dub.
Docs so far have not been included. But that adds one more repo I need
to get my hands dirty with.
Re: Common makefile (gasp) stuff
On Thursday, 15 January 2015 at 01:48:29 UTC, Rikki Cattermole
wrote:
Druntime and phobos now can be built and even more importantly
you can have druntime as a dependency to phobos. In fact it is.
Phobos supports being built as a dynamic library (there is a
configuration for for it).
So if you want to switch to dynamic library at any time its as
simple as adding:
"subConfigurations": {
"phobos": "dynamicLibrary"
}
I'm pretty sure anyway.
Thanks !
Last time I checked, building dynamic library with dub was buggy.
In addition, we can't have druntime has a dependency to phobos
with dynamic library (yet). See
https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/generator.d#L152
But having the static version in is a good start :)
Re: Common makefile (gasp) stuff
On 15/01/2015 2:58 p.m., Mathias LANG wrote:
On Thursday, 15 January 2015 at 01:48:29 UTC, Rikki Cattermole wrote:
Druntime and phobos now can be built and even more importantly you can
have druntime as a dependency to phobos. In fact it is.
Phobos supports being built as a dynamic library (there is a
configuration for for it).
So if you want to switch to dynamic library at any time its as simple
as adding:
"subConfigurations": {
"phobos": "dynamicLibrary"
}
I'm pretty sure anyway.
Thanks !
Last time I checked, building dynamic library with dub was buggy. In
addition, we can't have druntime has a dependency to phobos with dynamic
library (yet). See
https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/generator.d#L152
But having the static version in is a good start :)
The configuration is there. Atleast I'm prepared!
Anyway static version is default, so as long as dynamic isn't advertised
too much we're good.
Re: What is the D plan's to become a used language?
On Wednesday, 14 January 2015 at 05:10:05 UTC, Joakim wrote: Take a look at the official package registry, called dub: I love dub, who doesn't. It is evidence of a very active and large community. I don't think it's that unusual for a native compiled language: can you find C++ snippets to write tweets? I doubt it. A compiled languages is just not the tool people usually grab to write such things. Pardon my naivity, but I don't know why I *wouldn't* want to do this in D? I want something to pull tweets, analyse them quickly and produce results. And then I graph it in something else. Isn't this what this language would be *really* good at, as it provides efficiency with minimal coding? D would like to be good at all these things, and some of them are enabled on dub. But as a newer language with a smaller community than Java, obviously the amount of APIs covered is going to be less right now. I'd love to help it on this journey, with my limited knowledge. Where can I start? This is the normal chicken-or-egg problem with a new language like D, ie people want libraries or API wrappers to get their job done easier but if they don't spend time writing them, they never get done. Agreed. But if I'm looking to use an API library and their isn't one there, writing a new library entirely isn't exactly a trivial task. Also, maybe the D community doesn't put their code up for public consumption as much as some other language communities. This is my belief and main point. I don't doubt that these issues exist, I just consider them normal for a newer language. As for recommending D, I think it depends on the type of user. If they care at all about efficiency, I don't know that I'd recommend a language other than D. If they don't really care how fast their code runs and prefer to stay at a higher scripting level, then the advantages of D fade compared to other languages. Yes the language is efficient but what's the point in having efficient code if I don't know how to get it to do what I want? While I'm not sure if you agree or disagree with me, I think you also clarify what I was trying to say. My point wasn't that there aren't ways to do things in D. My point was that there are fewer examples of *how* to do things in D. This will discourage the new user, which will prevent it becoming a more popular language. So if I'm looking for a new language to use, I'd probably stick to the ones that have more examples.
Druntime and phobos with dub
I'm currently working on getting dub package files for Druntime and phobos.
It has been reasonably easy getting code to compile atleast for 2.066
branch.
Problems:
- Druntime contains assembly + c files requiring external compilers.
To play nicely with dub repos and having them dependencies, they could
be stored in git like I have it right now.
But the real problem here is that atleast one of these assembly files
can't even be compiled by pretty much anyone but Walter.
- Phobos has zlib which is in the same situation as druntime for c files.
We seriously should consider rewriting or porting that.
*wink* GSOC.
That would only leave curl but that's manual anyway.
- Documentation building.
This is separated out into dlang.org and druntime/phobos.
- Dlang.org repo contains the base website and formatting.
Dub doesn't really understand past sourceLibrary that certain files
are ddoc macro files and should include them in all packages that depend
upon it.
That is okay. The problem is both the formatting but also
images/css/js are required as part of this.
- With druntime/phobos they merely need resources from dlang.org.
Which are detailed above.
- Dlang.org IS A MESS
I'm not joking here. Before tackling getting a dub file for e.g. html
output I moved everything into a new folder.
- std.c.linux and std.c.osx need guard version statements. Other then
that only issue is std.metastrings doesn't compile so is excluded.
TLDR: Turning druntime/phobos into dub repos are easy. Getting
documentation to play nicely does not.
For reference here are the files:
Druntime's dub.json:
{
"name": "druntime",
"description": "This is DRuntime. It is the low-level runtime
library backing the D programming language.",
"homepage": "http://dlang.org";,
"authors": ["Walter Bright", "Andrei Alexandrescu"],
"license": "Boost",
"targetType": "none",
"targetPath": "bin",
"sourcePaths": [],
"dependencies": {
"druntime:rt": "*",
"druntime:core": "*",
"druntime:gc": "*",
"druntime:etc": "*"
},
"subPackages": [
{
"name": "gcstub",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": [],
"sourceFiles": ["src/gcstub/gc.d"]
},
{
"name": "rt",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": ["src/rt"],
"sourceFiles": ["src/object_.d"],
"sourceFiles-windows": ["bin/rt_minit.obj"],
"sourceFiles-posix": ["bin/rt_bss_section.obj"]
},
{
"name": "gc",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": ["src/gc"]
},
{
"name": "core",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": ["src/core"],
"sourceFiles-windows": ["bin/stdc_errno_c.obj"],
"sourceFiles-posix": ["bin/stdc_errno_c.obj",
"bin/core_threadasm.obj"]
},
{
"name": "etc",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": ["src/etc"]
}
]
}
Phobos's dub.json:
{
"name": "phobos",
"description": "Phobos is the standard library that comes with the
D Programming Language Compiler.",
"homepage": "http://dlang.org";,
"authors": ["Walter Bright", "Andrei Alexandrescu"],
"license": "Boost",
"targetPath": "bin",
"sourcePaths": ["std", "etc"],
"excludedSourceFiles": ["std/metastrings.d"],
"sourceFiles-windows-x86": ["bin/zlib.lib"],
"sourceFiles-windows-x86_64": ["bin/zlib64.lib"],
"sourceFiles-osx": ["bin/zlib_osx.a"],
"sourceFiles-linux": ["bin/zlib_linux.a"],
"dependencies": {
"druntime": "*"
},
"configurations": [
{
"name": "staticLibrary",
"targetType": "staticLibrary"
},
{
"name": "dynamicLibrary",
"targetType": "dynamicLibrary",
"dflags": ["-main"]
}
]
}
This is not about debating who should be listed as authors FYI.
Re: Druntime and phobos with dub
On 15/01/2015 4:35 p.m., Rikki Cattermole wrote:
I'm currently working on getting dub package files for Druntime and phobos.
It has been reasonably easy getting code to compile atleast for 2.066
branch.
Problems:
- Druntime contains assembly + c files requiring external compilers.
To play nicely with dub repos and having them dependencies, they could
be stored in git like I have it right now.
But the real problem here is that atleast one of these assembly files
can't even be compiled by pretty much anyone but Walter.
- Phobos has zlib which is in the same situation as druntime for c files.
We seriously should consider rewriting or porting that.
*wink* GSOC.
That would only leave curl but that's manual anyway.
- Documentation building.
This is separated out into dlang.org and druntime/phobos.
- Dlang.org repo contains the base website and formatting.
Dub doesn't really understand past sourceLibrary that certain files
are ddoc macro files and should include them in all packages that depend
upon it.
That is okay. The problem is both the formatting but also
images/css/js are required as part of this.
- With druntime/phobos they merely need resources from dlang.org.
Which are detailed above.
- Dlang.org IS A MESS
I'm not joking here. Before tackling getting a dub file for e.g. html
output I moved everything into a new folder.
- std.c.linux and std.c.osx need guard version statements. Other then
that only issue is std.metastrings doesn't compile so is excluded.
TLDR: Turning druntime/phobos into dub repos are easy. Getting
documentation to play nicely does not.
For reference here are the files:
Druntime's dub.json:
{
"name": "druntime",
"description": "This is DRuntime. It is the low-level runtime
library backing the D programming language.",
"homepage": "http://dlang.org";,
"authors": ["Walter Bright", "Andrei Alexandrescu"],
"license": "Boost",
"targetType": "none",
"targetPath": "bin",
"sourcePaths": [],
"dependencies": {
"druntime:rt": "*",
"druntime:core": "*",
"druntime:gc": "*",
"druntime:etc": "*"
},
"subPackages": [
{
"name": "gcstub",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": [],
"sourceFiles": ["src/gcstub/gc.d"]
},
{
"name": "rt",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": ["src/rt"],
"sourceFiles": ["src/object_.d"],
"sourceFiles-windows": ["bin/rt_minit.obj"],
"sourceFiles-posix": ["bin/rt_bss_section.obj"]
},
{
"name": "gc",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": ["src/gc"]
},
{
"name": "core",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": ["src/core"],
"sourceFiles-windows": ["bin/stdc_errno_c.obj"],
"sourceFiles-posix": ["bin/stdc_errno_c.obj",
"bin/core_threadasm.obj"]
},
{
"name": "etc",
"targetType": "staticLibrary",
"targetPath": "bin",
"sourcePaths": ["src/etc"]
}
]
}
Phobos's dub.json:
{
"name": "phobos",
"description": "Phobos is the standard library that comes with the
D Programming Language Compiler.",
"homepage": "http://dlang.org";,
"authors": ["Walter Bright", "Andrei Alexandrescu"],
"license": "Boost",
"targetPath": "bin",
"sourcePaths": ["std", "etc"],
"excludedSourceFiles": ["std/metastrings.d"],
"sourceFiles-windows-x86": ["bin/zlib.lib"],
"sourceFiles-windows-x86_64": ["bin/zlib64.lib"],
"sourceFiles-osx": ["bin/zlib_osx.a"],
"sourceFiles-linux": ["bin/zlib_linux.a"],
"dependencies": {
"druntime": "*"
},
"configurations": [
{
"name": "staticLibrary",
"targetType": "staticLibrary"
},
{
"name": "dynamicLibrary",
"targetType": "dynamicLibrary",
"dflags": ["-main"]
}
]
}
This is not about debating who should be listed as authors FYI.
Personally I believe we should move towards a model where every library
is represented by JSON (maybe with help of e.g. markdown) that gets e.g.
parsed by client side technologies such as json.
Benefits:
- We can have central documentation as part of dub registry for all
libraries registered
- Same look and feel for every piece of documentation
- Less dependencies between druntime/phobos docs and dlang.org
Negatives:
- Loss of control over end formatting excluding what e.g. markdown support
- If javascript is disabled, nothing gets displayed
Re: Druntime and phobos with dub
On Thursday, 15 January 2015 at 03:42:39 UTC, Rikki Cattermole wrote: Personally I believe we should move towards a model where every library is represented by JSON (maybe with help of e.g. markdown) that gets e.g. parsed by client side technologies such as json. Benefits: - We can have central documentation as part of dub registry for all libraries registered - Same look and feel for every piece of documentation - Less dependencies between druntime/phobos docs and dlang.org Negatives: - Loss of control over end formatting excluding what e.g. markdown support - If javascript is disabled, nothing gets displayed Nice work! Central searchable documentation for third party libraries registered on code.dlang.org could be a killer :-).
Re: Walter's DConf 2014 Talks - Topics in Finance
On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote: Walter, I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us. I am a Finance Professor. I currently teach and do research in computational finance. Might I suggest that you include some finance (say Monte Carlo options pricing) examples? If you can get the finance industry interested in D you might see a massive adoption of the language. Many are desperate for an alternative to C++ in that space. Just a thought. Best, TJB 1+ for finance talk
Re: What is the D plan's to become a used language?
On Thursday, 15 January 2015 at 03:19:10 UTC, brian wrote: On Wednesday, 14 January 2015 at 05:10:05 UTC, Joakim wrote: I don't think it's that unusual for a native compiled language: can you find C++ snippets to write tweets? I doubt it. A compiled languages is just not the tool people usually grab to write such things. Pardon my naivity, but I don't know why I *wouldn't* want to do this in D? I want something to pull tweets, analyse them quickly and produce results. And then I graph it in something else. Isn't this what this language would be *really* good at, as it provides efficiency with minimal coding? You originally talked about _writing_ tweets by using a D tool, not pulling and analyzing them as you do now, which is usually what people use a native language for. For writing tweets, tossing off something in a scripting language is usually much quicker and easier, as you see with all the perl/python/php/ruby libraries listed in the official Twitter libraries link Ola provided above. However, D could be used for both writing and analyzing, and if you look on dub, you'll see two libraries that advertise twitter support: http://code.dlang.org/packages/twitter4d http://code.dlang.org/packages/graphite D would like to be good at all these things, and some of them are enabled on dub. But as a newer language with a smaller community than Java, obviously the amount of APIs covered is going to be less right now. I'd love to help it on this journey, with my limited knowledge. Where can I start? Simple, write the kinds of libraries or API wrappers you'd like to use. This is the normal chicken-or-egg problem with a new language like D, ie people want libraries or API wrappers to get their job done easier but if they don't spend time writing them, they never get done. Agreed. But if I'm looking to use an API library and their isn't one there, writing a new library entirely isn't exactly a trivial task. It doesn't have to be a new library. It could just be a D wrapper for an existing C library, because D provides for wrapping C easily. I ran the automated C->D header translation tool dstep and modified the output a little to provide a D wrapper for the native Android C APIs: https://github.com/jacob-carlborg/dstep https://github.com/joakim-noah/android Also, maybe the D community doesn't put their code up for public consumption as much as some other language communities. This is my belief and main point. Tough to say. I don't doubt that these issues exist, I just consider them normal for a newer language. As for recommending D, I think it depends on the type of user. If they care at all about efficiency, I don't know that I'd recommend a language other than D. If they don't really care how fast their code runs and prefer to stay at a higher scripting level, then the advantages of D fade compared to other languages. Yes the language is efficient but what's the point in having efficient code if I don't know how to get it to do what I want? Generally, the kind of people who write efficient code don't mind writing and figuring out such stuff themselves, without relying on existing code examples. While I'm not sure if you agree or disagree with me, I think you also clarify what I was trying to say. My point wasn't that there aren't ways to do things in D. My point was that there are fewer examples of *how* to do things in D. This will discourage the new user, which will prevent it becoming a more popular language. So if I'm looking for a new language to use, I'd probably stick to the ones that have more examples. I agree that most users learn from examples, so to the extent D is missing those, it will not get as many users. But any new language without corporate support has this problem, as language users generally don't bother taking the time to slap all their support code and examples online. dub has been an effort to remedy that, and taking your twitter example, appears to have worked, based on the two links I found. Obviously, D still has a ways to go to reach ruby or Java levels of example/library availability.
Re: Druntime and phobos with dub
On 15/01/2015 7:34 p.m., NVolcz wrote: On Thursday, 15 January 2015 at 03:42:39 UTC, Rikki Cattermole wrote: Personally I believe we should move towards a model where every library is represented by JSON (maybe with help of e.g. markdown) that gets e.g. parsed by client side technologies such as json. Benefits: - We can have central documentation as part of dub registry for all libraries registered - Same look and feel for every piece of documentation - Less dependencies between druntime/phobos docs and dlang.org Negatives: - Loss of control over end formatting excluding what e.g. markdown support - If javascript is disabled, nothing gets displayed Nice work! Central searchable documentation for third party libraries registered on code.dlang.org could be a killer :-). Thanks, and I agree it could very well be. But it will be quite a lot of work, even if everyone agrees this is the right direction to go. Eventually this could allow for making e.g. std.algorithm as a subpackage. But atleast we are getting round to sorting out our documentation now.
Re: Common makefile (gasp) stuff
On 2015-01-14 20:50, Andrei Alexandrescu wrote: Currently there must be a place where druntime finds dmd for building purposes. Also phobos needs to find druntime. Also dlang.ord needs to find the source of both phobos and druntime. There's no specific setup of one person as much as a boring: /some/dir/ dmd druntime phobos dlang.org tools I have a hard time making it any simpler. Last time I tried to build the docs in dlang.org, quite a long time ago. The d-programming-language.org repository just had been moved to dlang.org. So I update the repository URL, pull the new code and tried building the docs. Nothing worked because I had forget to rename the directory. A super repository with submodules would have solved this. Where would that super-repo sit? https://github.com/D-Programming-Language/dlang for example -- /Jacob Carlborg
Re: Common makefile (gasp) stuff
On 2015-01-14 21:54, Andrei Alexandrescu wrote: I hear you but The Internet says submodules are a kind of a bummer. Most issues I have read about is because they don't know how submodules work. It's the same thing with most tools, if you don't know how to use it the experience is going to be crappy. I'm hoping the submodules can be automatically update, i.e. on a push to some of the submodules. I'm expecting most work to be done in the submodules and the super repository will be kept in sync automatically. -- /Jacob Carlborg
Re: Common makefile (gasp) stuff
On 2015-01-15 02:48, Rikki Cattermole wrote: Dub can run external processes but its best to leave it up to the end dev to run the c/assembly generation. When they want it regenerated. I think its best we commit most of the binary outputs. Mostly c/assembly generation. Not the D stuff. Why don't you want to build the C/assembly stuff? The user is already expected to have a C compiler installed. -- /Jacob Carlborg
