SubClass[] does not implicitly convert to SuperClass[], why?
What's the reason behind this design?
class Super {}
class Sub : Super {}
void foo(Super[] sup) {}
void main() {
Sub[] array;
foo(array); // error, cannot call foo(Super[]) with arguments
(Sub[])
}
Re: Berlin D Meetup Feb 2015
Just a reminder that this is happening tonight at 19:30. For those coming from further away the closest U-Bahn is Kottbusser Tor on the U1 and U8. The directions for getting to the room (from the http://co-up.de/ website) are: Go through the big metal gate to the left of Adalbertstr. 7, straight to the far end of the courtyard, and in the first tunnel to your right. Ring the bell marked co.up 3.OG and come up to the 3rd floor. If you are attending an evening/weekend meetup, you may find the big gate closed. In that case, go back in the direction of Kottbusser Tor to the small gate at Adalbertstr. 5-6. Reach through the bars to turn the handle and make your way straight through the tunnel, left through a second tunnel and then straight past the bike rack until you see the door of our building, across from the mailboxes. Looking forward to seeing everyone and to Joseph's talk.
Re: let (x,y) = ...
On Friday, 20 February 2015 at 09:12:26 UTC, Jacob Carlborg wrote:
On 2015-02-19 05:38, thedeemon wrote:
Creating tuples and returning them from functions is trivial
in D:
auto getTuple() { return tuple(Bob, 42); }
but using them afterwards can be confusing and error prone
auto t = getTuple();
writeln(name is , t[0], age is , t[1]);
I really missed the ML syntax to write
let (name, age) = getTuple();
Didn't someone create a pull request for something like:
auto(name, age) = getTuple();
Or was it a DIP?
This one, by Kenji?
http://wiki.dlang.org/DIP32
[Issue 14195] Ice when mangling templated function parameter extern(C++) function
https://issues.dlang.org/show_bug.cgi?id=14195 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/c4ef4296e217337de4d4137bae57bfda710454e2 Fixed bug 14195: Added C++ mangling for passing function signatures as template parameters. https://github.com/D-Programming-Language/dmd/commit/a68e1c1d4a08b029490c0c832920e0fdb12d7093 Merge pull request #4419 from Ingrater/fix14195 Fixed bug 14195: Added C++ mangling for passing function signatures --
Re: dfmt 0.1.0
On Friday, 20 February 2015 at 05:53:32 UTC, Brian Schott wrote: On Friday, 20 February 2015 at 05:23:45 UTC, Joakim wrote: On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott wrote: dfmt is a D source code formatting tool. https://github.com/Hackerpilot/dfmt/ https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0 Thanks, you should list some of the formatting changes it makes in the README. It doesn't do formatting changes. It wipes out the formatting during lexing and builds it up from scratch. The only thing that gets preserved is that it will look at line numbers on comments and try to keep them in roughly the same place. (For example, // comments that are on the end of a line instead of on the next line) Several examples in the README would indeed be nice.
Re: SubClass[] does not implicitly convert to SuperClass[], why?
On Friday, February 20, 2015 08:25:48 rumbu via Digitalmars-d-learn wrote:
On Friday, 20 February 2015 at 07:57:17 UTC, Tobias Pankrath
wrote:
What's the reason behind this design?
class Super {}
class Sub : Super {}
void foo(Super[] sup) {}
void main() {
Sub[] array;
foo(array); // error, cannot call foo(Super[]) with
arguments (Sub[])
}
Just make the sup parameter const:
void foo(in Super[] sup) {}
http://dlang.org/arrays.html (end of the page):
A dynamic array T[] can be implicitly converted to one of the
following:
const(U)[]
const(U[])
Where U is a base class of T.
The reson behind the design - I wonder about that also.
Well, if it were legal, you could do something like
class Super {}
class Sub : Super {}
class Sub2 : Super {}
Sub[] subArr = createSubArr();
Super[] superArr = subArr;
superArr[2] = new Sub2;
Now, all of a sudden, subArr[2] is a Sub2, when a Sub2 is not a Sub. So, you
would have broken the type system. The issue is called array covariance.
const avoids the problem, because you can't assign any of the elements of
the array.
A similar question was asked an answered previously on SO:
http://stackoverflow.com/questions/18158106/array-of-concrete-class-not-covariant-with-array-of-interface
though it looks like at the time that the questioned was answered, the
conversion didn't work with const, so things have improved since then. But
it should never work with mutable arrays or the type system would be
violated.
- Jonathan M Davis
Re: Are there any 2D games libraries available for D2?
On Friday, 20 February 2015 at 07:30:37 UTC, Namespace wrote: [snip] I will try to fix the Derelict 3 mess this weekend. Putting it on DUB will take some more time, which I don't have currently, because I have my exams right now. I've just managed to get building with DUB and submitted a PR. NOTE: You will want to review the diffs carefully because I've had to change some things like Derelict import paths which may break non-dub builds. Feel free to reject the PR if the breakage is too great and cherry pick anything you find useful. Or I can amend the PR if that helps also. Thanks, Stew
[Issue 14206] New: cdouble is broken
https://issues.dlang.org/show_bug.cgi?id=14206
Issue ID: 14206
Summary: cdouble is broken
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ilyayaroshe...@gmail.com
unittest {
cfloat conj00(cfloat z) { return z.re - z.im*1fi; }
assert(conj00(7+3i) == 7-3i);
cfloat conj10(cfloat z) { return z.re - z.im*1i; }
assert(conj10(7+3i) == 7-3i);
cfloat conj20(cfloat z) { return z.re - z.im*1Li; }
assert(conj20(7+3i) == 7-3i);
cdouble conj01(cdouble z) { return z.re - z.im*1fi; }
assert(conj01(7+3i) == 7-3i); //fails
cdouble conj11(cdouble z) { return z.re - z.im*1i; }
assert(conj11(7+3i) == 7-3i); //fails
cdouble conj21(cdouble z) { return z.re - z.im*1Li; }
assert(conj21(7+3i) == 7-3i);
creal conj02(creal z) { return z.re - z.im*1fi; }
assert(conj02(7+3i) == 7-3i);
creal conj12(creal z) { return z.re - z.im*1i; }
assert(conj12(7+3i) == 7-3i);
creal conj22(creal z) { return z.re - z.im*1Li; }
assert(conj22(7+3i) == 7-3i);
}
--
[Issue 14205] New: Document D compatibility with fork
https://issues.dlang.org/show_bug.cgi?id=14205 Issue ID: 14205 Summary: Document D compatibility with fork Product: D Version: D1 D2 Hardware: All URL: http://forum.dlang.org/post/mc352o$239k$2@digitalmars. com OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: dfj1es...@sneakemail.com People express concerns about compatibility of D with fork (see link). People take naive assumptions, that everything works after fork, e.g. GC, but it's probably not, and this should be addressed in the documentation. --
[Issue 14003] fork() on MacOS X 10.10.1 results in a core.exception.InvalidMemoryOperationError@(0)
https://issues.dlang.org/show_bug.cgi?id=14003 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14205 --
[Issue 4368] Fork() on OS X 2.047 results in a core.thread.ThreadException
https://issues.dlang.org/show_bug.cgi?id=4368 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14205 --
[Issue 6846] std.concurrency and fork/execv
https://issues.dlang.org/show_bug.cgi?id=6846 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14205 --
Re: contiguous ranges
On Friday, 20 February 2015 at 08:22:38 UTC, John Colvin wrote: Maybe I'm missing something, but I don't see anything here that isn't already covered by built-in slices, opSlice, opSliceAssign and put. That's the wrong direction. What you want is a means to query a unknown container for it's properties so that you can bypass builtin operators: 1. by comparing addresses of elements and be able to assume strict order as you progress 2. by assessing compile time uniformity in distribution so that you can iterate using SIMD.
Re: D and GPGPU
On Wednesday, 18 February 2015 at 18:14:19 UTC, luminousone wrote: HSA does work with discrete gpu's and not just the embedded stuff, And I believe that HSA can be used to accelerate OpenCL 2.0, via copyless cache coherent memory access. Unless I'm mistaken, it will more like the opposite: HSA will use OpenCL 2.0 as a backend to do that kind of copyless GPGPU acceleration.
Re: GC deadlocks on linux
I think, it's better to diagnose, what problem the program encounters, than to explain, what happens in kernel and glibc. The first step is to see, where it hangs and get a stacktrace.
[Issue 14205] Document D compatibility with fork
https://issues.dlang.org/show_bug.cgi?id=14205 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=6846, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=4368, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=14003 --
Re: let (x,y) = ...
On 2015-02-19 05:38, thedeemon wrote:
Creating tuples and returning them from functions is trivial in D:
auto getTuple() { return tuple(Bob, 42); }
but using them afterwards can be confusing and error prone
auto t = getTuple();
writeln(name is , t[0], age is , t[1]);
I really missed the ML syntax to write
let (name, age) = getTuple();
Didn't someone create a pull request for something like:
auto(name, age) = getTuple();
Or was it a DIP?
--
/Jacob Carlborg
Re: We are Beta (2.067.0-b2)
On 2015-02-19 23:06, Brian Schott wrote: Many of the beta-2 files are missing from downloads.dlang.org, and all of them are missing from ftp.digitalmars.com. This makes testing the Debian packages or using DVM impossible. As a workaround for DVM use can manually download the zip file and place it in ~/.dvm/archives. Then run dvm install ... as usually. -- /Jacob Carlborg
[Issue 14195] Ice when mangling templated function parameter extern(C++) function
https://issues.dlang.org/show_bug.cgi?id=14195 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||C++, ice CC||yebbl...@gmail.com --
Re: contiguous ranges
On Friday, 20 February 2015 at 09:44:36 UTC, John Colvin wrote: Eh? Knowing the ordering and that the distribution is uniform* isn't going to be enough to iterate by SIMD. You need to know the complete iteration scheme. That's the point of a concept. The concept provides constraints that in turn provides certain guarantees. E.g. 1. that the addresses of elements provided by the iterator (or range) are in order 2. that they are evenly spaced 3. a means to obtain the stride (distance between elements) So if you obtain the address of a start element and and end element you can iterate using SIMD. *what do you even mean by that? Jargon is only useful when it's used with precision. That elements are evenly spaced in storage.
[Issue 6846] std.concurrency and fork/execv
https://issues.dlang.org/show_bug.cgi?id=6846 --- Comment #1 from Sobirari Muhomori dfj1es...@sneakemail.com --- You allocate in a forked process. Try to use spawnProcess instead, it tries to avoid complex operations after fork. --
Re: SubClass[] does not implicitly convert to SuperClass[], why?
On Friday, 20 February 2015 at 07:57:17 UTC, Tobias Pankrath
wrote:
What's the reason behind this design?
class Super {}
class Sub : Super {}
void foo(Super[] sup) {}
void main() {
Sub[] array;
foo(array); // error, cannot call foo(Super[]) with
arguments (Sub[])
}
Just make the sup parameter const:
void foo(in Super[] sup) {}
http://dlang.org/arrays.html (end of the page):
A dynamic array T[] can be implicitly converted to one of the
following:
const(U)[]
const(U[])
Where U is a base class of T.
The reson behind the design - I wonder about that also.
Re: SubClass[] does not implicitly convert to SuperClass[], why?
On Friday, 20 February 2015 at 08:25:49 UTC, rumbu wrote:
On Friday, 20 February 2015 at 07:57:17 UTC, Tobias Pankrath
wrote:
What's the reason behind this design?
class Super {}
class Sub : Super {}
void foo(Super[] sup) {}
void main() {
Sub[] array;
foo(array); // error, cannot call foo(Super[]) with
arguments (Sub[])
}
Just make the sup parameter const:
void foo(in Super[] sup) {}
http://dlang.org/arrays.html (end of the page):
A dynamic array T[] can be implicitly converted to one of the
following:
const(U)[]
const(U[])
Where U is a base class of T.
The reson behind the design - I wonder about that also.
Thanks, didn't know that. Makes sense.
Probably the reason is:
void foo(Super[] sup) { sup[3] = new AnotherDerivedClass(); }
After foo returns the slice passed as argument would violate its
invariant.
Re: contiguous ranges
On Friday, 20 February 2015 at 08:45:23 UTC, Ola Fosheim Grøstad wrote: On Friday, 20 February 2015 at 08:22:38 UTC, John Colvin wrote: Maybe I'm missing something, but I don't see anything here that isn't already covered by built-in slices, opSlice, opSliceAssign and put. That's the wrong direction. What you want is a means to query a unknown container for it's properties so that you can bypass builtin operators: 1. by comparing addresses of elements and be able to assume strict order as you progress 2. by assessing compile time uniformity in distribution so that you can iterate using SIMD. Eh? Knowing the ordering and that the distribution is uniform* isn't going to be enough to iterate by SIMD. You need to know the complete iteration scheme. *what do you even mean by that? Jargon is only useful when it's used with precision.
[Issue 14096] ICE in toir.c: 187
https://issues.dlang.org/show_bug.cgi?id=14096 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||ice, pull Hardware|x86_64 |All Version|D1 D2 |D2 OS|Linux |All --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4424 --
[Issue 14204] New: ldexp for double and float
https://issues.dlang.org/show_bug.cgi?id=14204 Issue ID: 14204 Summary: ldexp for double and float Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: ilyayaroshe...@gmail.com ldexp for double and float is missing. --
Re: contiguous ranges
On Thursday, 19 February 2015 at 23:11:16 UTC, Pasqui23 wrote: On Thursday, 19 February 2015 at 19:32:26 UTC, Andrei Alexandrescu wrote: I don't see a need for contiguous ranges if the only embodiment is T[]. -- Andrei Yeah,but it could be useful to access where the range is located So that you can assess whether a pointer (iterator) is in a range on or not at O(1)? Seems there is a different between: 1. uniform spacing 2. with strides or not 3. dense packing (plain array)
Re: contiguous ranges
On Friday, 20 February 2015 at 01:25:34 UTC, deadalnix wrote: On Monday, 16 February 2015 at 06:06:19 UTC, Vlad Levenfeld wrote: Since C++17, there's a new iterator category: the contiguous iterator. Check it out: http://en.cppreference.com/w/cpp/iterator So, by extension, I think a ContiguousRange would be any RandomAccessRange which has a member called ptr which supports a dereferencing operator * that yields an ElementType!R. This notion is useful for functions which might otherwise perform an element-by-element transfer to an OutputRange via put, instead perform an optimized batch transfer directly to a ContiguousRange via ptr. (Not that Contiguous implies Output; this example assumes the ContigiousRange has enough length to accomodate the transfer or otherwise has mutable length, e.g. builtin arrays.) I've been using the idea implicitly in my code with static if (is (typeof(*R.init.ptr) == ElementType!R)), but seeing that table made me realize it could be formally abstracted out to a range concept. Isn't it what a slice is already ? Yeah... Maybe I'm missing something, but I don't see anything here that isn't already covered by built-in slices, opSlice, opSliceAssign and put.
Re: Are there any 2D games libraries available for D2?
On Thursday, 19 February 2015 at 23:32:45 UTC, Kingsley wrote: Hi I'm looking for a 2D games library in D2 similar to gosu from ruby: http://www.libgosu.org/ or ray: https://github.com/Mon-Ouie/ray Does such a thing exist? --K
Re: GC deadlocks on linux
On Thursday, 19 February 2015 at 22:12:03 UTC, Steven Schveighoffer wrote: I'm not sure what the issue here is, but I don't think forking is as unstable as you seem to think, or maybe I'm reading this wrong. I can agree there are many gotchas with forking. You need to very carefully configure what happens to resources before/after forking. So if you use third party libraries with threading all bets are off... If you fork early in the process' lifespan, before acquiring resources, then it is much easier... http://linux.die.net/man/2/fork
Re: Writing game engine in C++, considering switching to D
On Thursday, 19 February 2015 at 02:08:39 UTC, Will Cassella wrote: Thanks for the replies, everyone! I think I'll try my hand at writing bindings for my existing game engine, as Grøstad suggested - that way I can gradually transition the codebase to D if I like what I see. My 2 cents would be: start with a toy project that stresses a bit resource management (the toy project might as well be the rendering part of your existing engine). The only part of D I really don't like is non-deterministic resource destruction, because it can be really painful when it comes to stuff like OpenGL resources (e.g: if the GC calls any OpenGL function, you get a nice crash since OpenGL is not multithread-aware by default). IMO the first thing you should do, is trying to see if you are able to manage all your critical resources (including OpenGL objects) by using D structs coupled with Unique! and RefCounted! templates you can find in std.typecons module. I highly suggest you to do that, because that is the worst hurdle I had to face during any kind of D + OpenGL development. If you understand how to get stuff done right, you are set, and the rest of the work will be painless and fun.
Re: GC deadlocks on linux
On Fri, 20 Feb 2015 09:04:29 +, Ola Fosheim Grøstad wrote: If you fork early in the process' lifespan, before acquiring resources, then it is much easier... and even if `fork()` is the first line of code in `main()`, there cannot be any guarantees. there can be module constructor doing something, or 3rd party library that already initialized something, or... you got the idea. ;-) signature.asc Description: PGP signature
Re: contiguous ranges
On Friday, 20 February 2015 at 12:23:49 UTC, Vlad Levenfeld wrote: Slicing and in-place transformations are pretty much the only things that will preserve contiguity. Piping ac through map or something will take us back to manually propagating the sampling rate. In general, deciding how and when to preserve what information under which transformations is tough. Lazily mapping, say, to increase the volume could meaningfully preserve sampling rate, but under filtering, zipping or striding it doesn't make sense. The sensible thing to do is to have ranges of contiguous ranges: 1. to get better cache locality 2. to iterate over btrees (which are popular now due to memory bus issues) 3. to do intermediate buffering for higher speed (SIMD) In the worst case the contiguous range will degrade to 1 element, which is OK for prototyping. Then you can insert an intermediate buffer where needed after profiling performance.
Re: Are there any 2D games libraries available for D2?
On 2015-02-20 00:32, Kingsley wrote: Hi I'm looking for a 2D games library in D2 similar to gosu from ruby: http://www.libgosu.org/ or ray: https://github.com/Mon-Ouie/ray Does such a thing exist? This is for 3D but have a look at Dash Engine [1] [2] [1] http://dash.circularstudios.com [2] https://github.com/Circular-Studios/Dash -- /Jacob Carlborg
Re: Are there any 2D games libraries available for D2?
On Friday, 20 February 2015 at 07:43:42 UTC, Russel Winder wrote: On Thu, 2015-02-19 at 23:32 +, Kingsley via Digitalmars-d wrote: Hi I'm looking for a 2D games library in D2 similar to gosu from ruby: http://www.libgosu.org/or ray: https://github.com/Mon-Ouie/ray I got totally confused there for a moment: Gosu is a programming language for the JVM, and nothing to do with Ruby. same here. when i first saw the name libgosu i thought wow, gosu guys made a game lib and then when i went to the libgosu website i saw that it has nothing to do with gosu, the jvm programming language. for teh lazy, libgosu website says: Gosu is a 2D game development library for the Ruby and C++ programming languages, available for Mac OS X, Windows, and Linux
[Issue 14207] New: Assertion failure: '(vd-storage_class (STCout | STCref)) ? isCtfeReferenceValid(newval) : isCtfeValueValid(newval)' on line 6724 in file 'interpret.c'
https://issues.dlang.org/show_bug.cgi?id=14207 Issue ID: 14207 Summary: Assertion failure: '(vd-storage_class (STCout | STCref)) ? isCtfeReferenceValid(newval) : isCtfeValueValid(newval)' on line 6724 in file 'interpret.c' Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: electrolysis.j...@gmail.com test.d: --- import std.digest.sha; enum h = digest!SHA1(abc); // I'm not interested in whether this is valid --- DMD 2.067.0-b2 dies with: Assertion failure: '(vd-storage_class (STCout | STCref)) ? isCtfeReferenceValid(newval) : isCtfeValueValid(newval)' on line 6724 in file 'interpret.c' On the other hand, DMD 2.066.1 throws: D:\d\dmd2\windows\bin\..\..\src\phobos\std\digest\sha.d(757): Error: cannot cast ubyte[8] to const(ubyte)[] D:\d\dmd2\windows\bin\..\..\src\phobos\std\digest\sha.d(765):called from here: this.put(cast(const(ubyte)[])bits) D:\d\dmd2\windows\bin\..\..\src\phobos\std\digest\digest.d(435):called from here: hash.finish() test.d(2):called from here: digest(abc) --
Re: Bugzilla email queue jammed?
On 2015-02-19 03:23, Martin Nowak wrote: That was apparently cause by me updating the 2.067 branches. I probably should have deleted and recreated it instead, but I didn't knew how the mails are generated. So that's way I've seen over 300 issues updated in the newsgroup and commit messages which seems to contain already merged pull requests. -- /Jacob Carlborg
Re: C++ calling convention only
On Friday, 20 February 2015 at 12:23:31 UTC, Benjamin Thaut wrote: On Thursday, 19 February 2015 at 21:34:57 UTC, John Colvin wrote: I would duplicate the declaration, once without extern(C++), once with, the use the .mangleof from the 1st to set the mangle of the 2nd with pragma(mangle Yes that would work. But using pragma(mangle) feels so hacky... I agree. Wrap it in a mixin / mixin template? Why do you need this? Presumably it'll be hidden in the depths of some library / bindings where beauty is somewhat optional? Using the .mangleof from an extern(D) function should mean it's robust.
Re: Writing game engine in C++, considering switching to D
On Friday, 20 February 2015 at 09:57:48 UTC, francesco.cattoglio wrote: (e.g: if the GC calls any OpenGL function, you get a nice crash since OpenGL is not multithread-aware by default). Really? I don't see this in my projects. The GC stops the world, so there shouldn't be any races.
Re: SubClass[] does not implicitly convert to SuperClass[], why?
On Fri, 20 Feb 2015 12:58:01 +, rumbu wrote: A simple cast will always permit to destroy the type system entirely: `cast` is the thing programmer does explicitly. it's assumed that programmer is know what he is doing, and he takes full responsibility for that. hidden type system breakage is completely different thing. moving checks to runtime turns language to JS. signature.asc Description: PGP signature
Re: We are Beta (2.067.0-b2)
On Wednesday, 18 February 2015 at 14:13:25 UTC, Martin Nowak wrote: Find more information on the dmd-beta mailing list. http://forum.dlang.org/thread/54e41ca2.4060...@dawg.eu Thanks! Note: dmd.2.067.0-b2.dmg is missing.
Re: C++ calling convention only
On Thursday, 19 February 2015 at 21:34:57 UTC, John Colvin wrote: I would duplicate the declaration, once without extern(C++), once with, the use the .mangleof from the 1st to set the mangle of the 2nd with pragma(mangle Yes that would work. But using pragma(mangle) feels so hacky...
Re: contiguous ranges
I feel the bigger picture is being missed amid the focus on
blitting.
On Thursday, 19 February 2015 at 11:20:13 UTC, Guillaume Chatelet
wrote:
From this discussion I understand you mainly want to be able to
BitBlt ranges
BitBlit is useful, yes, but not the main point. Interfacing with
C APIs and supporting in-place transformations is also important.
On Thursday, 19 February 2015 at 19:32:26 UTC, Andrei
Alexandrescu wrote:
I don't see a need for contiguous ranges if the only embodiment
is T[]. -- Andrei
Agreed. I don't think that defining contiguous ranges as
implicitly convertible to T[] is useful - in this case, you could
just write functions to take a T[], and forget the original range
type entirely. For a range concept to be useful for generic
programming, it needs to enable templates to lift algorithms to
the argument type's category. Instead, lowering a range to T[]
loses the capabilities and constraints defined in the original
range and obviates the need for the category in the first place.
On Friday, 20 February 2015 at 01:25:34 UTC, deadalnix wrote:
Isn't it what a slice is already ?
Yes. A slice is the simplest realization of a contiguous range. I
argue that it is useful to have structures which have slice-like
behavior without actually being slices.
On Friday, 20 February 2015 at 08:20:50 UTC, Ola Fosheim Grøstad
wrote:
So that you can assess whether a pointer (iterator) is in a
range on or not at O(1)?
Hadn't thought of that, it could be useful.
On Friday, 20 February 2015 at 08:22:38 UTC, John Colvin wrote:
I don't see anything here that isn't already covered by
built-in slices, opSlice, opSliceAssign and put.
opSlice.* and put are defined in the data structure, whereas
range concepts inform the algorithm.
//
I claim that the practical benefit of range concepts as type
predicates is:
1) to make overloading logic more succinct and uniform.
2) to concentrate implementation decisions in the appropriate
abstraction layer.
both of which serve to make generic code more robust, expressive
and efficient.
Sometimes you want something like a slice (in that it guarantees
contiguous memory layout) but with additional capabilities and
constraints which you would like to have preserved under certain
transformations. This can be encapsulated in a contiguous range
concept.
Let me illustrate with an example:
struct AudioClip {
float[2][] samples;
uint sampling_rate;
this (string path) {load (path, samples);}
void play () {some_C_audio_lib_call (samples.ptr,
samples.length, sampling_rate);}
}
// we'll start with an audio clip with contiguous layout in
memory
auto ac = AudioClip (90 minutes of screaming cats.flac);
// now we define two implementations of the same filter
auto ref declaw_filter1 (R)(R r) if (isContiguousRange!R) {
// pattern match to get the size of the sample
static if (is (ElementType!R == float[stride], uint stride))
{}
// i know the gsl functions don't work like this, just bear
with me
gsl_fft (ptr, stride, r.length);
gsl_fgemm (/*pretend this is sensible*/);
gsl_fft_inverse (ptr, stride, r.length);
return r;
}
auto declaw_filter2 (uint n)(float[n][] slice) {
// like declaw_filter1 but without the contiguous stuff
}
// now, we can finish this one of two ways
// the easy way:
ac.declaw_filter1.play; // UFCS all day
// or, if we passed a T[] made from AudioClip or defined
AudioClip to be implicitly convertible to T[]:
AudioClip ac2;
ac2.samples = ac.declaw_filter2;
ac2.sampling_rate = ac.sampling_rate; // this could
desynchronize after the code is refactored, opening us up for bugs
ac2.play;
THE UPSHOT:
Both variants of declaw_filter are generic - they'll operate on
data in an arbitrary number of channels, it could be an audio
file or voltages from a DAQ or whatever.
Variant 1 lifts the algorithm to accommodate the range, while
variant 2 lowers the range to accommodate the algorithm.
The use of variant 2 is more verbose, error-prone, and bubbles
implementation details up to a layer where they don't belong.
Variant 1 uses the concept of a contiguous range to keep the
knowledge of its implementation (specifically, that it calls
functions which expect pointers) encapsulated.
THE DOWNSIDE:
Slicing and in-place transformations are pretty much the only
things that will preserve contiguity. Piping ac through map or
something will take us back to manually propagating the sampling
rate. In general, deciding how and when to preserve what
information under which transformations is tough. Lazily mapping,
say, to increase the volume could meaningfully preserve sampling
rate, but under filtering, zipping or striding it doesn't make
sense.
Re: GC deadlocks on linux
On Fri, 20 Feb 2015 08:03:00 +, Kagamin wrote: I think, it's better to diagnose, what problem the program encounters, than to explain, what happens in kernel and glibc. The first step is to see, where it hangs and get a stacktrace. this way of thinking is exactly why i recommend to avoid `fork()` unless one can explain *everything* it does. signature.asc Description: PGP signature
Re: SubClass[] does not implicitly convert to SuperClass[], why?
On Friday, 20 February 2015 at 10:41:04 UTC, Jonathan M Davis
wrote:
class Super {}
class Sub : Super {}
class Sub2 : Super {}
Sub[] subArr = createSubArr();
Super[] superArr = subArr;
superArr[2] = new Sub2;
Now, all of a sudden, subArr[2] is a Sub2, when a Sub2 is not a
Sub. So, you
would have broken the type system. The issue is called array
covariance.
const avoids the problem, because you can't assign any of the
elements of
the array.
A simple cast will always permit to destroy the type system
entirely:
class Super {}
class Sub : Super {
string alpha() { return I am Sub; }
void SomeMethodNotFoundInSub2() { }
}
class Sub2: Super {
string beta() { return I am Sub2; }
}
void foo(in Super[] sup)
{
cast(Super)sup[0] = new Sub();
cast(Super)sup[1] = new Sub2();
}
int main(string[] argv)
{
Sub[] subArr = new Sub[2];
foo(subArr);
writeln(subArr[0]);
writeln(subArr[1]); //look ma', my Sub[] array contains Sub2
elements
writeln(subArr[0].alpha());
writeln(subArr[1].alpha()); //look ma', I'm calling beta of
Sub2, because it has the same vtbl offset as alpha in Sub
subArr[0].SomeMethodNotFoundInSub2(); //ok
subArr[1].SomeMethodNotFoundInSub2(); // now we have an
AccesViolation or maybe not, depending on Sub2 contents.
getchar();
return 0;
}
The problem is in fact the line below, and that kind of
assignment must be checked at runtime instead of limiting compile
time features that can be anyway circumvented, by throwing a
specific exception.
sup[1] = new Sub2();
Re: D and GPGPU
On 2015-02-18 18:56, ponce wrote: - the Runtime API abstract over multi-GPU and is the basis for high-level libraries NVIDIA churns out in trendy domains. (request to Linux/Mac readers: still searching for the correct library names for linux :) ). For OS X: CUDA Driver: This will install /Library/Frameworks/CUDA.framework and the UNIX-compatibility stub /usr/local/cuda/lib/libcuda.dylib that refers to it I would recommend the framework. Make sure the correct path is added, take a look at SDL for example [1]. You need something like ../Frameworks/CUDA.framework/CUDA to make sure it's possible to bundle the cuda framework in an application bundle. [1] https://github.com/DerelictOrg/DerelictSDL2/blob/master/source/derelict/sdl2/sdl.d#L42 -- /Jacob Carlborg
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote: Adding core.memory.GC.disable; to main causes the application to work correctly (and quickly till it runs out of memory :D ) GC.disable shouldn't run OOM, BTW. http://dlang.org/phobos/core_memory.html#.GC.disable
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:41:12 UTC, Dicebot wrote: Any chance you are using gdm-3.12.x? I was so mad when I have encountered this: https://issues.dlang.org/show_bug.cgi?id=4890 Indeed, maybe http://dlang.org/phobos-prerelease/core_thread.html#.thread_setGCSignals might help. We should probably try to improve druntime to only use a single signal for suspending and resuming.
[Issue 14208] New: Use a single signal number for GC thread suspend and resume
https://issues.dlang.org/show_bug.cgi?id=14208 Issue ID: 14208 Summary: Use a single signal number for GC thread suspend and resume Product: D Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu I've seen that in some other GC implementation (V8?) and it should be possible for us as well. Saves on signal number and reduces chances for collision. --
Re: Writing game engine in C++, considering switching to D
On Friday, 20 February 2015 at 13:04:51 UTC, John Colvin wrote: On Friday, 20 February 2015 at 09:57:48 UTC, francesco.cattoglio wrote: (e.g: if the GC calls any OpenGL function, you get a nice crash since OpenGL is not multithread-aware by default). Really? I don't see this in my projects. The GC stops the world, so there shouldn't be any races. Not a race. An OpenGL contect can only active in one thread at once. If the GC calls a destructor from a thread which doesn't have that context active, it will probably crash.
Re: C++ calling convention only
On Friday, 20 February 2015 at 13:00:39 UTC, John Colvin wrote: I agree. Wrap it in a mixin / mixin template? Why do you need this? Presumably it'll be hidden in the depths of some library / bindings where beauty is somewhat optional? Using the .mangleof from an extern(D) function should mean it's robust. Well the use case is creating a function which sole purpose it is to create a function pointer from it and pass it to C++. If it recieves C++ mangling however I have to pay attention that it does not conflict with any other C++ symbols. The same goes for extern(C). Sometimes you want to create functions with a C calling convetion so you can create a function pointer from it. With extern(C) its even a bigger problem because the C mangling conflicts a lot easier.
Reloaded for dub
Hi Just thought I would share this in case anyone else finds it useful. I wrote a tiny utility that detects changes to D files and then rebuilds and re-executes the main binary using dub. I use for developing with vibe.d and other dub D project that have an executable binary. The code is here: https://github.com/kingsleyh/reloaded essentially you just run dub in the root and it builds the reloaded binary. Then you just copy that binary to the root of your dub project and ./reloaded and then as soon as you make a change to a D file your code will be built and executed. --K
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote: I have a medium size daemon application that uses several threads, libasync, and daemonize. On windows it runs correctly with GC enabled, but on linux the GC causes a deadlock while allocating memory. Can you reliably reproduce the deadlock? If so please attach a gdb to the deadlocked process and provide us back traces of all threads? If you can share the code (maybe privately), that would help as well.
Re: GC deadlocks on linux
On Friday, 20 February 2015 at 12:47:58 UTC, ketmar wrote: 3rd party library that already initialized something, or... you got the idea. ;-) Yeah, either use plain C or avoid 3rd party libraries... I guess that includes phobos ;)
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote: System: DMD 2.066.1 Can you also try the latest beta please, maybe we already fixed something. http://forum.dlang.org/post/54e49e2d.2010...@dawg.eu
Re: vibe-d basic build errors
On Friday, 20 February 2015 at 04:48:09 UTC, Charles wrote: They're installer versions, dub is 0.9.22 Nov 22 I want to say, and DMD is 2.066.1 Same ones I tried. With --force dmd seems to fail but there is not output. Can you run only the link command with a -v to get verbose dmd output? dmd -c -of.dub\build\application-debug-windows-x86-dmd_2066-7FF336D92D4F5796EA8623FC9A6A9B90\web.obj -debug -g -w -version=VibeDefaultMain -version=VibeWin32Driver -version=Have_web -version=Have_vibe_d -version=Have_openssl -Isource -IC:\Users\Charles\AppData\Roaming\dub\packages\vibe-d-0.7.22\source -IC:\Users\Charles\AppData\Roaming\dub\packages\openssl-1.1.3_1.0.1g -Jviews source\app.d C:\Users\Charles\AppData\Roaming\dub\packages\vibe-d-0.7.22\source\vibe\appmain.d
Re: GC deadlocks on linux
On Fri, 20 Feb 2015 14:33:29 +, Ola Fosheim Grøstad wrote: On Friday, 20 February 2015 at 12:47:58 UTC, ketmar wrote: 3rd party library that already initialized something, or... you got the idea. ;-) Yeah, either use plain C or avoid 3rd party libraries... I guess that includes phobos ;) maybe even druntime to some extent. and, of course, no other D libraries, as who knows what they can do in their module initialisers... signature.asc Description: PGP signature
Re: Writing game engine in C++, considering switching to D
On Friday, 20 February 2015 at 13:44:04 UTC, ponce wrote: On Friday, 20 February 2015 at 13:04:51 UTC, John Colvin wrote: On Friday, 20 February 2015 at 09:57:48 UTC, francesco.cattoglio wrote: (e.g: if the GC calls any OpenGL function, you get a nice crash since OpenGL is not multithread-aware by default). Really? I don't see this in my projects. The GC stops the world, so there shouldn't be any races. Not a race. An OpenGL contect can only active in one thread at once. If the GC calls a destructor from a thread which doesn't have that context active, it will probably crash. Exactly. Unless you do some special work yourself, you can't call OpenGL function from a different thread. It's not a real D problem, in fact, D is probably doing the right thing when it comes to Thread Local Storage and such. It is more of an OpenGL limitation. This is also the reason I can't wait to see OpenGL Next, since there were also promises of far better multithread support.
Re: Disallow destroy(structPtr)?
On 2/20/15 1:05 PM, Nick Treleaven wrote:
Hi,
The following code is supposed to destroy the struct instance:
import std.stdio;
struct S{
~this(){destruct.writeln;}
}
auto p = new S;
destroy(p);
end.writeln;
It works correctly if I use destroy(*p), but the above code could
perhaps be statically rejected by object.destroy to help prevent bugs.
Currently, the pointer p is set to null without calling the destructor
(with recent dmd the destructor is called, but only after end is
printed).
Here is the destroy overload:
void destroy(T)(ref T obj)
if (!is(T == struct) !is(T == interface) !is(T == class)
!_isStaticArray!T)
{
obj = T.init;
}
I'm beginning to think this is the right thing to do. It confuses so
many people, and setting a pointer/class reference/array to null is easy
enough without needing a special function to do it. In other words, if
you are using destroy, you aren't just trying to nullify a pointer. You
want to destroy what the pointer represents.
The only problem is, how does this affect existing code?
-Steve
To GC or Not To GC in std.container.*
What's the policy on using GC or not in std.container.* ? - std.container.Array uses malloc for its allocation but - RedBlackTree.allocate() returns a: new RBNode!Elem* Is this because RBNode* should be reachable outside of RedBlackTree or is this a todo?
D usage quotes/badges
One thing I've noticed about D vs other languages which are getting more interest is that we do not have a list of companies actually using D in production on our homepage. While I know that there are quite a few development companies using go, we are not actively soliciting them for using their badges. E.g. Why don't we have a link to Facebook on our homepage? If you go someplace like http://msgpack.org/ you can clearly see a number of companies who effectively use msgpack in production and quotes from them. We should setup something like that on our homepage. So... Who all is using D in production? -Shammah
Re: Undefined symbol?
https://issues.dlang.org/show_bug.cgi?id=13172
reflect on this function
I'd like to do something like this:
@reflexive @transitive bool relation (T)(T a, T b)
out (result) {
mixin(property_verification!result);
}
body {
...
}
which becomes
out (result) {
// generated from @reflexive
assert (result == skip_contract!relation (b,a));
// generated from @transitive
static typeof(result) c;
if (result)
assert (skip_contract!relation (b,c) ==
skip_contract!relation (a,c));
c = b;
}
or something like that. I don't see a way to get exactly this,
but does anyone have any thoughts on something similar?
[Issue 14211] New: Compiler should devirtualize calls to members of final class
https://issues.dlang.org/show_bug.cgi?id=14211
Issue ID: 14211
Summary: Compiler should devirtualize calls to members of final
class
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
Compile with -m64 -inline -release -O:
class Mutex
{
void lock() {}
}
final class GCMutex : Mutex
{
//final override void lock() { super.lock(); }
}
void test()
{
GCMutex gcLock = new GCMutex;
gcLock.lock();
}
The disassembly for test() is:
_D4test4testFZv:
: 55 pushrbp
0001: 48 8B EC mov rbp,rsp
0004: 48 8D 0D 00 00 00 lea
rcx,[_D4test7GCMutex7__ClassZ]
000B: 48 83 EC 20sub rsp,20h
000F: E8 00 00 00 00 call_d_newclass
0014: 48 83 C4 20add rsp,20h
0018: 48 89 C1 mov rcx,rax
001B: 48 83 EC 20sub rsp,20h
001F: 48 8B 01 mov rax,qword ptr [rcx]
0022: 48 FF 50 28callqword ptr [rax+28h]
0026: 48 83 C4 20add rsp,20h
002A: 5D pop rbp
002B: C3 ret
I.e. the call to lock is still made through the virtual function table although
the class GCMutex is declared final.
If the commented code in GCMutex is enabled, the call is deviertualized, but
not inlined.
--
[Issue 13548] wrong sqrt
https://issues.dlang.org/show_bug.cgi?id=13548 Илья Ярошенко ilyayaroshe...@gmail.com changed: What|Removed |Added Summary|wrong CTFE sqrt |wrong sqrt --
Re: D usage quotes/badges
On Friday, 20 February 2015 at 21:51:27 UTC, Shammah Chancellor wrote: While I know that there are quite a few development companies using go, we are not actively soliciting them for using their badges. I know that this isn't what you're looking for because it lists people who use D, but you may find it interesting anyways: http://wiki.dlang.org/Current_D_Use
Re: GC deadlocks on linux
On Friday, 20 February 2015 at 14:33:31 UTC, Ola Fosheim Grøstad wrote: Yeah, either use plain C or avoid 3rd party libraries... I guess that includes phobos ;) AFAIK, in early days of unix there were no threads, processes were single-threaded, fork was the way to concurrency and exec was the most efficient way to run a program in memory-constrained conditions of 70s (kbytes of RAM!). Plain unix-like single-threaded processes, plain C heap, which didn't serialize access, because no threads, and worked fine with just virtual memory, which fork got right. That's the model, which should work the best with fork+exec.
Re: GC deadlocks on linux
On Friday, 20 February 2015 at 22:07:56 UTC, Kagamin wrote: AFAIK, in early days of unix there were no threads, processes were single-threaded, fork was the way to concurrency and exec was the most efficient way to run a program in memory-constrained conditions of 70s (kbytes of RAM!). Plain unix-like single-threaded processes, plain C heap, which didn't serialize access, because no threads, and worked fine with just virtual memory, which fork got right. That's the model, which should work the best with fork+exec. Indeed, actually, not only for the early days, but for the first 20 years or so! :-D Single thread, C, fork and a pipe + limited use of shared memory is a quite clean model. The underlying principle in Unix is to build complex software from many isolated simple units. This robust philosophy somehow got lost in the quest for bleeding edge.
Re: D and GPGPU
On Friday, 20 February 2015 at 10:05:34 UTC, francesco.cattoglio wrote: On Wednesday, 18 February 2015 at 18:14:19 UTC, luminousone wrote: HSA does work with discrete gpu's and not just the embedded stuff, And I believe that HSA can be used to accelerate OpenCL 2.0, via copyless cache coherent memory access. Unless I'm mistaken, it will more like the opposite: HSA will use OpenCL 2.0 as a backend to do that kind of copyless GPGPU acceleration. HSAIL does not depend on opencl, and it supports more then copyless gpgpu acceleration, as it said, it has been access to virtual memory, including the program stack. HSA defines changes to the MMU, IOMMU, cpu cache coherency protocol, a new bytecode(HSAIL), a software stack built around llvm and its own backend in the gpu device driver. OpenCL 2.0, generally obtains its copyless accel from remapping the gpu memory into system memory, not from direct access to virtual memory, Intel supports a form of copyless accel via this remapping system. The major difference between the two systems, is that HSA can access any arbitrary location in memory, where as OpenCL must still rely on the pointers being mapped for use. HSA has for example have complete access to runtime type reflection, vtable pointers, you could have a linked list or a tree that is allocated arbitrarily in memory.
Re: State of Windows x64 COFF support?
Implementations can have bugs, probably COFF support wasn't stress tested.
Re: Disallow destroy(structPtr)?
On 02/20/2015 12:30 PM, Steven Schveighoffer wrote: On 2/20/15 1:05 PM, Nick Treleaven wrote: It works correctly if I use destroy(*p), but the above code could perhaps be statically rejected by object.destroy to help prevent bugs. I'm beginning to think this is the right thing to do. It confuses so many people, and setting a pointer/class reference/array to null is easy enough without needing a special function to do it. In other words, if you are using destroy, you aren't just trying to nullify a pointer. You want to destroy what the pointer represents. The only problem is, how does this affect existing code? And templated containers... Despite the issue, I favor the current behavior partly because I am used to it from C++: A pointer going out of scope does not delete what it points to. (It can't do that because the pointer does not know about the object's ownership.) Ali
Re: reflect on this function
On 02/20/2015 02:32 PM, Vlad Levenfeld wrote:
I'd like to do something like this:
@reflexive @transitive bool relation (T)(T a, T b)
out (result) {
mixin(property_verification!result);
}
body {
...
}
which becomes
out (result) {
// generated from @reflexive
assert (result == skip_contract!relation (b,a));
// generated from @transitive
static typeof(result) c;
if (result)
assert (skip_contract!relation (b,c) == skip_contract!relation
(a,c));
c = b;
}
or something like that. I don't see a way to get exactly this, but does
anyone have any thoughts on something similar?
Apparently, __FUNCTION__ is valid in an out block:
import std.stdio;
import std.string;
struct reflexive
{}
struct transitive
{}
string property_verification(alias var)(string func = __FUNCTION__)
{
return format(
`writefln(We are in %s; and the value of '%s' is '%%s'., %s);`,
func, var.stringof, var.stringof);
}
@reflexive @transitive bool relation (T)(T a, T b)
out (result) {
mixin(property_verification!result);
} body {
return false;
}
void main()
{
int a, b;
relation(a, b);
}
The output printed inside the out block:
We are in deneme.relation!int.relation; and the value of 'result' is
'false'.
Ali
Re: reflect on this function
On Fri, 20 Feb 2015 22:51:21 +, Vlad Levenfeld wrote:
On Friday, 20 February 2015 at 22:44:35 UTC, ketmar wrote:
can you go with `relationImpl` and mixin/template that generates
`relation` with contract then? something like:
@reflexive @transitive bool relationImpl (T)(T a, T b) { ... }
alias relation = buildWithContracts!relationImpl;
then you can simply call `relationImpl` in your out section.
Yeah, this looks pretty good. As much as I hate the pimpl idiom,
having a one-liner alias right next to the definition should minimize
the eye-bleeding. Thanks!
and you can have an alias even before definition! ;-) this way it will
not lost.
signature.asc
Description: PGP signature
Re: dfmt 0.1.0
On Friday, 20 February 2015 at 23:00:25 UTC, Brad Anderson wrote: From what I understand they implemented a LaTeX style weighted line breaker which would explain why it works so much better than a typical code formatter. It's very smart about how it does line breaks. This seems to make all the difference. dfmt uses a weighting system for line breaks as well, though because this is 0.1.0 it doesn't always do what I expect it to do.
Re: reflect on this function
On Friday, 20 February 2015 at 22:44:35 UTC, ketmar wrote:
can you go with `relationImpl` and mixin/template that generates
`relation` with contract then? something like:
@reflexive @transitive bool relationImpl (T)(T a, T b) { ... }
alias relation = buildWithContracts!relationImpl;
then you can simply call `relationImpl` in your out section.
Yeah, this looks pretty good. As much as I hate the pimpl idiom,
having a one-liner alias right next to the definition should
minimize the eye-bleeding. Thanks!
Compiler instrinsics
Is there a complete list of DMD compiler intrinsics? I searched the compiler source code but they seem scattered around. I discovered some of them (strlen, memcpy, strcmp, etc) but I suppose there is a list somewhere.
[Issue 13172] optimize and rawread cause symbol undefined errors
https://issues.dlang.org/show_bug.cgi?id=13172 briancsch...@gmail.com changed: What|Removed |Added CC||briancsch...@gmail.com --- Comment #15 from briancsch...@gmail.com --- I'm not able to reproduce this with 2.067.0-b2. --
Re: reflect on this function
On Fri, 20 Feb 2015 22:32:53 +, Vlad Levenfeld wrote:
I'd like to do something like this:
@reflexive @transitive bool relation (T)(T a, T b)
out (result) {
mixin(property_verification!result);
}
body {
...
}
which becomes
out (result) {
// generated from @reflexive
assert (result == skip_contract!relation (b,a));
// generated from @transitive static typeof(result) c;
if (result)
assert (skip_contract!relation (b,c) ==
skip_contract!relation (a,c));
c = b;
}
or something like that. I don't see a way to get exactly this,
but does anyone have any thoughts on something similar?
can you go with `relationImpl` and mixin/template that generates
`relation` with contract then? something like:
@reflexive @transitive bool relationImpl (T)(T a, T b) { ... }
alias relation = buildWithContracts!relationImpl;
then you can simply call `relationImpl` in your out section.
sorry if i didn't understand what you want and just throws in some noise.
signature.asc
Description: PGP signature
Re: contiguous ranges
On Friday, 20 February 2015 at 19:54:20 UTC, Andrei Alexandrescu wrote: On 2/20/15 11:09 AM, deadalnix wrote: On Friday, 20 February 2015 at 12:23:49 UTC, Vlad Levenfeld wrote: Yes. A slice is the simplest realization of a contiguous range. I argue that it is useful to have structures which have slice-like behavior without actually being slices. I'm still not sure what more complex continuous range exists, and if it is worth the complexity of adding them to the language. Reference counted slices would be the only one coming to mind. There are several other ranges with contiguous _support_: retro, randomCover, map (over ranges with that property), and probably more. Andrei The RCSlice I can buy it, but map is certainly not contiguous. If an RCSlice can decay to a borrowed slice, then even this one goes away.
Re: D usage quotes/badges
On Friday, 20 February 2015 at 21:51:27 UTC, Shammah Chancellor wrote: While I know that there are quite a few development companies using go, Dude. we are not actively soliciting them for using their badges.
Re: dfmt 0.1.0
On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott wrote: dfmt is a D source code formatting tool. https://github.com/Hackerpilot/dfmt/ https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0 Great! I've been using clang-format lately for my C++ code and it's really blown me away how good it is. It's not opinionated about how things should be, it just does whatever style you've set it to. The Visual Studio plugin they have just gives me a keyboard shortcut and when I hit it, it formats the current line or selection. I waste almost no time formatting code now. I just type and hit the format key and move on. If it formatted something differently than how I would have done it I just let it be because how it formatted is usually almost as good anyway. I feel like it's been as big of boon to my coding speed as learning vim was. From what I understand they implemented a LaTeX style weighted line breaker which would explain why it works so much better than a typical code formatter. It's very smart about how it does line breaks. This seems to make all the difference. This is all to say I hope dfmt becomes as awesome as clang-format is at some point. Hopefully I can find some time to contribute.
Re: contiguous ranges
On Friday, 20 February 2015 at 19:47:24 UTC, Pasqui23 wrote: You could have the best of both worlds this way: R declaw_filter3(R)(R r)if(is(R:float[stride][],size_t stride)) and write ac.declaw_filter3.play; Stride is tied to alignment and not value type size in the general case (float being a special case), so stride should be in bytes...
[Issue 14210] invalid merging of template instances
https://issues.dlang.org/show_bug.cgi?id=14210 --- Comment #2 from Kenji Hara k.hara...@gmail.com --- (In reply to Ketmar Dark from comment #0) compiler erroneously merges templates with different delegate types. let's run the following code: [snip] both results are obviously wrong, 'cause compiler should not merge two instantiations. yet compiler checks for merge possibility by checking mangled names, and both types mangles to the same string. this breaks automatic CTFE wrapping of functions for some scripting engines, and possibly many more cases. In D, default arguments of a function pointer/delegate type is not a part of type. I's mostly fixed in the PR: https://github.com/D-Programming-Language/dmd/pull/1102 In a nutshell, instantiated templates cannot take a type with default arguments. They should be stripped off in the instantiation. In the OP code, the two 'test' function template call should instantiate only one function with DT = int function(int) pure nothrow @nogc @safe. --
[Issue 14210] invalid merging of template instances
https://issues.dlang.org/show_bug.cgi?id=14210
--- Comment #3 from Ketmar Dark ket...@ketmar.no-ip.org ---
it's ok to instantiate the same template (as the function signatures are the
same). but it's not ok to merge them for CTFE. actually, i have code like this:
===
import std.traits : isSomeFunction;
Cell opIndexAssign(DT) (DT dg, string name) if (isSomeFunction!DT) {
import std.traits : ParameterTypeTuple, ParameterDefaultValueTuple,
ReturnType;
alias args = ParameterTypeTuple!DT;
alias retType = ReturnType!DT;
Cell cfn;
// default args can be taken only from delegate itself, not from the type,
hence this hack
alias defaultArguments = ParameterDefaultValueTuple!dg;
cfn new CellFnX!(DT, defaultArguments)(dg);
this[name] = cfn;
return cfn;
}
private class CellFnX(DT, Defs…) : Cell {
DT dg;
this (DT adg) { super(aismacro); dg = adg; }
override Cell execute (Milf eng, CellCons args) {
…
ParameterTypeTuple!DT arguments;
foreach (auto idx, ref arg; arguments) {
static if (!is(Defs[idx] == void)) {
arg = Defs[idx];
} else {
arg = Cell.from(args.car);
args = args.cdr;
}
}
}
}
===
this is CTFE wrapper generator, and with merging like now *each* registered
delegate with the same parameter types will get the same default values. this
kills the whole CTFE wrapper generation idea.
--
[Issue 14201] fatal error LNK1235: corrupt or invalid COFF symbol table
https://issues.dlang.org/show_bug.cgi?id=14201 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1acab082d11618f635332bf15a5c270b6bc14856 Merge pull request #4422 from etcimon/coff-symbol-tbl fatal error LNK1235: corrupt or invalid COFF symbol table - Fix Issue 14201 --
[Issue 14201] fatal error LNK1235: corrupt or invalid COFF symbol table
https://issues.dlang.org/show_bug.cgi?id=14201 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12368] std.file.write conflicts with std.stdio.write
https://issues.dlang.org/show_bug.cgi?id=12368 Issue 12368 depends on issue 13009, which changed state. Issue 13009 Summary: [REG2.064] inout overload conflicts with non-inout when used via alias this https://issues.dlang.org/show_bug.cgi?id=13009 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13009] [REG2.064] inout overload conflicts with non-inout when used via alias this
https://issues.dlang.org/show_bug.cgi?id=13009 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14200] C++ mangling issue with expanded tuples
https://issues.dlang.org/show_bug.cgi?id=14200 --- Comment #2 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1c24d35583b1d49045013d7451c92c0752ba55e8 Merge pull request #4421 from Ingrater/fix141920 Fix Issue 14200 - Tuples not being expanded during c++ mangling. --
[Issue 14210] invalid merging of template instances
https://issues.dlang.org/show_bug.cgi?id=14210
--- Comment #6 from Ketmar Dark ket...@ketmar.no-ip.org ---
(In reply to Kenji Hara from comment #4)
(In reply to Ketmar Dark from comment #3)
this is CTFE wrapper generator, and with merging like now *each* registered
delegate with the same parameter types will get the same default values.
this kills the whole CTFE wrapper generation idea.
Unfortunately the code does not work as you expected. Default arguments
won't be encoded in type, so you cannot capture them via type.
Instead of that, you need to handle a function symbol.
void foo(alias f)()
{
import std.traits;
pragma(msg, ParameterDefaultValueTuple!f); // directly give a function
symbol
}
void main()
{
foo!((int a=40) = a+2); // tuple(40)
foo!((int a) = a+2);// (void)
}
yep, that was exactly the thing i wanted to avoid… i wanted to use `eng[func]
= (int a=40) = a+2;` instead of `eng[func] = buildWrapper!((int a=40) =
a+2);`.
i was tricked by the fact that `typeof(dg)` knows about default args (hence the
hack with `ParameterDefaultValueTuple!dg`), and i was sure that different
default values means different declared types for dg, with same actual
types (or something like that, i don't know how to word it right).
and your patch broke even that hack. (sobs)
ah, well, i guess i can't get everything i want. at least i found a bug.
thank you.
--
[Issue 14096] ICE in toir.c: 187
https://issues.dlang.org/show_bug.cgi?id=14096 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3fb5ef65a1ee69c4198a4ed8b52df515f91370fc fix Issue 14096 - ICE in toir.c: 187 https://github.com/D-Programming-Language/dmd/commit/0e0a328fe8bd07e753c7869e138382cb64f0faea Merge pull request #4424 from 9rnsr/fix14096 Issue 14096 - ICE in toir.c: 187 --
[Issue 14210] invalid merging of template instances
https://issues.dlang.org/show_bug.cgi?id=14210 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #5 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4426 --
[Issue 14210] invalid merging of template instances
https://issues.dlang.org/show_bug.cgi?id=14210
--- Comment #4 from Kenji Hara k.hara...@gmail.com ---
(In reply to Ketmar Dark from comment #3)
this is CTFE wrapper generator, and with merging like now *each* registered
delegate with the same parameter types will get the same default values.
this kills the whole CTFE wrapper generation idea.
Unfortunately the code does not work as you expected. Default arguments won't
be encoded in type, so you cannot capture them via type.
Instead of that, you need to handle a function symbol.
void foo(alias f)()
{
import std.traits;
pragma(msg, ParameterDefaultValueTuple!f); // directly give a function
symbol
}
void main()
{
foo!((int a=40) = a+2); // tuple(40)
foo!((int a) = a+2);// (void)
}
--
[Issue 12379] Add toFile function which writes its first argument to a file
https://issues.dlang.org/show_bug.cgi?id=12379 Issue 12379 depends on issue 13009, which changed state. Issue 13009 Summary: [REG2.064] inout overload conflicts with non-inout when used via alias this https://issues.dlang.org/show_bug.cgi?id=13009 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: GC deadlocks on linux
On Friday, 20 February 2015 at 15:17:22 UTC, Martin Nowak wrote: Might want to try using libasync without multiple threads. http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them Or you temporarily disable the GC before forking and enable it again afterwards.
Re: Reloaded for dub
On 02/20/2015 03:00 PM, Kingsley wrote: I use for developing with vibe.d and other dub D project that have an executable binary. The code is here: https://github.com/kingsleyh/reloaded Nice, want to contribute? https://github.com/D-Programming-Language/dub/issues/446
Re: GC deadlocks on linux
On 02/18/2015 09:35 PM, Byron Heads wrote: I am in the daemonize library https://github.com/NCrashed/daemonize Might want to try using libasync without multiple threads. http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
Re: Writing game engine in C++, considering switching to D
On Friday, 20 February 2015 at 13:44:04 UTC, ponce wrote: On Friday, 20 February 2015 at 13:04:51 UTC, John Colvin wrote: On Friday, 20 February 2015 at 09:57:48 UTC, francesco.cattoglio wrote: (e.g: if the GC calls any OpenGL function, you get a nice crash since OpenGL is not multithread-aware by default). Really? I don't see this in my projects. The GC stops the world, so there shouldn't be any races. Not a race. An OpenGL contect can only active in one thread at once. If the GC calls a destructor from a thread which doesn't have that context active, it will probably crash. Hmm, yeah you're right. That would explain some of my weirder crashes! However, if you make the context current in the GC thread that's cleaning up, then you should be fine. There's nothing wrong with having the same context current in multiple threads as long as you don't access it concurrently.
Re: We are Beta (2.067.0-b2)
On 02/19/2015 11:06 PM, Brian Schott wrote: Many of the beta-2 files are missing from downloads.dlang.org, and all of them are missing from ftp.digitalmars.com. This makes testing the Debian packages or using DVM impossible. Quote from the dmd-beta post. We had some troubles with the documentation generation. In order to not delay the beta even further the zip files don't contain documentation, the dman tool is missing and there are no installers. We'll try to deliver those subsequently or with the next beta.
Re: Are there any 2D games libraries available for D2?
On Friday, 20 February 2015 at 07:12:34 UTC, Gan wrote: On Friday, 20 February 2015 at 04:52:29 UTC, Jeremy DeHaan Chiming in with my own library. https://github.com/Jebbs/DSFML Things are a bit of a mess, but I'm gearing up for a release soon and things will be all nice and tidy and structured. I really want to check out DGame but I suggest withholding from it until it becomes actively maintained again. I'm using DSFML and it is one of the easiest. Though I had strange issues like high ram usage and text not rendering. Though the ease of use and performance is phenomenal. Thanks for the heads up. I'll open an issue to inspect RAM usage, but can you let me know when you were having Text rendering issues so I can inspect that too?
