Re: std.parallelism equivalents for posix fork and multi-machine processing
On Friday, 15 May 2015 at 00:07:15 UTC, Laeeth Isharc wrote: But why would one use python when fork itself isn't hard to use in a narrow sense, and neither is the kind of interprocess communication I would like to do for the kind of tasks I have in mind. It just seems to make sense to have a light wrapper. The managing process doesn't have to be fast, but should be easy to reconfigure. It is overall more effective (not efficient) to use a scripting language with a REPL for scripty tasks. Forking comes with its own set of pitfalls. The unix-way is to have a conglomerate of simple processes tied together with a script. Overall easier to debug and modify. Just because some problems in parallel processing are hard doesn't seem to me a reason not to do some work on addressing the easier ones that may in a practical sense have great value in having an imperfect (but real) solution for. Sometimes I have the sense when talking with you that the answer to any question is anything but D! ;) (But I am sure I must be mistaken!) I would have said the same thing about Rust and Nim too. Overall, what other people do with a tool affects the eco system and maturity. If you do system level programming you are less affected by the eco system then when you do higher level task-oriented programming. What is your mission, to solve a problem effectively now or to start building a new framework with a time horizon measured in years? You have to decide this first. Then you have to decide what is more expensive, your time or spending twice as much on CPU power (whether it is hardware or rented time at a datacenter). True. But we are not speaking of getting from a raw state to perfection but just starting to play with the problem. If Walter Bright had listened to well-intentioned advice, he wouldn't be in the compiler business, let alone have given us what became D. He set out to build a new framework with a time horizon measured in decades. That's perfectly reasonable and what you have to expect when starting on a new language. If you want to build a framework for a specific use you need both the theoretical insights and the pragmatical experience in order to complete it in a timely manner. You need many many iterations to get to a state where it is better (than whatever people use today). Which is why most (sensible) engineers will pick existing solutions that are receiving polish, rather than the next big thing. Yes, indeed. But my question was more about the distinctions between processes and threads and the non-obvious implications for the design of such a framework. If you want to use fork(), you might as well use threads, the main distinction is that with processes you have to be explicit about what resources to share, but after a fork() you also risk ending up in an inconsistent state if you aren't careful. With a fork based solution you still need to deal with a different level of complexity than you get with a Unixy conglomerate of simple programs that cooperate, the Unix way is easier to debug and test, but slower than an optimized multi threaded solution (and marginally slower than a process that fork itself).
Re: std.allocator: nomenclature needed
On 2015-05-15 05:27, Andrei Alexandrescu wrote: Ready for yet another name debate? Here's an opportunity! I just added: http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d It's very useful, but it seems the name doesn't do it justice. ScopedAllocator? -- /Jacob Carlborg
[Issue 13270] ddoc can't find parameters of ditto'd function overloads
https://issues.dlang.org/show_bug.cgi?id=13270 --- Comment #9 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/63644c09847007807087eeaad85cc9fddcc27c11 Merge pull request #4642 from 9rnsr/refactor_doc Some preparation changes and refactoring for issue 13270 --
Re: Feature or bug: print braces
On Thursday, 14 May 2015 at 00:29:06 UTC, Dennis Ritchie wrote:
Why doesn't the compiler produces an error?
-
import std.stdio;
void main() {
writeln({});
}
-
http://ideone.com/qTZCAd
Somehow reminds me of this lambda:
https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d#L127-L128
Re: Linking to Dynamic Library on Mac OS X
On Friday, 15 May 2015 at 03:33:47 UTC, TJB wrote: I have built a toy dynamic shared library on Mac OS X (in C), and I have verified that it works from C. Now I would like to call it from D. So I have created the following interface file: $ cat hello.di extern (C): void printHelloWorld(); which I try to compile and run. But I get the following error: $ dmd main.d -L-lhello ld: library not found for -lhello clang: error: linker command failed with exit code 1 (use -v to see invocation) --- errorlevel 1 I gather that mac os x doesn't know where to find libhello.dylib (it is in the current directory). So how do I pass that information? Thanks! TJB Off the top of my head: does adding -L-L$(pwd) help?
Re: How to simulate a new type
On Friday, 15 May 2015 at 06:11:41 UTC, Charles Hixson wrote: On 05/14/2015 06:38 PM, Adam D. Ruppe via Digitalmars-d-learn wrote: On Friday, 15 May 2015 at 01:03:32 UTC, Charles Hixson wrote: Yes, that looks as if it would do the job, but what are its advantages over a simple struct? None really, except perhaps automatic forwarding of operators which is easy enough to do on a struct too (and with a struct, you can do only the ones that actually make sense for you). Typedef has a few major disadvantages too - surprising behavior if you forget the second parameter, for example. The library typedef should really be removed. Thank you. I was hoping that struct was a good approach, I've just never seen anyone recommending it, so I wanted to check. FWIW, I've seen a lot of user-defined types made with structs in the code of C-ported libs, and was sure that is a common approach.
Re: What wrong?
On Saturday, 2 May 2015 at 02:51:52 UTC, Fyodor Ustinov wrote: Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ What I'm doing wrong? Try using class instead of struct. Last time I played with std.concurrency it used Variants to store the messages, so when something bigger than a little basic value or a reference, like a class object, is sent it behaves unpredictably: can crash or shit garbage. Trying to send structs larger than ~20 bytes usually caused problems.
Re: Let's improve D's exceptions
On 2015-05-14 14:33, Adam D. Ruppe wrote: I think hierarchies will get better too if there were more incentive to use them - data members instead of string concat encourages new classes and you want to inherit from something So why isn't data members used more, because of the boilerplate to create a new subcalss? -- /Jacob Carlborg
Re: What wrong?
On Friday, 15 May 2015 at 07:51:29 UTC, thedeemon wrote: On Saturday, 2 May 2015 at 02:51:52 UTC, Fyodor Ustinov wrote: Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ What I'm doing wrong? Try using class instead of struct. Last time I played with std.concurrency it used Variants to store the messages, so when something bigger than a little basic value or a reference, like a class object, is sent it behaves unpredictably: can crash or shit garbage. Trying to send structs larger than ~20 bytes usually caused problems. Please raise a bugzilla issue for this.
[Issue 12423] extern(Windows) interfaces with -m64 broken
https://issues.dlang.org/show_bug.cgi?id=12423 John Chapman johnch_a...@hotmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from John Chapman johnch_a...@hotmail.com --- This appears to be fixed in 2.067. --
Re: D casually mentioned and dismissed + a suggestion
On Thursday, 14 May 2015 at 23:04:55 UTC, Ali Çehreli wrote: On 05/14/2015 03:20 PM, Dragos Carp wrote: Dragos [1] http://funkwerk-itk.com/funkwerk_itk_de/imagepool/jobs/SoftwareEntwickler.pdf Added: http://wiki.dlang.org/Jobs Ali If this ain't good PR for D, I don't know what is: http://funkwerk-itk.com/funkwerk_itk_en/news/artikel/2014_09_12_Auftrag_Norwegen_E.php
Re: std.allocator: nomenclature needed
On Friday, 15 May 2015 at 03:27:15 UTC, Andrei Alexandrescu wrote: Ready for yet another name debate? Here's an opportunity! I just added: http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d BulkDeallocator FlushDeallocator Also, I need two more good names: one for what's now called porcelain - high-level typed interface for allocators, and one for best of Beatles (not defined yet) - a module collecting a number of canned good allocator designs by connecting together components. std.allocator.bestof std.allocator.recipes std.allocator.cots std.allocator.premade std.allocator.prefab Thanks, Andrei
Re: Array of objects and their inheritance
Thank you for the explanation
Re: How to simulate a new type
On 05/14/2015 06:38 PM, Adam D. Ruppe via Digitalmars-d-learn wrote: On Friday, 15 May 2015 at 01:03:32 UTC, Charles Hixson wrote: Yes, that looks as if it would do the job, but what are its advantages over a simple struct? None really, except perhaps automatic forwarding of operators which is easy enough to do on a struct too (and with a struct, you can do only the ones that actually make sense for you). Typedef has a few major disadvantages too - surprising behavior if you forget the second parameter, for example. The library typedef should really be removed. Thank you. I was hoping that struct was a good approach, I've just never seen anyone recommending it, so I wanted to check.
Re: Let's improve D's exceptions
On 2015-05-14 14:41, Adam D. Ruppe wrote: Is it really? My thought of enforce was it iwas just a lazy way to throw on cases like file not found... Yeah, that's what I thought too. The documentation doesn't mention anything about this. -- /Jacob Carlborg
Destructured Tuple Assignment
I recall having seen an example of using some D magic (via mixin perhaps?) to realize tuple destructuring in assignments like magic(first, _, second) = expression.findSplit(separator); somewhere. But I can't seem to find it right now. References anyone? BTW :I'm aware of Kenjis PR, which I am very much longing for ;)
Re: Destructured Tuple Assignment
import std.algorithm;
template magicassign(A...) {
void magicassign(B)(B b) @property {
foreach(I, ref a; A)
static if (!is(typeof(A[I]):typeof(null)))
a = b[I];
}
}
template let(string D) {
mixin({
enum sdsl = D.findSplit(=);
mixin(`struct S { int `~sdsl[0]~`; }`);
string code = `auto v = ` ~ sdsl[2] ~ `;`;
foreach (I, _; typeof(S.tupleof))
code ~= `auto ` ~ S.tupleof[I].stringof ~ ` = v[`~I.stringof~`]; `;
return code;
}());
}
void main(string[] args) {
import std.stdio;
string a, b;
magicassign!(a, null, b) = args[1].findSplit(-);
writeln(a);
writeln(b);
mixin let!q{ c, _, d = args[1].findSplit(-) };
writeln(c);
writeln(d);
}
artur
[Issue 14585] New: destructor called on garbage in std.variant
https://issues.dlang.org/show_bug.cgi?id=14585
Issue ID: 14585
Summary: destructor called on garbage in std.variant
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
Originally found by Fyodor Ustinov who posted to digitalmars.D.learn and
digitalmars.D:
http://forum.dlang.org/post/nobzbhpqsbzutljej...@forum.dlang.org
http://forum.dlang.org/post/oqjnjvchzatzkaboe...@forum.dlang.org
Pull request on the way.
import std.stdio;
import std.variant: Variant;
struct S
{
int x = 42;
~this()
{
writeln(x: , x);
assert(x == 42);
}
}
void main()
{
Variant(S()).get!S;
}
Output (truncated):
x: 42
x: 42
x: 42
x: 7017840
x: 42
core.exception.AssertError@test4.d(10): Assertion failure
--
Re: Destructured Tuple Assignment
On Friday, 15 May 2015 at 11:04:24 UTC, Per Nordlöw wrote:
I'm guessing the closest thing we can get in current D version
is something like
let(q{first, _, second},
expression.findSplit(separator));
right?
Correction: I believe it must look like
let!q{first, _, second}(expression.findSplit(separator));
or
let!`first, _, second`(expression.findSplit(separator));
Is it possible to define a let that does what I want here?
If so, could someone, pleeeze, help me write out a stub for this?
I'm guessing something along the lines of
mixin template let(string vars, Ts...)
{
import std.range: splitter;
// declare variables in current scope. TODO do we need a
mixin here?
foreach (i, var; vars.splitter(`, `))
{
mixin(Ts[i] ~ ` ` ~ var);
}
auto let(Tuple!Ts xs)
{
foreach (i, var; vars.splitter(`, `))
{
mixin(Ts[i] ~ ` = ` ~ xs[i]);
}
}
}
unittest
{
let!q{first, _, second}(tuple(`first`, `_`, `second`));
}
but this fails in many ways.
Could someone, please help out here?
Re: What wrong?
On Friday, 15 May 2015 at 09:20:32 UTC, Gary Willoughby wrote: On Friday, 15 May 2015 at 07:51:29 UTC, thedeemon wrote: On Saturday, 2 May 2015 at 02:51:52 UTC, Fyodor Ustinov wrote: Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ What I'm doing wrong? Try using class instead of struct. Last time I played with std.concurrency it used Variants to store the messages, so when something bigger than a little basic value or a reference, like a class object, is sent it behaves unpredictably: can crash or shit garbage. Trying to send structs larger than ~20 bytes usually caused problems. Please raise a bugzilla issue for this. this commit cause the issue: https://github.com/D-Programming-Language/phobos/commit/45fda72192ff5b878ebe915db0ffb9f6504cca8f but it is probably just a trigger not a real cause.
Re: Destructured Tuple Assignment
On Friday, 15 May 2015 at 10:23:24 UTC, Per Nordlöw wrote: I recall having seen an example of using some D magic (via mixin perhaps?) to realize tuple destructuring in assignments like magic(first, _, second) = expression.findSplit(separator); somewhere. But I can't seem to find it right now. References anyone? BTW :I'm aware of Kenjis PR, which I am very much longing for ;) Well there's always this, which is a bit ugly: typeof(expression) first, _, second; TypeTuple!(first, _, second) = expression.findSplit(separator); But of course the holy grail is being able to declare variables inline.
Re: Destructured Tuple Assignment
On Friday, 15 May 2015 at 10:23:24 UTC, Per Nordlöw wrote: I recall having seen an example of using some D magic (via mixin perhaps?) to realize tuple destructuring in assignments like magic(first, _, second) = expression.findSplit(separator); I found it: http://forum.dlang.org/thread/ubrngkdmyduepmfkh...@forum.dlang.org?page=1 I'm however still as frustrated because instead of having to specify tuple indexes explicitly as const result = expression.findSplit(separator); const first = result[0]; const second = result[2]; I instead have to write types explicitly (no type-inference) string first, _, second; // non-generic unstable type guess tie(first, _, second) = expression.findSplit(separator); or just as bad typeof(expression.findSplit(separator)[0]) first, _, second; tie(first, _, second) = expression.findSplit(separator); Can this be solved with a mixin somehow?
SIG11 crashing - can't figure it out
Working my way through Ali Çehreli's rather amazing e-book, I've
hit a snag where some code I've written is pretty crashy. I
consistently get Segmentation fault: 11 (dmd 2.067.1, OSX).
I can't figure out where things are going wrong, because any
attempt I make to debug via extra print statements causes the
program to run successfully. Same if I try to compile with -gc
... it suddenly starts working, so I can't debug with gdb.
Putting aside any that's probably not a great solution to the
problem you're tying to solve thoughts, can anyone offer me the
eureka moment I'm missing to understand why the code below
doesn't work?
Many thanks in advance!
* * *
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) {
case Value.ACE:
write(A);
break;
case Value.TWO, Value.THREE, Value.FOUR, Value.FIVE, Value.SIX,
Value.SEVEN, Value.EIGHT, Value.NINE, Value.TEN:
writef(%d, card.value);
break;
case Value.JACK:
write(J);
break;
case Value.QUEEN:
write(Q);
break;
case Value.KING:
write(K);
break;
}
final switch(card.suit) {
case Suit.HEARTS:
write(♡);
break;
case Suit.DIAMONDS:
write(♢);
break;
case Suit.CLUBS:
write(♣);
break;
case Suit.SPADES:
write(♠);
break;
}
write(\n);
}
int main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
return 0;
}
Re: SIG11 crashing - can't figure it out
On Friday, 15 May 2015 at 11:08:06 UTC, Rob Pieké wrote:
Working my way through Ali Çehreli's rather amazing e-book,
I've hit a snag where some code I've written is pretty crashy.
I consistently get Segmentation fault: 11 (dmd 2.067.1, OSX).
I can't figure out where things are going wrong, because any
attempt I make to debug via extra print statements causes the
program to run successfully. Same if I try to compile with
-gc ... it suddenly starts working, so I can't debug with gdb.
Putting aside any that's probably not a great solution to the
problem you're tying to solve thoughts, can anyone offer me
the eureka moment I'm missing to understand why the code
below doesn't work?
Many thanks in advance!
* * *
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) {
case Value.ACE:
write(A);
break;
case Value.TWO, Value.THREE, Value.FOUR, Value.FIVE,
Value.SIX, Value.SEVEN, Value.EIGHT, Value.NINE, Value.TEN:
writef(%d, card.value);
break;
case Value.JACK:
write(J);
break;
case Value.QUEEN:
write(Q);
break;
case Value.KING:
write(K);
break;
}
final switch(card.suit) {
case Suit.HEARTS:
write(♡);
break;
case Suit.DIAMONDS:
write(♢);
break;
case Suit.CLUBS:
write(♣);
break;
case Suit.SPADES:
write(♠);
break;
}
write(\n);
}
int main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
return 0;
}
It seems to be DMD specific, it works fine with ldc. If you're a
homebrew user, brew install ldc and try it for yourself.
P.s. you can use the `with` statement to make things less verbose:
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) with(Value) {
case ACE:
write(A);
break;
case TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN:
writef(%d, card.value);
break;
case JACK:
write(J);
break;
case QUEEN:
write(Q);
break;
case KING:
write(K);
break;
}
final switch(card.suit) with(Suit) {
case HEARTS:
write(♡);
break;
case DIAMONDS:
write(♢);
break;
case CLUBS:
write(♣);
break;
case SPADES:
write(♠);
break;
}
write(\n);
}
void main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
}
Re: rvalue references
On Thursday, 14 May 2015 at 06:56:47 UTC, Namespace wrote: On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote: On Tue, 12 May 2015 08:54:15 -0400, Namespace rswhi...@gmail.com wrote: As far as I know, the problem (or at least one of the biggest problems) for rvalue references was that they could escape. Since DIP25 is approved and already implemented this problem should be solved. Would it be possible to allow rvalues references now? I'm just curious what the mindfactory of D has in mind and what the scheme for that problem is. Side note: DIP36 seems to be missing the table with the authors, status, etc. Bit Huh, DIP36? DIP36 was rejected, but the authors (me and Dicebot) are below. I've heard that DIP69 is [quote]almost dead in favor of DIP25[/quote]. That's why I'm a bit confused and would like to know the scheme, if any. :) There's been no official decision, AFAIK. I was just going from the impression I got from Walter Andrei's posts. But `scope` as a storage class is still necessary, because there are many more kinds of references in D besides `ref`. You can think of `ref` implying `scope`. The next steps will be to a) complete the implementation of `return ref`, b) extend it to those other reference types like pointers, slices, classes and delegates, and c) close the holes (see the thread RCArray is unsafe).
[Issue 3425] StdioException on end of stdin on Windows
https://issues.dlang.org/show_bug.cgi?id=3425 Marc Schütz schue...@gmx.net changed: What|Removed |Added Status|RESOLVED|REOPENED CC||schue...@gmx.net Resolution|WORKSFORME |--- --- Comment #6 from Marc Schütz schue...@gmx.net --- According to a user on the forums, this bug still occurs with DMD 2.067.1: http://forum.dlang.org/thread/fqdukibittdcamnwq...@forum.dlang.org --
Re: Destructured Tuple Assignment
On Friday, 15 May 2015 at 10:46:32 UTC, Per Nordlöw wrote:
Can this be solved with a mixin somehow?
To clarify, I want to be able to write
let(first, _, second) = expression.findSplit(separator);
without having to first declare `first`, `_` and `second`.
I'm guessing the closest thing we can get in current D version is
something like
let(q{first, _, second},
expression.findSplit(separator));
right?
Which might be good enough for now.
Re: Adding Radix Sort into Phobos
On Tuesday, 28 April 2015 at 15:29:11 UTC, Andrea Fontana wrote: Have you done some tests with sorted-data/almost sorted data/etc? Nope.
Re: SIG11 crashing - can't figure it out
On Friday, 15 May 2015 at 11:44:32 UTC, John Colvin wrote:
On Friday, 15 May 2015 at 11:08:06 UTC, Rob Pieké wrote:
Working my way through Ali Çehreli's rather amazing e-book,
I've hit a snag where some code I've written is pretty crashy.
I consistently get Segmentation fault: 11 (dmd 2.067.1, OSX).
I can't figure out where things are going wrong, because any
attempt I make to debug via extra print statements causes the
program to run successfully. Same if I try to compile with
-gc ... it suddenly starts working, so I can't debug with
gdb.
Putting aside any that's probably not a great solution to the
problem you're tying to solve thoughts, can anyone offer me
the eureka moment I'm missing to understand why the code
below doesn't work?
Many thanks in advance!
* * *
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE,
TEN, JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) {
case Value.ACE:
write(A);
break;
case Value.TWO, Value.THREE, Value.FOUR, Value.FIVE,
Value.SIX, Value.SEVEN, Value.EIGHT, Value.NINE, Value.TEN:
writef(%d, card.value);
break;
case Value.JACK:
write(J);
break;
case Value.QUEEN:
write(Q);
break;
case Value.KING:
write(K);
break;
}
final switch(card.suit) {
case Suit.HEARTS:
write(♡);
break;
case Suit.DIAMONDS:
write(♢);
break;
case Suit.CLUBS:
write(♣);
break;
case Suit.SPADES:
write(♠);
break;
}
write(\n);
}
int main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
return 0;
}
It seems to be DMD specific, it works fine with ldc. If you're
a homebrew user, brew install ldc and try it for yourself.
P.s. you can use the `with` statement to make things less
verbose:
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) with(Value) {
case ACE:
write(A);
break;
case TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN:
writef(%d, card.value);
break;
case JACK:
write(J);
break;
case QUEEN:
write(Q);
break;
case KING:
write(K);
break;
}
final switch(card.suit) with(Suit) {
case HEARTS:
write(♡);
break;
case DIAMONDS:
write(♢);
break;
case CLUBS:
write(♣);
break;
case SPADES:
write(♠);
break;
}
write(\n);
}
void main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
}
Please submit a bug report at issues.dlang.org
Re: SIG11 crashing - can't figure it out
https://issues.dlang.org/show_bug.cgi?id=14587 And confirmed that ldc2 seems to work, thanks again :)
Re: Destructured Tuple Assignment
On Friday, 15 May 2015 at 12:22:55 UTC, Artur Skawina wrote:
template let(string D) {
mixin({
enum sdsl = D.findSplit(=);
mixin(`struct S { int `~sdsl[0]~`; }`);
string code = `auto v = ` ~ sdsl[2] ~ `;`;
foreach (I, _; typeof(S.tupleof))
code ~= `auto ` ~ S.tupleof[I].stringof ~ ` =
v[`~I.stringof~`]; `;
return code;
}());
}
I added support for auto, const and immutable declarations at
https://github.com/nordlow/justd/blob/master/ties.d#L96
which allows usage as
mixin let!q{ auto i, d, s, c = tuple(42, 3.14, `pi`, 'x') };
mixin let!q{ const i, d, s, c = tuple(42, 3.14, `pi`, 'x') };
mixin let!q{ immutable i, d, s, c = tuple(42, 3.14, `pi`,
'x') };
:)
See unittests for details
Re: What wrong?
On Saturday, 2 May 2015 at 02:51:52 UTC, Fyodor Ustinov wrote: Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ This code works compiled by DMD v2.066.1 and LDC2 (0.15.1) based on DMD v2.066.1 and LLVM 3.5.0. $ ./z TUQLUE 42 11 Compiled by DMD v2.067.1 the program crashes: $ ./aa TUQLUE Segmentation fault What I'm doing wrong? (Copying my reply to the post in the main group here:) I investigated this further. std.variant is to blame. I filed an issue an made a pull request to fix it: https://issues.dlang.org/show_bug.cgi?id=14585 https://github.com/D-Programming-Language/phobos/pull/3284
Re: Destructured Tuple Assignment
On Friday, 15 May 2015 at 12:22:55 UTC, Artur Skawina wrote:
import std.algorithm;
template let(string D) {
mixin({
enum sdsl = D.findSplit(=);
mixin(`struct S { int `~sdsl[0]~`; }`);
string code = `auto v = ` ~ sdsl[2] ~ `;`;
foreach (I, _; typeof(S.tupleof))
code ~= `auto ` ~ S.tupleof[I].stringof ~ ` =
v[`~I.stringof~`]; `;
return code;
}());
}
Thanks!
Re: std.allocator: nomenclature needed
Not a naming suggestion, but a suggestion for a guideline on how to chose names: make it simpler for most users. If we still want one million users: 1. Most of them will never bother with std.allocator (by which I don't mean it is not necessary!) 2. Of those relatively few using std.allocator, most will use the canned, easy-to-use, high-level stuff 3. Just a few users will reach the plumbing. As someone personally prefering to remain in group 1 forever, but I willing to visit group 2 occasionally if necessary, I'd prefer to simply say import std.allocator; and get access to the higher-level stuff instead of import std.allocator.whatever; This has implications even for the hypothetical day in which I'll be required to use std.allocator. The closer to the root I find the stuff I need (that is, the high-level stuff), the quicker I'll find it. If I find lower-level stuff before finding the higher-level ones, I might even be fooled to believe that I don't have better (better for me) alternatives, and start a path of unnecessary suffering. The bottom line: please make the naming reflect the expected usage, taking into account the mythical one million users. Simpler names for the stuff that will be used by most of us. Cheers, LMB On Fri, May 15, 2015 at 12:27 AM, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: Ready for yet another name debate? Here's an opportunity! I just added: http://erdani.com/d/phobos-prerelease/std_experimental_allocator_auto_deallocator.html https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/auto_deallocator.d It's very useful, but it seems the name doesn't do it justice. Also, I need two more good names: one for what's now called porcelain - high-level typed interface for allocators, and one for best of Beatles (not defined yet) - a module collecting a number of canned good allocator designs by connecting together components. Thanks, Andrei
Re: problem with parallel foreach
On Thursday, 14 May 2015 at 17:12:07 UTC, John Colvin wrote: Would it be OK if I showed some parts of this code as examples in my DConf talk in 2 weeks? Sure!!!
Re: Destructured Tuple Assignment
On Friday, 15 May 2015 at 13:40:01 UTC, Per Nordlöw wrote:
I added support for auto, const and immutable declarations at
https://github.com/nordlow/justd/blob/master/ties.d#L96
And support for ignoring `_` as a variable as:
import std.algorithm.searching: findSplit;
mixin let!q{ c, _, d = `11-12`.findSplit(`-`) };
static assert(__traits(compiles, c == c));
static assert(!__traits(compiles, _ == _)); // assert that it
was ignored
Re: SIG11 crashing - can't figure it out
Thanks John, I'll log the issue and start brewing ldc. I'm happy that I wasn't doing something obviously stupid with my code (again, in terms of crashing, not design). And also thanks for the with tip! - Rob
Re: Returning an empty range of a given type
On 5/14/15 11:22 PM, rcorre wrote:
On Thursday, 14 May 2015 at 18:44:58 UTC, Steven Schveighoffer wrote:
It depends on the guts of MyContainer.Range.
I'm assuming MyContainer.Range has SOME sort of references (i.e.
pointers) to the data in the container, so why not just have:
bool empty() { return someRef == null || yourCurrentTest; }
In this case, I want to return an empty range when the container
instance itself is null. I could have a static method
MyContainer.emptySlice, but I feel like I've seen this general situation
crop up a lot with small variations.
I'd have to see the code, but it seems like your situation is different
from what I think, or you are not understanding what I'm saying :)
As an example:
struct MyContainer
{
private int[] data;
struct Range
{
private int *curData;
private int *endOfData;
int front() { return *curData; }
bool empty() { return curData == endOfData; }
void popFront() { ++curData; }
}
Range opSlice() {return Range(data.ptr, data.ptr + data.length);}
}
Range.init would be a valid empty range in this case. But I have no idea
what your situation is. That's why I said it depends on the guts of the
Range.
-Steve
Re: SIG11 crashing - can't figure it out
On 5/15/15 7:08 AM, Rob =?UTF-8?B?UGlla8OpIg==?= robpi...@gmail.com
wrote:
Working my way through Ali Çehreli's rather amazing e-book, I've hit a
snag where some code I've written is pretty crashy. I consistently get
Segmentation fault: 11 (dmd 2.067.1, OSX).
Using dustmite (and 2.067.0), I reduced it to this:
enum Suit {
DIAMONDS, CLUBS}
enum Value {
ACE , TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN, JACK,
QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(Card card) {
final switch(card.value) {
case Value.ACE:
;
case Value.TWO, Value.THREE, Value.FOUR, Value.FIVE, Value.SIX,
Value.SEVEN, Value.EIGHT, Value.NINE, Value.TEN:
;
case Value.JACK:
;
case Value.QUEEN:
;
case Value.KING:
;
}
}
int main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
return 0;
}
But before I figured out how to use dustmite (it was my first time), I
hand reduced it to this:
struct Card {
int value;
int suit;
}
void foo(Card card) {
switch(card.value) {
case 4: case 5: case 6: case 11:
break;
default:
}
}
void main() {
auto card = Card(11, 1);
foo(card);
}
I see you filed a bug, I'll update with the reduced case.
-Steve
Re: What wrong?
On Monday, 4 May 2015 at 08:48:47 UTC, Fyodor Ustinov wrote: Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ This code works compiled by DMD v2.066.1 and LDC2 (0.15.1) based on DMD v2.066.1 and LLVM 3.5.0. $ ./z TUQLUE 42 11 Compiled by DMD v2.067.1 the program crashes: $ ./aa TUQLUE Segmentation fault What I'm doing wrong? I investigated this further. std.variant is to blame. I filed an issue an made a pull request to fix it: https://issues.dlang.org/show_bug.cgi?id=14585 https://github.com/D-Programming-Language/phobos/pull/3284
[Issue 14097] root/async.c: use after free
https://issues.dlang.org/show_bug.cgi?id=14097 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9bc9da61751c7a543168fda16e66bc37f2e396f5 Fix Issue 14097 - root/async.c: free after use Also add some docs. https://github.com/D-Programming-Language/dmd/commit/017bf13d4a95cb2a35476489b1d45f53d671b424 Merge pull request #4653 from ZombineDev/fix-async-read-on-windows Fix Issue 14097 - root/async.c: free after use --
[Issue 14586] New: can't get an immutable value from a const std.variant.Variant
https://issues.dlang.org/show_bug.cgi?id=14586
Issue ID: 14586
Summary: can't get an immutable value from a const
std.variant.Variant
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
import std.variant;
void main()
{
const Variant v = new immutable Object;
auto o = v.get!(immutable Object); /* line 5 */
}
test.d(5): Error: mutable method
std.variant.VariantN!32LU.VariantN.get!(immutable(Object)).get is not callable
using a const object
Pull request on the way.
--
[Issue 14587] DMD 2.067.1 generating crashing binary on OSX
https://issues.dlang.org/show_bug.cgi?id=14587
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #1 from Steven Schveighoffer schvei...@yahoo.com ---
A reduced version:
struct Card {
int value;
int suit;
}
void foo(Card card) {
switch(card.value) {
case 4: case 5: case 6: case 11:
break;
default:
}
}
void main() {
auto card = Card(11, 1);
foo(card);
}
Changing anything at this point seems to make it run properly.
--
'const' and 'in' parameter storage classes
What is the difference between 'const' and 'in' parameter storage classes? When should I use 'const' or 'in'? The documentation says 'in' is the same as 'const scope' but I can't write 'const scope ref' though it's legal to write 'in ref'. Thank you
[Issue 14587] New: DMD 2.067.1 generating crashing binary on OSX
https://issues.dlang.org/show_bug.cgi?id=14587
Issue ID: 14587
Summary: DMD 2.067.1 generating crashing binary on OSX
Product: D
Version: unspecified
Hardware: x86_64
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: robpi...@mail.com
(reporting as an issue - suggested by John Colvin)
I'm consistently getting Segmentation fault: 11 (dmd 2.067.1, OSX) on the
code below.
I can't figure out where things are going wrong, because any attempt I make to
debug via extra print statements causes the program to run successfully. Same
if I try to compile with -gc ... it suddenly starts working, so I can't debug
with gdb. And the code similarly seems to work fine with ldc2.
Many thanks in advance!
* * *
import std.stdio;
enum Suit {
HEARTS, DIAMONDS, CLUBS, SPADES
}
enum Value {
ACE = 1, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
JACK, QUEEN, KING
}
struct Card {
Value value;
Suit suit;
}
void printCard(in Card card) {
final switch(card.value) {
case Value.ACE:
write(A);
break;
case Value.TWO, Value.THREE, Value.FOUR, Value.FIVE, Value.SIX,
Value.SEVEN, Value.EIGHT, Value.NINE, Value.TEN:
writef(%d, card.value);
break;
case Value.JACK:
write(J);
break;
case Value.QUEEN:
write(Q);
break;
case Value.KING:
write(K);
break;
}
final switch(card.suit) {
case Suit.HEARTS:
write(♡);
break;
case Suit.DIAMONDS:
write(♢);
break;
case Suit.CLUBS:
write(♣);
break;
case Suit.SPADES:
write(♠);
break;
}
write(\n);
}
int main() {
auto card = Card(Value.JACK, Suit.CLUBS);
printCard(card);
return 0;
}
--
Re: Need a JQuery plugin for D
On Thursday, 14 May 2015 at 19:11:19 UTC, Idan Arye wrote: On Thursday, 14 May 2015 at 18:23:47 UTC, Wyatt wrote: On Thursday, 14 May 2015 at 18:09:06 UTC, extrawurst wrote: On Tuesday, 12 May 2015 at 15:53:53 UTC, Walter Bright wrote: https://i.stack.imgur.com/ssRUr.gif I hope this is fake!? Look at the sidebar stuff. It's clearly a joke. (From about two years ago, I think?) I've seen this joke several times and this is the first time I looked at the sidebar. It's even more hilarious than the main joke! Is there a jQuery plugin for making an html page appear in the browser? Obviously I must be doing something wrong as jQuery is perfect :O Ha ha ha!
Re: Let's improve D's exceptions
On Friday, 15 May 2015 at 09:23:12 UTC, Jacob Carlborg wrote:
So why isn't data members used more, because of the boilerplate
to create a new subcalss?
Yeah, I think so. A new exception subclass has to write out the
long constructor signature, forward it, add the data members,
write code to set them, and at least write code to add them to
the toString (which itself has a long signature and needs a lot
of string formatting tedium).
That's a fair amount of code to write, especially compared to new
Exception(foo ~ to!string(value)) right there inline when it
comes up.
But with reflection we can really simplify it to the point where
writing class Foo : Exception { int value; mixin ExtendException;
} becomes less of a hassle, or we could even extend a hierarchy
right inline like raise!SomeException(variadic, arguments).
Re: 'const' and 'in' parameter storage classes
The scope storage class means you promise not to escape any reference to the data. This isn't enforced but it is similar in concept to Rust's borrowed pointers - it may someday be implemented to be an error to store them in an outside variable. Only use 'in' if you are looking at the data, but not modifying or storing copies of pointers/references to it anywhere in any way.
Re: std.allocator: nomenclature needed
On 5/15/15 6:26 AM, Leandro Motta Barros via Digitalmars-d wrote: Not a naming suggestion, but a suggestion for a guideline on how to chose names: make it simpler for most users. [snip] Sensible argument. Yes, importing std.allocator will make the high-level goodies available. (Not sure whether it should /also/ make the low-level stuff available, too.) -- Andrei
[Issue 14587] DMD 2.067.1 generating crashing binary on OSX
https://issues.dlang.org/show_bug.cgi?id=14587 --- Comment #2 from Rob Pieké robpi...@mail.com --- Thanks for reducing it Steven! I also did a bit more leg-work. It could be coincidence, but the code seems to work in DMD 2.063.2 and below and fails in 2.064 and above. Not only OSX. Linux (64-bit) at a minimum as well. --
Re: Need a JQuery plugin for D
On Thursday, 14 May 2015 at 18:23:47 UTC, Wyatt wrote: On Thursday, 14 May 2015 at 18:09:06 UTC, extrawurst wrote: On Tuesday, 12 May 2015 at 15:53:53 UTC, Walter Bright wrote: https://i.stack.imgur.com/ssRUr.gif I hope this is fake!? Look at the sidebar stuff. It's clearly a joke. (From about two years ago, I think?) the sidebar is great!! XD
Re: UFCS
On 05/15/2015 11:31 PM, Manfred Nowak wrote:
class C{}
int main(){
void opOpAssign( string op)( C a, C b){
}
C a, b;
a+= b;
}
https://issues.dlang.org/show_bug.cgi?id=8062
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On 5/15/15 1:34 PM, Timon Gehr wrote: On 05/15/2015 10:13 PM, deadalnix wrote: On Friday, 15 May 2015 at 19:49:27 UTC, Andrei Alexandrescu wrote: Well I added the rule that allocate(0) should return null, there are a few more tests but probably nothing worrisome: https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220 Andrei I do think think this is what makes sense for us: - We should throw in case of error, not return null. - Too much overhead, there might be a fall-back installed. - Where do you allocate the exception object? Yeh, failed allocations are relatively frequent within the framework components. -- Andrei
Re: New adapter: std.allocator.quantizer
On 5/15/15 1:28 PM, Timon Gehr wrote: I have just noticed that all the calls to alignedAllocate do not pass the alignment argument. Crikey, that must have something to do with all that missing test coverage :o). -- Andrei
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On Friday, 15 May 2015 at 17:01:26 UTC, Andrei Alexandrescu wrote: Since there's a long-established tradition that reallocate() and free() accept a null pointer, Question, is there a strong rationale for this? The usefulness is obvious if malloc(0) returns null, but otherwise, attempting to free a resource that has never been created usually indicates a bug.
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On 5/15/15 6:56 PM, Vladimir Panteleev wrote: On Friday, 15 May 2015 at 17:01:26 UTC, Andrei Alexandrescu wrote: Since there's a long-established tradition that reallocate() and free() accept a null pointer, Question, is there a strong rationale for this? The usefulness is obvious if malloc(0) returns null, but otherwise, attempting to free a resource that has never been created usually indicates a bug. Yah, you don't want to special case null everywhere: cleanup functions, destructors, etc. etc. If deallocation wouldn't accept the null pointer, if (p) free(p); would cause carpal tunnel syndrome. -- Andrei
Re: functors with template lambdas
On Saturday, 16 May 2015 at 02:06:45 UTC, weaselcat wrote: very long standing compiler bug https://issues.dlang.org/show_bug.cgi?id=3051 see also https://issues.dlang.org/show_bug.cgi?id=5710 unsure if they're duplicate bugs, never really looked into it.
Re: functors with template lambdas
On Saturday, 16 May 2015 at 02:04:39 UTC, Vlad Levenfeld wrote:
I think this code should be allowed, but it isn't:
struct Functor (T)
{
T a;
auto ref fmap (alias f)()
{
return Functor (f(a));
}
}
auto ref identity (T)(auto ref T a)
{
return a;
}
void main()
{
Functor!int a;
static auto id (T)(T x)
{return x;}
a.fmap!identity; // ok
a.fmap!id; // ok
a.fmap!((int x) = x); // ok
a.fmap!(x = x); // Error: template instance fmap!((x) = x)
cannot use local '__lambda1' as parameter to non-global
template fmap(alias f)()
}
This seems like one of those things that doesn't work because
of some compiler implementation detail rather than a
consequence of the language rules but I'm not sure. Opinion?
very long standing compiler bug
https://issues.dlang.org/show_bug.cgi?id=3051
Re: functors with template lambdas
On Saturday, 16 May 2015 at 02:08:09 UTC, weaselcat wrote:
On Saturday, 16 May 2015 at 02:06:45 UTC, weaselcat wrote:
very long standing compiler bug
https://issues.dlang.org/show_bug.cgi?id=3051
see also
https://issues.dlang.org/show_bug.cgi?id=5710
unsure if they're duplicate bugs, never really looked into it.
Yeah it looks like the bugs come from the same root cause.
http://wiki.dlang.org/DIP30
Also, this came up during the discussion of the latter bug. Its
still in Draft status. Haven't read it carefully enough yet to
tell whether or not it would be helpful.
GDC rejects this code as well. I dunno about LDC.
BUT!! I found a way to make this pattern, at least, work as
intended. I expected a symbol resolution error from the following
code but was very pleased to find that it compiles:
module ffunc;
struct F (T)
{
T a;
}
auto ref fmap (alias f, T)(auto ref F!T x)
{
return F!T (f(x.a));
}
---
module gfunc;
struct G (T)
{
T a;
}
auto ref fmap (alias f, T)(auto ref G!T x)
{
return G!T (f(x.a));
}
---
import ffunc;
import gfunc;
auto ref identity (T)(auto ref T a)
{
return a;
}
void main ()
{
F!int a;
G!int b;
a.fmap!identity;
b.fmap!identity;
static auto id (T)(T x)
{return x;}
a.fmap!id;
b.fmap!id;
a.fmap!((int x) = x);
b.fmap!((int x) = x);
a.fmap!(x = x);
b.fmap!(x = x);
}
Frankly this is even better than the original code, because now
fmap can be defined after the functor, as a UFCS extension.
Awesome!!
Inferring Purity Woes
I've been avoiding purity in D for a while but I decided to take
a stab at it today. I encountered two issues which make inferring
purity difficult.
(1) While the compiler infers purity for instantiated functions,
it's unable to infer purity for functions within templates.
Consider the following three statements:
void foo()(){ }
template T(){ void foo()(){ } }
template T(){ void foo(){ } }
The compiler can infer purity for the first two statements but
not the third. So even though the functions are within a
template, you still have to make each individual function an
instantiated function in order to infer purity for them.
I think the compiler should infer purity for all functions, but
adding support for functions within templates would be good
enough. Otherwise, you end up with a lot of syntactic noise by
adding empty parenthesis to all of these function declarations
without any clear reason why they're even there.
(2) When the compiler fails to infer purity, it prints an error
pure function [] cannot call impure function []. However, it
fails to tell you where the impurity occurs. So if you have a
series of instantiated functions spanning thousands of lines of
code, you have to manually sift through all of that code to find
the impurity.
Are there any bug reports for these two issues? I tried searching
but couldn't find anything.
functors with template lambdas
I think this code should be allowed, but it isn't:
struct Functor (T)
{
T a;
auto ref fmap (alias f)()
{
return Functor (f(a));
}
}
auto ref identity (T)(auto ref T a)
{
return a;
}
void main()
{
Functor!int a;
static auto id (T)(T x)
{return x;}
a.fmap!identity; // ok
a.fmap!id; // ok
a.fmap!((int x) = x); // ok
a.fmap!(x = x); // Error: template instance fmap!((x) = x)
cannot use local '__lambda1' as parameter to non-global template
fmap(alias f)()
}
This seems like one of those things that doesn't work because of
some compiler implementation detail rather than a consequence of
the language rules but I'm not sure. Opinion?
[Issue 14572] cannot build dmd from source anymore: 'g++ -m64: No such file or directory'
https://issues.dlang.org/show_bug.cgi?id=14572 Timothee Cour timothee.co...@gmail.com changed: What|Removed |Added CC||timothee.co...@gmail.com --- Comment #3 from Timothee Cour timothee.co...@gmail.com --- it happens when user has export CC=clang in his ~/.zshrc / ~/.bashrc for example, and then calls the makefile. Note that the makefile sets CC to g++ (a hack to allow the .c files to be treated as .cpp files); which I think is problematic. a better way would be to call $(CXX) -x c++ some_badly_named_cpp_file.c --
Re: UFCS
On Friday, May 15, 2015 21:31:35 Manfred Nowak via Digitalmars-d-learn wrote:
The following gives:
Error: 'a += b' is not a scalar, it is a C
although UFCS should engage.
-manfred
class C{}
int main(){
void opOpAssign( string op)( C a, C b){
}
C a, b;
a+= b;
}
Overloaded operators have to be defined as part of the type that they're
overloading the operator for, and UFCS is only ever used with the . syntax.
So, this isn't a bug.
- Jonathan M Davis
Re: Linking to Dynamic Library on Mac OS X
Off the top of my head: does adding -L-L$(pwd) help? This is what I get: $ dmd main.d -L-L$(pwd) -lhello Error: unrecognized switch '-lhello' Sorry if this is completely elementary and I am being quite dumb. Thanks, TJB
Re: Adding Radix Sort into Phobos
On Friday, 15 May 2015 at 12:31:26 UTC, Per Nordlöw wrote: On Tuesday, 28 April 2015 at 15:29:11 UTC, Andrea Fontana wrote: Have you done some tests with sorted-data/almost sorted data/etc? Nope. Amongst other thing, when you do the first count pass, you can check if the dataset is sorted and early bailout if it is already.
Re: Any plans to support STL value types?
On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote: Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend? Given that the inheritance they have is actually undesirable when they are treated as value types, I doubt that there's much need. If you're using inheritance in C++, you're putting your class on the heap and accessing it via pointers, in which case, accessing them in D as classes makes sense. And if you're using these STL types as value types on the stack, then they can be treated as value types. Doing otherwise just risks object slicing, which is not desirable in the least. So, while I don't know how we're going to be handling STL types (I don't even know what the current state of C++ state support is, since it keeps improving), I really don't see why there's value in supported inheritance with value types. It would just be begging for bugs - which is why native D types don't support it. - Jonathan M Davis
Re: Linking to Dynamic Library on Mac OS X
On Friday, 15 May 2015 at 19:39:53 UTC, TJB wrote: Off the top of my head: does adding -L-L$(pwd) help? This is what I get: $ dmd main.d -L-L$(pwd) -lhello Error: unrecognized switch '-lhello' Sorry if this is completely elementary and I am being quite dumb. Thanks, TJB should be $ dmd main.d -L-L$(pwd) -L-lhello The -L means send the following argument to the linker. Note that you may also find you need to help OS X find the dylib when running the program, either by moving it to one of the system locations or using DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH (see http://stackoverflow.com/questions/3146274/is-it-ok-to-use-dyld-library-path-on-mac-os-x-and-whats-the-dynamic-library-s). However, I think the runtime linker looks in the present directory by default, so you might get away with it.
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On 5/15/15 11:51 AM, Andrei Alexandrescu wrote: On 5/15/15 11:37 AM, deadalnix wrote: On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote: This is a matter with some history behind it. In C, malloc(0) always returns a new, legit pointer that can be subsequently reallocated, freed etc. What most malloc() implementations practically do in their first line is: if (size == 0) size = 1; and take it from there. There are actually 2 way to do this in malloc. Either you return null, but then you need to be able to accept null in the free implementation (as malloc must return a freeable pointer) or you just bump to 1. Both are valid per spec and there are implementations of malloc for both. Ah, nice. I was under the misconception that malloc(0) cannot return null in C. Apparently it's implementation defined at least since C99, see http://stackoverflow.com/a/2132318/348571. Thanks! Well I added the rule that allocate(0) should return null, there are a few more tests but probably nothing worrisome: https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220 Andrei
[Issue 14587] DMD 2.067.1 generating crashing binary on OSX
https://issues.dlang.org/show_bug.cgi?id=14587 Marc Schütz schue...@gmx.net changed: What|Removed |Added CC||schue...@gmx.net --- Comment #3 from Marc Schütz schue...@gmx.net --- FWIW, I can reproduce it with DMD master on Linux x86_64. Interestingly, compiling with debug info makes the SEGV go away. --
[Issue 14587] DMD 2.067.1 generating crashing binary on OSX
https://issues.dlang.org/show_bug.cgi?id=14587 Marc Schütz schue...@gmx.net changed: What|Removed |Added Keywords||wrong-code OS|Mac OS X|All --- Comment #4 from Marc Schütz schue...@gmx.net --- It crashes upon entering the jump table: (gdb) disas Dump of assembler code for function _D2xx3fooFS2xx4CardZv: 0x0041c7b0 +0:push %rbp 0x0041c7b1 +1:mov%rsp,%rbp 0x0041c7b4 +4:sub$0x10,%rsp 0x0041c7b8 +8:mov%rdi,-0x8(%rbp) 0x0041c7bc +12:cmp$0xb,%edi 0x0041c7bf +15:ja 0x41c7c8 _D2xx3fooFS2xx4CardZv+24 = 0x0041c7c1 +17:jmpq *0x4374f8(,%rdi,8) 0x0041c7c8 +24:leaveq 0x0041c7c9 +25:retq (gdb) print $edi $1 = 11 (gdb) print $rdi $2 = 4294967307 As you can see, %edi contains the correct offset, but it uses %rdi as an index. Most likely a bug in the code generator. --
[Issue 14588] New: undefined reference error while linking with -debug option to a static library.
https://issues.dlang.org/show_bug.cgi?id=14588
Issue ID: 14588
Summary: undefined reference error while linking with -debug
option to a static library.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: pyc...@qq.com
//testa.d
module testa.d;
void func(alias a, T, R...)()
{
}
class A
{
int i;
void all(T...)()
{
func!(i,T)();
}
}
//test.d
import testd;
void main()
{
new A().all!int();
}
dmd -debug -lib testa.d //ok
dmd -debug test.d testa.d //ok
dmd test.a testa.a //ok
dmd -debug test.d testa.a //error, undefined reference to func
--
Re: CTFE enums static assert
On 2015-05-04 18:22:17 +, Ali Çehreli said:
There are many different kinds of tuples in D, only two of which I can handle:
1) Tuple from std.typecons, which are ordinarily created at run time
2) TypeTuple from std.typetuple, which are compile-time entities
The documentation is not clear that __traits(allMembers) returns a
TypeTuple, which additionally has a bad name.
TypeTuple is great because it enables compile-time foreach
(unfortunately, implicitly):
foreach (m; __traits(allMembers, A)) {
// This body is repeated for each member at compile time
}
Is there a way I can build an ENUM from within the FOREACH? What I want
to achive is, that I would like to use:
final switch (myEnum) ...
and have myEnum build at compiletime. With this the compiler would give
an error whenever I have forgotten to update my code to handle a new
case.
2. I'm wondering why members1 doesn't has a type at all.
Because it is a TypeTuple of values of various types and even types themselves.
But shouldn't be the type than be TypeTuple?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Deprecation
Deprecation: super is not an lvalue 1) How to know when this will indeed be deprecated? 2) What does it mean, when `super++' is signalled as depracation, but `super+=' is not signalled? -manfred
Re: New adapter: std.allocator.quantizer
On 5/12/15 12:57 PM, Timon Gehr wrote: On 05/12/2015 04:54 AM, Andrei Alexandrescu wrote: On 5/11/15 4:59 PM, Timon Gehr wrote: On 05/11/2015 08:48 PM, Andrei Alexandrescu wrote: On 5/11/15 11:31 AM, Timon Gehr wrote: - The assertion in line 141 may fail. (expand can return false.) OK, it seems the previous commit should take care of that. ... Nope. Well, yes, in the sense that there is no longer a possibly failing assertion on line 141. In any case, 'allocate' within 'expand' may fail, and if it does, b.ptr will still be null throughout the body of reallocate/alignedReallocate. Somebody shoot me :o). https://github.com/andralex/phobos/commit/18d5cd9526db5057cacff5832a6246d1f84ada2a ... Missed alignedReallocate. :o) On a related note, alignedReallocate is now also buggy in that it does not necessarily align the allocated memory if b.ptr is null. Missed this, thanks for the email! I've simplified matters a bit by testing for null up front: https://github.com/andralex/phobos/commit/af0abf6adb325cf57f2ef0f07bf787ebb1351288 I suspect the other allocators have similar issues though... I'll need to make a careful pass. Thanks!! Andrei
Re: Deprecation
On 5/15/15 12:50 PM, Manfred Nowak wrote: Deprecation: super is not an lvalue 1) How to know when this will indeed be deprecated? 2) What does it mean, when `super++' is signalled as depracation, but `super+=' is not signalled? That seems like a bug. I think super being an lvalue in this context simply means that the *reference* is not an lvalue (e.g. you can't do super = someOtherObject), not the object it points at. Clearly anything that is passed by reference is an lvalue. -Steve
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On 5/15/15 9:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Ha! Two fools, one thought :-) It's a nice idea but as Vladimir mentioned expand(), reallocate(), free() - all need now to worry about checking two singular values instead of one. Since there's a long-established tradition that reallocate() and free() accept a null pointer, we can't (and probably shouldn't) change that. So I'm thinking in a way null as a singular value comes for free. Andrei
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On Friday, 15 May 2015 at 17:01:26 UTC, Andrei Alexandrescu wrote: On 5/15/15 9:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Ha! Two fools, one thought :-) It's a nice idea but as Vladimir mentioned expand(), reallocate(), free() - all need now to worry about checking two singular values instead of one. Since there's a long-established tradition that reallocate() and free() accept a null pointer, we can't (and probably shouldn't) change that. So I'm thinking in a way null as a singular value comes for free. Yes, and std.allocator is a new piece of software, which means we can choose what makes sense and don't need to worry about compatibility. It just needs to be clearly defined.
Re: 'const' and 'in' parameter storage classes
On Friday, 15 May 2015 at 16:30:29 UTC, Steven Schveighoffer wrote: On 5/15/15 12:04 PM, ref2401 wrote: What is the difference between 'const' and 'in' parameter storage classes? When should I use 'const' or 'in'? The documentation says 'in' is the same as 'const scope' but I can't write 'const scope ref' though it's legal to write 'in ref'. scope ref const -Steve still getting the error: Error: scope cannot be ref or out
Re: 'const' and 'in' parameter storage classes
On Friday, 15 May 2015 at 16:08:31 UTC, Adam D. Ruppe wrote:
The scope storage class means you promise not to escape any
reference to the data. This isn't enforced but it is similar in
concept to Rust's borrowed pointers - it may someday be
implemented to be an error to store them in an outside variable.
Only use 'in' if you are looking at the data, but not modifying
or storing copies of pointers/references to it anywhere in any
way.
I expected the compiler forbids 'in' params escaping.
struct MyStruct {
this(int a) {
this.a = a;
}
int a;
}
const(MyStruct)* globalPtr;
void main(string[] args) {
MyStruct ms = MyStruct(10);
foo(ms);
ms.a = 12;
writeln(global: , *globalPtr); // prints const(MyStruct)(12)
}
void foo(in ref MyStruct ms) {
globalPtr = ms; // is it legal?
}
std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
This is a matter with some history behind it. In C, malloc(0) always
returns a new, legit pointer that can be subsequently reallocated, freed
etc. What most malloc() implementations practically do in their first
line is:
if (size == 0) size = 1;
and take it from there.
The reasoning was to make failure of malloc easy to test for. This would
suffice:
size_t s;
...
void* p = malloc(s);
if (!p) {
... failed! ...
}
as opposed to:
if (!p s) {
... failed! ...
}
That kinda makes sense, but it's not super consistent. For example,
realloc() does not obey the same protocol. Calling realloc() with a new
size of 0 actually free()s the pointer and then returns null.
Anyhow, on to D. In D it's easy to test whether an allocation succeeded:
auto buf = alloc.allocate(s);
if (buf.length != s) {
... failed! ...
}
It is a bit subtle, but I think overall it makes everyone's life easier.
Thoughts?
Andrei
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:
This is a matter with some history behind it. In C, malloc(0)
always returns a new, legit pointer that can be subsequently
reallocated, freed etc. What most malloc() implementations
practically do in their first line is:
if (size == 0) size = 1;
and take it from there.
The reasoning was to make failure of malloc easy to test for.
This would suffice:
size_t s;
...
void* p = malloc(s);
if (!p) {
... failed! ...
}
as opposed to:
if (!p s) {
... failed! ...
}
That kinda makes sense, but it's not super consistent. For
example, realloc() does not obey the same protocol. Calling
realloc() with a new size of 0 actually free()s the pointer and
then returns null.
Anyhow, on to D. In D it's easy to test whether an allocation
succeeded:
auto buf = alloc.allocate(s);
if (buf.length != s) {
... failed! ...
}
It is a bit subtle, but I think overall it makes everyone's
life easier. Thoughts?
Not necessarily a good idea, but there's a third option:
return cast(void*) -1;
Or some other arbitrary non-zero value.
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:
This is a matter with some history behind it. In C, malloc(0)
always returns a new, legit pointer that can be subsequently
reallocated, freed etc. What most malloc() implementations
practically do in their first line is:
if (size == 0) size = 1;
and take it from there.
The reasoning was to make failure of malloc easy to test for.
This would suffice:
size_t s;
...
void* p = malloc(s);
if (!p) {
... failed! ...
}
as opposed to:
if (!p s) {
... failed! ...
}
That kinda makes sense, but it's not super consistent. For
example, realloc() does not obey the same protocol. Calling
realloc() with a new size of 0 actually free()s the pointer and
then returns null.
Anyhow, on to D. In D it's easy to test whether an allocation
succeeded:
auto buf = alloc.allocate(s);
if (buf.length != s) {
... failed! ...
}
It is a bit subtle, but I think overall it makes everyone's
life easier. Thoughts?
Andrei
There is a third option: return a non-null yet invalid pointer
(e.g. 0x1) that is used exclusively for empty allocations.
This allows the if(p) pattern and elides the cost of allocating
one byte, however it complicates allocator code a bit (resizing,
freeing needs to know about this magic pointer), and breaks the
contract malloc(size)!=malloc(size).
Re: Clean way to tell whether a destructor is called by the GC
On Thursday, 14 May 2015 at 17:25:55 UTC, ponce wrote: But then we would need a standardized name (some use close, some use dispose, some use release) In .net the standardized name is dispose and IDisposable interface having the method: https://msdn.microsoft.com/en-us/library/System.IDisposable.aspx it also suggests possible operations free and reset. close makes sense for files, but files are not the only type of disposable resource.
Re: Deprecation
Steven Schveighoffer wrote: That seems like a bug. https://issues.dlang.org/show_bug.cgi?id=14589 -manfred
Re: Any plans to support STL value types?
On Friday, 15 May 2015 at 19:44:29 UTC, Jonathan M Davis wrote: On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote: Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend? Given that the inheritance they have is actually undesirable when they are treated as value types, I doubt that there's much need. If you're using inheritance in C++, you're putting your class on the heap and accessing it via pointers, in which case, accessing them in D as classes makes sense. And if you're using these STL types as value types on the stack, then they can be treated as value types. Doing otherwise just risks object slicing, which is not desirable in the least. So, while I don't know how we're going to be handling STL types (I don't even know what the current state of C++ state support is, since it keeps improving), I really don't see why there's value in supported inheritance with value types. It would just be begging for bugs - which is why native D types don't support it. - Jonathan M Davis rust does it just fine without slicing, and supports both static dispatch and dynamic dispatch through the same interface. http://blog.rust-lang.org/2015/05/11/traits.html honestly, this is one of the worst parts of D. Being forced to code a certain way because it might be misused is the equivalent of digital socialism.
Re: Any plans to support STL value types?
On Friday, 15 May 2015 at 19:44:29 UTC, Jonathan M Davis wrote: On Friday, 15 May 2015 at 18:42:31 UTC, Kagamin wrote: Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend? Given that the inheritance they have is actually undesirable when they are treated as value types, I doubt that there's much need. If you're using inheritance in C++, you're putting your class on the heap and accessing it via pointers, in which case, accessing them in D as classes makes sense. And if you're using these STL types as value types on the stack, then they can be treated as value types. Doing otherwise just risks object slicing, which is not desirable in the least. So, while I don't know how we're going to be handling STL types (I don't even know what the current state of C++ state support is, since it keeps improving), I really don't see why there's value in supported inheritance with value types. It would just be begging for bugs - which is why native D types don't support it. - Jonathan M Davis Is there any place better to go to learn about C++ support than the old dlang.org writeup? My C++ knowledge isn't strong enough to just figure it out through experimentation, but there are some libraries I would like to link to.
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On Friday, 15 May 2015 at 19:49:27 UTC, Andrei Alexandrescu wrote: Well I added the rule that allocate(0) should return null, there are a few more tests but probably nothing worrisome: https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220 Andrei I do think think this is what makes sense for us: - We should throw in case of error, not return null. - There is no point in allocating something if 0 byte are going to be used. The thing we got to make sure is very clear in the spec is that free, realloc and so on functions are able to accept null as input.
Re: Any plans to support STL value types?
On Friday, 15 May 2015 at 19:51:09 UTC, anonymous wrote: rust does it just fine without slicing, and supports both static dispatch and dynamic dispatch through the same interface. http://blog.rust-lang.org/2015/05/11/traits.html honestly, this is one of the worst parts of D. Being forced to code a certain way because it might be misused is the equivalent of digital socialism. Everything is new does not have time to enter the weight of C++ and obsolete! This is the phenomenon of the digital socialism. Even D3 will not be able to correct this situation :) Need to invent D++ to change the situation :) Although you can just move forward and not to look at any Rusts.
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On 05/15/2015 09:49 PM, Andrei Alexandrescu wrote: On 5/15/15 11:51 AM, Andrei Alexandrescu wrote: On 5/15/15 11:37 AM, deadalnix wrote: On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote: This is a matter with some history behind it. In C, malloc(0) always returns a new, legit pointer that can be subsequently reallocated, freed etc. What most malloc() implementations practically do in their first line is: if (size == 0) size = 1; and take it from there. There are actually 2 way to do this in malloc. Either you return null, but then you need to be able to accept null in the free implementation (as malloc must return a freeable pointer) or you just bump to 1. Both are valid per spec and there are implementations of malloc for both. Ah, nice. I was under the misconception that malloc(0) cannot return null in C. Apparently it's implementation defined at least since C99, see http://stackoverflow.com/a/2132318/348571. Thanks! Well I added the rule that allocate(0) should return null, there are a few more tests but probably nothing worrisome: https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220 Andrei - Quantizer currently does not necessarily follow this rule. - Might it not be surprising behaviour for AffixAllocator?
Re: New adapter: std.allocator.quantizer
On 05/15/2015 06:58 PM, Andrei Alexandrescu wrote: On 5/12/15 12:57 PM, Timon Gehr wrote: ... Missed alignedReallocate. :o) On a related note, alignedReallocate is now also buggy in that it does not necessarily align the allocated memory if b.ptr is null. Missed this, thanks for the email! I've simplified matters a bit by testing for null up front: https://github.com/andralex/phobos/commit/af0abf6adb325cf57f2ef0f07bf787ebb1351288 I suspect the other allocators have similar issues though... I'll need to make a careful pass. Thanks!! Andrei I have just noticed that all the calls to alignedAllocate do not pass the alignment argument.
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On 05/15/2015 10:13 PM, deadalnix wrote: On Friday, 15 May 2015 at 19:49:27 UTC, Andrei Alexandrescu wrote: Well I added the rule that allocate(0) should return null, there are a few more tests but probably nothing worrisome: https://github.com/andralex/phobos/commit/f73f6ecf1b45b0fc3cffd50d375eb15eb2311220 Andrei I do think think this is what makes sense for us: - We should throw in case of error, not return null. - Too much overhead, there might be a fall-back installed. - Where do you allocate the exception object?
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On 5/15/15 11:37 AM, deadalnix wrote: On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote: This is a matter with some history behind it. In C, malloc(0) always returns a new, legit pointer that can be subsequently reallocated, freed etc. What most malloc() implementations practically do in their first line is: if (size == 0) size = 1; and take it from there. There are actually 2 way to do this in malloc. Either you return null, but then you need to be able to accept null in the free implementation (as malloc must return a freeable pointer) or you just bump to 1. Both are valid per spec and there are implementations of malloc for both. Ah, nice. I was under the misconception that malloc(0) cannot return null in C. Apparently it's implementation defined at least since C99, see http://stackoverflow.com/a/2132318/348571. Thanks! Andrei
Re: Feature or bug: print braces
On Friday, 15 May 2015 at 08:44:41 UTC, Ivan Kazmenko wrote:
Somehow reminds me of this lambda:
https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d#L127-L128
Maybe it generally blocks for initialization of variables:
https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d#L130-L131
-
for ( { int i = 0; } i 5; ++i ) {
writeln(test);
}
It seems to me that this should be fixed :)
-
int x;
void foo(int tmp) {
x = tmp;
}
...
writeln( { int i = 5; writeln(i); foo(i); });
writeln(x);
Re: SysTime object from unixtime
thanks, that did the trick!
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 20:50:05 UTC, ivoras wrote:
I'm experimenting to get a feel for the language. Do you have a
suggestion about this example code: https://goo.gl/F7LCAg to
make it more D-like, idiomatic?
Quoting from the code:
for (int i = 0; i count; i++) {
foreach(i; 0 .. count)
try {
auto choices = markov[current];
[...]
} catch (RangeError e) {
break;
}
Don't catch Errors. Use the `in` operator to check if `current`
is in `markov`:
if(current !in markov) break;
Or avoiding double lookup:
string[]* choicesp = current in markov;
if(choicesp is null) break;
auto choices = *choicesp;
int main(string[] args)
You cam omit the return type and `args` if you're not going to
use them:
void main()
foreach (c_line; stdin.byLine()) {
auto line = to!string(c_line);
Could use byLineCopy:
foreach(line; stdin.byLineCopy)
if (prev_token in markov) {
markov[prev_token] ~= token;
} else {
markov[prev_token] = [token];
}
I think you can just go with appending here:
markov[prev_token] ~= token;
But I'm not 100% sure about the implications.
Re: 'const' and 'in' parameter storage classes
On Friday, 15 May 2015 at 18:18:13 UTC, ref2401 wrote: globalPtr = ms; // is it legal? No, but the compiler check isn't implemented.
Re: std.allocator.allocate(0) - return null or std.allocator.allocate(1)?
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote: This is a matter with some history behind it. In C, malloc(0) always returns a new, legit pointer that can be subsequently reallocated, freed etc. What most malloc() implementations practically do in their first line is: if (size == 0) size = 1; and take it from there. There are actually 2 way to do this in malloc. Either you return null, but then you need to be able to accept null in the free implementation (as malloc must return a freeable pointer) or you just bump to 1. Both are valid per spec and there are implementations of malloc for both.
Any plans to support STL value types?
Many STL types inherit from base classes, yet they are used as value types: std::string, std::vector etc. Are there plans to support C++ types with inheritance as proper value types in D frontend?
Re: piping on Windows
The bug was fixed for reading, you have a similar problem with writing: head exits and closes the pipes before your program writes all it needs.
Re: 'const' and 'in' parameter storage classes
On 5/15/15 12:04 PM, ref2401 wrote: What is the difference between 'const' and 'in' parameter storage classes? When should I use 'const' or 'in'? The documentation says 'in' is the same as 'const scope' but I can't write 'const scope ref' though it's legal to write 'in ref'. scope ref const -Steve
