Re: Blog post : OOP composition with mixins
On Monday, 24 August 2015 at 11:10:16 UTC, Dicebot wrote: Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins Nice. I've only just started exploring code reuse with template mixins, and used it to great effect in my last project. Blogs like this are useful since there aren't many examples in other languages (Ruby modules come to mind). Atila
Re: string - null/bool implicit conversion
On Friday, 21 August 2015 at 20:01:21 UTC, Vladimir Panteleev wrote: This warning almost doesn't break any code! Yes it flipping does. It does break some code, but only in certain extremely specialized contexts like memory allocation! No it's bleeping not. Many of those warnings are probably actual bugs, you should fix your buggy code! No, they quacking aren't. I just write code this way, because I find the empty/null distinction obvious and useful. Shocking, I know. The distinction has its merits, but it shouldn't prevent you from seeing how it doesn't quite fit the D slice design.
Re: associative arrays with manual memory management
On Saturday, 22 August 2015 at 04:16:30 UTC, Rikki Cattermole wrote: On 8/22/2015 5:20 AM, Ilya Yaroshenko wrote: Hi All! I am going to implement associative arrays with manual memory management based on amazing std.experimental.allocator by Andrei http://wiki.dlang.org/Review/std.experimental.allocator I will be happy to receive any advices about algorithms, use cases and API. Best Regards, Ilya Will it be language feature fix, or is it an independent container? If the later I already have a simple dumb one which I can share (not on this machine). I'll be happy to use what you create. Same goes for list and friends ones. Annonce http://forum.dlang.org/post/hgawkhhbvkkxbnjzi...@forum.dlang.org
associative arrays with manual memory management
http://code.dlang.org/packages/aammm/~master # aammm Associative arrays with manual memory management All enries and buckets would be dealocated and disposed by internal implementation's destructor. The destructor is called by garbage collector (by default). Example ```D //std.experimental.allocator is included into `aammm` import std.experimental.allocator.mallocator; import aammm; auto a = AA!(string, int, shared Mallocator)(Mallocator.instance); a[foo] = 0; a.remove(foo); //dealocates and disposes the entry assert(a == null); // should not crash ``` AAMMM is based on Andrei's allocators and Martin's associative arrays. References: http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html https://github.com/D-Programming-Language/druntime/pull/1282 Best Regards, Ilya
Re: dmd codegen improvements
On Monday, 24 August 2015 at 08:59:57 UTC, ixid wrote: One of D's potential massive wins is speed and I think that has the most easily conveyed impacted on the audience. If we had the best benchmark site for a very large range of languages it would not only draw people here but drive the improvement of D on all compilers (and perhaps allow us to make LDC/GCD for run speed, DMD for compile speed more explicit) as every time there is a benchmark contest we seem to find some small thing that needs a fix and then D blows others away. This would also convey more idiomatic D for performance as D seems to suffer from people writing it as whatever language they come from. People love competitions, the current benchmark site that seems to weirdly dislike D is one of people's go to references. I do not have the ability to do this but it would seem like an excellent project for someone outside the major development group, a Summer of Code-esque thing. You mean this site? http://benchmarksgame.alioth.debian.org/
Re: [OT] Sharp Regrets: Top 10 Worst C# Features
On Thursday, 20 August 2015 at 16:22:22 UTC, Jonathan M Davis wrote: I really don't mind NaN. Well with silent NaN you have 'x == x' is false which means all the generic algorithms (silently) fail. It really doesn't cause problems normally. The problem with floating point values is floating point values themselves. They're so painfully inexact. Even without NaN, you can't use == with them and expect it to work. Compared to that, how NaN is dealt with is a total non-issue. Floating points themselves just plain suck. They're sometimes necessary, but they suck. - Jonathan M Davis I think that at Sun some pushed for interval arithmetic support, but 1) Oracle has bought Sun 2) range has its own set of problem and they are more expensive to compute. I'm still a bit sad that modern CPU seems to spend their humongous amount of transistors on dubious feature yet they don't try to support important basic things such as 'trap on overflow' integer computations, interval arithmetic.
Re: string - null/bool implicit conversion
On Saturday, 22 August 2015 at 21:23:19 UTC, Timon Gehr wrote: For the comma operator, I think it's pretty clear that the usage of ',' to separate components of a tuple would be more useful. Why not use C/C++/C# initializer syntax? Technically it's a tuple, but not related to comma operator.
Re: [OT] Sharp Regrets: Top 10 Worst C# Features
On 19/08/15 15:01, Kagamin wrote: Just switch your editor to RTL mode, haha. OT: (so this is an off topic reply to an off topic thread) I actually tried to write a good RTL text editor (you can see the half baked result at http://bidiedit.lingnu.com). I know your comment was meant as a joke, but the truth is that mixing RTL text with code does not work well in any editor I have ever encountered. The BiDi engine is located too low to incorporate the syntax analysis required to do it properly (and, in some cases, it is not clear what properly even means) for any editor I've seen to do it. I usually end up using VIM, because it does not reoredering at all (I.e. - all text, regardless of language, is shown from left to right), which means that I can separate syntax from content. Shachar
Re: string - null/bool implicit conversion
On Friday, 21 August 2015 at 11:34:42 UTC, Marc Schütz wrote: On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote: if(arr != null) Definitely don't do that. IMHO, == null and != null should be illegal. If you really want to check for null, then you need to use is null or !is null, whereas if you want to check that an array is empty, check its length or call empty. By using == null or != null, you tend to give the false impression that you're checking whether the object or array is null - which is not what you're actually doing. I disagree. `is null` is the one that should be illegal. `is` is supposed to do a bitwise comparison, but `null` is usually just a pointer/reference, while a slice consists of both a reference and a length. Which of those are compared? No ambiguity there: D doesn't allow comparison of array with pointer.
[Issue 14929] [REG2.067] ICE: Assertion failure: 'ez-exp ez-exp-op == TOKconstruct' on line 302 in file 'escape.c'
https://issues.dlang.org/show_bug.cgi?id=14929 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3e3fdfe12e49815f3a78659266b2a5aad737ec79 fix Issue 14929 - ICE: Assertion failure: 'ez-exp ez-exp-op == TOKconstruct' on line 302 in file 'escape.c' If error happens, propagate it without storing. https://github.com/D-Programming-Language/dmd/commit/45c115bccd2e3fe64e607eb2cf40786fe1dc4412 Merge pull request #4950 from 9rnsr/fix14929 [REG2.067] Issue 14929 - ICE: Assertion failure: 'ez-exp ez-exp-op == TOKconstruct' on line 302 in file 'escape.c' --
Re: Ranges - Question about desing choices
On Monday, 24 August 2015 at 15:09:14 UTC, Michal Minich wrote: What are the advantages of current design. One advantage of the current design is you can statically determine if something is an infinite range by seeing if empty is a constant false. With your change, you could never be sure if something was infinite or not since popFront would just keep returning true. It is also sometimes useful to see if something is empty without modifying it, like when doing a wrapper.
Ranges - Question about desing choices
I'm thinking about ranges I can think of similar design of the
input range, but with different pros and cons. Obviously not
for/in D. Currently ranges has 3 primitive operations, and they
can be translated from foreach like:
for (auto __r = range; !__r.empty; __r.popFront())
{
auto e = __r.front;
...
}
I'm thinking of design where range would have only 2 primitive
operations:
bool popFront() // returns true if current will have an
element
front// it may be called only if popFrount (would)
have returned true
foreach would be translated to:
while (auto r = r.popFront())
{
auto e = __r.front;
...
}
This design results in following differences
1) 2 primitive operations (empty and popFront) are merge into one
less primitive
2) it will result in less calls per item (2 instead for 3)
3) it is not possible to ask a range if it's empty more times
per iteration of one item
4) it does _not_ requires range to be in ready state
immediately after construction. That means that popFront needs to
be called firstly, before front can be. This I feel is biggest
change. Since D ranges are required to have front ready
immediately after their construction. Which for some non trivial
ranges can seem as less effective/convenient/expected.
I would be interested what do you think about this possible
design. Does it have some special flaws in general, or
specifically for D. What are the advantages of current design. Do
you think it would be reasonable in some other language? What do
you think is better in practice from point of view of
implementors and users of range: that range has ready front
immediately, or better to have it ready only after first popFront
call.
Thank you.
[Issue 14929] [REG2.067] ICE: Assertion failure: 'ez-exp ez-exp-op == TOKconstruct' on line 302 in file 'escape.c'
https://issues.dlang.org/show_bug.cgi?id=14929 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Ranges - Question about desing choices
On Mon, Aug 24, 2015 at 03:16:10PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: On Monday, 24 August 2015 at 15:09:14 UTC, Michal Minich wrote: What are the advantages of current design. One advantage of the current design is you can statically determine if something is an infinite range by seeing if empty is a constant false. With your change, you could never be sure if something was infinite or not since popFront would just keep returning true. It is also sometimes useful to see if something is empty without modifying it, like when doing a wrapper. [...] It's also useful in parsing algorithms to look at the current item in the input without also consuming it. T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
C++/STL interop
I saw https://issues.dlang.org/show_bug.cgi?id=14956 .
questions:
- is std.basic_string released into the wild?
- where do I find std.basic_string?
- does std.vector exist? That would allow me to get rid of some
C++ clue code (build an C-like interface, copy data etc)...
Putting
extern(C++)
{
void foo14a(std.basic_string!(char) *p);
void foo14b(std.basic_string!(int) *p);
void foo14f(std.char_traits!char* x, std.basic_string!char* p,
std.basic_string!char* q);
}
into a file results in Error: undefined identifier (dmd 2.068).
Re: dmd codegen improvements
On Monday, 24 August 2015 at 15:03:48 UTC, Isaac Gouy wrote: On Monday, 24 August 2015 at 08:59:57 UTC, ixid wrote: -snip- People love competitions, the current benchmark site that seems to weirdly dislike D is one of people's go to references. I do not have the ability to do this but it would seem like an excellent project for someone outside the major development group, a Summer of Code-esque thing. Lest we forget, this time last year -- http://forum.dlang.org/post/lv9s7n$1trl$1...@digitalmars.com Yes, it requires someone to pick up the baton for what is clearly a very significant task. Your site is excellent and it's very unfortunate that D is absent.
[Issue 14955] New: [D1] Add module profiling feature
https://issues.dlang.org/show_bug.cgi?id=14955 Issue ID: 14955 Summary: [D1] Add module profiling feature Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: andrej.mitrov...@gmail.com Since the -profile switch by default generates a try/finally for every function which is generated this causes a major slowdown of the application and makes it hard to frequently do performance analysis or even do analysis on a specific set of functions. Instead one could profile a specific module via: $ dmd -profile=my.mod ... It's fairly easy to implement. --
Re: associative arrays with manual memory management
On Monday, 24 August 2015 at 12:01:52 UTC, Ilya Yaroshenko wrote: http://code.dlang.org/packages/aammm/~master # aammm Associative arrays with manual memory management [...] Awesome, I was waiting for something like that. Thank you!
Re: Digger 2.3 verstr.h problem
On Monday, 24 August 2015 at 09:18:14 UTC, Robert M. Münch wrote: On 2015-08-23 20:13:38 +, Vladimir Panteleev said: Not really sure what's going on there... If I could reproduce it, I'd try building DMD manually - if it still occurred, build DMD 2.067.1 from source and add debugging printfs to see why it's not finding verstr.h. I'm not building 2.067.1 I try to build HEAD and digger uses 2.067.1 for this. Might this be a cause? Well, yes, your problem is that DMD 2.067 isn't finding a file while compiling DMD HEAD. So you would need to debug DMD 2.067 to find why it refuses to compile DMD HEAD.
Re: dmd codegen improvements
On Monday, 24 August 2015 at 08:59:57 UTC, ixid wrote: -snip- People love competitions, the current benchmark site that seems to weirdly dislike D is one of people's go to references. I do not have the ability to do this but it would seem like an excellent project for someone outside the major development group, a Summer of Code-esque thing. Lest we forget, this time last year -- http://forum.dlang.org/post/lv9s7n$1trl$1...@digitalmars.com
[Issue 14956] New: C++ Mangling incompatible with C++11
https://issues.dlang.org/show_bug.cgi?id=14956
Issue ID: 14956
Summary: C++ Mangling incompatible with C++11
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: blocker
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
DMD cannot link with C++ code compiled with GCC-5 because the mangling of the
mangling for basic_string has changed.
Reference: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
Affects the following tests:
extern(C++)
{
void foo14a(std.basic_string!(char) *p);
void foo14b(std.basic_string!(int) *p);
void foo14f(std.char_traits!char* x, std.basic_string!char* p,
std.basic_string!char* q);
}
Before (C++-98):
_Z6foo14aPSs
_Z6foo14bPSbIiSt11char_traitsIiESaIiEE
_Z6foo14fPSt11char_traitsIcEPSsS2_
After (C++-11):
_Z6foo14aPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
_Z6foo14bPNSt7__cxx1112basic_stringIiSt11char_traitsIiESaIiEEE
_Z6foo14fPSt11char_traitsIcEPNSt7__cxx1112basic_stringIcS0_SaIcEEES6_
--
Re: dmd codegen improvements
On Monday, 24 August 2015 at 13:45:58 UTC, jmh530 wrote: You mean this site? http://benchmarksgame.alioth.debian.org/ Yes, precisely that but try to one up it with more challenges.
Re: order of declaration/definition
On Monday, 24 August 2015 at 01:01:13 UTC, John Colvin wrote: enum A = 1; enum B = C; //Error static if(A) enum C = 0; enum D = C; //OK Is order supposed to matter here? No.
Re: DDT 0.13.0 released - DUB configurations support.
On 11/08/2015 18:03, Bruno Medeiros wrote: A new DDT release (nicknamed Candy Kingdom ) is out, please read the changelog: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.13.0 This is Release Candidate quality, there might be a few undiscovered bugs with the recently introduced functionality. Minor follow up release: https://github.com/DDT-IDE/DDT/releases/tag/Release_0.13.1 -- Bruno Medeiros https://twitter.com/brunodomedeiros
This Week in D summarizes those long threads for you!
I haven't posted these to the announce forum for a while, but they still come out each week! If you aren't subscribed yet, there's an rss link on the page or you can follow me on Twitter, where I post most of them: https://twitter.com/adamdruppe This Week in D has the argument over export/Object.factory, the if(array) thread, dmd codegen, and the official switch to ddmd! http://arsdnet.net/this-week-in-d/aug-23.html Next week, we have another interview planned. In previous weeks, I've summarized DConf, written tips, and highlighted interesting projects. So if you want to keep up with D but don't want to read all the long threads, take a look at these. I don't cover everything and sometimes my bias will influence the summaries... but it still should give you a more digestable look at the community.
Re: Blog post : OOP composition with mixins
Good article. However, composition also has some drawbacks and they should be explained. Speaking about Java and inheritance, and popular believe it is overused - Yes, maybe it is, but Java does not have language features D has, and it should not be blamed for that. Interesting article for those looking for more serious criticism of Java and inheritance: https://www.cs.auckland.ac.nz/~ewan/qualitas/studies/inheritance/TemperoYangNobleECOOP2013-pre.pdf What I think D community would benefit from would be a series of Idiomatic D articles.
[Issue 14957] New: order of declaration at global scope
https://issues.dlang.org/show_bug.cgi?id=14957 Issue ID: 14957 Summary: order of declaration at global scope Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com enum A = 1; enum B = C; //Error static if(A) enum C = 0; enum D = C; //OK --
[Issue 14958] New: Casting a double to ulong sometimes produces wrong results
https://issues.dlang.org/show_bug.cgi?id=14958
Issue ID: 14958
Summary: Casting a double to ulong sometimes produces wrong
results
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: marcio...@gmail.com
import std.stdio;
void main() {
double x = 1.2;
writeln(cast(ulong)(x * 10.0));
double y = 1.2 * 10.0;
writeln(cast(ulong)y);
}
Output:
11
12
to!ulong instead of the cast does the right thing, and is a viable work-around.
--
Re: Ranges - Question about desing choices
On Monday, 24 August 2015 at 15:16:12 UTC, Adam D. Ruppe wrote:
One advantage of the current design is you can statically
determine if something is an infinite range by seeing if empty
is a constant false.
That is important aspect! By having this information at compile
or runtime, you can enforce that algorithms which consume entire
range, and are expected to finish, would not accept this range as
an argument, for example saveToFile(randomNumbersRange).
I see two possible way to model this:
1) provide another property 'bool isInifinite'. This of course
causes dependency on empty property: when isInfinte is false,
empty also needs to be false. This can be complex to enforce.
2) instead of empty property, have state property, returning enum
{ empty, full, infinite }. This might complicate algorithms
implementation, and of course this enum could not be never
extended, since it would be breaking change. For example if
algorithm ask currently for !empty, it would ask for just state
== full, so it might not complicate many algorithms
Any more insights? :)
Re: Ranges - Question about desing choices
On Monday, 24 August 2015 at 15:23:09 UTC, H. S. Teoh wrote: It's also useful in parsing algorithms to look at the current item in the input without also consuming it. I design I outlined the 'front' property could still be called multiple times. It is the 'empty' property that would be merged into 'bool popFront'.
[Issue 14959] Regression in HEAD: linker error on printing SysTime with writeln
https://issues.dlang.org/show_bug.cgi?id=14959 --- Comment #1 from Jack Stouffer j...@jackstouffer.com --- Oops, should have been writeln(d1); --
Re: Casting double to ulong weirdness
On Monday 24 August 2015 18:52, wrote:
import std.stdio;
void main() {
double x = 1.2;
writeln(cast(ulong)(x * 10.0));
double y = 1.2 * 10.0;
writeln(cast(ulong)y);
}
Output:
11
12
to!ulong instead of the cast does the right thing, and is a
viable work-around.
Issue: https://issues.dlang.org/show_bug.cgi?id=14958)
1.2 is not representable exactly in binary. Try printing it with a lot of
decimal places:
writefln(%.20f, x); /* prints 1.19995559 */
Multiply that by 10: ~11.999; cast to ulong: 11.
Interestingly, printing x * 10.0 that way shows exactly 12:
writefln(%.20f, x * 10.0); /* 12. */
But cast one operand to real and you're back at 11.9...:
writefln(%.20f, cast(real)x * 10.0); /* 11.99955591 */
So, apparently, real precision is used in your code. This is not unexpected;
compilers are allowed to use higher precision than requested for floating
point operations. I think people have argued against it in the past, but so
far Walter has been adamant about it being the right choice.
Re: Casting double to ulong weirdness
On Monday, 24 August 2015 at 16:52:54 UTC, Márcio Martins wrote:
I'm posting this here for visibility. This was silently
corrupting our data, and might be doing the same for others as
well.
import std.stdio;
void main() {
double x = 1.2;
writeln(cast(ulong)(x * 10.0));
double y = 1.2 * 10.0;
writeln(cast(ulong)y);
}
Output:
11
12
to!ulong instead of the cast does the right thing, and is a
viable work-around.
Issue: https://issues.dlang.org/show_bug.cgi?id=14958)
I would not describe to!ulong as a work-around. You just
discovered one of the reasons to! exists: it is the right way to
do it and cast(ulong) is the wrong way. As the others have noted,
floating point is tricky business, and you need to use the right
tools for the job.
std.math.round also works.
Casting double to ulong weirdness
I'm posting this here for visibility. This was silently
corrupting our data, and might be doing the same for others as
well.
import std.stdio;
void main() {
double x = 1.2;
writeln(cast(ulong)(x * 10.0));
double y = 1.2 * 10.0;
writeln(cast(ulong)y);
}
Output:
11
12
to!ulong instead of the cast does the right thing, and is a
viable work-around.
Issue: https://issues.dlang.org/show_bug.cgi?id=14958)
Re: Ranges - Question about desing choices
Looking at the random access range, if the indexing must be done just by numeric value, or also by other type, like string (typically used for dictionaries) or also custom object?
Sub forum for dmd implementation details
As a occasional contributor to dmd I usually manage to get everything working the way I want by digging through the dmd source code long enough, but sometimes bad / non-existing documentation and missing knowdelge result in suboptimal solutions or unsolved problems. I would greatly appreciate a subforum which purpose it is to discuss compiler implementation details. I know that there is dmd-internals, but it seems that this forum only gets spammed by some bot with pull-request messages. Kind Regards Benjamin Thaut
Re: Ranges - Question about desing choices
On 8/24/15 11:09 AM, Michal Minich wrote:
I'm thinking about ranges I can think of similar design of the input
range, but with different pros and cons. Obviously not for/in D.
Currently ranges has 3 primitive operations, and they can be translated
from foreach like:
for (auto __r = range; !__r.empty; __r.popFront())
{
auto e = __r.front;
...
}
I'm thinking of design where range would have only 2 primitive operations:
bool popFront() // returns true if current will have an element
front// it may be called only if popFrount (would) have
returned true
foreach would be translated to:
while (auto r = r.popFront())
{
auto e = __r.front;
...
}
This design results in following differences
1) 2 primitive operations (empty and popFront) are merge into one less
primitive
2) it will result in less calls per item (2 instead for 3)
3) it is not possible to ask a range if it's empty more times per
iteration of one item
This isn't very composable. If I call a function that consumes some
number of items from a range, that function needs to forward the
information back to me of whether the range is now empty or not.
4) it does _not_ requires range to be in ready state immediately after
construction. That means that popFront needs to be called firstly,
before front can be. This I feel is biggest change. Since D ranges are
required to have front ready immediately after their construction. Which
for some non trivial ranges can seem as less effective/convenient/expected.
So on the flip side, ranges that *could* be ready as soon as they are
created, must store some state that says popFront hasn't yet been
called. I find this requirement to be a wash implementation-wise, and
actually a negative API wise, since you as the consumer of the range
must carry the burden of storing whether it was empty the last time
popFront was called.
I would challenge you to write a wrapper for an array slice (yes, you
would need a wrapper, not just simple UFCS functions) and see whether
you think it's still worth it.
-Steve
[Issue 14958] Casting a double to ulong sometimes produces wrong results
https://issues.dlang.org/show_bug.cgi?id=14958 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution|--- |INVALID --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com --- This is floating point, and D does all calculations at the highest precision possible (i.e. real). Please don't treat floating point as an exact representation of decimal numbers. https://en.wikipedia.org/wiki/Floating_point#Minimizing_the_effect_of_accuracy_problems --
Re: Ranges - Question about desing choices
On Monday, 24 August 2015 at 17:17:16 UTC, Steven Schveighoffer wrote: 3) it is not possible to ask a range if it's empty more times per iteration of one item This isn't very composable. If I call a function that consumes some number of items from a range, that function needs to forward the information back to me of whether the range is now empty or not. That is a very good point. Non-existence of 'empty' property would have negative impact on composability and convenience of use if range is shared between alogorithms (For example in a parser). As you say that information would need to be transferred in program using another means. I see this composability aspect as critical, and for me it alone makes 100% case for the existence of 'empty' property. 4) it does _not_ requires range to be in ready state immediately after construction. That means that popFront needs to be called firstly, before front can be. This I feel is biggest change. Since D ranges are required to have front ready immediately after their construction. Which for some non trivial ranges can seem as less effective/convenient/expected. So on the flip side, ranges that *could* be ready as soon as they are created, must store some state that says popFront hasn't yet been called. I find this requirement to be a wash implementation-wise, and actually a negative API wise, since you as the consumer of the range must carry the burden of storing whether it was empty the last time popFront was called. I would challenge you to write a wrapper for an array slice (yes, you would need a wrapper, not just simple UFCS functions) and see whether you think it's still worth it. -Steve Ok. What about this: there exactly the same 3 primitives as in D range, but popFront is requred to be called first, before calling front, or empty properties. Why current approach against this?
[Issue 14959] New: Regression in HEAD: linker error on printing SysTime with writeln
https://issues.dlang.org/show_bug.cgi?id=14959
Issue ID: 14959
Summary: Regression in HEAD: linker error on printing SysTime
with writeln
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: j...@jackstouffer.com
This works in DMD 2.068, but errors in git head of master
import std.stdio : written;
import std.datetime;
void main() {
auto d1 = Clock.currTime;
writeln(d2);
}
--
$ dmd test.d
Undefined symbols for architecture x86_64:
_D3std6format64__T14formatIntegralTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatIntegralFNaNbNfS3std5array17__T8AppenderTAyaZ8AppenderxmKxS3std6format18__T10FormatSpecTaZ10FormatSpeckmZv,
referenced from:
_D3std6format61__T11formatValueTS3std5array17__T8AppenderTAyaZ8AppenderThTaZ11formatValueFNaNfS3std5array17__T8AppenderTAyaZ8AppenderhKS3std6format18__T10FormatSpecTaZ10FormatSpecZv
in test.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--- errorlevel 1
--
Re: dmd codegen improvements
On Monday, 24 August 2015 at 15:36:42 UTC, ixid wrote: -snip- Yes, it requires someone to pick up the baton for what is clearly a very significant task. Your site is excellent and it's very unfortunate that D is absent. iirc I asked Peter Alexander about progress last December and he had successfully used the provided scripts without any difficulty. Someone has published a Python comparison website (even re-using the PHP scripts as-is!) without needing to ask me any questions at all -- http://pybenchmarks.org/ It just needs someone to pick up the baton and do it, instead of talking about doing it.
Re: Sub forum for dmd implementation details
On 8/24/15 1:00 PM, Benjamin Thaut wrote: As a occasional contributor to dmd I usually manage to get everything working the way I want by digging through the dmd source code long enough, but sometimes bad / non-existing documentation and missing knowdelge result in suboptimal solutions or unsolved problems. I would greatly appreciate a subforum which purpose it is to discuss compiler implementation details. I know that there is dmd-internals, but it seems that this forum only gets spammed by some bot with pull-request messages. Questions asked there do get answered. Most of the developers access it via a mailing list, and it's pretty easy to filter out the github messages from the real stuff. -Steve
Re: Casting double to ulong weirdness
On 8/24/15 12:52 PM, =?UTF-8?B?Ik3DoXJjaW8=?= Martins\
marcio...@gmail.com\ wrote:
I'm posting this here for visibility. This was silently corrupting our
data, and might be doing the same for others as well.
import std.stdio;
void main() {
double x = 1.2;
writeln(cast(ulong)(x * 10.0));
double y = 1.2 * 10.0;
writeln(cast(ulong)y);
}
Output:
11
12
Yes. This is part of the issue of floating point. 1.2 cannot be
represented accurately.
The second case is done via real, not double, and at compile time (i.e.
constant folding). There may be other reasons why this works.
You are better off adding a small epsilon:
writeln(cast(ulong)(x * 10.0 + 0.1));
to!ulong instead of the cast does the right thing, and is a viable
work-around.
to!ulong likely adds the epsilon, but you'd have to look to be sure.
Note, this is NOT a D problem, this is a problem with floating point.
And by problem, I mean feature-that-you-should-avoid :)
-Steve
Re: Casting double to ulong weirdness
On Monday, 24 August 2015 at 17:26:12 UTC, Steven Schveighoffer
wrote:
On 8/24/15 12:52 PM, =?UTF-8?B?Ik3DoXJjaW8=?= Martins\
marcio...@gmail.com\ wrote:
I'm posting this here for visibility. This was silently
corrupting our
data, and might be doing the same for others as well.
import std.stdio;
void main() {
double x = 1.2;
writeln(cast(ulong)(x * 10.0));
double y = 1.2 * 10.0;
writeln(cast(ulong)y);
}
Output:
11
12
Yes. This is part of the issue of floating point. 1.2 cannot be
represented accurately.
The second case is done via real, not double, and at compile
time (i.e. constant folding). There may be other reasons why
this works.
You are better off adding a small epsilon:
writeln(cast(ulong)(x * 10.0 + 0.1));
to!ulong instead of the cast does the right thing, and is a
viable
work-around.
to!ulong likely adds the epsilon, but you'd have to look to be
sure.
Note, this is NOT a D problem, this is a problem with floating
point. And by problem, I mean feature-that-you-should-avoid :)
-Steve
I am familiar with floating-point representations and their
pitfalls, and I think that is not the issue here.
The issue I am trying to illustrate is the fact that the same
exact operation returns different results.
Both operations are x * 10.0, except one of them passes through
the stack before the cast.
I would expect this to be consistent, as I believe is the case in
C/C++.
Re: Casting double to ulong weirdness
On Monday, 24 August 2015 at 17:26:12 UTC, Steven Schveighoffer
wrote:
Note, this is NOT a D problem, this is a problem with floating
ponit. And by problem, I mean feature-that-you-should-avoid :)
-Steve
Visual C++ 19.00.23026, x86, x64:
int _tmain(int argc, _TCHAR* argv[])
{
double x = 1.2;
printf(%d\r\n, (unsigned long long)(x * 10.0));
double y = 1.2 * 10.0;
printf(%d\r\n, ((unsigned long long)y));
return 0;
}
Output:
12
12
Same output in debugger for an ARM Windows App.
C# 6.0:
static void Main(string[] args)
{
double x = 1.2;
WriteLine((ulong)(x * 10.0));
double y = 1.2 * 10.0;
WriteLine((ulong)y);
}
Output:
12
12
Same output in debugger for ARM in all flavours (Android, iOS,
Windows)
It seems like a D problem.
Re: Casting double to ulong weirdness
BTW, 1.2 and 12.0 are directly representable as double In C++: printf(%.20f\r\n, 1.2); printf(%.20f\r\n, 12.0); will output: 1.2000 12. Either upcasting to real is the wrong decision here, either the writeln string conversion is wrong.
Re: Casting double to ulong weirdness
On Monday, 24 August 2015 at 18:16:44 UTC, Justin Whear wrote: On Mon, 24 Aug 2015 18:06:07 +, rumbu wrote: BTW, 1.2 and 12.0 are directly representable as double In C++: printf(%.20f\r\n, 1.2); printf(%.20f\r\n, 12.0); will output: 1.2000 12. Either upcasting to real is the wrong decision here, either the writeln string conversion is wrong. No it's not, this must be some sort of constant-folding or precision increase. Maybe the constant folding is using a different rounding mode to the runtime?
Re: most elegant functional way to make a histogram
On Monday, 24 August 2015 at 09:50:41 UTC, yawniek wrote: On Friday, 21 August 2015 at 21:08:25 UTC, Laeeth Isharc wrote: I guess this kind of thing will do: upRangeHighs.each!((ref a)=(++histogram[a][0])); int[] arr = [5,1,2,2,3,4,5,5,5]; int[int] histo; arr.each!( a = ++histo[a] ); writeln(histo); this works Thanks v much for suggestions, everyone. In the end I just went with something like the above.
Moving forward with work on the D language and foundation
Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. Facebook has impacted my career and life very positively, and I am grateful to have been a part of it for this long. The time has come for me, however, to fully focus on pushing D forward. As sorry I am for leaving a good and secure career behind, I am excited many times over about the great challenges and opportunities going forward. Next step with the D Language Foundation is a formal talk with the foundation's prospective attorney tomorrow. I hope to get the foundation in motion as soon as possible, though I'm told there are numerous steps to complete. I will keep this forum posted about progress. I'm also glad to announce that the D Language Foundation already has a donor - I have decided to contribute my books' royalties to it. I encourage others to respond in kind. Thanks, Andrei
Re: Casting double to ulong weirdness
On Mon, 24 Aug 2015 18:06:07 +, rumbu wrote:
BTW, 1.2 and 12.0 are directly representable as double
In C++:
printf(%.20f\r\n, 1.2);
printf(%.20f\r\n, 12.0);
will output:
1.2000 12.
Either upcasting to real is the wrong decision here, either the writeln
string conversion is wrong.
No it's not, this must be some sort of constant-folding or precision
increase.
$ cat test.c
#include stdio.h
int main(int nargs, char** args)
{
double x = 1.2;
printf(%.20f\n, x);
}
$ clang test.c ./a.out
1.19995559
Re: Casting double to ulong weirdness
On 08/24/2015 11:06 AM, rumbu wrote:
BTW, 1.2 and 12.0 are directly representable as double
12 is but 1.2 is not.
In C++:
printf(%.20f\r\n, 1.2);
printf(%.20f\r\n, 12.0);
will output:
1.2000
12.
Either upcasting to real is the wrong decision here, either the writeln
string conversion is wrong.
Output is one thing. The issue is with the representation of 1.2. You
need infinite digits. D's %a helps with visualizing it:
import std.stdio;
void main()
{
writefln(%a, 1.2);
writefln(%a, 12.0);
}
Outputs
0x1.3p+0
0x1.8p+3
Ali
Re: Casting double to ulong weirdness
On Monday, 24 August 2015 at 18:06:08 UTC, rumbu wrote: BTW, 1.2 and 12.0 are directly representable as double 12.0 is representable, but I'm pretty sure, if you work it out, 1.2 isn't.
Re: Casting double to ulong weirdness
On 8/24/15 2:06 PM, rumbu wrote:
BTW, 1.2 and 12.0 are directly representable as double
In C++:
printf(%.20f\r\n, 1.2);
printf(%.20f\r\n, 12.0);
will output:
1.2000
12.
Either upcasting to real is the wrong decision here, either the writeln
string conversion is wrong.
I don't think they are directly representable as floating point, because
they are have factors other than 2 in the decimal portion. From my
understanding, anything that only has to do with powers of 2 are
representable in floating point, just like you cannot represent 1/3 in
decimal exactly.
But there is definitely something weird going on with the casting.
I wrote this program:
testfp.d:
extern(C) void foo(double x);
void main() {
double x = 1.2;
foo(x);
}
testfp2.d:
extern(C) void foo(double x)
{
import std.stdio;
writeln(cast(ulong)(x * 10.0));
}
testfp2.c:
#include stdio.h
void foo(double x)
{
printf(%lld\n, (unsigned long long)(x * 10));
}
If I link testfp.d against testfp2.c, then it outputs 12. If I link
against testfp2.d, it outputs 11.
I have faith that printf and writeln properly output ulongs. Something
different happens with the cast. There can be no constant folding
operations or optimizations going on here, as this is done via separate
compilation. I'll re-open the bug report.
-Steve
Re: Moving forward with work on the D language and foundation
That is fricken' awesome. Interesting times ahead, for you, and for us as a community. On Mon, Aug 24, 2015 at 8:42 PM, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. Facebook has impacted my career and life very positively, and I am grateful to have been a part of it for this long. The time has come for me, however, to fully focus on pushing D forward. As sorry I am for leaving a good and secure career behind, I am excited many times over about the great challenges and opportunities going forward. Next step with the D Language Foundation is a formal talk with the foundation's prospective attorney tomorrow. I hope to get the foundation in motion as soon as possible, though I'm told there are numerous steps to complete. I will keep this forum posted about progress. I'm also glad to announce that the D Language Foundation already has a donor - I have decided to contribute my books' royalties to it. I encourage others to respond in kind. Thanks, Andrei
Re: Casting double to ulong weirdness
On 8/24/15 2:38 PM, Steven Schveighoffer wrote:
On 8/24/15 2:06 PM, rumbu wrote:
BTW, 1.2 and 12.0 are directly representable as double
In C++:
printf(%.20f\r\n, 1.2);
printf(%.20f\r\n, 12.0);
will output:
1.2000
12.
Either upcasting to real is the wrong decision here, either the writeln
string conversion is wrong.
I don't think they are directly representable as floating point, because
they are have factors other than 2 in the decimal portion. From my
understanding, anything that only has to do with powers of 2 are
representable in floating point, just like you cannot represent 1/3 in
decimal exactly.
But there is definitely something weird going on with the casting.
I wrote this program:
testfp.d:
extern(C) void foo(double x);
void main() {
double x = 1.2;
foo(x);
}
testfp2.d:
extern(C) void foo(double x)
{
import std.stdio;
writeln(cast(ulong)(x * 10.0));
}
testfp2.c:
#include stdio.h
void foo(double x)
{
printf(%lld\n, (unsigned long long)(x * 10));
}
If I link testfp.d against testfp2.c, then it outputs 12. If I link
against testfp2.d, it outputs 11.
More data:
It definitely has something to do with the representation of 1.2 * 10.0
in *real*.
I changed the code so that it writes the result of the multiplication to
a shared double.
In this case it *works* and prints 12, just like C does.
This also works:
double x = 1.2;
double y = x * 10.0;
writeln(cast(ulong)y); // 12
However, change y to a real, and you get 11.
Note that if I first convert from real to double, then convert to ulong,
it works.
This code:
double x = 1.2;
double x2 = x * 10.0;
real y = x * 10.0;
real y2 = x2;
double y3 = y;
writefln(%a, %a, %a, y, y2, cast(real)y3);
outputs:
0xb.ep+0, 0xcp+0, 0xcp+0
So some rounding happens in the conversion from real to double, that
doesn't happen in the conversion from real to ulong.
All this gets down to: FP cannot accurately represent decimal. Should
this be fixed? Can it be fixed? I don't know. But I would be very
cautious about converting anything FP to integers without some epsilon.
-Steve
[Issue 14958] Casting a double to ulong sometimes produces wrong results
https://issues.dlang.org/show_bug.cgi?id=14958
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #2 from Steven Schveighoffer schvei...@yahoo.com ---
I'm not sure whether this is a bug or not, but the behavior comes down to the
conversion from real to double vs. to ulong.
This code can demonstrate:
import std.stdio;
void main() {
double x = 1.2;
double x2 = x * 10.0;
real y = x * 10.0;
real y2 = x2;
double y3 = y;
writefln(%a, %a, %a, y, y2, cast(real)y3);
}
This outputs:
0xb.ep+0, 0xcp+0, 0xcp+0
Showing that in real representation, the number is not exact, but when
converted to double, it does represent what is asked for. However, we know that
the conversion definitely is rounding somehow because the original number isn't
precise.
--
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. [...] Respect. Joseph
Re: Casting double to ulong weirdness
On Monday, 24 August 2015 at 18:59:58 UTC, Steven Schveighoffer wrote: All this gets down to: FP cannot accurately represent decimal. Should this be fixed? Can it be fixed? I don't know. But I would be very cautious about converting anything FP to integers without some epsilon. -Steve I don't see anything that needs to be fixed, because I don't think anything is broken - there is nothing that violates my understanding of floating point precision in D. cast is not round. What is broken is a program that attempts to convert a double to an integer type using a cast rather than the functions that were written to do it correctly.
Re: Casting double to ulong weirdness
On Mon, Aug 24, 2015 at 07:15:43PM +, bachmeier via Digitalmars-d wrote: On Monday, 24 August 2015 at 18:59:58 UTC, Steven Schveighoffer wrote: All this gets down to: FP cannot accurately represent decimal. Should this be fixed? Can it be fixed? I don't know. But I would be very cautious about converting anything FP to integers without some epsilon. -Steve I don't see anything that needs to be fixed, because I don't think anything is broken - there is nothing that violates my understanding of floating point precision in D. cast is not round. What is broken is a program that attempts to convert a double to an integer type using a cast rather than the functions that were written to do it correctly. +1. Floating-point != mathematical real numbers. Don't expect it to behave the same. T -- It's amazing how careful choice of punctuation can leave you hanging:
A better way than foreach with this?
auto names = Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split; foreach (ref name; names) name = replace(name, _, );
Re: A better way than foreach with this?
try: auto names1 = names.map!( a = replace(a, _, )); ...not sure how to do it in-place though. Joel wrote: auto names = Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split; foreach (ref name; names) name = replace(name, _, );
Re: Ruby 3.0 to have immutable strings by default / C++ heading towards generic all the time.
On Monday, 24 August 2015 at 06:17:06 UTC, Jacob Carlborg wrote: On 2015-08-21 23:55, Walter Bright wrote: I don't understand why the C++ committee, in its quest to improve the language, has not pushed forward with proper replacements for typical preprocessor uses, with the intent of eventually deprecating it entirely. With modules being already implemented in Clang, is there a legitimate use case for the preprocessor left? I use it all the time for handling log messages and throwing exceptions. Without that, you can't get stuff like the current file and line number, because C++ isn't smart enough to use the call point for __FILE__ and __LINE__. So, you either use macros so that the code _is_ at the call point, or you have to do it manually, and no one is going to do that sort of thing manually. I'm sure that there are other use cases, but those are the ones that I use all the time. Also, in my experience, getting static or global variables to work with dlls when you need them is hell, so it pretty much inevitably comes down to either using a macro or making it a function with a static variable inside it which it returns. I usually go with the useless function, but the macro sure seems tempting sometimes. To really replace macros - especially in a language that's already using them - you pretty much have to replace every use case for them, and I really don't see that happening to C++. Also, getting rid of macros would break C compatibility, which they won't do. Even if they add better alternatives to the language and recommend that you use those instead, they'll still support macros because of C. - Jonathan M Davis
Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Wow! I'll spread the Word!
Re: Ruby 3.0 to have immutable strings by default / C++ heading towards generic all the time.
On 2015-08-24 08:35, rsw0x wrote: implement this in D https://github.com/solodon4/Mach7 It's just a matter of syntax. -- /Jacob Carlborg
Re: DWT fails to build with DMD 2.068.0
On Tuesday, 11 August 2015 at 21:03:23 UTC, Jacob Carlborg wrote: On 2015-08-11 10:23, Mike James wrote: Is there an updated release for DWT - it fails to build with the latest version of DMD - mainly casting errors... There's an open pull request for adding support for 2.068.0. I'll take a look at it as soon as possible. Bump! :-)
Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Congratulations!
front-page examples not working
I love the new examples on the front-page, but when I click the run button, I get this error: /d982/f573.d(32): Error: undefined identifier centerJustifier I got a different error on one of the other new examples yesterday. Please make sure these work. They are a great showcase of the language.
Re: front-page examples not working
On Monday, 24 August 2015 at 07:27:29 UTC, Øivind wrote: I love the new examples on the front-page, but when I click the run button, I get this error: /d982/f573.d(32): Error: undefined identifier centerJustifier I got a different error on one of the other new examples yesterday. Please make sure these work. They are a great showcase of the language. It's because it uses DPaste to run and DPaste compiler is seriously outdated. (same problem for a user using 2.066.1 http://forum.dlang.org/post/aqoyjlykqywjkvxde...@forum.dlang.org) DPaste is at 2.065 see also: http://forum.dlang.org/thread/mr5da0$1djk$1...@digitalmars.com
Re: A better way than foreach with this?
On 2015-08-24 07:58, Joel wrote: auto names = Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split; foreach (ref name; names) name = replace(name, _, ); Why not call the replace function directly on names? -- /Jacob Carlborg
Re: (De)Serializing interfaces
On 2015-08-22 21:14, nims wrote: Using Orange all I got was a lot of compiler errors. Seems I completely overlooked interfaces. I'll see if I can add support for them. -- /Jacob Carlborg
Re: Ruby 3.0 to have immutable strings by default / C++ heading towards generic all the time.
On 2015-08-21 23:55, Walter Bright wrote: I don't understand why the C++ committee, in its quest to improve the language, has not pushed forward with proper replacements for typical preprocessor uses, with the intent of eventually deprecating it entirely. With modules being already implemented in Clang, is there a legitimate use case for the preprocessor left? -- /Jacob Carlborg
Re: D-Day for DMD is today!
On 23-Aug-2015 08:17, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Many, many thanks to Daniel Murphy for slaving away for 2.5 years to make this happen. More thanks to Martin Nowak for helping shepherd it through the final stages, and to several others who have pitched in on this. This is a HUGE milestone for us. Much work remains to be done, such as rebasing existing dmd pull requests. Thanks in advance for the submitters who'll be doing that. I hope you aren't too unhappy about the extra work - it's in a good cause! Congratulations! Looks like my last excuse for not hacking on DMD evaporated.. Ouch ;) -- Dmitry Olshansky
Re: std.data.json formal review
On 2015-08-21 18:25, Nick Sabalausky wrote: Module boundaries should be determined by organizational grouping, not by size. Well, but it depends on how you decide what should be in a group. Size is usually a part of that decision, although it might not be conscious. You wouldn't but the whole D compiler on one module ;) -- /Jacob Carlborg
Re: Ruby 3.0 to have immutable strings by default / C++ heading towards generic all the time.
On 24-Aug-2015 09:17, Jacob Carlborg wrote: On 2015-08-21 23:55, Walter Bright wrote: I don't understand why the C++ committee, in its quest to improve the language, has not pushed forward with proper replacements for typical preprocessor uses, with the intent of eventually deprecating it entirely. With modules being already implemented in Clang, is there a legitimate use case for the preprocessor left? Code generation and crude meta-programming. -- Dmitry Olshansky
Re: Trying to compile weather program
On Sun, 23 Aug 2015 16:00:16 +, Tony wrote: Thanks for the replies. It compiles OK with just. However, it isn't linking: /usr/bin/ld: cannot find -lcurl I do have some versions of libcurl on my system: /usr/lib/x86_64-linux-gnu/libcurl.so.3 /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0 /usr/lib/x86_64-linux-gnu/libcurl.so.4 I see there is a -L option to pass things to the linker -Llinkerflag pass linkerflag to link but I am not sure how to use it. I've had the same problem recently. What I did was that I ran `dmd main.d -L-L/usr/lib/x86_64-linux-gnu/ -L-lcurl -v`. It would still fail to link, but I can find the linking command from the verbose output. It was something like this: `gcc main.o -o main -m64 -L/usr/lib/x86_64-linux- gnu/ -lcurl -L/usr/lib/x86_64-linux-gnu -Xlinker --export-dynamic - l:libphobos2.a -lpthread -lm -lrt`. As you can see, -lcurl is there, but it still needs to be added again after -l:libphobos2.a. So just add it again so the command becomes: `gcc main.o -o main -m64 -L/usr/lib/x86_64-linux-gnu/ -lcurl -L/usr/lib/ x86_64-linux-gnu -Xlinker --export-dynamic -l:libphobos2.a -lpthread -lm - lrt -lcurl`. And it links and runs.
Re: Object.factory() and exe file size bloat
On 2015-08-21 22:26, Walter Bright wrote: The principle often used by languages (C, C++, Rust) is you only pay for what you use. With Object.factory, every program pays for it with every class, despite very few actual uses of it. A always thought of D as a bit more convenient language. Variables are automatically initialized, virtual by default, minimal reflation functionality, i.e. Object.factory. Although, all of these can be avoided except for Object.factory. -- /Jacob Carlborg
Re: Ruby 3.0 to have immutable strings by default / C++ heading towards generic all the time.
On 8/23/2015 11:40 PM, Jonathan M Davis wrote: To really replace macros - especially in a language that's already using them - you pretty much have to replace every use case for them, and I really don't see that happening to C++. Also, getting rid of macros would break C compatibility, which they won't do. Even if they add better alternatives to the language and recommend that you use those instead, they'll still support macros because of C. C++ continues to support old, bad practices while relentlessly advocating other techniques as best practices. So far, I have not seen that w.r.t. the preprocessor.
Re: A better way than foreach with this?
On Monday, 24 August 2015 at 06:13:50 UTC, Jacob Carlborg wrote: On 2015-08-24 07:58, Joel wrote: auto names = Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split; foreach (ref name; names) name = replace(name, _, ); Why not call the replace function directly on names? They would split wrong.
Re: D-Day for DMD is today!
On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/4923 We have made the switch from C++ DMD to D DMD! Worth mentioning: The final call to dmd that compiles 117 klines (~80 files) of D code in one show and links dmd takes 1.1 seconds on my laptop. Pretty darn cool. Thank you!
[Issue 14954] New: extern opaque struct instance doesn't compile
https://issues.dlang.org/show_bug.cgi?id=14954 Issue ID: 14954 Summary: extern opaque struct instance doesn't compile Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com Let's say I have some C headers that have code like this in: extern struct UndeclaredStruct blah; UndeclaredStruct *p = blah; which would naïvely translate to D as: struct UndeclaredStruct; extern(C) __gshared extern UndeclaredStruct blah; __gshared auto p = blah; which doesn't compile: Error: variable opaque.blah no definition of struct UndeclaredStruct --
Re: extern opaque struct
On Monday, 24 August 2015 at 04:08:28 UTC, Daniel Murphy wrote: John Colvin wrote in message news:uhpgjffttsuqeswyj...@forum.dlang.org... Let's say I have some C headers that have code like this in: extern struct UndeclaredStruct blah; Undeclared *p = blah; which would naïvely translate to D as: struct UndeclaredStruct; extern UndeclaredStruct blah; auto p = blah; which doesn't compile. Why not? Neither the size nor any default initialiser is needed. It should work, please file in bugzilla. done: https://issues.dlang.org/show_bug.cgi?id=14954
Re: Digger 2.3 verstr.h problem
On Monday, 24 August 2015 at 09:13:56 UTC, Robert M. Münch wrote: On 2015-08-23 16:23:57 +, John Colvin said: almost certainly a consequence of the recent switchover to the dmd frontend being written in D. Have you tried building the latest Digger git HEAD first? If that doesn't work I suggest reporting it here for Vladimir (CyberShadow) to look at: https://github.com/CyberShadow/Digger/issues/new Yes, and get this: mac-pro:Digger robby$ rdmd --build-only digger digger.d(36): Error: no property 'additionalComponents' for type 'ae.sys.d.manager.DManager' Failed: [dmd, -v, -o-, digger.d, -I.] So, I downloaded the binary... Maybe I somehow screwed up my setup? But can't imagine how and why... Is this from a clean clone of Digger, either with --recursive or having done git submodule update --init ? What version of DMD are you using to build it?
Re: Ruby 3.0 to have immutable strings by default / C++ heading towards generic all the time.
On Monday, 24 August 2015 at 06:17:06 UTC, Jacob Carlborg wrote: On 2015-08-21 23:55, Walter Bright wrote: I don't understand why the C++ committee, in its quest to improve the language, has not pushed forward with proper replacements for typical preprocessor uses, with the intent of eventually deprecating it entirely. With modules being already implemented in Clang, is there a legitimate use case for the preprocessor left? implement this in D https://github.com/solodon4/Mach7
Re: Object.factory() and exe file size bloat
On 2015-08-21 07:06, Walter Bright wrote: This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it. This leads to bloat: https://issues.dlang.org/show_bug.cgi?id=14758 and sometimes the bloat can be overwhelming. The solution seems straightforward - only have Object.factory be able to instantiate classes marked as 'export'. This only makes sense anyway. If we're actually going to talk about solution then it seems better to have a flag that disables Object.factory. It won't break any code and everyone that doesn't like can disable it. Everybody wins. -- /Jacob Carlborg
Re: A better way than foreach with this?
On Monday, 24 August 2015 at 06:17:02 UTC, ted wrote: try: auto names1 = names.map!( a = replace(a, _, )); ...not sure how to do it in-place though. Joel wrote: auto names = Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split; foreach (ref name; names) name = replace(name, _, ); Thanks, worked it out, (though has 'array'): names = names.map!( a = replace(a, _, )).array;
[Issue 14953] New: std.concurrency: Add function to flush message box
https://issues.dlang.org/show_bug.cgi?id=14953
Issue ID: 14953
Summary: std.concurrency: Add function to flush message box
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: wend...@tcd.ie
This enhancement request was inspired by this thread:
http://forum.dlang.org/post/yavfidlhfohqfziqv...@forum.dlang.org
The scenario:
A thread has several items in the message box, and the user wants to cancel not
just the current operation but flush the thread's message box, since the items
in the message box are no longer relevant.
The current behavior is that the thread insists on processing all items in the
message box. To suppress the thread from doing actual work, John Colvin
proposed this workaround:
void flushMailbox()
{
bool r;
do
{
r = receiveTimeout(Duration.zero, (Variant _){});
} while(r);
}
In this way, the thread loops over each item in the message box, but does
nothing - until the message box is empty.
However, it would be more efficient to have a library function that empties the
message box immediately, instead of looping over the message box, cancelling
each item individually, before new input can be processed.
--
Re: flush MessageBox
On Friday, 21 August 2015 at 17:05:56 UTC, John Colvin wrote: On Friday, 21 August 2015 at 14:35:53 UTC, Chris wrote: On Friday, 21 August 2015 at 12:59:09 UTC, John Colvin wrote: [...] Wouldn't it be easier to have a library function that can empty the mailbox immediately? It's a waste of time to have all items in the mailbox crash against a wall, before you can go on as in [ item1 // cancel item2 === do nothing return; item3 === do nothing return; ] In parts I find std.concurrency lacking. Simple things sometimes need workarounds. yes, it would be better. Please file an enhancement request: https://issues.dlang.org Done. https://issues.dlang.org/show_bug.cgi?id=14953
Re: most elegant functional way to make a histogram
On Friday, 21 August 2015 at 21:08:25 UTC, Laeeth Isharc wrote: I guess this kind of thing will do: upRangeHighs.each!((ref a)=(++histogram[a][0])); int[] arr = [5,1,2,2,3,4,5,5,5]; int[int] histo; arr.each!( a = ++histo[a] ); writeln(histo); this works
Re: [OT] Sharp Regrets: Top 10 Worst C# Features
On Friday, 21 August 2015 at 19:58:04 UTC, Tobias Müller wrote: Chris wend...@tcd.ie wrote: [...] As if most people were too stpid to grasp the concept that `x++` is the same as `x += 1` (which is intellectually as 'challenging' as `x++`, by the way). Because it's not. ++x is the same as x+=1, not x++. Tobi This distinction is only relevant if there are two variables involved (i.e. assignment): `y = x++;` where `y = ++x;` does in fact yield a different result (most likely the desired one). If you work on the same variable, `x++;` is fine. Thus, I don't agree with Python's philosophy.
Re: dmd codegen improvements
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote: Martin ran some benchmarks recently that showed that ddmd compiled with dmd was about 30% slower than when compiled with gdc/ldc. This seems to be fairly typical. I'm interested in ways to reduce that gap. One of D's potential massive wins is speed and I think that has the most easily conveyed impacted on the audience. If we had the best benchmark site for a very large range of languages it would not only draw people here but drive the improvement of D on all compilers (and perhaps allow us to make LDC/GCD for run speed, DMD for compile speed more explicit) as every time there is a benchmark contest we seem to find some small thing that needs a fix and then D blows others away. This would also convey more idiomatic D for performance as D seems to suffer from people writing it as whatever language they come from. People love competitions, the current benchmark site that seems to weirdly dislike D is one of people's go to references. I do not have the ability to do this but it would seem like an excellent project for someone outside the major development group, a Summer of Code-esque thing.
Re: Digger 2.3 verstr.h problem
On 2015-08-23 16:23:57 +, John Colvin said: almost certainly a consequence of the recent switchover to the dmd frontend being written in D. Have you tried building the latest Digger git HEAD first? If that doesn't work I suggest reporting it here for Vladimir (CyberShadow) to look at: https://github.com/CyberShadow/Digger/issues/new Yes, and get this: mac-pro:Digger robby$ rdmd --build-only digger digger.d(36): Error: no property 'additionalComponents' for type 'ae.sys.d.manager.DManager' Failed: [dmd, -v, -o-, digger.d, -I.] So, I downloaded the binary... Maybe I somehow screwed up my setup? But can't imagine how and why... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: (De)Serializing interfaces
On Monday, 24 August 2015 at 09:26:40 UTC, Edwin van Leeuwen wrote: On Saturday, 22 August 2015 at 19:14:16 UTC, nims wrote: Painlessjson indeed does not support interfaces/subclasses at the moment. There was some discussion about it here: https://github.com/BlackEdder/painlessjson/issues/8 , but we haven't really thought of a good way of doing it yet. Pull requests are welcome of course :)
Re: (De)Serializing interfaces
On Saturday, 22 August 2015 at 19:14:16 UTC, nims wrote: I think interfaces are very powerful and I heavily use them. The only problem I have with them is that serializing/deserializing them to XML or JSON doesn't seem to work. So far I got to try Orange and painlessjson. Using Orange all I got was a lot of compiler errors. Painlessjson did compile normally but just ignores all interface class members. Painlessjson indeed does not support interfaces/subclasses at the moment. There was some discussion about it here: https://github.com/BlackEdder/painlessjson/issues/8 , but we haven't really thought of a good way of doing it yet. There is also: http://code.dlang.org/packages/jsonizer which I think should support at least subclasses, not sure about intefaces.
Re: Ruby 3.0 to have immutable strings by default / C++ heading towards generic all the time.
On Thursday, 20 August 2015 at 22:07:10 UTC, John Carter wrote: https://twitter.com/yukihiro_matz/status/634386185507311616 Pity that concepts looks to be a very painful syntax for expressing what D does so clearly. One big difference is that C++1z concepts are supposed to allow looking for external functions, not only methods. That would require some kind of principled hijacking of templates in Dlang (or else the constraint template would keep looking for the functions, called by ufcs, either inside the type of in the templates declaration position). I haven't managed to work that out yet except by using mixins :/
Re: Digger 2.3 verstr.h problem
On 2015-08-23 20:13:38 +, Vladimir Panteleev said: Not really sure what's going on there... If I could reproduce it, I'd try building DMD manually - if it still occurred, build DMD 2.067.1 from source and add debugging printfs to see why it's not finding verstr.h. I'm not building 2.067.1 I try to build HEAD and digger uses 2.067.1 for this. Might this be a cause? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: D-Day for DMD is today!
Good news indeed! Well done everybody!
Blog post : OOP composition with mixins
Rough summary of the talk I have given for recent Berlin D meetup event: https://blog.dicebot.lv/posts/2015/08/OOP_composition_with_mixins
Re: Digger 2.3 verstr.h problem
On 2015-08-24 11:01:47 +, John Colvin said: Is this from a clean clone of Digger, either with --recursive or having done git submodule update --init ? What version of DMD are you using to build it? Hi, no it was not. Doing a git submodule update --init fixed this problem. After this, the import path problem still exists. Thanks for this tip. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
[Issue 14923] [REG2.067] ICE: Assertion failed: (tret-ty != Tvoid), function semantic3, file func.c, line 1736.
https://issues.dlang.org/show_bug.cgi?id=14923 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/bdd7d5bf7b5dd148ab0dd0087b2754b0b6867ce7 fix Issue 14923 - ICE: Assertion failed: (tret-ty != Tvoid), function semantic3, file func.c, line 1736. https://github.com/D-Programming-Language/dmd/commit/d780e3114333c17056e78f982012f37ca141e958 Merge pull request #4949 from 9rnsr/fix14923 [REG2.067] Issue 14923 - ICE: Assertion failed: (tret-ty != Tvoid), function semantic3, file func.c, line 1736. --
[Issue 14923] [REG2.067] ICE: Assertion failed: (tret-ty != Tvoid), function semantic3, file func.c, line 1736.
https://issues.dlang.org/show_bug.cgi?id=14923 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
