On Wednesday, October 18, 2017 10:36:41 Per Nordlöw via Digitalmars-d-learn
wrote:
> On Wednesday, 18 October 2017 at 10:17:38 UTC, Biotronic wrote:
> > Make them templates, that should solve the problem:
> >
> > struct S(T) {
> >
> > void foo()() {
> >
> > compileerror;
> >
> > }
On Wednesday, 18 October 2017 at 11:18:31 UTC, Biotronic wrote:
I'm not actually sure why D behaves this way - C++ doesn't. I
guess there is some value as tests - instantiating the type
tests that all its methods compile. Not actually sure that's
more of a positive than a negative, but it's
On 10/18/2017 10:05 AM, user1234 wrote:
On Wednesday, 18 October 2017 at 15:16:21 UTC, drug wrote:
18.10.2017 18:11, pham пишет:
Is there a way to identify if a type is a struct, something like
isStruct
similar to isArray.
struct X
{
}
isStruct!X == true?
Also, there are isAbstractClass &
On Wednesday, 18 October 2017 at 15:16:21 UTC, drug wrote:
18.10.2017 18:11, pham пишет:
Is there a way to identify if a type is a struct, something
like isStruct
similar to isArray.
struct X
{
}
isStruct!X == true?
Also, there are isAbstractClass & isFinalClass but want to
check if type
On 10/18/17 1:40 AM, Tony wrote:
On Tuesday, 17 October 2017 at 13:27:24 UTC, Steven Schveighoffer wrote:
I don't know what "allocations" represents, but reserve actually calls
gc_malloc, and the others do not (the space is available to expand
into the block). There should be only one
18.10.2017 18:11, pham пишет:
Is there a way to identify if a type is a struct, something like isStruct
similar to isArray.
struct X
{
}
isStruct!X == true?
Also, there are isAbstractClass & isFinalClass but want to check if type
is a class regardless? something like isClass?
Thanks
Pham
Is there a way to identify if a type is a struct, something like
isStruct
similar to isArray.
struct X
{
}
isStruct!X == true?
Also, there are isAbstractClass & isFinalClass but want to check
if type is a class regardless? something like isClass?
Thanks
Pham
18.10.2017 16:37, ikod пишет:
I ran this under linux perf, and here is top from 'perf report'
# Overhead Command Shared Object Symbol
# ... ..
...
#
7.34% t
On Wednesday, 18 October 2017 at 11:52:08 UTC, Biotronic wrote:
On Wednesday, 18 October 2017 at 11:34:57 UTC, Nordlöw wrote:
Another thing...how should the synchronization between the
fibers figure out when the total number of fibers have reached
one million?...via an atomic counter fed by
On Wednesday, 18 October 2017 at 12:32:31 UTC, Nordlöw wrote:
Further, are we forced to use the GC for Fiber allocation or
can a sub-class of Fibers implement its own allocation strategy?
Afraid it's set in stone. Now, it doesn't actually use the GC for
allocating the stack memory, instead
On Wednesday, 18 October 2017 at 11:52:08 UTC, Biotronic wrote:
It seems to make very little difference in terms of run time,
though. I tried using a mix of these approaches - parallel at
low depth, basically just to fill up the cores, and serial
closer to the leaves. The difference is still
On Wednesday, 18 October 2017 at 11:34:57 UTC, Nordlöw wrote:
Another thing...how should the synchronization between the
fibers figure out when the total number of fibers have reached
one million?...via an atomic counter fed by reference to the
constructor...or are there better ways? Because I
18.10.2017 14:34, Nordlöw пишет:
And how do I parallelize this over multiple worker threads? AFAICT
fibers are by default all spawned in the same main thread, right?
Probably it will works - every fiber substract 1 from its argument, then
divides remainder by count of child fibers and spawns
On Wednesday, 18 October 2017 at 11:04:10 UTC, Biotronic wrote:
On Wednesday, 18 October 2017 at 11:01:56 UTC, Per Nordlöw
wrote:
On Wednesday, 18 October 2017 at 09:01:30 UTC, Per Nordlöw
wrote:
Creates an actor (goroutine, whatever), which spawns 10 new
actors, each of them spawns 10 more
On Wednesday, 18 October 2017 at 10:55:49 UTC, Per Nordlöw wrote:
On Wednesday, 18 October 2017 at 10:36:41 UTC, Per Nordlöw
wrote:
Yeah I've thought of that.
I still would like to have it built-in to the compiler.
Would such a change cause any serious breakage?
Seems unlikely - when did
On Wednesday, 18 October 2017 at 11:01:56 UTC, Per Nordlöw wrote:
On Wednesday, 18 October 2017 at 09:01:30 UTC, Per Nordlöw
wrote:
Creates an actor (goroutine, whatever), which spawns 10 new
actors, each of them spawns 10 more actors, etc. until one
million actors are created on the final
On Wednesday, 18 October 2017 at 09:01:30 UTC, Per Nordlöw wrote:
Creates an actor (goroutine, whatever), which spawns 10 new
actors, each of them spawns 10 more actors, etc. until one
million actors are created on the final level. Then, each of
them returns back its ordinal number (from 0 to
On Wednesday, 18 October 2017 at 10:36:41 UTC, Per Nordlöw wrote:
Yeah I've thought of that.
I still would like to have it built-in to the compiler.
Would such a change cause any serious breakage?
On Wednesday, 18 October 2017 at 10:17:38 UTC, Biotronic wrote:
Make them templates, that should solve the problem:
struct S(T) {
void foo()() {
compileerror;
}
}
Yeah I've thought of that.
I still would like to have it built-in to the compiler.
On Wednesday, 18 October 2017 at 09:56:33 UTC, Nordlöw wrote:
On Wednesday, 18 October 2017 at 09:32:39 UTC, Jonathan M Davis
wrote:
On Wednesday, October 18, 2017 09:13:47 Per Nordlöw via
Digitalmars-d-learn wrote:
Are there any nearby plans to make more template
instantiations (especially
On Wednesday, 18 October 2017 at 09:32:39 UTC, Jonathan M Davis
wrote:
On Wednesday, October 18, 2017 09:13:47 Per Nordlöw via
Digitalmars-d-learn wrote:
Are there any nearby plans to make more template
instantiations (especially aggregate members) lazy in DMD?
Are there any specific
Is there any reason `std.container.array.Array.__dtor` isn't @safe,
@pure etc?
On Wednesday, October 18, 2017 09:13:47 Per Nordlöw via Digitalmars-d-learn
wrote:
> Are there any nearby plans to make more template instantiations
> (especially aggregate members) lazy in DMD?
>
> Are there any specific obstacles against doing that or has it
> just not been prioritized?
Are there any nearby plans to make more template instantiations
(especially aggregate members) lazy in DMD?
Are there any specific obstacles against doing that or has it
just not been prioritized?
I'm curious about Fiber/coroutine performance in D compared to
other languages such as Rust.
How should the following test be implemented in D?
Creates an actor (goroutine, whatever), which spawns 10 new
actors, each of them spawns 10 more actors, etc. until one
million actors are created on
On Wednesday, 18 October 2017 at 07:57:25 UTC, Dmitry wrote:
On Tuesday, 17 October 2017 at 10:09:12 UTC, Dmitry wrote:
On Tuesday, 17 October 2017 at 08:38:20 UTC, Arjan wrote:
Before this will work, one must install the Microsoft C/C++
Addin i.e. ms-vscode.cpptools.
Start debugging and
On Wednesday, 18 October 2017 at 08:22:09 UTC, Andrea Fontana
wrote:
On Wednesday, 18 October 2017 at 03:48:01 UTC, Ky-Anh Huynh
wrote:
You can write your script in D using
#!/usr/local/bin/rdmd
as shebang line.
Or, using dstep, you can convert C headers to D imports, so you
can compile your
On Wednesday, 18 October 2017 at 03:48:01 UTC, Ky-Anh Huynh wrote:
Hi,
I'm using Bash heavily in my systems. Things become slow and
slow when I have tons of scripts :) And sometimes it's not easy
to manipulate data.
You may have heard of recutils [1] which has a C extension to
be loaded by
On Wednesday, 18 October 2017 at 08:15:53 UTC, evilrat wrote:
...
extern(C) static int test_builtin(WORD_LIST* list)
...
This of course should be nothrow also, because if it throws
something really bad may(will) happen
On Wednesday, 18 October 2017 at 03:48:01 UTC, Ky-Anh Huynh wrote:
Hi,
I'm using Bash heavily in my systems. Things become slow and
slow when I have tons of scripts :) And sometimes it's not easy
to manipulate data.
You may have heard of recutils [1] which has a C extension to
be loaded by
On Tuesday, 17 October 2017 at 10:09:12 UTC, Dmitry wrote:
On Tuesday, 17 October 2017 at 08:38:20 UTC, Arjan wrote:
Before this will work, one must install the Microsoft C/C++
Addin i.e. ms-vscode.cpptools.
Start debugging and select the C++ debugger.
Yep
On Wednesday, 18 October 2017 at 07:26:20 UTC, Nordlöw wrote:
On Wednesday, 18 October 2017 at 07:01:19 UTC, Andrea Fontana
wrote:
If you try to use your data with chunkBy!"a != b+1", it does
not work, as expected.
What's the motivation behind this limitation?
Without it
chunkBy!"a + 1
On Wednesday, 18 October 2017 at 07:01:19 UTC, Andrea Fontana
wrote:
If you try to use your data with chunkBy!"a != b+1", it does
not work, as expected.
What's the motivation behind this limitation?
Without it
chunkBy!"a + 1 == b"
is exactly what I want.
It's worth pointing out, btw, that the main reason for this code
is to help drug diagnose his or her problem, not to be the
be-all, end-all of stack identifying functions. :)
It will of course not correctly identify pointers to variables on
other threads' stacks, and fiber stacks probably
On Tuesday, 17 October 2017 at 23:59:19 UTC, Steven Schveighoffer
wrote:
On 10/17/17 7:32 PM, flamencofantasy wrote:
On Tuesday, 17 October 2017 at 17:27:17 UTC, Biotronic wrote:
On Tuesday, 17 October 2017 at 15:33:02 UTC, drug wrote:
[...]
I have very little knowledge about sbrk, so
On Wednesday, 18 October 2017 at 06:45:37 UTC, Nordlöw wrote:
On Tuesday, 17 October 2017 at 14:15:02 UTC, Andrea Fontana
wrote:
auto splitBy(alias F, R)(R range)
Because of lazyness shouldn't it be named something with
splitter, say splitterBy, instead?
Yes but I think it is something
On Tuesday, October 17, 2017 18:33:02 drug via Digitalmars-d-learn wrote:
> My code fails and I guess the reason is I have a slice to data in the
> stack and it becomes garbage in some moment. So I need a way to check
> where data is placed. Is it right that it can be done in linux using
> `sbrk`
On Tuesday, 17 October 2017 at 14:15:02 UTC, Andrea Fontana wrote:
auto splitBy(alias F, R)(R range)
Because of lazyness shouldn't it be named something with
splitter, say splitterBy, instead?
On Tuesday, 17 October 2017 at 15:47:25 UTC, Andrea Fontana wrote:
More phobos-ized version:
https://run.dlang.io/is/iwgeAl
Thanks!
On Tuesday, 17 October 2017 at 23:59:19 UTC, Steven Schveighoffer
wrote:
On 10/17/17 7:32 PM, flamencofantasy wrote:
On Tuesday, 17 October 2017 at 17:27:17 UTC, Biotronic wrote:
On Tuesday, 17 October 2017 at 15:33:02 UTC, drug wrote:
[...]
I have very little knowledge about sbrk, so
40 matches
Mail list logo
