Re: D Profile Viewer

I've updated the d-profile-viewer. There are three changes: Works on Windows (simple '\r' or '\n' bug fixed) Works with smaller numbers (division by integers -> divide by doubles) Uses HTML entities rather than UTF-8 (coz CodeWrite doesn't know UTF-8) Its on dub: dub fetch

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 11:15:38 UTC, Joseph Rushton Wakeling wrote: On Sunday, 15 May 2016 at 10:43:55 UTC, Joseph Rushton Wakeling wrote: Probably the best way to handle this is to handle the take-the-address side of things by a @trusted wrapper that uses `return ref` to guarantee the

Re: [Semi OT] deadalnix inspires a C++ dependency-based coroutine scheduler

On Saturday, 14 May 2016 at 23:49:40 UTC, Ali Çehreli wrote: Found on Reddit: https://www.reddit.com/r/programming/comments/4jawhk/cosche_a_dependencybased_coroutine_scheduler_c/ The project: https://github.com/matovitch/cosche#cosche The author says "I got the idea of building this by

Re: Found on Reddit: Cache sizes with CPUID in C++ and D

On 5/15/2016 7:56 AM, Ali Çehreli wrote: Then the author provides a function that does it correctly. https://issues.dlang.org/show_bug.cgi?id=16028

Re: Found on Reddit: Cache sizes with CPUID in C++ and D

On Sunday, 15 May 2016 at 14:56:47 UTC, Ali Çehreli wrote: Quote from the original article: "In D, there is a cpuid module that can retrieve cache information, but from what I've found it's incorrect." Then the author provides a function that does it correctly. But the article doesn't tell

Re: Found on Reddit: Cache sizes with CPUID in C++ and D

On Sunday, 15 May 2016 at 14:56:47 UTC, Ali Çehreli wrote: https://www.reddit.com/r/programming/comments/4jfoez/cache_sizes_with_cpuid_in_c_and_d/ Quote from the original article: "In D, there is a cpuid module that can retrieve cache information, but from what I've found it's incorrect."

Re: dxorshift: random number generators from the extended Xorshift family

On 05/15/2016 05:33 PM, Joseph Rushton Wakeling wrote: Ah, interesting. I think you may have discovered a bug in `isForwardRange`, because that test _should_ have detected that, if BaseRNG is a forward range, the RNG accessed via `alias this` is also `save`able. For a forward range, save must

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 15:33:24 UTC, Joseph Rushton Wakeling wrote: I think you may have discovered a bug in `isForwardRange` Less a bug than a subtlety, it seems. Because of this line:

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 15:15:30 UTC, Basile B. wrote: I confirm that all of them are run. As in your original paste. All pass, 100% coverage. No problem. Anyway, NVM I should just take care of my own buisness... Ah, interesting. I think you may have discovered a bug in `isForwardRange`,

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 14:49:16 UTC, Joseph Rushton Wakeling wrote: On Sunday, 15 May 2016 at 14:25:44 UTC, Basile B. wrote: The wrapper could be smaller with an alias this: [... snip ...] even if I'm not 100% sure if this is conform with previous version. At least the tests pass. I'm

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 15:09:17 UTC, Stefan Koch wrote: You want it ? Write it. I don't «want» anything.

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 14:56:02 UTC, Ola Fosheim Grøstad wrote: Well, this looks really bad. But a solver would get you much more than an interpreter. E.g. proving that asserts always hold etc. You want it ? Write it.

Found on Reddit: Cache sizes with CPUID in C++ and D

https://www.reddit.com/r/programming/comments/4jfoez/cache_sizes_with_cpuid_in_c_and_d/ Quote from the original article: "In D, there is a cpuid module that can retrieve cache information, but from what I've found it's incorrect." Then the author provides a function that does it correctly.

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 14:25:44 UTC, Basile B. wrote: The wrapper could be smaller with an alias this: [... snip ...] even if I'm not 100% sure if this is conform with previous version. At least the tests pass. I'm surprised that one passes the test, static

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 13:26:52 UTC, Joseph Rushton Wakeling wrote: On Sunday, 15 May 2016 at 11:15:38 UTC, Joseph Rushton Wakeling wrote: On Sunday, 15 May 2016 at 10:43:55 UTC, Joseph Rushton Wakeling wrote: Probably the best way to handle this is to handle the take-the-address side of

Re: Battle-plan for CTFE

On 05/15/2016 04:00 PM, Daniel Murphy wrote: > The problem is, if index refers to a single variable on the stack, then > it's insufficient to refer to a variable inside an aggregate on the > stack. Then you need to start building constructs for member of struct > in array of struct pointers and

Re: Battle-plan for CTFE

On 05/15/2016 02:54 PM, Daniel Murphy wrote: > > We really should have discussed this last week! I talked about it w/ Stefan, and asked him to volunteer for an implementation, that's why we have this thread ;). In any case I'm convinced that the simple-first strategy has a much higher chance to

Re: Battle-plan for CTFE

On 15/05/2016 11:25 PM, Martin Nowak wrote: On 05/15/2016 02:17 PM, Daniel Murphy wrote: For simple types that's true. For more complicated reference types... Variable indexes are not enough, you also need heap memory, but slices and pointers (and references) can refer to values either on

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 12:54:33 UTC, Daniel Murphy wrote: We really should have discussed this last week! I agree. Maybe we can have a skype conference or something in the next days. About the whole to BC or not to BC discussion. As Daniel already outlined, the main purpose it not

Re: Battle-plan for CTFE

On 05/15/2016 02:13 PM, Ola Fosheim Grøstad wrote: > > Well, you can, but it won't bring improvements to the language down the > line. Maybe you don't know the actual problem of the current interpreter? I leaks memory like hell b/c it allocates new AST nodes for almost every expression

Re: Battle-plan for CTFE

On 05/15/2016 02:17 PM, Daniel Murphy wrote: > > For simple types that's true. For more complicated reference types... > > Variable indexes are not enough, you also need heap memory, but slices > and pointers (and references) can refer to values either on the heap or > the stack, and you can

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 11:15:38 UTC, Joseph Rushton Wakeling wrote: On Sunday, 15 May 2016 at 10:43:55 UTC, Joseph Rushton Wakeling wrote: Probably the best way to handle this is to handle the take-the-address side of things by a @trusted wrapper that uses `return ref` to guarantee the

Re: Battle-plan for CTFE

On 15/05/2016 9:57 PM, Martin Nowak wrote: On 05/15/2016 01:58 PM, Daniel Murphy wrote: The biggest advantage of bytecode is not the interpreter speed, it's that by lowering you can substitute VarExps etc with actual references to memory without modifying the AST. By working with something

Re: Battle-plan for CTFE

On 15/05/2016 9:57 PM, Martin Nowak wrote: On 05/15/2016 01:58 PM, Daniel Murphy wrote: The biggest advantage of bytecode is not the interpreter speed, it's that by lowering you can substitute VarExps etc with actual references to memory without modifying the AST. By working with something

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 12:00:43 UTC, Martin Nowak wrote: On 05/15/2016 01:55 PM, Ola Fosheim Grøstad wrote: If you are going to have fast evaluation of loops/recursion then you need to use a solver. And well, doing worse than O(log N) at compile time is a very bad idea. Why not start with

Re: Battle-plan for CTFE

On 05/15/2016 02:02 PM, Stefan Koch wrote: > > Correct. A ByteCode Interpreter will add even more implementation > overhead, and the benefit is only realizable if the ByteCode is a > standard format that can be read other backends such as a jit. This indeed would be an interesting proposal,

Re: Battle-plan for CTFE

On 05/15/2016 01:55 PM, Ola Fosheim Grøstad wrote: > If you are going to have fast evaluation of loops/recursion then you > need to use a solver. And well, doing worse than O(log N) at compile > time is a very bad idea. > > Why not start with the most difficult case first? Then the simple cases >

Re: Battle-plan for CTFE

On 05/15/2016 01:58 PM, Daniel Murphy wrote: > The biggest advantage of bytecode is not the interpreter speed, it's > that by lowering you can substitute VarExps etc with actual references > to memory without modifying the AST. > > By working with something lower level than the AST, you should

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote: On 05/10/2016 08:45 AM, Jacob Carlborg wrote: I was listening to a discussion Don and Daniel had about the current implementation of CTFE. They talked about using a byte code interpreter. Even implementing a really crappy byte code

Re: Battle-plan for CTFE

On 15/05/2016 8:29 PM, Martin Nowak wrote: No need for a byte-code interpreter, it mostly just adds overhead and complexity over an AST interpreter. If you want to go really fast you need some sort of JIT anyhow, but a proper interpreter will be orders of mangnitude faster than the current

Re: Battle-plan for CTFE

On 05/09/2016 06:57 PM, Stefan Koch wrote: > I was shocked to discover that the PowExpression actually depends on > phobos! (depending on the exact codePath it may or may not compile...) > which let to me prematurely stating that it worked at ctfe >

Re: Battle-plan for CTFE

On Sunday, 15 May 2016 at 10:29:21 UTC, Martin Nowak wrote: On 05/10/2016 08:45 AM, Jacob Carlborg wrote: overhead and complexity over an AST interpreter. If you want to go really fast you need some sort of JIT anyhow, but a proper interpreter will be orders of mangnitude faster than the

Re: Battle-plan for CTFE

On 05/13/2016 06:32 PM, Stefan Koch wrote: > I would like to work on a solution that does scale. The Problem is > not making a byteCode-interpreter. That part is relatively easy. > Currently I am trying to get a detailed understanding of dmd and > it's data-structures. (mainly it's AST.) > >

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 10:43:55 UTC, Joseph Rushton Wakeling wrote: Probably the best way to handle this is to handle the take-the-address side of things by a @trusted wrapper that uses `return ref` to guarantee the pointer remains valid for the lifetime of the wrapper itself. Note, I've

Re: It's alive! D building D building D, all on Android

On Wednesday, 11 May 2016 at 19:07:10 UTC, Joakim wrote: On Thursday, 5 May 2016 at 14:07:07 UTC, Vadim Lopatin wrote: On Thursday, 5 May 2016 at 08:17:07 UTC, Joakim wrote: [...] Great work! I've slapped up some beta builds, have at it:

Re: dxorshift: random number generators from the extended Xorshift family

On Sunday, 15 May 2016 at 10:35:11 UTC, Basile B. wrote: The "@disable this" is really a concern, because pointers have to be used (for example if the seed comes from a program option and that the gen is a global var then global var must be a pointer to the stuff). I see that you are

Re: Battle-plan for CTFE

On 05/10/2016 08:45 AM, Jacob Carlborg wrote: > > I was listening to a discussion Don and Daniel had about the current > implementation of CTFE. They talked about using a byte code interpreter. > Even implementing a really crappy byte code interpreter would be a huge > improvement. No need for a

dxorshift: random number generators from the extended Xorshift family

http://code.dlang.org/packages/dxorshift https://github.com/WebDrake/dxorshift Following my earlier list posting , I'm pleased to announce an initial release of a dub package providing some of the RNGs from the extended family of