Re: Invoking writeln() from a lot of threads running concurrently --> crash
On Saturday, 9 December 2017 at 09:38:05 UTC, IM wrote:
For purposes of debugging, I'm using writeln() to print stuff
out from tasks running concurrently on many threads. At some
point it crashes with the following stack trace:
Thread 4 received signal SIGUSR1, User defined signal 1.
[...]
Bug in phobos?
Is that a crash or just thread 4 receiving SIGUSR1? (GC signal)
If so you just need to tell gdb not to stop on that. ("handle
SIGUR1 SIGUSR2 nostop", place it in ~/.gdbinit)
Re: What is the best way to stop App after exception?
On Monday, 15 February 2016 at 15:17:01 UTC, tcak wrote: [...] BUT (This is a big but with single t), in multithreaded process, throwing Error in a thread that is not the main thread won't stop your process still and you are still left with "exit" function. Mind, if you're doing the normal message passing thread dance, you can do periodic checks for an OwnerTerminated message. http://melpon.org/wandbox/permlink/jxAzU0fcsnouMa9z
Re: How to force evaluation of range?
On Friday, 12 February 2016 at 20:43:24 UTC, Taylor Hillegeist
wrote:
So I have this code and I have to add the element
.each!(a => a.each!("a"));
to the end in order for it to evaluate the range completely and
act like I expect it too. Is there a better thing to put in
the place of
.each!(a => a.each!("a"));?
[...]
dirEntries(Args[1], SpanMode.depth)
.filter!(f => f.name.endsWith(".c",".h"))
.tee!(a => writeln("\n",a,"\n\t","=".repeat(80).join))
.map!(a => a
.File("r")
.byLine
.enumerate
.filter!( l => l.value.byGrapheme.walkLength > 80)
.tee!(a => writeln("Line: ",a.index,"\t",a.value))
).each!(a => a.each!("a")); //Force evaluation of
every item
}
Have you tried .array? I *think* it's the commonly used way to
flatten a lazy range.
Re: Why this code can't take advantage from CTFE?
On Wednesday, 3 February 2016 at 15:59:43 UTC, Adam D. Ruppe wrote: You never asked for CTFE. CTFE only happens when it *has* to - when you write code that specifically asks for or requires it. What is a good way to try to force it? Using enum? Then optionally copying the value once to avoid the "manifest constant" copy/paste behaviour, where applicable?
Re: Why this code can't take advantage from CTFE?
On Wednesday, 3 February 2016 at 17:16:30 UTC, Andrea Fontana wrote: But if I want a normal var, not static or enum? There's no way to force it? Just make a mutable copy of it, I think.
Re: Regex benchmarks in Rust, Scala, D and F#
On Tuesday, 5 January 2016 at 20:04:35 UTC, rsw0x wrote: [...] Anyone on linux who could imgur a callgraph please? Premature optimisation and all that.
Re: How about appender.put() with var args?
On Thursday, 16 April 2015 at 03:53:56 UTC, Andrei Alexandrescu wrote: Sidetracking a bit, but when I started using Appender I was surprised to see that put didn't return a reference to the Appender itself. Had it done so, you could have chained your put calls very nicely. app.put(foo) .put(var) .put(bar) .put(more) .put(stuff); You can naturally write a small wrapper function that does this for you, but it still strikes me as odd. Sadly I imagine changing the return type would make the function signature mangle differently, breaking ABI compatibility. Does ~= chain? -- Andrei I'm not sure I understand. Appender!string app; app ~= hello ~= ~= kitty; -- Error: Cannot modify ' ' Is the order of evaluation not such that this becomes app ~= (hello ~= ( ~= kitty))?
Re: How about appender.put() with var args?
On Wednesday, 15 April 2015 at 19:09:42 UTC, Márcio Martins wrote: Hi! I use Appender a lot, and find it ugly to write this all the time to efficiently construct strings: app.put(foo); app.put(var); app.put(bar); Sidetracking a bit, but when I started using Appender I was surprised to see that put didn't return a reference to the Appender itself. Had it done so, you could have chained your put calls very nicely. app.put(foo) .put(var) .put(bar) .put(more) .put(stuff); You can naturally write a small wrapper function that does this for you, but it still strikes me as odd. Sadly I imagine changing the return type would make the function signature mangle differently, breaking ABI compatibility.
Re: How about appender.put() with var args?
On Wednesday, 15 April 2015 at 20:59:25 UTC, Steven Schveighoffer
wrote:
with(app)
{
put(var);
put(bar);
put(more);
put(stuff);
}
-Steve
Awesome.
Re: D vs nim
On Friday, 10 April 2015 at 21:26:35 UTC, bachmeier wrote: On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons. Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use. To be fair, a vocal minority says the same of D. Accusations of linkbombing are commonplace, as is the notion that the D forums are nice except for the constant go-bashing, claims that there is an organized secret cabal (naturally led by AA and WB) directing people over IRC to upvote everything D regardless of content, etc. Once the seed of doubt is there suddenly everyone saying anything positive about D is probably/maybe/possibly just part of the mob. On Monday, 13 April 2015 at 17:28:14 UTC, Timothee Cour wrote: [...] * feature set is very rich, many features (semantic and syntax) not found in D or improving the ones in D, eg hygenic macros, I really like how younger languages can afford to take ideas and find inspiration in eachother. Everyone is better off having mindsets along the lines of that's awesome, how can we do better as opposed to Simpsons did it, you just stole that from XYZ.
Re: OT; Donald Knuth on beauty, efficiency, and the programmer as artist
On Saturday, 28 March 2015 at 01:09:44 UTC, Laeeth Isharc wrote: On Friday, 27 March 2015 at 11:33:39 UTC, Kagamin wrote: Hmm... science exists only as long as we don't understand something, then it disappears and only knowledge remains. Looks like he talks about engineering, but calls it science. One dismisses Knuth discussing the topic for which he is rightfully exceptionally well known at one's peril. He may be wrong, but one should agonize before being sure this is the case and read widely and carefully about the topic first. Often in our society people resolve cognitive dissonance by dismissing the awkward perspective that causes such discomfort, when one would reach a fuller perspective by putting up with the discomfort for a while before attempting to reach intellectual closure. I don't believe he is making the confusion you suggest. Without touching on what Kagamin said, one must also take care not to fall to argumentum ab auctoritate.
Re: I want to introduce boost_asio to dlang
On Thursday, 5 March 2015 at 07:38:35 UTC, ketmar wrote: On Thu, 05 Mar 2015 06:05:55 +, zhmt wrote: But I am not familiar with dlang this is the root of the problem. please, make yourself familiar before starting to wrap boost crap. Unwarranted tone imo. Let's play nice.
Re: problem with size_t and an easy solution
On Monday, 8 December 2014 at 14:31:50 UTC, ketmar via Digitalmars-d wrote: Personally, when I face the need for a size_t, I usually can (and do) use auto instead. And even if I have to spell it, I don't care too much how it's called, only whether it can be easily recognized. i bet that woobooAAARGH will be even easier to recognize than size_t. as there is no other types in D with _t suffix, you have to remember that anyway, so it doesn't really matter which one to remember. ;-) brb aliasing
Re: [OT] Microsoft filled patent applications for scoped and immutable types
On Tuesday, 26 August 2014 at 21:26:36 UTC, H. S. Teoh via Digitalmars-d wrote: D has had immutable for years! Surely that counts as prior art?? If the patent passes for whatever reason, this becomes a valid point if and only if you have the resources to contest its validity. The patent holder can effectively strongarm you into paying for licensing unless you have the (upwards of) hundreds of thousands of dollars needed for lawyer fees. They need only to drag out the court proceedings to starve you monetarily and win by walkover. It's not a far stretch to make an analogy to protection rackets, and it seems to me that the very point of patents has been subverted.
Re: whats happening to my binary file size?
On Tuesday, 26 August 2014 at 23:36:44 UTC, Israel wrote: I wasnt paying any attention to the file size of my binaries when i started using D. My first program is simple and compiles at 486kb, which honestly, is kind of absurd but anyways, after i start adding other imports it ran all the way up to 4.5mb. what i want to ask is, what exactly is happening to my binary when all i do is import various modules? Conjecture: your binary has its imports statically linked in, and your linker doesn't remove unused code (--gc-sections). https://issues.dlang.org/show_bug.cgi?id=879
Re: What does the compiler really require from the runtime?
On Tuesday, 19 August 2014 at 16:55:49 UTC, Jacob Carlborg wrote: On 2014-08-19 18:31, Alex wrote: Hi Everyone, Is there a list of functions and data structures, the D-Compiler would expect from a custom runtime? Here's a list [1]. It's probably not complete but it's a start. It's best to look at the source code of the existing runtime. [1] http://wiki.dlang.org/Runtime_Hooks Use the source, Luke!
Re: Appender is ... slow
On Friday, 15 August 2014 at 10:31:59 UTC, Dicebot wrote: On Friday, 15 August 2014 at 08:35:41 UTC, Philippe Sigaud via Digitalmars-d-learn wrote: I wonder if using plain `Array` instead may be result in better performance where immutability is not needed. Hmm, no: ... It is very different with better compiler though : $ ldmd2 -release -O a.d $ ./appendertest Appender.put :378 ms, 794 μs, and 9 hnsecs Appender ~=:378 ms, 416 μs, and 3 hnsecs Std array :2 secs, 222 ms, 256 μs, and 2 hnsecs Std array.reserve :2 secs, 199 ms, 64 μs, and 5 hnsecs Array :349 ms and 250 μs Array.reserve :347 ms, 694 μs, and 1 hnsec new T[]() :37 ms, 989 μs, and 8 hnsecs uninitializedArray :39 ms, 333 μs, and 3 hnsecs (size 10_000) T[size] beats all of those on dmd head, though it is inarguably a bit limiting.
Re: 'with(Foo):' not allowed, why?
On Saturday, 9 August 2014 at 09:11:53 UTC, Marc Schütz wrote:
On Saturday, 9 August 2014 at 03:46:05 UTC, timotheecour wrote:
On Wednesday, 6 August 2014 at 17:03:23 UTC, Timothee Cour via
Digitalmars-d-learn wrote:
Is there a reason why 'with(Foo):' is not allowed, and we
have to
use with(Foo){...} ?
It would be more in line with how other scope definitions
work (extern(C)
etc)
ping, anyone?
Probably for syntactic reasons: `with` is a statement, while
`extern(C)`, `@safe`, `private` etc. are attributes.
But the idea is certainly nice, it would only require a simple
rewriting rule.
Also a way to cancel such...
struct Foo {
@nogc:
void bar() {
with (someEnum):
// ...
!:with (someEnum) // ?
// ...
}
!:@nogc // ?
void gcFunction() { /*...*/ }
}
Re: scope guards
On Friday, 8 August 2014 at 00:27:21 UTC, Jonathan M Davis wrote:
On Thursday, 7 August 2014 at 20:59:45 UTC, Messenger wrote:
On Thursday, 7 August 2014 at 20:54:02 UTC, Jonathan M Davis
wrote:
I'd say that if you're trying to use scope in any situation
where you'd try and handle an exception, then you're using it
wrong.
But it's super convenient.
It fundamentally doesn't work to handle an exception with a
scope guard. They rethrow the exception.
void fun() {
scope(failure) return;
throw new Exception(__FUNCTION__);
}
void main() {
import std.exception;
assertNotThrown(fun());
}
Re: scope guards
On Thursday, 7 August 2014 at 20:54:02 UTC, Jonathan M Davis wrote: I'd say that if you're trying to use scope in any situation where you'd try and handle an exception, then you're using it wrong. But it's super convenient.
Re: DConf 2014 Day 2 Talk 2: Refactoring JIT Compilation by Maxime Chevalier-Boisvert
On Thursday, 3 July 2014 at 16:12:45 UTC, Andrei Alexandrescu wrote: We're back in business publishing DConf talks! https://news.ycombinator.com/newest (please vote quickly) https://twitter.com/D_Programming/status/484730864220504064 https://www.facebook.com/dlang.org/posts/877858112227871 http://www.reddit.com/r/programming/comments/29r0or/dconf_2014_day_2_talk_2_refactoring_jit/ Andrei Loved it. Great pacing, good slides, kept me interested. Lastly, the biggest issue I ran into lately was with the garbage collector performance. So I didn't realize how much of an issue this was until recently [...][1] I think we're losing out on a lot of users because of this; more than we realize. And not always because of its low performance but by its mere presence. [1]: http://www.youtube.com/watch?v=cJGNItlMWBM#t=1955
Re: [OT] Apple introduces Swift as Objective-C sucessor
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote: On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote: - no exceptions (!) How do they do error handling ? segfault
Re: Parallel execution of unittests
On Monday, 5 May 2014 at 00:40:41 UTC, Walter Bright wrote:
D has so many language features, we need a higher bar for
adding new ones, especially ones that can be done
straightforwardly with existing features.
Sure, but you'll have to agree that there comes a point where
library solutions end up being so syntactically convoluted that
it becomes difficult to visually parse.
Bad-practice non-sensical example.
version(ParallelUnittests)
const const(TypeTuple!(string, name, UnittestImpl!SomeT,
test, bool, result)) testTempfileHammering(string name, alias
fun, SomeT, Args...)(Args args) pure @safe @(TestSuite.standard)
if ((name.length 0) __traits(parallelizable, fun)
!is(Args) (Args.length 2) allSatisfy!(isSomeString, args))
{
/* ... */
}
Re: Discusssion on the Discussion of the Design for a new GC
On Thursday, 24 April 2014 at 17:33:08 UTC, Kagamin wrote: Another issue is that in 64-bit address space precise GC gives no advantage as false pointers have low probability, so precise GC seems to be not worth the effort. Except a precise gc is type-aware, no? And you could basically ask it to please print out everything that you have currently allocated so I can debug what's allocating.
Re: Compile-time memory footprint of std.algorithm
On Wednesday, 23 April 2014 at 15:46:00 UTC, Steven Schveighoffer wrote: The time it takes to compile a program where the compiler consumes 2G of ram on a 2G machine is infinite ;) (nitpick: not necessarily given good swap behaviour!)
Re: Discusssion on the Discussion of the Design for a new GC
On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote: After all of that, I intend to include a base draft of the design of the GC, along with opening the PRs and committing the starting API. So, is there something I’m missing? Am I overlooking the obvious? Is there a more practical way to produce the same results? What is the state of Rainer Schütze's precise gc? Duplication of effort and all that.
