[Issue 6004] std.range.unzip()
https://issues.dlang.org/show_bug.cgi?id=6004 weaselcat r9shacklef...@gmail.com changed: What|Removed |Added CC||r9shacklef...@gmail.com --- Comment #1 from weaselcat r9shacklef...@gmail.com --- I was looking for this in std.range and didn't find anything, came across this issue. Since this is about 4 years old, was anything like this ever implemented? --
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 13:26:27 UTC, ivoras wrote: Is it resizable? You can append with the ~= operator and size down by slicing it. Apparently it doesn't even have an insert method: http://dlang.org/phobos/std_array.html . http://dlang.org/phobos/std_array.html#insertInPlace is the one you'd use for that.
Re: D casually mentioned and dismissed + a suggestion
On Thursday, 14 May 2015 at 14:37:03 UTC, weaselcat wrote: On Thursday, 14 May 2015 at 14:33:13 UTC, Vladimir Panteleev wrote: http://wiki.dlang.org/Jobs I think EMSI is in Moscow, Idaho. Err, fixed.
[OT] Slogan for this Forum
Arguing with an engineer is a lot like wrestling in the mud with a pig. After a few hours, you realize that he likes it. :-)
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 12:46:48 UTC, Adam D. Ruppe wrote: I would just use a regular `string[]` array... Is it resizable? Somehow I didn't get that impression from the docs. Apparently it doesn't even have an insert method: http://dlang.org/phobos/std_array.html .
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 13:26:27 UTC, ivoras wrote: On Thursday, 14 May 2015 at 12:46:48 UTC, Adam D. Ruppe wrote: I would just use a regular `string[]` array... Is it resizable? Somehow I didn't get that impression from the docs. Apparently it doesn't even have an insert method: http://dlang.org/phobos/std_array.html . string[] arr; arr ~= Foo; arr ~= Bar; writeln(arr, ':', arr.length); It's all built in. ;) A nice article: http://dlang.org/d-array-article.html and the language reference: http://dlang.org/arrays.html
Re: D casually mentioned and dismissed + a suggestion
On Thursday, 14 May 2015 at 14:02:38 UTC, Liran Zvibel wrote: On Wednesday, 13 May 2015 at 16:24:12 UTC, Andrei Alexandrescu wrote: On 5/13/15 8:26 AM, Vladimir Panteleev wrote: So do we want a front page widget that's hosted on the wiki? That would be a good idea generally though it opens the site for vandalism. So does the latest announcements ticker, and we haven't had any incidents so far. Unlike with the forum, anyone can revert wiki vandalism, and wiki admins can protect pages. I'd say we start with a wiki page and work from there. -- Andrei We don't have any publicly available job listing for D, but we would like to also have an entry in that wiki once you create it. We're always on the look for good engineers, and D is our main development language. Let's get this started, then: http://wiki.dlang.org/Jobs I found two older job postings on the forum, not sure if they're still valid: http://forum.dlang.org/post/uzemmpgbmdepdbyee...@forum.dlang.org http://forum.dlang.org/post/fqof9i$1ge6$1...@digitalmars.com
Re: D casually mentioned and dismissed + a suggestion
On Thursday, 14 May 2015 at 14:33:13 UTC, Vladimir Panteleev wrote: On Thursday, 14 May 2015 at 14:02:38 UTC, Liran Zvibel wrote: On Wednesday, 13 May 2015 at 16:24:12 UTC, Andrei Alexandrescu wrote: On 5/13/15 8:26 AM, Vladimir Panteleev wrote: So do we want a front page widget that's hosted on the wiki? That would be a good idea generally though it opens the site for vandalism. So does the latest announcements ticker, and we haven't had any incidents so far. Unlike with the forum, anyone can revert wiki vandalism, and wiki admins can protect pages. I'd say we start with a wiki page and work from there. -- Andrei We don't have any publicly available job listing for D, but we would like to also have an entry in that wiki once you create it. We're always on the look for good engineers, and D is our main development language. Let's get this started, then: http://wiki.dlang.org/Jobs I found two older job postings on the forum, not sure if they're still valid: http://forum.dlang.org/post/uzemmpgbmdepdbyee...@forum.dlang.org http://forum.dlang.org/post/fqof9i$1ge6$1...@digitalmars.com I think EMSI is in Moscow, Idaho.
Re: Let's improve D's exceptions
On Thursday, 14 May 2015 at 10:24:45 UTC, Ola Fosheim Grøstad wrote: Using alias like this makes code hard to read. Error types should be humanly deducible at the failure site. Perhaps, I don't hate it too much here though because the alias is fairly local. Without it, you'd probably write enforce!(BaseClass, fopen)(file, rb) to get the thing I was going for. You'd be better off having non-ignorable result types (e.g. tagged union/variant/algebraic) and a typed way to turn those into exceptions. The only place where I'd be interested in using something like this is calling F functions and you can't change their signature too much...
Re: Let's improve D's exceptions
On Thursday, 14 May 2015 at 10:29:57 UTC, Kagamin wrote: Maybe also replace file name with ModuleInfo similar to how assert works? Those bug me because all it really wants from it is the name and then you need all the moduleinfo even in bare metal. Exception support requires some RTTI anyway so maybe it doesn't matter, but my playing with bare metal has made me really prefer the filename versions over the moduleinfo versions...
Re: Breaking changes in Visual C++ 2015
On Thursday, 14 May 2015 at 13:22:21 UTC, Chris wrote: However, the data comes from somewhere outside the program, and although you can IoC most parts of a program _after_ it's been fed the data, the initial input section is not easily unit tested (i.e. unit test in D). Gathering parts together is integration point, and unit tests don't test integration. In your example you would be able to test the Process class. If you are unsure Loader can't parse files - that can be tested without files, streams are enough.
Re: Let's improve D's exceptions
On Thursday, 14 May 2015 at 12:39:59 UTC, Adam D. Ruppe wrote: On Thursday, 14 May 2015 at 10:29:57 UTC, Kagamin wrote: Maybe also replace file name with ModuleInfo similar to how assert works? Those bug me because all it really wants from it is the name and then you need all the moduleinfo even in bare metal. AFAIK, ModuleInfo is only 8 bytes + module name. Exception support requires some RTTI anyway so maybe it doesn't matter, but my playing with bare metal has made me really prefer the filename versions over the moduleinfo versions... ModuleInfo is primarily to extract module name and use it instead of file name, you can use module name directly if you don't like full ModuleInfo.
Dynamic / resizable array type, and a crash problem
What is the recommended dynamic array type in D? So far I found Array (specifically Array!string, as I need a dynamic array of strings), but my example program crashes: https://gist.github.com/ivoras/2d7737c214c3dc937c28 The crash is at line 20: core.exception.AssertError@/usr/include/dmd/phobos/std/container/array.d(334): Assertion failure ./markov() [0x80fbfd1] ./markov(uint std.container.array.Array!(immutable(char)[]).Array.Payload.insertBack!(immutable(char)[]).insertBack(immutable(char)[])+0x6f) [0x80fa997] ./markov(uint std.container.array.Array!(immutable(char)[]).Array.insertBack!(immutable(char)[]).insertBack(immutable(char)[])+0x36) [0x80fa866] ./markov(_Dmain+0x167) [0x80d7ce7] This is on DMD32 D Compiler v2.067.1
Re: Let's improve D's exceptions
On Thursday, 14 May 2015 at 12:26:45 UTC, w0rp wrote: I wonder if enforce should throw an Error instead, if it exists at all. Because it's designed to throw an exception you shouldn't catch. Is it really? My thought of enforce was it iwas just a lazy way to throw on cases like file not found...
Re: Returning an empty range of a given type
So I thought this might work:
struct MaybeEmpty(R) if (isInputRange!R) {
private bool _isEmpty;
private R_input;
alias _input this;
this(bool isEmpty, R input) {
_input = input;
_isEmpty = isEmpty;
}
@property bool empty() {
return _isEmpty || _input.empty;
}
}
auto maybeEmpty(R)(bool empty, R input = R.init) if
(isInputRange!R) {
return MaybeEmpty!R(empty, input);
}
It's kind of ugly, but it can be used like:
auto a = maybeEmpty!MyRange(true);
auto b = maybeEmpty!MyRange(false, actualRange);
static assert(is(typeof(a) == typeof(b)));
However, it fails the input range test:
static assert(isInputRange!MyRange); //pass
static assert(isInputRange!(typeof(a))); // fail
But it seems to be something weird with cross-module template
instantiation. If I replace `import std.range` with a copy-paste
of `isInputRange`, the above passes.
Either that or I'm doing something stupid because I'vebeen
staring at this too long.
I'm wondering if the isInputRange thing is a bug, so here's a
gist if anyone wants to play with it:
https://gist.github.com/rcorre/7a62395c53baf3c0bfbc
Re: D casually mentioned and dismissed + a suggestion
On Wednesday, 13 May 2015 at 16:24:12 UTC, Andrei Alexandrescu wrote: On 5/13/15 8:26 AM, Vladimir Panteleev wrote: So do we want a front page widget that's hosted on the wiki? That would be a good idea generally though it opens the site for vandalism. I'd say we start with a wiki page and work from there. -- Andrei We don't have any publicly available job listing for D, but we would like to also have an entry in that wiki once you create it. We're always on the look for good engineers, and D is our main development language. Liran
Re: D needs...
What about mutable references to immutable/shared/const classes?
class A {}
immutable(A)[int] aa;
aa[1] = new immutable A;// doesn't compile
Rebindable!(immutable(A))[int]; // looks like ugly shamefull
workaround.
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 12:42:01 UTC, ivoras wrote: https://gist.github.com/ivoras/2d7737c214c3dc937c28 The crash is at line 20: core.exception.AssertError@/usr/include/dmd/phobos/std/container/array.d(334): [...] This is on DMD32 D Compiler v2.067.1 Seems to be fixed in git head.
Re: Let's improve D's exceptions
I wonder if enforce should throw an Error instead, if it exists at all. Because it's designed to throw an exception you shouldn't catch. If you are going to have it throw an Exception subclass, then it should take the exception type, like enforce!WhateverException(...), or something.
Re: Let's improve D's exceptions
On Thursday, 14 May 2015 at 10:08:36 UTC, Jacob Carlborg wrote: It was a while since I looked at that DIP, but I'm mostly interested in the hierarchy. 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... then if there's not a million lines of boilerplate for a new class, it gets to be a lot easier to do.
Re: Dynamic / resizable array type, and a crash problem
I would just use a regular `string[]` array...
Re: Breaking changes in Visual C++ 2015
On Wednesday, 13 May 2015 at 08:26:35 UTC, Kagamin wrote:
On Monday, 11 May 2015 at 09:31:34 UTC, Chris wrote:
Hm, I was thinking of something like that, however, it gets
more and more complicated if you have e.g. a class that uses
another class etc.
class Data // A singleton
{
// stores paths to resources etc.
}
class Loader
{
this()
this.data = Data.getInstance();
// Loads files and caches them in memory
}
class Process
{
// Uses cached data
}
It ain't easy to unit test Process, but even Loader and Data
can be tricky to unit test, because all of them depend on
input from the outside.
That's the reason for IoC design; it's similar to ranges in a
sense that you feed the range with data instead of letting it
figure out where to get that data on its own.
However, the data comes from somewhere outside the program, and
although you can IoC most parts of a program _after_ it's been
fed the data, the initial input section is not easily unit tested
(i.e. unit test in D).
Unit tests only work for the data processing logic inside a unit
after the program has received the data from the outside. But the
initial acquisition of data is outside the scope of these unit
tests. Thus, there are always bits and pieces that cannot be
unit-tested like e.g. loading files.
Re: D casually mentioned and dismissed + a suggestion
On 5/14/15 7:02 AM, Liran Zvibel wrote: On Wednesday, 13 May 2015 at 16:24:12 UTC, Andrei Alexandrescu wrote: On 5/13/15 8:26 AM, Vladimir Panteleev wrote: So do we want a front page widget that's hosted on the wiki? That would be a good idea generally though it opens the site for vandalism. I'd say we start with a wiki page and work from there. -- Andrei We don't have any publicly available job listing for D, but we would like to also have an entry in that wiki once you create it. We're always on the look for good engineers, and D is our main development language. Liran Added to http://wiki.dlang.org/Jobs, feel free to edit (e.g. I didn't know the city). -- Andrei
[Issue 14582] bigEndianToNative buffer slice allows only literals
https://issues.dlang.org/show_bug.cgi?id=14582 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Broken by https://github.com/D-Programming-Language/dmd/pull/4193. I believe this change is intentional. --
Re: rvalue references
On Thu, 14 May 2015 02:56:46 -0400, Namespace rswhi...@gmail.com wrote: On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote: 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. Hmm.. so they are ;) 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. :) Makes sense, but if scope is dead, I assume it would have to be removed at some point. So I guess 'ref' could just take rvalues now that it's escape-proof right? Also, what becomes of the 'in' storage class? being just another word for 'const' seems like a waste. If it were up to me, I would say: 'scope' should be removed as a storage class, 'ref' should be left as is, and 'in' should adopt the behavior of 'ref' post DIP25 Bit
Re: D casually mentioned and dismissed + a suggestion
On 5/13/2015 9:24 AM, Andrei Alexandrescu wrote: On 5/13/15 8:26 AM, Vladimir Panteleev wrote: So do we want a front page widget that's hosted on the wiki? That would be a good idea generally though it opens the site for vandalism. I'd say we start with a wiki page and work from there. -- Andrei I agree.
Re: Cannot Qualify Variadic Functions with Lazy Arguments as nothrow
On Thursday, 14 May 2015 at 10:18:13 UTC, Maxim Fomin wrote:
On Thursday, 14 May 2015 at 09:53:20 UTC, Per Nordlöw wrote:
At
https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L43
I've implemented a function either() with behaviour similar to
the `or` function/operator in dynamic languages such as Python
and Lisp.
I'm almost satisified with it except that the lazy evaluation
at
https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L45
cannot be made nothrow.
If I qualify the function as nothrow DMD complains as
algorithm_ex.d(45,16): Error: 'a' is not nothrow
algorithm_ex.d(46,29): Error: '_param_1' is not nothrow
I don't see a reason why any of these two cases should throw.
Lazy argument is essentially delegate/function. Currently there
is no
way to mark it as nothrow.
The same problem occurs if I make the implementation use only
one function and check the recursion termination case with
`static if (bs.length == 1)` instead.
Is there a workaround for this?
One way to address is to use delegate explicitly.
int foo(lazy int a) //nothrow
{
return a;
}
int bar(int delegate() nothrow dg) nothrow
{
return dg();
}
void main() nothrow
{
int a;
bar(()=a);
}
That does not feel right at all. D's filosophy is to infer these
things.Are you saying that I should create to overloads for the
leaf case of either(), namely one that takes a nothrow delegate
as argument and another overload that handles the throw case.
Further you example functions are not templates. either() must be
a template. Could you please show how to modify either() to use
your delegate-version instead.
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 --- Comment #6 from Martin Nowak c...@dawg.eu --- (In reply to safety0ff.bugz from comment #5) The first idea that came to mind was to add FINALIZE in _d_monitor_create, not sure if it'll work. Interesting idea. --
Re: Need a JQuery plugin for D
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?)
Re: A few thoughts on std.allocator
On 5/13/15 8:00 PM, Jakob Ovrum wrote:
On Wednesday, 13 May 2015 at 17:49:38 UTC, Steven Schveighoffer wrote:
OK, then consider that this:
void main()
{
string x;
x ~= hello;
x ~= world;
}
would require locking. That's unacceptable. Nobody would append with
strings if this all required locking for no reason. The runtime
currently does NOT lock for this case, it considers immutable and
const to be thread-local.
Well, it's necessary because the design of druntime arrays is
incompatible with D2's type system. Without locking, multi-threaded
applications that use dynamic array operations could easily contain some
particularly hard to track concurrency bugs.
I don't think we should go there. I would say it's very unlikely to have
this bug occur, but you are right it could occur. I just don't think
destroying append performance for all const and immutable array types is
worth it to fix the bug opportunity.
No, I think the answer is simpler. Introduce shared(immutable), and
then we can distinguish between immutable data that is shared and data
that is not shared. It also makes implementing local heaps easier.
Shared really is orthogonal to mutability.
Basically, shared(immutable(T)) would only be useful to allocators,
including arrays because they may need to allocate when growing. I don't
think it would be useful beyond that; the sharedness of immutable data
is probably not interesting to any other kind of code.
Yes, it really only matters for cases where the immutable pointer can be
used to obtain mutable data. But these are important cases.
The fact that most code doesn't share *at all*, makes it less of an
issue. Perhaps we need some way to indicate that when an array is
shared, it can no longer be appended in-place. It would be as simple as
flipping the APPENDABLE bit. The problem is, you're not always passing
the immutable array directly.
It would make immutable considerably harder to use than it is today.
shared(immutable(T)) would be implicitly convertible to
shared(const(T)), but not const(T), which precludes the vast majority of
mutation-agnostic D code out there today (I have never seen
shared(const(T)) used in the wild). We would no longer be able to do
even the simplest things, like passing a path string to another thread
and use std.file.read on it.
Yeah, there is no attribute that takes shared/unshared. I don't know a
good solution to that, and I understand that shared(immutable) screws up
most usages for immutable. It's not a good answer.
The problem is that when you share an immutable pointer, it changes the
rules for that pointer, but no type information has been altered. It's
impossible to track.
I think the idea of making immutable not shared by default is probably
not a good answer, but I don't know of a good one. I have a feeling
whatever answer we choose is going to be really painful :(
-Steve
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 --- Comment #5 from safety0ff.bugz safety0ff.b...@gmail.com --- (In reply to Martin Nowak from comment #4) I'm so tired of this reverting business, let's just fix the bug. We have 2 options - introduce a finalizeMonitor flag that tells the GC to only free the monitor - try to add a quickpath in rt_finalize2 to skip destruction, but keep the FINALIZE flag, even for classes without a dtor I think introducing another flag will be overhead for little gain (flags aren't cheap currently.) The first idea that came to mind was to add FINALIZE in _d_monitor_create, not sure if it'll work. I don't have the time for a fix that will require me to check the monitor source code, which is why I talked about reverting + comment. --
[Issue 14535] std.net.curl.CurlException should include status line
https://issues.dlang.org/show_bug.cgi?id=14535 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/81b4dcd17521ffdfbf39deb7dcd0a76686da3c44 fix Issue 14535 - std.net.curl.CurlException should include status line https://github.com/D-Programming-Language/phobos/commit/5eb7b54dc1d0d9e2e34ecd2b1f032a3d5f7574de Merge pull request #3257 from CyberShadow/pull-20150505-091936-curl fix Issue 14535 - std.net.curl.CurlException should include status line --
Re: problem with parallel foreach
On Thursday, 14 May 2015 at 10:46:53 UTC, Gerald Jansen wrote: John Colvin's improvements to my D program seem to have resolved the problem. (http://forum.dlang.org/post/ydgmzhlspvvvrbeem...@forum.dlang.org and http://dpaste.dzfl.pl/114d5a6086b7). I have rerun my tests and now the picture is a bit different (see tables below). In the middle table I have used gnu parallel in combination with a slightly modified version of the D program which runs a single trait (specified in argv[1]). This approach runs the jobs as completely isolated processes, but at the extra cost of re-reading the common data for each trait. The elapsed time is very similar with the parallel foreach in the D program or using gnu parallel (for this particular program and these data run on this server...). I'm guessing the program is now essentially limited by disk I/O, so this is about as good as it gets. So, just to wrap up: - there is a nice speed improvement over Python program :-) - one needs to learn a fair bit to fully benefit from D's potential - thanks for all the help! Gerald Jansen Jobs __ time for D parallel foreach w. JC mods 1 4.71user 0.56system 0:05.28elapsed 99%CPU 2 6.59user 0.96system 0:05.48elapsed 137%CPU 411.45user 1.94system 0:07.24elapsed 184%CPU 820.30user 5.18system 0:13.16elapsed 193%CPU 16 68.48user 13.87system 0:27.21elapsed 302%CPU 27 99.66user 18.73system 0:42.34elapsed 279%CPU Jobs __ gnu parallel + D program for single job __ 1 4.71user 0.56system 0:05.28elapsed 99%CPU as above 2 9.66user 1.28system 0:05.76elapsed 189%CPU 418.86user 3.85system 0:08.15elapsed 278%CPU 840.76user 7.53system 0:14.69elapsed 328%CPU 16 135.76user 20.68system 0:31.06elapsed 503%CPU 27 189.43user 28.26system 0:47.75elapsed 455%CPU Jobs _ time for python version _ 145.39user 1.52system 0:46.88elapsed 100%CPU 277.76user 2.42system 0:47.16elapsed 170%CPU 4 141.28user 4.37system 0:48.77elapsed 298%CPU 8 280.45user 8.80system 0:56.00elapsed 516%CPU 16 926.05user 20.48system 1:31.36elapsed 1036%CPU 27 1329.09user 27.18system 2:11.79elapsed 1029%CPU Would it be OK if I showed some parts of this code as examples in my DConf talk in 2 weeks?
Re: Clean way to tell whether a destructor is called by the GC
On Wednesday, 13 May 2015 at 11:24:10 UTC, Kagamin wrote: On Tuesday, 12 May 2015 at 12:53:59 UTC, ponce wrote: I already have such a dispose() function. The problem is that to support Unique! and scoped! and friends, the destructor must call dispose(). Thus my need for a way to separate the GC-induced destructors within dispose() or ~this (same problem). Maybe it's simpler to copy-paste Unique and scoped and modify them to handle disposable objects? But then we would need a standardized name (some use close, some use dispose, some use release) The closest thing we have to a standardized function name is the destructor.
Re: rvalue references
On Thursday, 14 May 2015 at 17:50:35 UTC, Andrei Alexandrescu wrote: On 5/14/15 10:15 AM, Namespace wrote: But interesting question, what will happen with scope, now that we have return ref. Evaluate its merit once we have everything else in. -- Andrei Short and meaningful. Thank you.
Re: Thoughts about the ideal programming language
On Thursday, 14 May 2015 at 06:02:37 UTC, thedeemon wrote: On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote: http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F Just some usual C++ critique and very vague basic principles about having a core language with some extensions and library support, nothing constructive or informative really. I generally agree with you. But his idea of language extension looks very nice, and as I think is similar to tendency in D make some features part of library (e.g. octal numbers, complex numbers). And verbalize such concept can make this tendency sharper and clearer and possible more productive. The last Andrej proposal for allocators may become example of such language extension. D specifies interface of allocators and introduce reference implementation, but for example embeded D provide other implementation.
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 Martin Nowak c...@dawg.eu changed: What|Removed |Added Assignee|nob...@puremagic.com|c...@dawg.eu --
How to simulate a new type
What are the downsides to simulating a new type with a struct.
What I have in mind is something along the lines of:
struct myType
{ uint64_t value;
}
The goal of this type is to prevent accidental conversions from myType
into ints, uint64_ts, etc.
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull --- Comment #8 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/druntime/pull/1272 --
Re: Let's improve D's exceptions
On 5/14/15 6:12 AM, Jacob Carlborg wrote:
On 2015-05-14 00:55, Steven Schveighoffer wrote:
enforce is one of the most needless pieces of phobos:
enforce(cond, message);
vs.
if(!cond) throw new Exception(message);
And the second doesn't mess up inlining.
I think enforce could be boiler-plated better. The only verbose part of
the if version is the throwing and newing.
template throe(Etype = Exception)
{
void throe(Args...)(Args args, string file = __FILE__, size_t line =
__LINE__)
{
throw new Etype(args, file, line);
}
}
if(!cond) throe(message);
Now you're back to the same problem as enforce has. That it throws
Exception by default. It shouldn't have a default value for the
exception type.
Sure, but I wasn't arguing about that. I just don't like the utility of
enforce completely -- it provides very little value, and kills inlining.
BTW, it could be called raise as it's called in some other languages.
My symbol wasn't intended as a proposal, just something that sounds like
throw but without using the keyword :) raise would be fine.
Wait, you're in an io package, and you want to always throw IO
exceptions?
alias except = throe!IOException;
if(!cond) except(args, to, ioexception);
That is a bit better but I still think that IOException is too generic.
Streaming something over the network and trying to open a file is quite
different.
It was just an example, you can use whatever exception you want.
-Steve
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 --- Comment #4 from Martin Nowak c...@dawg.eu --- (In reply to safety0ff.bugz from comment #3) Probably best just to revert the commit in question for now and leave a comment in _d_newclass explaining why classes need the FINALIZE flag regardless. I'm so tired of this reverting business, let's just fix the bug. We have 2 options - introduce a finalizeMonitor flag that tells the GC to only free the monitor - try to add a quickpath in rt_finalize2 to skip destruction, but keep the FINALIZE flag, even for classes without a dtor --
Re: rvalue references
On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote: On Thu, 14 May 2015 02:56:46 -0400, Namespace rswhi...@gmail.com wrote: On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote: 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. Hmm.. so they are ;) 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. :) Makes sense, but if scope is dead, I assume it would have to be removed at some point. So I guess 'ref' could just take rvalues now that it's escape-proof right? Also, what becomes of the 'in' storage class? being just another word for 'const' seems like a waste. If it were up to me, I would say: 'scope' should be removed as a storage class, 'ref' should be left as is, and 'in' should adopt the behavior of 'ref' post DIP25 Bit As Andrei said several times (recently here: http://forum.dlang.org/thread/scaufixfdyyrbmijg...@forum.dlang.org?page=3#post-mit5lp:241kpt:241:40digitalmars.com) auto ref will take care about rvalue references. I've only hoped that I could get a schedule for that or at least a confirmation. :) But interesting question, what will happen with scope, now that we have return ref.
Re: rvalue references
On 5/14/15 10:15 AM, Namespace wrote: But interesting question, what will happen with scope, now that we have return ref. Evaluate its merit once we have everything else in. -- Andrei
[Issue 14573] [REG2.067] Extreme memory usage when `synchronized( object )` is used
https://issues.dlang.org/show_bug.cgi?id=14573 --- Comment #7 from Martin Nowak c...@dawg.eu --- (In reply to Martin Nowak from comment #6) Interesting idea. Even better would be to pick up the old explicit @monitor idea and finally implement it. https://github.com/D-Programming-Language/dmd/pull/3547 --
Re: Need a JQuery plugin for D
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!?
Re: Cannot Qualify Variadic Functions with Lazy Arguments as nothrow
On Thursday, 14 May 2015 at 09:53:20 UTC, Per Nordlöw wrote: I'm almost satisified with it except that the lazy evaluation at https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L45 cannot be made nothrow. If I qualify the function as nothrow DMD complains as algorithm_ex.d(45,16): Error: 'a' is not nothrow algorithm_ex.d(46,29): Error: '_param_1' is not nothrow https://issues.dlang.org/show_bug.cgi?id=12647
Re: Returning an empty range of a given type
On 5/13/15 10:58 PM, rcorre wrote:
Actually, this doesn't even seem to work with a custom range:
import std.range;
import std.stdio;
import std.algorithm;
struct MyContainer {
@nogc auto opSlice() {
struct Range {
@property bool empty() { return true; }
@property int front() { return 9; }
void popFront() { }
}
return Range();
}
}
/// Return a slice of aa[key], or an empty slice if not found
@nogc auto maybeGetRange(MyContainer[string] aa, string key) {
alias RangeType = typeof(MyContainer.init[]);
auto val = key in aa;
return (val is null) ? takeNone!RangeType :
(*val)[].take(size_t.max);
}
Is there any way to create an empty MyContainer.Range() without creating
a new container?
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; }
-Steve
Re: Need a JQuery plugin for D
On 05/12/2015 11:54 AM, Walter Bright wrote: https://i.stack.imgur.com/ssRUr.gif That is hilarious. And disturbing ;)
Re: D casually mentioned and dismissed + a suggestion
On Thursday, 14 May 2015 at 15:14:25 UTC, Dragos Carp wrote: On Wednesday, 13 May 2015 at 15:24:02 UTC, Andrei Alexandrescu wrote: It should be easy to update by the community, so a wiki might be a good start. So I saw three links, any others? -- Andrei My company have 2-3 positions open in Munich, unfortunately the current job listing is just in German. I'll see if I can get one also in English. Dragos Have you posted it here? There are German users as well.
[Issue 14539] +508KB (684KB - 1191KB) filesize increase Hello, world binary
https://issues.dlang.org/show_bug.cgi?id=14539 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #3 from Martin Nowak c...@dawg.eu --- Would be helpful to share any findings instead of just treating symptoms. Is the reason for the size increase some added imports? --
Re: Breaking changes in Visual C++ 2015
I think that besides all problems D have, the only one that mattered most and never was fixed was proper ARM support. Since dmd 1 I'm dreaming to ditch C++ for D on game development but this day never comes as it seems that there's always priorities(mostly justified) that postpone this. So I had to move to rust, which I'm my opinion is a subpar language comparing with D, but at least is moving on this direction.
Re: D casually mentioned and dismissed + a suggestion
On Wednesday, 13 May 2015 at 15:24:02 UTC, Andrei Alexandrescu wrote: It should be easy to update by the community, so a wiki might be a good start. So I saw three links, any others? -- Andrei My company have 2-3 positions open in Munich, unfortunately the current job listing is just in German. I'll see if I can get one also in English. Dragos
Re: Calypso: Direct and full interfacing to C++
On Wednesday, 13 May 2015 at 15:54:47 UTC, John Colvin wrote: That's great! I'm looking forward to being able to easily make direct use of some of the great C++ code out there. Are there are performance pitfalls to watch out for that are unique to the way calypso interfaces between D and C++? E.g. sneaky copies, implicit callbacks to keep things synced etc. There are a few: - Many simple non-POD C++ classes are being mapped to D classes instead of structs, for example QFlagsAlignmentFlag (qt5demo.d uses its alias Qt::Alignment) which is a wrapper around a single int but contains an overloaded assignment operator so is considered non-POD in C++. Same story for QString. string, vector, almost all STL types are non-POD too because they have base classes. So this may be inconvenient when trying to avoid heap allocations.. For QFlags and QString we could do more than just checking if the class/struct is POD according to the C++ definition (i.e we could ignore overloaded operators, which are allowed in D structs), but STL types will most likely stay that way. - For the time being when calling a C++ function taking a class value argument with FunctionB(new ClassA(...)), the ClassA instance is 1/GC-allocated 2/ctor is called 3/copied to the stack-allocated memory for the call. Whereas in C++ FunctionB(ClassA(...)) the ClassA constructor is directly called over the stack-allocated memory. In D there's no way to avoid the copy yet, I think we could mimic the C++ way but that'd involve another small alteration to the language. That's about it, I can't think of anything else, what's cool is that almost all symbols Calypso exposes are the C++ symbols themselves with no wrapper layer in-between, with a few exceptions such as overloaded operators opBinary!+ etc. which dispatch the call to the C++ operator mapped to a non-templated function (because the C++ overloaded operator might be virtual, it can't be mapped directly to a template).
Re: Breaking changes in Visual C++ 2015
Am Thu, 14 May 2015 15:00:32 + schrieb Victor victor.v.carva...@gmail.com: I think that besides all problems D have, the only one that mattered most and never was fixed was proper ARM support. proper arm support depends on your definition of arm support. GDC supports ARM/GLibc/Linux just as well as X86/GlibC/Linux. Only ARM/Android, ARM/iOS and ARM/BareMetal are not supported. That's more an OS than processor architecture thing though.
[Issue 14583] New: std.typecons.Rebindable works incorrectly with classes in which there is an 'alias this' to AA member.
https://issues.dlang.org/show_bug.cgi?id=14583
Issue ID: 14583
Summary: std.typecons.Rebindable works incorrectly with classes
in which there is an 'alias this' to AA member.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: jappleg...@gmail.com
I spent several hours to discover this very weird bug. :(
import std.typecons;
class Foo {
string[int] aa;
}
class Bar {
string[int] aa;
alias aa this;
}
void main() {
auto foo = new immutable Foo;
assert(rebindable(foo).get is foo); // ok
auto bar = new immutable Bar;
assert(rebindable(bar).get is bar); // fails
auto len = rebindable(bar).aa.length; // crash
}
Sometimes 'alias this' is very dangerous thing.
--
Re: std.parallelism equivalents for posix fork and multi-machine processing
On Wednesday, 13 May 2015 at 20:34:24 UTC, weaselcat wrote: On Wednesday, 13 May 2015 at 20:28:02 UTC, Laeeth Isharc wrote: Is there value to having equivalents to the std.parallelism approach that works with processes rather than threads, and makes it easy to manage tasks over multiple machines? I'm not sure if you're asking because of this thread, but see http://forum.dlang.org/thread/tczkndtepnvppggzm...@forum.dlang.org#post-tczkndtepnvppggzmews:40forum.dlang.org python outperforming D because it doesn't have to deal with synchronization headaches. I found D to be way faster when reimplemented with fork, but having to use the stdc API is ugly(IMO) It was also easy to get D very fast by just being a little more eager with IO and reducing the enormous number of little allocations being made.
Re: D casually mentioned and dismissed + a suggestion
On 5/14/15 8:14 AM, Dragos Carp wrote: On Wednesday, 13 May 2015 at 15:24:02 UTC, Andrei Alexandrescu wrote: It should be easy to update by the community, so a wiki might be a good start. So I saw three links, any others? -- Andrei My company have 2-3 positions open in Munich, unfortunately the current job listing is just in German. I'll see if I can get one also in English. Dragos Sorry, I've forgotten your company's name. What is it? -- Andrei
Re: Returning an empty range of a given type
On Thursday, 14 May 2015 at 12:40:57 UTC, rcorre wrote:
So I thought this might work:
struct MaybeEmpty(R) if (isInputRange!R) {
private bool _isEmpty;
private R_input;
alias _input this;
this(bool isEmpty, R input) {
_input = input;
_isEmpty = isEmpty;
}
@property bool empty() {
return _isEmpty || _input.empty;
}
}
auto maybeEmpty(R)(bool empty, R input = R.init) if
(isInputRange!R) {
return MaybeEmpty!R(empty, input);
}
It's kind of ugly, but it can be used like:
auto a = maybeEmpty!MyRange(true);
auto b = maybeEmpty!MyRange(false, actualRange);
static assert(is(typeof(a) == typeof(b)));
However, it fails the input range test:
static assert(isInputRange!MyRange); //pass
static assert(isInputRange!(typeof(a))); // fail
But it seems to be something weird with cross-module template
instantiation. If I replace `import std.range` with a
copy-paste of `isInputRange`, the above passes.
Either that or I'm doing something stupid because I'vebeen
staring at this too long.
I'm wondering if the isInputRange thing is a bug, so here's a
gist if anyone wants to play with it:
https://gist.github.com/rcorre/7a62395c53baf3c0bfbc
How about a more flexible solution?
http://dpaste.dzfl.pl/2f99cc270651
[Issue 14539] +508KB (684KB - 1191KB) filesize increase Hello, world binary
https://issues.dlang.org/show_bug.cgi?id=14539 --- Comment #4 from Martin Nowak c...@dawg.eu --- (In reply to Martin Nowak from comment #3) Would be helpful to share any findings instead of just treating symptoms. Is the reason for the size increase some added imports? https://github.com/D-Programming-Language/phobos/pull/2956#issuecomment-99328828 --
Re: Breaking changes in Visual C++ 2015
On 14 May 2015 at 17:40, Johannes Pfau via Digitalmars-d digitalmars-d@puremagic.com wrote: Am Thu, 14 May 2015 15:00:32 + schrieb Victor victor.v.carva...@gmail.com: I think that besides all problems D have, the only one that mattered most and never was fixed was proper ARM support. proper arm support depends on your definition of arm support. GDC supports ARM/GLibc/Linux just as well as X86/GlibC/Linux. Only ARM/Android, ARM/iOS and ARM/BareMetal are not supported. That's more an OS than processor architecture thing though. We still have one disrepency in runtime though (LTR vs. RTL): https://github.com/D-Programming-Language/dmd/pull/4035 I say that, however, there are infact two discrepencies (this exists on GDC x86 vs DMD x86): https://github.com/D-Programming-Language/dmd/pull/3670 I'll be happy the day DMD stops using it's own (non-conforming to spec) ABI. Iain.
Re: Array of objects and their inheritance
On Thursday, 14 May 2015 at 19:00:16 UTC, tired_eyes wrote:
First, I don't understand why we see array[2] as 'Child'. While
it is a 'Child', shouldn't it be shown as a 'Parent' due to we
explicitly create an array of 'Parents'?
It is getting the name through a virtual interface (a hidden one
that has typeinfo).
class Base {
string getName() { return Base; }
}
class Derived : Base {
override string getName() { return Derived; }
}
Base b = new Derived();
b.getName() == Derived; // because the virtual function can
still be called through an interface
Well, if it's still a 'Child', why we can't access it's fields?
It is a Child object, but you are talking to it through the
Parent interface, so only functions+members available on Parent
can be accessed without casting it.
And what is the proper way of storing a collection of inherited
objects without losing access to their fields and methods?
Best you can do is say
if(child = cast(Child) parentArray[0]) {
// it is a child, now use child to access that
}
Though often a better way is to add an interface method that does
it in the parent and is overridden in the child, just like with
the getName above.
Re: rvalue references
Don't ask me, I'm just a little light here. But I think it's because 'in' means 'const scope' and as you said, scope is out. ;)
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 20:03:16 UTC, ivoras wrote: Where would I look for documentation on the ~= operator? http://dlang.org/arrays.html under the heading array concatenation What would be the difference between Array!string and string[] ? Array!string takes ownership of its own memory and frees it when no longer used making it appropriate in cases where you want that optmization. string[] is a slice - pointer plus length combination - into externally managed memory.
Re: std.parallelism equivalents for posix fork and multi-machine processing
On Thursday, 14 May 2015 at 20:15:38 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 May 2015 at 20:06:55 UTC, Laeeth Isharc wrote: To start the process off (because small beginnings are better than no beginning): what are the key features of processes vs threads one would need to bear in mind when designing such a thing? Because I spent the past couple of decades in a different field, multiprocessing passed me by, so I am only now slowly catching up. nobody understands multiprocessing. Or rather… you need to understand the hardware and the concrete problem space first. There are no general solutions. Yes, I certainly understand that it is a highly specialist and complex area where the best minds in the world have not yet the answers. So if one were addressing the problem from a computer science academic perspective, then perhaps one will arrive at a different answer. My own is a pragmatic commercial one. I have some problems which perhaps scale quite well, and rather than write it using fork directly, I would rather have a higher level wrapper along the lines of std.parallelism. Perhaps such would be flawed and limited, but often something is better than nothing, even if not perfect. And I mention it on the forum only because usually I have found the problems I face turn out to be those faced by many others too.. If you have any thoughts on what should be considered, I would very much appreciate them. (And I owe you a response on our last suspended discussion, but haven't had time of late). Laeeth.
Re: How to simulate a new type
On Thursday, 14 May 2015 at 18:42:56 UTC, Charles Hixson wrote:
What are the downsides to simulating a new type with a struct.
What I have in mind is something along the lines of:
struct myType
{ uint64_t value;
}
The goal of this type is to prevent accidental conversions from
myType into ints, uint64_ts, etc.
http://dlang.org/phobos/std_typecons.html#.Typedef
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 20:32:28 UTC, rumbu wrote: On Thursday, 14 May 2015 at 20:03:16 UTC, ivoras wrote: What would be the difference between Array!string and string[] ? std.array is used to manipulate or create built-in arrays from various sources (ranges). For basic needs, you can safely use built-in arrays: http://dlang.org/arrays.html Concatenation operator (~) is documented here: http://dlang.org/arrays.html#array-concatenation Thanks, everyone! 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?
Re: std.parallelism equivalents for posix fork and multi-machine processing
On Thursday, 14 May 2015 at 20:06:55 UTC, Laeeth Isharc wrote: To start the process off (because small beginnings are better than no beginning): what are the key features of processes vs threads one would need to bear in mind when designing such a thing? Because I spent the past couple of decades in a different field, multiprocessing passed me by, so I am only now slowly catching up. nobody understands multiprocessing. Or rather… you need to understand the hardware and the concrete problem space first. There are no general solutions.
Re: Calypso: Direct and full interfacing to C++
Elie, Congratulations on this very impressive work. Out of curiosity, how far away do you think it is from being at a beta stage that one can use to write non-critical work in ? One open source library that might not be too tough but would have high value in the financial domain is Quantlib. (I don't think it is heavily templated, but I don't yet know the codebase well). https://github.com/lballabio/quantlib Also, I am embarrassed to confess that I still have trouble building calypso (although I can build LDC fine). Specifically some symbols not found during compilation. I can pull them out if helpful, but I have tried several times over the past months and it is different ones each time. Which commit of Calypso should I use, and which versions of clang and llvm? I am using arch linux. Laeeth.
Re: Thoughts about the ideal programming language
On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote: Hi, I think that many will find something interesting in this article: - https://translate.google.ru/translate?hl=rusl=rutl=enu=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F - Sorry translated using google translate. Can few to say regarding your thoughts, but need to mention that that site is the only significant one I am aware of with anti-technical, inflated, self - important culture of discussion (this has nothing to do with your post particular).
Re: std.parallelism equivalents for posix fork and multi-machine processing
On Thursday, 14 May 2015 at 20:28:20 UTC, Laeeth Isharc wrote: My own is a pragmatic commercial one. I have some problems which perhaps scale quite well, and rather than write it using fork directly, I would rather have a higher level wrapper along the lines of std.parallelism. Languages like Chapel and extended versions of C++ have built in support for parallel computing that is relatively effortless and designed by experts (Cray/IBM etc) to cover common patterns in demanding batch processing for those who wants something higher level than plain C++ (or in this case D which is pretty much the same thing). However, you could consider combining single threaded processes in D with e.g. Python as a supervising process if the datasets allow it. You'll find lots of literature on Inter Process Communication (IPC) for Unix. Performance will be lower, but your own productivity might be higher, YMMV. Perhaps such would be flawed and limited, but often something is better than nothing, even if not perfect. And I mention it on the forum only because usually I have found the problems I face turn out to be those faced by many others too.. You need momentum in order to get from a raw state to something polished, so you essentially need a larger community that both have experience with the topic and a need for it in order to get a sensible framework that is maintained. If you can get away with it, the most common simplistic approach seems to be map-reduce. Because it is easy to distribute over many machines and there are frameworks that do the tedious bits for you. If you have any thoughts on what should be considered, I would very much appreciate them. (And I owe you a response on our last suspended discussion, but haven't had time of late). Nah, you owe me nothing ;-). And I also have no time atm. ;-) Ola.
Array of objects and their inheritance
Hi.
I'm having a hard time understanding D's inheritance. Consider
the following code:
class Parent {
public int x = 10;
}
class Child : Parent {
public int y = 20;
}
void main() {
import std.stdio;
Parent[] array;
auto obj1 = new Parent();
auto obj2 = new Child();
array ~= obj1;
array ~= obj2;
writeln(array[0]); // prints Parent, as expected
writeln(array[1]); // prints Child, so I assume that if
it's a Child, we can access Child's fields
writeln(array[0].x); // 10
writeln(array[1].y); // Error: no property 'y' for type
'Parent'
}
First, I don't understand why we see array[2] as 'Child'. While
it is a 'Child', shouldn't it be shown as a 'Parent' due to we
explicitly create an array of 'Parents'?
Well, if it's still a 'Child', why we can't access it's fields?
And what is the proper way of storing a collection of inherited
objects without losing access to their fields and methods?
Please point me in the right direction. I'm (still) relatively
new to D, and will appreciate any help.
Re: What wrong?
On Tuesday, 5 May 2015 at 07:41:04 UTC, sclytrack wrote:
On Monday, 4 May 2015 at 01:03:43 UTC, Fyodor Ustinov wrote:
On Saturday, 2 May 2015 at 20:46:32 UTC, Dennis Ritchie wrote:
On Saturday, 2 May 2015 at 19:38:01 UTC, Fyodor Ustinov wrote:
I see it by the lack of 42. :)
But why is this receive breaks down?
import std.stdio;
import std.variant;
struct SoMany
{
int number = 10;
~this()
{
writeln(number);
}
}
void main()
{
Variant v = SoMany();
}
DMD64 D Compiler v2.067.1
10
10
10
10
gdc (Debian 4.9.2-10) 4.9.2
10
10
For DMD I'm getting 4x10 and for gdc 2x10
Re: rvalue references
On Thu, 14 May 2015 13:15:34 -0400, Namespace rswhi...@gmail.com wrote: On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote: If it were up to me, I would say: 'scope' should be removed as a storage class, 'ref' should be left as is, and 'in' should adopt the behavior of 'ref' post DIP25 Bit As Andrei said several times (recently here: http://forum.dlang.org/thread/scaufixfdyyrbmijg...@forum.dlang.org?page=3#post-mit5lp:241kpt:241:40digitalmars.com) auto ref will take care about rvalue references. I've only hoped that I could get a schedule for that or at least a confirmation. :) If I understand Andrei's response correctly though, you will still have to use 'auto ref' to get ref to bind to rvalues.. no? So if I'm right about the above, and scope is out, why not just use 'in' instead of 'auto ref'? Bit
Re: std.parallelism equivalents for posix fork and multi-machine processing
On Thursday, 14 May 2015 at 16:33:46 UTC, John Colvin wrote: On Wednesday, 13 May 2015 at 20:34:24 UTC, weaselcat wrote: On Wednesday, 13 May 2015 at 20:28:02 UTC, Laeeth Isharc wrote: Is there value to having equivalents to the std.parallelism approach that works with processes rather than threads, and makes it easy to manage tasks over multiple machines? I'm not sure if you're asking because of this thread, but see http://forum.dlang.org/thread/tczkndtepnvppggzm...@forum.dlang.org#post-tczkndtepnvppggzmews:40forum.dlang.org python outperforming D because it doesn't have to deal with synchronization headaches. I found D to be way faster when reimplemented with fork, but having to use the stdc API is ugly(IMO) It was also easy to get D very fast by just being a little more eager with IO and reducing the enormous number of little allocations being made. Yes - thank you for your highly educational rewrite, which I personally very much appreciate your taking the trouble to do. Perhaps this should be turned (by you or someone else) into a mini case-study on the wiki of how to write idiomatic and efficient D code. Or maybe just put up the slides from your forthcoming talk (which I look forward to watching later when it is up). It's good to know D can in fact deliver on the implicit promise in a real use case with not too much work. (Yes, naively written code was a bit slow when dealing with millions of lines, but in which language of comparable flexibility would that not be true). It's also interesting that your code was idiomatic. (I was reading up about Scala, which seems beautiful in many ways, but it is terribly disturbing to see that the idiomatic way often seems to be the most inefficient, at least as things stood a couple of years ago). But, even so, I think having a wrapper for fork and an API for multiprocessing (which you could then hook up to eg the Digital Ocean, AWS apis etc) would be rather helpful. I spoke with a friend of mine at one of the most admired/hated Wall Street firms. One of the smartest quants I know who has now moved to portfolio management. He was doing a study on tick data going back to 2000. I asked him how long it took to run on his firm's infrastructure. An hour! And the operations were pretty simple. I think it should only take a couple of minutes. And it would be nice to show an example of - from a spreadsheet - spinning up 100 digital ocean instances - and running the numbers not just on one security, but every relevant security, and having a nice summary appear back in the sheet within a couple of minutes. The reason speed matters is that long waits interfere with rapid iteration and the creative thought process. In a market environment you may well have forgotten what you wanted after an hour... Laeeth.
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 13:50:17 UTC, Adam D. Ruppe wrote: On Thursday, 14 May 2015 at 13:26:27 UTC, ivoras wrote: Is it resizable? You can append with the ~= operator and size down by slicing it. Apparently it doesn't even have an insert method: http://dlang.org/phobos/std_array.html . http://dlang.org/phobos/std_array.html#insertInPlace is the one you'd use for that. Ok, string[] and ~= work and it doesn't crash now. Where would I look for documentation on the ~= operator? It's not described in http://dlang.org/phobos/std_array.html (though it is mentioned so you need to know what you are looking for before you find it...). What would be the difference between Array!string and string[] ?
Re: rvalue references
On Thursday, 14 May 2015 at 20:02:29 UTC, bitwise wrote: On Thu, 14 May 2015 13:15:34 -0400, Namespace rswhi...@gmail.com wrote: On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote: If it were up to me, I would say: 'scope' should be removed as a storage class, 'ref' should be left as is, and 'in' should adopt the behavior of 'ref' post DIP25 Bit As Andrei said several times (recently here: http://forum.dlang.org/thread/scaufixfdyyrbmijg...@forum.dlang.org?page=3#post-mit5lp:241kpt:241:40digitalmars.com) auto ref will take care about rvalue references. I've only hoped that I could get a schedule for that or at least a confirmation. :) If I understand Andrei's response correctly though, you will still have to use 'auto ref' to get ref to bind to rvalues.. no? Yes, that's what I said. :) Besides, it would be horrible if rvalues could be bound to normal ref. So if I'm right about the above, and scope is out, why not just use 'in' instead of 'auto ref'? Bit Don't ask me, I'm just a little light here.
Re: std.parallelism equivalents for posix fork and multi-machine processing
On Thursday, 14 May 2015 at 10:15:48 UTC, Daniel Murphy wrote: Laeeth Isharc wrote in message news:ejbhesbstgazkxnpv...@forum.dlang.org... Is there value to having equivalents to the std.parallelism approach that works with processes rather than threads, and makes it easy to manage tasks over multiple machines? I took a look at std.parallelism and it's beyond what I can do for now. But it seems like this might be a useful project, and not one of unmanageable difficulty... Yes, there is enormous value. It's just waiting for someone to do it. To start the process off (because small beginnings are better than no beginning): what are the key features of processes vs threads one would need to bear in mind when designing such a thing? Because I spent the past couple of decades in a different field, multiprocessing passed me by, so I am only now slowly catching up.
Re: Dynamic / resizable array type, and a crash problem
On Thursday, 14 May 2015 at 20:03:16 UTC, ivoras wrote: What would be the difference between Array!string and string[] ? std.array is used to manipulate or create built-in arrays from various sources (ranges). For basic needs, you can safely use built-in arrays: http://dlang.org/arrays.html Concatenation operator (~) is documented here: http://dlang.org/arrays.html#array-concatenation
Re: std.allocator: plea for contributions
On 5/13/15 2:19 PM, Atila Neves wrote: Tried to, couldn't get it to compile with git HEAD. Could you please post the dmd and druntime git hashes, or are those forks as well? Thanks for looking into it! Here's what I have: dmd - acbe13ee54e024c0bba044d1146e244a5ea57502 druntime - 18d57ffe3eed8674ca2052656bb3f410084379f6 I haven't rebased phobos in a while, maybe that's the matter. What errors are you getting? Thanks, Andrei
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?) 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?
Re: D casually mentioned and dismissed + a suggestion
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
Re: D casually mentioned and dismissed + a suggestion
On Thursday, 14 May 2015 at 16:28:01 UTC, Andrei Alexandrescu wrote: On 5/14/15 8:14 AM, Dragos Carp wrote: On Wednesday, 13 May 2015 at 15:24:02 UTC, Andrei Alexandrescu wrote: It should be easy to update by the community, so a wiki might be a good start. So I saw three links, any others? -- Andrei My company have 2-3 positions open in Munich, unfortunately the current job listing is just in German. I'll see if I can get one also in English. Dragos Sorry, I've forgotten your company's name. What is it? -- Andrei Funkwerk Aktiengesellschaft, Traffic Control Communication http://funkwerk-itk.com/funkwerk_itk_en/ The job posting [1] is not targeted for people knowing D already, if necessary a training period is allowed. Dragos [1] http://funkwerk-itk.com/funkwerk_itk_de/imagepool/jobs/SoftwareEntwickler.pdf
Re: Feature or bug: print braces
On 05/14/2015 03:39 PM, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 21:55:40 UTC, Alex Parrill wrote:
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something like:
-
writeln({}); // prints literal[{}]
Or the compiler will not be able to distinguish the literal from the
ordinary function arguments?
Literal what?
Associative array? That uses square brackets, not curly brackets.
Struct? What struct would you be creating? And curly braces only works
for initialization.
Lambda? Well you can omit the parameters if there are none, and `{}`
in a lambda will give you a block to write, so `{}` is a valid lambda
that accepts nothing and does nothing.
I just wanted to say that writeln function of demand should not print
anything else at this challenge, not 804CF88 :)
-
writeln({});
Yes, it is weird but that value happens to be the address of the
function. Here is another test:
import std.stdio;
void foo() pure nothrow @nogc @safe
{}
void main()
{
void printInfo(T)(T t)
{
writefln(%s %s, T.stringof, t);
}
auto f = (){};// -- Why the need for () here?
printInfo(foo);
printInfo(f);
printInfo({});// -- No need for () here.
}
There is an inconsistency where a lambda need to be defined with empty
parentheses in one context while it is just fine without in another context.
One output shows that they are all of the same type (function pointers):
void function() pure nothrow @nogc @safe 473264
void function() pure nothrow @nogc @safe 4732BC
void function() pure nothrow @nogc @safe 4732C4
Ali
[Issue 14584] New: spurious autotester deadlocks
https://issues.dlang.org/show_bug.cgi?id=14584 Issue ID: 14584 Summary: spurious autotester deadlocks Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Happens in multithreading unittests such as core.sync.rwmutex or core.sync.semaphore. I just encountered a process that dead-locks in the the newly added synchronized statement of the rt.trace tls dtor. https://github.com/D-Programming-Language/druntime/commit/01087ce464d3b905d16e55799d02b710fcdd9939#commitcomment-11204041 --
[Issue 14584] spurious autotester deadlocks
https://issues.dlang.org/show_bug.cgi?id=14584 Martin Nowak c...@dawg.eu changed: What|Removed |Added Severity|enhancement |major --
[Issue 14584] spurious autotester deadlocks
https://issues.dlang.org/show_bug.cgi?id=14584 --- Comment #1 from Martin Nowak c...@dawg.eu --- I ran a debug build of druntime and the mutex was unlocked too often (__count == -1). The double checked locking bug in rt.critical_ (https://github.com/D-Programming-Language/druntime/blob/e840f588d6cdc1386a1f4b1fcf7502ba171efd33/src/rt/critical_.d#L169) might be the cause. --
Re: Feature or bug: print braces
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something like:
-
writeln({}); // prints literal[{}]
Or the compiler will not be able to distinguish the literal
from the ordinary function arguments?
Literal what?
Associative array? That uses square brackets, not curly brackets.
Struct? What struct would you be creating? And curly braces only
works for initialization.
Lambda? Well you can omit the parameters if there are none, and
`{}` in a lambda will give you a block to write, so `{}` is a
valid lambda that accepts nothing and does nothing.
Re: Feature or bug: print braces
On Thursday, 14 May 2015 at 21:55:40 UTC, Alex Parrill wrote:
On Thursday, 14 May 2015 at 00:39:25 UTC, Dennis Ritchie wrote:
On Thursday, 14 May 2015 at 00:33:33 UTC, Brian Schott wrote:
You told it to output a function literal, so it did.
Yes, but it would be logical to deduce something like:
-
writeln({}); // prints literal[{}]
Or the compiler will not be able to distinguish the literal
from the ordinary function arguments?
Literal what?
Associative array? That uses square brackets, not curly
brackets.
Struct? What struct would you be creating? And curly braces
only works for initialization.
Lambda? Well you can omit the parameters if there are none, and
`{}` in a lambda will give you a block to write, so `{}` is a
valid lambda that accepts nothing and does nothing.
I just wanted to say that writeln function of demand should not
print anything else at this challenge, not 804CF88 :)
-
writeln({});
[Issue 14584] spurious autotester deadlocks
https://issues.dlang.org/show_bug.cgi?id=14584 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull --- Comment #2 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/druntime/pull/1274 --
Re: How to simulate a new type
On 05/14/2015 01:42 PM, Laeeth Isharc via Digitalmars-d-learn wrote:
On Thursday, 14 May 2015 at 18:42:56 UTC, Charles Hixson wrote:
What are the downsides to simulating a new type with a struct.
What I have in mind is something along the lines of:
struct myType
{ uint64_t value;
}
The goal of this type is to prevent accidental conversions from
myType into ints, uint64_ts, etc.
http://dlang.org/phobos/std_typecons.html#.Typedef
Yes, that looks as if it would do the job, but what are its advantages
over a simple struct? I'd be hesitant to try to predict the RAM layout
of a templated variable, but it's my understanding that a struct has
neither compile time nor runtime penalties over a simple variable, and
that it doesn't increase RAM comsumption when included within another
struct, or in a static array.
What I was really wondering was whether the limitation of access caused
by enclosing a variable within a struct was worth the benefit.
Templates add a whole 'nother layer of complexity. For that matter I
was thinking that, if I so chose, I could at some point add limits along
the lines of Ada's types. I like being *able* to define conversions for
types, but frequently I'd rather not have them arbitrarily assumed.
Otherwise I'd just use alias, which almost does what I want. (E.g., one
thing I might eventually want to do is use a couple of bits at the top
of the uint64_t as flags, so if I did define operations I'd need to be
able to mask the flag bits off before the operation and reapply them to
the result, in some defined way of combining the flags. Not good if
sometimes the value is going to be automatically reinterpreted as a
plain number.)
Re: How to simulate a new type
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.
Re: Calypso: Direct and full interfacing to C++
On Thursday, 14 May 2015 at 20:23:47 UTC, Laeeth Isharc wrote: Elie, Congratulations on this very impressive work. Out of curiosity, how far away do you think it is from being at a beta stage that one can use to write non-critical work in ? Thanks Laeeth, It's not too far I think. When finally comes the time when I can test one or two new complex libraries without triggering new bugs it should be good enough. At the moment I'm focusing on libraries that depend on Boost and are one order of magnitude more sophisticated than Qt, once they work the way out to usable state with any library may be in sight. One open source library that might not be too tough but would have high value in the financial domain is Quantlib. (I don't think it is heavily templated, but I don't yet know the codebase well). https://github.com/lballabio/quantlib Also, I am embarrassed to confess that I still have trouble building calypso (although I can build LDC fine). Specifically some symbols not found during compilation. I can pull them out if helpful, but I have tried several times over the past months and it is different ones each time. Missing symbols might be caused by your LLVM source tree having a different version from Arch's LLVM libraries. The changes made to LDC's CMake file are very primitive and won't check if the selected LLVM include/ and libraries match the one in LLVM_SOURCE_PATH added by Calypso. If you built and installed LLVM + Clang 3.6 yourself to /usr/local and if there's a different version from Arch packages in /usr, check that cmake got the right LLVM_CONFIG path with: $ cmake -LA |grep LLVM If it didn't fix the value with $ cmake -DLLVM_CONFIG=/usr/local/bin/llvm-config ../Calypso Which commit of Calypso should I use, and which versions of clang and llvm? I am using arch linux. The versions are the ones in the README, i.e the 3.6 branch of LLVM, Clang and compiler-rt. I'll add a note about the not very smart detection of LLVM libs, and if some of the instructions in the README are still confusing or incomplete please tell me.
Re: Feature or bug: print braces
On Thursday, 14 May 2015 at 22:55:43 UTC, Ali Çehreli wrote:
Yes, it is weird but that value happens to be the address of
the function. Here is another test:
import std.stdio;
void foo() pure nothrow @nogc @safe
{}
void main()
{
void printInfo(T)(T t)
{
writefln(%s %s, T.stringof, t);
}
auto f = (){};// -- Why the need for () here?
printInfo(foo);
printInfo(f);
printInfo({});// -- No need for () here.
}
There is an inconsistency where a lambda need to be defined
with empty parentheses in one context while it is just fine
without in another context.
One output shows that they are all of the same type (function
pointers):
void function() pure nothrow @nogc @safe 473264
void function() pure nothrow @nogc @safe 4732BC
void function() pure nothrow @nogc @safe 4732C4
Ali
Thanks. This example explains a lot. It's like echoes UFCS :)
Re: rvalue references
On Thu, 14 May 2015 16:12:36 -0400, Namespace rswhi...@gmail.com wrote: Don't ask me, I'm just a little light here. But I think it's because 'in' means 'const scope' and as you said, scope is out. ;) Which means 'in' is available! ;) Bit
Re: std.parallelism equivalents for posix fork and multi-machine processing
On Thursday, 14 May 2015 at 20:56:16 UTC, Ola Fosheim Grøstad wrote: On Thursday, 14 May 2015 at 20:28:20 UTC, Laeeth Isharc wrote: My own is a pragmatic commercial one. I have some problems which perhaps scale quite well, and rather than write it using fork directly, I would rather have a higher level wrapper along the lines of std.parallelism. Languages like Chapel and extended versions of C++ have built in support for parallel computing that is relatively effortless and designed by experts (Cray/IBM etc) to cover common patterns in demanding batch processing for those who wants something higher level than plain C++ (or in this case D which is pretty much the same thing). Yes - I am sure that there is excellent stuff here, from which one may learn much: especially if approaching it from a more theoretical or enterprisey industrial scale perspective. However, you could consider combining single threaded processes in D with e.g. Python as a supervising process if the datasets allow it. You'll find lots of literature on Inter Process Communication (IPC) for Unix. Performance will be lower, but your own productivity might be higher, YMMV. 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. 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!) Perhaps such would be flawed and limited, but often something is better than nothing, even if not perfect. And I mention it on the forum only because usually I have found the problems I face turn out to be those faced by many others too.. You need momentum in order to get from a raw state to something polished, so you essentially need a larger community that both have experience with the topic and a need for it in order to get a sensible framework that is maintained. 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. I am no Walter Bright, but this is an easier problem to start exploring, and this would be beyond the scope of anything I would do just by myself. If you can get away with it, the most common simplistic approach seems to be map-reduce. Because it is easy to distribute over many machines and there are frameworks that do the tedious bits for you. 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. Nice chatting. Laeeth.
[Issue 14578] [ddemangle] core.exception.InvalidMemoryOperationError@(0) handling large symbol list
https://issues.dlang.org/show_bug.cgi?id=14578
--- Comment #4 from Iain Buclaw ibuc...@gdcproject.org ---
OK, got a reduced test:
---
import std.stdio;
void main()
{
foreach (line; stdin.byLine())
{
}
}
---
Only require two lines of stdin with the following constraints:
#1 Line: Length = 510 Length = 1021
#2 Line: Length == 1023
--
[Issue 14578] [ddemangle] core.exception.InvalidMemoryOperationError@(0) handling large symbol list
https://issues.dlang.org/show_bug.cgi?id=14578
ag0ae...@gmail.com changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #5 from ag0ae...@gmail.com ---
(In reply to Iain Buclaw from comment #4)
OK, got a reduced test:
---
import std.stdio;
void main()
{
foreach (line; stdin.byLine())
{
}
}
---
Only require two lines of stdin with the following constraints:
#1 Line: Length = 510 Length = 1021
#2 Line: Length == 1023
Duplicate of issue 14005 and in turn of issue 13856?
--
Re: Thoughts about the ideal programming language
On Thursday, 14 May 2015 at 06:02:37 UTC, thedeemon wrote: On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote: http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F Just some usual C++ critique and very vague basic principles about having a core language with some extensions and library support, nothing constructive or informative really. The author develops his own ideal programming language and is based on his tongue D. Actually, currently the best candidate for the common languages - this is D, which proves this article. I agree completely. I among evernote-notes, where I keep the idea of the differences in programming languages, rather big section is dedicated IDE; the design language to take into account a bunch of IDE (in particular, the syntax of the language should be structured in such a way that it is convenient to work avtokompilitu, Tree Builder classes and other tools IDE, which should work on the fly); I did point out specific recommendations to the IDE, by organizing projects, etc., which are usually in the language is not included. And one of the first things with which I began experimenting with my compiler (fork D) - is to write a simple IDE for Qt and do visualizer AST (and then will visualizers all transformations within the compiler, up to the code generator). That is not only to use the compiler, but even without it razrarabyvat GUI uncomfortable.
Re: Returning an empty range of a given type
On Thursday, 14 May 2015 at 06:41:45 UTC, Ali Çehreli wrote: I am lucky because although the returned type is opaque to me, I know that it is constructed by a void lambda. Yeah, in this case I control the container so I may just add an emptySlice property, but it does seem like it might be a common need (to return an empty range of a given type without having that range constructed beforehand).
Re: Thoughts about the ideal programming language
On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote: http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F Just some usual C++ critique and very vague basic principles about having a core language with some extensions and library support, nothing constructive or informative really.
