Vibe.d diet template reuse
I would like to create some generic diet templates for different html functionality. Some code in the template will need to be setup/changed for it to function properly. How can I write code that allows for one to express generic statements in the template but access/modify them in another template? Is there a way to pass around a context, including functional code between templates? e.g., I might want to create a d function in a diet template that will be used in generating another template. e.g. (pseudo), block -auto MyFunc(int x) { return 3*x; } include test test.dt: block -for(i; 1..MyFunc(3)) ... having such a feature allows me to generalize my templates quite a bit and reuse them for various html features rather than duplicating the majority of the code but I need a way to pass some unspecified functionality to a template before instantiation.
[Issue 14613] DMD: Internal error: backend/cod1.c 1567 on '-O' switch
https://issues.dlang.org/show_bug.cgi?id=14613 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/a4f584ffdc195cc99a738ba495c8261284813d2a fix Issue 14613 - DMD: Internal error: backend/cod1.c 1567 on '-O' switch https://github.com/dlang/dmd/commit/5f803b0d75a722937a13b6590176984c3d436403 Merge pull request #6218 from WalterBright/fix14613 fix Issue 14613 - DMD: Internal error: backend/cod1.c 1567 on '-O' sw… --
Re: Ever want to compile D on your Android phone? Well, now you can!
On Saturday, 29 October 2016 at 21:47:35 UTC, Mergul wrote: On Sunday, 24 January 2016 at 15:12:30 UTC, Joakim wrote: An alpha release of ldc, the llvm-based D compiler, for Android devices is now available. It is best used with the excellent Termux app (https://play.google.com/store/apps/details?id=com.termux=en) and a bluetooth keyboard. ;) Updated test runners, that run most tests from the standard library on any Android device, are also available (results have been reported for everything from a TomTom BRIDGE GPS navigation device to a Huawei Watch): https://github.com/joakim-noah/android/releases/tag/polish You can install a test runner app or run a command-line binary. Please report your results in this thread in the ldc forum, which requires no registration, with the info and format requested there, particularly for Android 4.1 or earlier: https://forum.dlang.org/thread/bafrkjfwmoyriyhmq...@forum.dlang.org If you try out the native compiler, take a look at the README that comes with it for instructions. If you have a D/OpenGL app you'd like to port to Android and submit to the Play Store, let me know if I can help with that process. I'm trying to build native-activity sample in .d. I have build cross ldc compiler using your instructions. When I have build native activity its work properly on BlueStack, but on my phone (android 4.2.1) this always crash and run again. Your app test runner work perfect and every test passed. Application always crash when I'm using android_app.savedState. if (state.savedState != null) { // We are starting with a previous saved state; restore from it. engine.state = *cast(saved_state*)state.savedState; //crash! } Sorry for bad english. Hmm, I am unable to reproduce the crash with that sample app on my tablet running Marshmallow. Can you try the prebuilt cross-compilers at https://github.com/joakim-noah/android/releases and see if the problem crops up with those too? If you are able to reproduce consistently with some compiler, please file an issue with more info, such as which ldc version you built and what commands you used to build the app, either at the github repo for the sample app, https://github.com/joakim-noah/android/, or if you can reproduce with the pre-built ldc compilers, at the ldc github, https://github.com/ldc-developers/ldc/.
fPIC Error
I am running Debian Testing and I think I have run into the recent fPIC issue. This is the source code for the test project I am using: import std.stdio; void main() { writeln("Edit source/app.d to start your project."); readln(); } When I try to compile a project, I get the following errors (truncated for brevity): /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libphobos2.a(thread_26c_155.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status dmd failed with exit code 1. Exit code 2 Build complete -- 1 error, 0 warnings I followed the advice to add "-defaultlib=libphobos2.so -fPIC" to my dmd.conf file as a workaround. This causes it to build without errors, but now the resulting executable is marked as a shared library: Output of the file command: fpictest: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e83ac1d5dea9e78912a6175d3c1c54b50b4e29cd, not stripped Is this a known issue with this workaround or is there some other setting that I need to change?
mangle!(void function())("foo").demangle = "void function()* foo"
mangle!(void function())("foo").demangle returns "void function()* foo" how would i get instead: `void foo ()` ? my current workaround: alias FunctionTypeOf(Fun)=typeof(*Fun.init); mangle!(FunctionTypeOf!(void function()))("foo")
Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!
On 11/02/2016 11:43 PM, Vladimir Panteleev wrote: For each function that is only called during compilation (e.g. for code generation), at the top add: if (!__ctfe) return; That's it. For one project, this brought compilation time (with optimizations) from over an hour down to seconds! As it turns out, DMD will codegen all functions, even templated ones when they're instantiated, whether they're called by something or not. With metaprogramming-heavy code, it's easy to run into some optimizer performance corner cases, however this may make an impact regardless. That's interesting. cc Dmitry, perhaps adding that to ctRegex would be helpful. -- Andrei
Re: Error: function std.stdio.setmode is not accessible from module a
On Wednesday, 2 November 2016 at 11:17:49 UTC, Jonathan M Davis wrote: setmode was never publicly documented, and technically, you weren't supposed to be using it from there (since it wasn't documented). It was fixed in 2.072.0 so that all of the undocumented stuff in std.stdio was made private. It was never intended that setmode be part of the public API in std.stdio. But of course, since you were using it in spite of it being undocumented, your code broke. Now, setmode is a C function from Windows, so it should be in druntime where you could easily import it, but unfortunately, it looks like it's currently missing from there. Rather, the bindings for it were just put directly in std.stdio instead of in druntime where they belongs. So, if anything, the bug is that druntime doesn't have it. So, it would make sense to open a bug for that. But if you want to still use it without it being in druntime, you can just declare the bindings yourself, as annoying as that may be. e.g. this is essentially what's in std.stdio: version(DIGITAL_MARS_STDIO) extern(C) int setmode(int, int) nothrow @nogc; else version(MICROSOFT_STDIO) { extern(C) int _setmode(int, int) nothrow @nogc; alias setmode = _setmode; } It really should be put in druntime though. - Jonathan M Davis Thanks for the explanation, Jonathan! OK, I'll try adding my own binding for the time being, and submit a feature request. I guess this does not count as regression since it was undocumented, as you say. Although I would have thought it was a documentation deficiency instead. Working, not obviously wrong code stopped working without an alternative method available. Perhaps it's OK if it can be added to druntime the future. Also I am confused by it being both deprecation and error. I thought that deprecation message was just a warning about something that will stop working in the future, and the code should still compile. However in this case dmd first informs me that something is deprecated (it's not clear what exactly is deprecated). And then immediately fails with an error, on the same function call. Is it another separate diagnostic issue, or is it working as intended? Thanks, Kirill
[Issue 15576] extern(C++, namespace) wrong mangling of variables (Windows)
https://issues.dlang.org/show_bug.cgi?id=15576 --- Comment #3 from Walter Bright--- https://github.com/dlang/dmd/pull/6232 --
[Issue 16658] Win32API: default IE ver. set to 4.0 is too old
https://issues.dlang.org/show_bug.cgi?id=16658 --- Comment #1 from j...@red.email.ne.jp --- Forgot to mention: The value cooperating with this is defined that _WIN32_WINNT = 0x501 ( means WinXP ) So I suppose that _WIN32_IE should be changed as follows. version (IE10) { } else version (IE9) { } else version (IE8) { ... snipped ... } else static if (_WIN32_WINNT >= 0x501) { // ADD enum uint _WIN32_IE = 0x600; // ADD } else static if (_WIN32_WINNT >= 0x410) { enum uint _WIN32_IE = 0x400; // this is used now } else { --
[Issue 16658] New: Win32API: default IE ver. set to 4.0 is too old
https://issues.dlang.org/show_bug.cgi?id=16658 Issue ID: 16658 Summary: Win32API: default IE ver. set to 4.0 is too old Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: j...@red.email.ne.jp About Win32 API shipped with 2.070 druntime, the condition for IE 'version _WIN32_IE = 0x400' ( by default ) is too old. # See druntime/src/core/sys/windows/w32api.d. At least, the value should be 0x600(the version bundled with WinXP), otherwise some GUI enhansements (switch by that) are ignored because they are shared with the OS. Note: If someone made an old app for Win98 or 2000 with the Win32 Bindings _AND_ he has fixed it for the current druntime, it may be subject to change. --
Re: State of issues.dlang.org
On Wednesday, 2 November 2016 at 23:01:42 UTC, Brad Roberts wrote: Upgrading is on my todo list. I'll try to get to it soon. thank you for investigating the possibility. post preview is a great feature! ;-)
Re: State of issues.dlang.org
On 11/2/2016 4:01 PM, Brad Roberts via Digitalmars-d wrote: Upgrading is on my todo list. I'll try to get to it soon. Thank you, Brad. Your support of Bugzilla is critically important.
Re: Should I prefer immutable or const?
On Wednesday, November 02, 2016 23:23:22 Nordlöw via Digitalmars-d-learn wrote: > On Tuesday, 1 November 2016 at 18:55:26 UTC, Jonathan M Davis > > wrote: > > - Jonathan M Davis > > Thanks. I'll go for immutable, when possible, then. > > I wish I had a shorter way to write immutable, though :) > > Do you think it would be possible to adopt Rust's syntax `let`? I'm not very familiar with rust, so I don't know, but in general, at this point, you'd need a pretty solid argument why a syntactic change to the language was a big improvement, or it wouldn't happen. It also would likely require that someone put in the time and effort to produce a solid DIP in favor of it, and from how Andrei has been responding to DIP-related stuff of late, it sounds like he and Walter are setting the bar very high right now. And I'd guess that simply not liking how many characters it takes to type immutable is nowhere near a sufficient reason to get anything changed. But maybe a solid DIP would stand a chance. I don't know. - Jonathan M Davis
Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays
On Wednesday, 2 November 2016 at 03:36:42 UTC, Andrei Alexandrescu wrote: Last time I looked our associative arrays were arrays of singly-linked lists. It follows that in order to implement reserve() we'd need a freelist allocator approach, which preallocates a bunch of nodes in a single contiguous block of memory. Aren't associative arrays using open addressing for collision resolution? I'm looking at routines findSlotInsert() and findSlotLookup() here: https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L102 There is already a resize() routine: https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L141 The resize() routine takes the new size of the bucket array as an argument. Could a 'reserve' routine call this? Scanning through the code, it appears policy on size of the bucket array is established by callers to resize(), e.g. see the _aaRehash() function, which calls resize().
Re: CTFE Status
On Wednesday, 2 November 2016 at 23:48:46 UTC, Nordlöw wrote: On Wednesday, 2 November 2016 at 11:01:55 UTC, Stefan Koch wrote: I am now passing phobos unittests! I can't wait to see this in action! Keep on going and I'll keep praying... No need for prayer. I am trying my best to be doing solid engineering work. Neither god nor the devil will paly any role. I am currently working on making the DMD-AST-facing side of the code more solid. With a bit of luck I can role out a preview release soon. But I will only do so when there are no known bugs left.
Re: CTFE Status
On Wednesday, 2 November 2016 at 11:01:55 UTC, Stefan Koch wrote: I am now passing phobos unittests! I can't wait to see this in action! Keep on going and I'll keep praying...
Re: Should I prefer immutable or const?
On Tuesday, 1 November 2016 at 18:55:26 UTC, Jonathan M Davis wrote: - Jonathan M Davis Thanks. I'll go for immutable, when possible, then. I wish I had a shorter way to write immutable, though :) Do you think it would be possible to adopt Rust's syntax `let`?
Re: State of issues.dlang.org
On 11/2/16 2:44 PM, Vladimir Panteleev via Digitalmars-d wrote: On Wednesday, 2 November 2016 at 12:34:04 UTC, Wyatt wrote: This was added in Bugzilla 5.0. We're just running 4.4.2 on issues.d.o. Unfortunately, I'm not sure how easy it is to upgrade... I believe Brad is using the Debian packaged version, so we'll get it whenever it reaches whatever Debian flavor Brad is running. Actually, bugzilla is one of the few things that's not from pre-packaged installers. :) I do have some minor modifications that have to be ported over, primarily related to interacting with the newsgroups. I haven't looked at the 4 -> 5 update to see how easily they changes will translate. The 3 -> 4 transition took some re-working due to internal changes in bugzilla. Upgrading is on my todo list. I'll try to get to it soon. Later, Brad
Re: RC buffer
On 11/02/2016 01:00 AM, Andrei Alexandrescu wrote: In order to make opAssign safe, a language change will be necessary. Take that back, no need for a language change as long as nobody returns references to refcounted memory. Just pushed a commit to add @safe-ty annotations everywhere. Works as advertised! So now we have a buffer of ubyte that is reference counted, safe, and supports qualifiers properly (no shared yet). https://github.com/dlang/phobos/pull/4878 Andrei
Re: State of issues.dlang.org
On Wednesday, 2 November 2016 at 12:34:04 UTC, Wyatt wrote: This was added in Bugzilla 5.0. We're just running 4.4.2 on issues.d.o. Unfortunately, I'm not sure how easy it is to upgrade... I believe Brad is using the Debian packaged version, so we'll get it whenever it reaches whatever Debian flavor Brad is running.
Re: Function Proposal: std.algorithm.iteration : cumulativeSum
On Wednesday, 2 November 2016 at 20:03:59 UTC, Meta wrote: I think there's an obvious reason as to why they're not called that. I almost always see languages call it cumsum rather than cumulativeSum. R - https://stat.ethz.ch/R-manual/R-devel/library/base/html/cumsum.html Matlab - https://www.mathworks.com/help/matlab/ref/cumsum.html Python - https://docs.scipy.org/doc/numpy/reference/generated/numpy.cumsum.html The only exceptions I could find were languages that called it something else, like Accumulate in Mathematica or the scan functions noted in the cumulativeFold function doc. In practice, I would probably just create an alias.
Re: Ever want to compile D on your Android phone? Well, now you can!
On Tuesday, 1 November 2016 at 13:33:02 UTC, Steven Schveighoffer wrote: android_app.savedState appears to be defined here: https://github.com/joakim-noah/android/blob/polish/android_native_app_glue.d#L56 It's a void *. So comparing against null with != is identical to !is. There are actually cases where comparing against null with != is valid, and what you want exactly (e.g. comparing a string to null to check for empty string). In this case, fixing the comparison is not the answer. What is happening is one of several things: 1. I don't know what type `engine` is, so if it's a pointer, then dereferencing the state member may be the culprit if engine is invalid. 2. If state is a pointer, then you could be crashing at the if statement (unlikely). 3. state or state.savedState isn't being properly initialized. 4. Something else (e.g. code generation error). Hope it's not this one. -Steve I don't know what was bad but I start working on something different. I managed to compile project with SDL. Using SDL c++ code which call my D code. It's work. Used libraries: SDL, Assimp, FreeImage. http://imgur.com/a/aMs15
Re: SoundTab Theremin software synthesizer
On Wednesday, 2 November 2016 at 09:35:20 UTC, Vadim Lopatin wrote: On Monday, 31 October 2016 at 22:33:38 UTC, Karabuta wrote: On Friday, 28 October 2016 at 08:28:41 UTC, Vadim Lopatin wrote: Hello, I've open sourced my project SoundTab: https://github.com/buggins/soundtab/ I've published derelict-wintab (Wacom tablet API) and wasapi (windows audio API) libraries used for this project. +1
Re: Linux Kernel in D?
On Wednesday, 2 November 2016 at 13:56:22 UTC, qznc wrote: On Tuesday, 1 November 2016 at 16:22:58 UTC, Andrei Alexandrescu wrote: [...] Nevertheless, I don't see a successful D kernel in the foreseeable future. Building a kernel for IoT devices is trendy, but you want a lot more portability for that and C compilers are everywhere. On the server, you could build a hypervisor OS with D, but currently containers are hyped so much more. You'd only have a chance, if you also port the JVM onto your D-OS. Still, where is the advantage to Linux? Who knew containers will suddenly become a thing? You never know what might happen, a D kernel might as well be the game changer.
Re: Function Proposal: std.algorithm.iteration : cumulativeSum
On Wednesday, 2 November 2016 at 00:41:38 UTC, jmh530 wrote: On Tuesday, 1 November 2016 at 22:06:36 UTC, Ivan Kazmenko wrote: DMD 2.072 just got cumulativeFold: https://dlang.org/changelog/2.072.0.html#std-algorithm-iteration-cumulativeFold https://dlang.org/phobos/std_algorithm_iteration.html#cumulativeFold I was happy to see that. I'm surprised there wasn't more angst about the name. cumulativeSum should be cumsum, which implies that cumulativeFold should be cumfold, IMO. I think there's an obvious reason as to why they're not called that.
Re: __traits(getMember)
On 2016-11-02 17:30, Márcio Martins wrote: Can we get a getMember and a getOverloads that won't check for visibility or anything else? __traits appears really powerful, but every-time I try to use it for anything other than a toy example or very simple serialization, it seems like everything falls apart due to some detail... and I end up having to hack it up with string mixins and static if(is(typeof(() { some_code; }))). For serialization, where you most likely only need to access the fields, you can use .tupleof which will bypass the protection. -- /Jacob Carlborg
Re: Release D 2.072.0
On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. http://dlang.org/download.html This is the release ships with the latest version of dub (v1.1.0), comes with lots of phobos additions and native TLS on OSX. See the changelog for more details. http://dlang.org/changelog/2.072.0.html -Martin https://www.reddit.com/r/programming/comments/5aru4f/d_version_2072_released_over_200_bugs_fixed/
Re: __traits(getMember)
On Wednesday, November 02, 2016 16:30:04 Márcio Martins via Digitalmars-d wrote: > Can we get a getMember and a getOverloads that won't check for > visibility or anything else? That's coming. There was a big discussion on it after the import rules were changed. But IIRC, it was decided that we wouldn't just switch to that immediately (maybe because it was a point release?). I don't remember the details now, so I guess that I'm not very helpful. I'd suggest trying 2.072.0, now that it's out, and seeing if that fixes your problem. If not, 2.073.0 probably will when we get it - which wouldn't be very helpful now, but at least you'd know that the change was coming. - Jonathan M Davis
Re: Function Proposal: std.algorithm.iteration : cumulativeSum
On Tuesday, 1 November 2016 at 21:52:40 UTC, e-y-e wrote: ... bump : any more opinions?
Re: Mir GLAS is a C library and passes Natlib's test suite! And questions :-)
On Saturday, 29 October 2016 at 11:25:17 UTC, Nicholas Wilson wrote: On Saturday, 29 October 2016 at 10:21:02 UTC, Guillaume Piolat wrote: On Saturday, 29 October 2016 at 01:43:03 UTC, Nicholas Wilson wrote: If you have any experience with either OpenCL or CUDA we'd love to have your input. Have experience with both, more CUDA than OpenCL though. Feel free to contact me. Great! I'll let you know when the compiler stuff is merged, probably in mir's public gitter. I have experience with both CUDA and OpenCL. As soon as the compiler stuff is in, I'd be happy to port some of my standard microbenchmarks (mostly computational fluid dynamics stuff) and see how it stacks up in both performance/ease of use and get you some feedback. I'm following the git repo and occasionally checking these forums, but feel free to contact me via e-mail or any other medium.
Re: hashOf()
On Wednesday, 2 November 2016 at 16:14:23 UTC, Márcio Martins wrote: If you include core.internal.hash, you cannot call hashOf() anymore, because it conflicts with the implicit import in object.d, this is annoying in itself... You should still be able to call it with the full name, `object.hashOf(...)` vs `core.internal.hash.hashOf(...)`
__traits(getMember)
Can we get a getMember and a getOverloads that won't check for visibility or anything else? __traits appears really powerful, but every-time I try to use it for anything other than a toy example or very simple serialization, it seems like everything falls apart due to some detail... and I end up having to hack it up with string mixins and static if(is(typeof(() { some_code; }))). Also, I found this bug: import std.datetime; import std.stdio; import std.traits; import std.meta; template staticIota(int start, int stop, int step = 1) { static if(start < stop) { alias staticIota = AliasSeq!(start, staticIota!(start + step, stop, step)); } else { alias staticIota = AliasSeq!(); } } struct M { void test(T)(T x) { enum MemberName = "day"; foreach (i; staticIota!(0, __traits(getOverloads, x, MemberName).length)) { alias Member = Alias!(__traits(getOverloads, x, MemberName)[i]); alias MemberType = typeof(&__traits(getOverloads, x, MemberName)[i]); static if (is(FunctionTypeOf!(Member)) && (__traits(getProtection, Member) == "public")) { auto addr = //Error: this for day needs to be type Date not type M pragma(msg, MemberName, MemberType); writeln("addr: ", addr); } } } } void main() { Date x; M m; m.test(x); } // output: errocase.d(23): Error: this for day needs to be type Date not type M dayubyte delegate() const pure nothrow @property @safe errocase.d(23): Error: this for day needs to be type Date not type M dayvoid delegate(int day) pure @property @safe errocase.d(34): Error: template instance errocase.M.test!(Date) error instantiating It works fine if test(T)() is not a member function...
Re: hashOf()
On Wednesday, November 02, 2016 16:19:44 John Colvin via Digitalmars-d wrote: > I think that "internal" means "for internal use", I.e. don't > import and use it outside. > > You could argue that object.hashOf should hash the contents of > slices, not just the meta-data (i.e. length / ptr), but that's a > separate matter. Yeah. Don't use anything in an internal package in either druntime or Phobos. And now that we can do stuff like package(std), it should be possible to fix it so that those symbols _can't_ be imported while still being usable by other code inside the higher level package. Previously, the only way to have core.internal accessible by the rest of core was to have it be public, which then didn't actually prevent you form doing stuff like importing it in your own code even though you shouldn't. So, core.internal should be fixed to use package(core). - Jonathan M Davis
Re: hashOf()
On Wednesday, 2 November 2016 at 16:14:23 UTC, Márcio Martins wrote: There are 2 hashOf() definitions, one in object.d and one in core.internal.hash.d If you include core.internal.hash, you cannot call hashOf() anymore, because it conflicts with the implicit import in object.d, this is annoying in itself... The bigger issue though, is that they have different semantics: import core.internal.hash : hashOfInt = hashOf; void main() { string moo = "moo"; assert(moo.hashOfInt == moo.idup.hashOfInt); // ok - hashes moo.ptr[0..moo.length] assert(moo.hashOf == moo.idup.hashOf); // fail - hashes [0..moo.sizeof] } Did anyone else fall into this trap? I think that "internal" means "for internal use", I.e. don't import and use it outside. You could argue that object.hashOf should hash the contents of slices, not just the meta-data (i.e. length / ptr), but that's a separate matter.
hashOf()
There are 2 hashOf() definitions, one in object.d and one in core.internal.hash.d If you include core.internal.hash, you cannot call hashOf() anymore, because it conflicts with the implicit import in object.d, this is annoying in itself... The bigger issue though, is that they have different semantics: import core.internal.hash : hashOfInt = hashOf; void main() { string moo = "moo"; assert(moo.hashOfInt == moo.idup.hashOfInt); // ok - hashes moo.ptr[0..moo.length] assert(moo.hashOf == moo.idup.hashOf); // fail - hashes [0..moo.sizeof] } Did anyone else fall into this trap?
Re: RC buffer
On 11/02/2016 11:32 AM, Andrei Alexandrescu wrote: On 11/02/2016 07:29 AM, Nick Treleaven wrote: On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei Alexandrescu wrote: In order to make opAssign safe, a language change will be necessary. Technically, it should be possible with runtime checks: https://forum.dlang.org/post/aeeffshzkfjbrejzt...@forum.dlang.org The checking overheads disappear when -noboundschecks is passed. The user has to manually copy the RCSlice when necessary for correct code. It seems opAssign for RCSlice is unsafe, is that right? Consider (with your codebase): @safe void fun(ref RCSlice!int a, ref RCSlice!int b) { a = RCSlice!int(); ... use b ... } @safe void gun(ref RCSlice!int s) { fun(s, s); } Assume the reference count of s is 1 upon entering gun. Then the first thing opAssign does is to call the destructor of the slice, which deallocates memory. Subsequently the other reference (b) is dangling. Ah, never mind, the two names refer to the same object. -- Andrei
[Issue 16657] [The D Bug Tracker]
https://issues.dlang.org/show_bug.cgi?id=16657 --- Comment #1 from Eyal--- Minor correction: opCmp is not auto-generated anyway and opEquals should just be exhaustive and not lexicographic. --
Re: Best way to get ceil(log2(x)) of a BigInt?
On Wednesday, 2 November 2016 at 15:15:18 UTC, Andrea Fontana wrote: Why don't you perform a binary search over 200 power of 2? Something like: http://paste.ofcode.org/scMD5JbmLMZkrv3bWRmPPT I wonder if a simple binary search on whole array is faster than search for limits as in this example PS: If you need ceil, just use the else branch with <= instead of <. Andrea
Re: RC buffer
On 11/02/2016 07:29 AM, Nick Treleaven wrote: On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei Alexandrescu wrote: In order to make opAssign safe, a language change will be necessary. Technically, it should be possible with runtime checks: https://forum.dlang.org/post/aeeffshzkfjbrejzt...@forum.dlang.org The checking overheads disappear when -noboundschecks is passed. The user has to manually copy the RCSlice when necessary for correct code. It seems opAssign for RCSlice is unsafe, is that right? Consider (with your codebase): @safe void fun(ref RCSlice!int a, ref RCSlice!int b) { a = RCSlice!int(); ... use b ... } @safe void gun(ref RCSlice!int s) { fun(s, s); } Assume the reference count of s is 1 upon entering gun. Then the first thing opAssign does is to call the destructor of the slice, which deallocates memory. Subsequently the other reference (b) is dangling. Andrei
Re: Best way to get ceil(log2(x)) of a BigInt?
On Wednesday, 2 November 2016 at 14:49:08 UTC, pineapple wrote: On Wednesday, 2 November 2016 at 14:24:42 UTC, Andrea Fontana wrote: On Wednesday, 2 November 2016 at 14:05:50 UTC, pineapple wrote: I'm trying to do some math stuff with std.bigint and realized there's no obvious way to calculate the ceil of log2 of a bigint. Help? How big are your bigints? I think they'll generally stay between 0 and 2^200 I came up with this, I guess it'll work? auto clog2(BigInt number) in{ assert(number > 0); }body{ uint log; auto n = number - 1; while(n > 0){ log++; n >>= 1; } return log; } Why don't you perform a binary search over 200 power of 2? Something like: BigInt powers[] = [BigInt(2), BigInt(4), BigInt(8), ...]; And I think you can reduce your search in a smaller interval. Something like: string number = "71459266416693160362545788781600"; BigInt i = number; ulong l = number.length; ulong approxMin = cast(ulong)((l-1)/0.30103); ulong approxMax = cast(ulong)((l)/0.301029); So you can search on powers[approxMin .. approxMax], if i'm right.
Re: Set Operations on Set-like Containers
On 11/02/2016 11:07 AM, Nordlöw wrote: On Wednesday, 2 November 2016 at 13:45:41 UTC, Nordlöw wrote: Typically set- and map-like containers with O(1) key membership checking. A typical use case is intersection of the two sets `x` and `y`. When `x` and `y` both support O(1)-`contains(e)` the preferred algorithm is to interate over all elements in the shorter (smallest .length) of `x` and `y` (called `s`), and return only those elements of type E in `s` than can be looked up in `l` via `l.contains(E)`. Currently we don't have a good framework for associative ranges yet. We should define what the associative operations are, and then we can proceed to see where they'd make sense. -- Andrei
[Issue 16657] New: [The D Bug Tracker]
https://issues.dlang.org/show_bug.cgi?id=16657 Issue ID: 16657 Summary: [The D Bug Tracker] Product: D Version: D2 Hardware: All URL: http://dlang.org/ OS: All Status: NEW Severity: enhancement Priority: P3 Component: dmd Assignee: nob...@puremagic.com Reporter: e...@weka.io When adding an "alias this" to a type, the automatic opEquals and opCmp that compare the object lexicographically are removed and instead only the alias this portion of the type is compared via its opEquals/opCmp. struct A { int x; } struct B { A a, b; } static assert(B(A(1), A(1)) != B(A(1), A(2))); // Works struct C { A a, b; alias a this; } static assert(C(A(1), A(1)) != C(A(1), A(2))); // Fails! Adding alias this should NOT cause a preference for the base type's comparators. --
Re: Is the following code legal?
On Wednesday, 2 November 2016 at 14:21:32 UTC, Shachar Shemesh wrote: The D documentation (https://dlang.org/spec/hash-map.html) leaves this not defined. The foreach statement is defined to not allow it: http://dlang.org/spec/statement.html#ForeachStatement "The aggregate must be loop invariant, meaning that elements to the aggregate cannot be added or removed from it in the NoScopeNonEmptyStatement."
Re: Is the following code legal?
On 11/02/2016 11:17 AM, Adam D. Ruppe wrote: On Wednesday, 2 November 2016 at 14:21:32 UTC, Shachar Shemesh wrote: The D documentation (https://dlang.org/spec/hash-map.html) leaves this not defined. The foreach statement is defined to not allow it: http://dlang.org/spec/statement.html#ForeachStatement "The aggregate must be loop invariant, meaning that elements to the aggregate cannot be added or removed from it in the NoScopeNonEmptyStatement." Yah, we'd do good to relax that to allow removal of the currently iterated element. -- Andrei
Re: Release D 2.072.0
On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: On Wednesday, 2 November 2016 at 12:36:45 UTC, Johan Engelen wrote: LDC built with DMD 2.072.0 gives the following error when run: object.Error@src/rt/minfo.d(356): Cyclic dependency between module ddmd.traits and ddmd.cond ddmd.traits* -> ddmd.attrib -> ddmd.cond* -> ddmd.expression -> ddmd.traits* Pretty much all of LDC's D code is DDMD front-end code, master is at front-end version 2.071.2. I hope someone can try to build DMD 2.071.2 using 2.072.0 and see if a similar issue is found. I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... Maybe after this: https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 ddmd.attribs was removed https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 and it was also part of the cycle.
Re: Set Operations on Set-like Containers
On Wednesday, 2 November 2016 at 13:45:41 UTC, Nordlöw wrote: Typically set- and map-like containers with O(1) key membership checking. A typical use case is intersection of the two sets `x` and `y`. When `x` and `y` both support O(1)-`contains(e)` the preferred algorithm is to interate over all elements in the shorter (smallest .length) of `x` and `y` (called `s`), and return only those elements of type E in `s` than can be looked up in `l` via `l.contains(E)`.
Re: Release D 2.072.0
On Wednesday, 2 November 2016 at 12:36:45 UTC, Johan Engelen wrote: LDC built with DMD 2.072.0 gives the following error when run: object.Error@src/rt/minfo.d(356): Cyclic dependency between module ddmd.traits and ddmd.cond ddmd.traits* -> ddmd.attrib -> ddmd.cond* -> ddmd.expression -> ddmd.traits* Pretty much all of LDC's D code is DDMD front-end code, master is at front-end version 2.071.2. I hope someone can try to build DMD 2.071.2 using 2.072.0 and see if a similar issue is found. I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor...
Re: Is the following code legal?
On 11/02/2016 10:21 AM, Shachar Shemesh wrote: int[int] hash; .. foreach( key, ref value; hash ) { if( value>12 ) hash.remove(key); } Some hash implementations support this, some don't. The D documentation (https://dlang.org/spec/hash-map.html) leaves this not defined. As reference, C++ does define this (in C++ it is allowed, at least since C++14: http://en.cppreference.com/w/cpp/container/unordered_map/erase) Shachar We should render it defined, and document it as such. Could you please create an issue and I'll have someone look at it. Thanks! -- Andrei
Re: Best way to get ceil(log2(x)) of a BigInt?
On Wednesday, 2 November 2016 at 14:24:42 UTC, Andrea Fontana wrote: On Wednesday, 2 November 2016 at 14:05:50 UTC, pineapple wrote: I'm trying to do some math stuff with std.bigint and realized there's no obvious way to calculate the ceil of log2 of a bigint. Help? How big are your bigints? I think they'll generally stay between 0 and 2^200 I came up with this, I guess it'll work? auto clog2(BigInt number) in{ assert(number > 0); }body{ uint log; auto n = number - 1; while(n > 0){ log++; n >>= 1; } return log; }
[Issue 2742] std.stdio assumes console works in utf-8
https://issues.dlang.org/show_bug.cgi?id=2742 Martin Krejcirikchanged: What|Removed |Added CC||m...@krej.cz See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=15761 --
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761 Martin Krejcirikchanged: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=2742 --
Is the following code legal?
int[int] hash; .. foreach( key, ref value; hash ) { if( value>12 ) hash.remove(key); } Some hash implementations support this, some don't. The D documentation (https://dlang.org/spec/hash-map.html) leaves this not defined. As reference, C++ does define this (in C++ it is allowed, at least since C++14: http://en.cppreference.com/w/cpp/container/unordered_map/erase) Shachar
Re: Best way to get ceil(log2(x)) of a BigInt?
On Wednesday, 2 November 2016 at 14:05:50 UTC, pineapple wrote: I'm trying to do some math stuff with std.bigint and realized there's no obvious way to calculate the ceil of log2 of a bigint. Help? How big are your bigints?
[Issue 16655] lambda with type alias parameter fails std.traits.isSomeFunction
https://issues.dlang.org/show_bug.cgi?id=16655 ag0ae...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ag0ae...@gmail.com Resolution|--- |INVALID --- Comment #3 from ag0ae...@gmail.com --- (In reply to Nick Treleaven from comment #0) > The static asserts below fail: > > struct Color {struct Red {}} > > unittest { > import std.traits; > > alias ls = (string) => "string"; > static assert(isSomeFunction!ls); > > with (Color) { > alias lc = (Red) => "red"; > static assert(isSomeFunction!lc); > } > } This is a gotcha, but it's not a bug. In a function literal, a single identifier is interpreted as the name of the parameter, not the type. So `string` and `Red` do not refer to the types of the same names, but they're parameter names. Consequently, ls and lc are not functions, but templates, because the parameters are not typed yet. Closing as invalid. Please reopen if I'm missing something. --
Best way to get ceil(log2(x)) of a BigInt?
I'm trying to do some math stuff with std.bigint and realized there's no obvious way to calculate the ceil of log2 of a bigint. Help?
[Issue 15576] extern(C++, namespace) wrong mangling of variables (Windows)
https://issues.dlang.org/show_bug.cgi?id=15576 --- Comment #2 from Johan Engelen--- Bootcamp hint: start looking at `mangleVariable` in `VisualCPPMangler` in cppmangle.d. --
Re: Linux Kernel in D?
On Tuesday, 1 November 2016 at 16:22:58 UTC, Andrei Alexandrescu wrote: On 11/01/2016 09:41 AM, Wild wrote: On Tuesday, 1 November 2016 at 12:12:29 UTC, Heisenberg wrote: Just an idea. Do you think it would have any advantage compared to the one that is written in C? I think it wouldn't really be worth it. I tend to think the same but for different reasons. Currently the Linux kernel is a large mature product that has its own evolution. It would be very difficult to reimplement it from first principles in any other language and get a competitive, timely product. As an intellectual exercise, D's safety would help but at this point impart little advantage; the kernel has reached good stability and safety bugs are few and far across. This trend is likely for the foreseeable future. Security is a big topic for Linux: https://lwn.net/Articles/662219/ Mostly the problem are drivers. They are produced hastily by careless companies without the scrutiny of the core kernel parts (like scheduler, file system, etc). I think D might help there, because it could enforce @safe or other properties onto the drivers. Nevertheless, I don't see a successful D kernel in the foreseeable future. Building a kernel for IoT devices is trendy, but you want a lot more portability for that and C compilers are everywhere. On the server, you could build a hypervisor OS with D, but currently containers are hyped so much more. You'd only have a chance, if you also port the JVM onto your D-OS. Still, where is the advantage to Linux?
[Issue 15576] extern(C++, namespace) wrong mangling of variables (Windows)
https://issues.dlang.org/show_bug.cgi?id=15576 Johan Engelenchanged: What|Removed |Added Keywords||bootcamp --
Set Operations on Set-like Containers
Does https://dlang.org/phobos/std_algorithm_setops.html support specializations when (some) arguments are containers/ranges that provide the `in` operator? Typically set- and map-like containers with O(1) key membership checking. If not, should they? And what about operator overloading for union (|), intersection (&) and difference (-)?
[Issue 15576] extern(C++, namespace) wrong mangling of variables (Windows)
https://issues.dlang.org/show_bug.cgi?id=15576 Johan Engelenchanged: What|Removed |Added Summary|extern(C++) wrong mangling |extern(C++, namespace) ||wrong mangling of variables ||(Windows) --
[Issue 15576] extern(C++) wrong mangling
https://issues.dlang.org/show_bug.cgi?id=15576 Johan Engelenchanged: What|Removed |Added CC||jbc.enge...@gmail.com --- Comment #1 from Johan Engelen --- I ran into the same problem. Simpler reproducer: D: extern (C++, ep) extern __gshared int variable; C++: namespace ep { int variable; } --
[Issue 15984] [REG2.071] Interface contracts retrieve garbage instead of parameters
https://issues.dlang.org/show_bug.cgi?id=15984 --- Comment #9 from MichaelZ--- If this can't be readily fixed, then what exactly must we do (or rather, not do) in our code to avoid triggering the issue? Must we avoid using pre- (and post?) conditions in an interface at all? Or must we avoid using pre- (and post?) conditions on 'override' functions? Or something else entirely? So far we've had the issue pop up roughly 4 times, some of those after making apparently unrelated changes; cleaning up the problematic places once and for all now that we have the issue in mind, will avoid frustrating bug hunting in the future... --
Re: RC buffer
On 11/2/16 7:42 AM, anonymous wrote: BTW about this PR: why RCString an not more generally RCArray ? RCArray comes on top of RCBuffer. That way we isolate the matter of reference counting the buffer itself from the matter of managing the objects stored in the buffer. It's a simple matter of modularity. (Matters of alignment make this a bit more involved than it might seem, but nothing crazy.) What is important (and probably unprecedented) about this PR is that it's the first reference counted artifact that works with qualifiers without resorting to undefined casts. That's the Big Thing about it. It harkens back to Dicebot idea to stash the reference counter in the allocator. Andrei
[Issue 16656] move embedded zlib to a separate library
https://issues.dlang.org/show_bug.cgi?id=16656 Andrei Alexandrescuchanged: What|Removed |Added CC||and...@erdani.com Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com --
[Issue 16656] New: move embedded zlib to a separate library
https://issues.dlang.org/show_bug.cgi?id=16656 Issue ID: 16656 Summary: move embedded zlib to a separate library Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: c...@dawg.eu We'd like to get rid of the embedded zlib in phobos. https://github.com/dlang/phobos/tree/fd518eb310a9494cccf28c54892542b052c49669/etc/c/zlib As a shared zlib is available on literally any non-Windows OS, we should prefer using that over statically linking. For Windows we can integrate a DLL and import library with out binary releases, similarly to how we handle libcurl. That means someone documents and builds zlib [¹], we upload the results to downloads.dlang.org/other, and integrate it with the build script [²][³]. [¹]: https://wiki.dlang.org/Curl_on_Windows [²]: https://github.com/dlang/installer/blob/8b3c7efe1e049f73ec5fc526a849904bf80b434d/create_dmd_release/build_all.d#L451 [³]: https://github.com/dlang/installer/blob/8b3c7efe1e049f73ec5fc526a849904bf80b434d/create_dmd_release/build_all.d#L232 --
Re: Release D 2.072.0
On Tuesday, 1 November 2016 at 16:40:42 UTC, Andrei Alexandrescu wrote: On 11/01/2016 11:41 AM, Johan Engelen wrote: On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD 2.071.2 for CI testing. :( Is there somebody working on that bug? Thanks. -- Andrei LDC built with DMD 2.072.0 gives the following error when run: object.Error@src/rt/minfo.d(356): Cyclic dependency between module ddmd.traits and ddmd.cond ddmd.traits* -> ddmd.attrib -> ddmd.cond* -> ddmd.expression -> ddmd.traits* Pretty much all of LDC's D code is DDMD front-end code, master is at front-end version 2.071.2. I hope someone can try to build DMD 2.071.2 using 2.072.0 and see if a similar issue is found.
Re: State of issues.dlang.org
On Wednesday, 2 November 2016 at 11:00:58 UTC, Nick Treleaven wrote: One thing I miss is the ability to preview posts on Bugzilla, This was added in Bugzilla 5.0. We're just running 4.4.2 on issues.d.o. Unfortunately, I'm not sure how easy it is to upgrade... -Wyatt
Re: RC buffer
On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei Alexandrescu wrote: I've eliminated all UTF nonsense from https://github.com/dlang/phobos/pull/4878 resulting in a bare reference counted buffer of (qualified) ubyte. Andrei BTW about this PR: why RCString an not more generally RCArray ?
Re: RC buffer
On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei Alexandrescu wrote: In order to make opAssign safe, a language change will be necessary. Technically, it should be possible with runtime checks: https://forum.dlang.org/post/aeeffshzkfjbrejzt...@forum.dlang.org The checking overheads disappear when -noboundschecks is passed. The user has to manually copy the RCSlice when necessary for correct code. The RCSlice in the link is just a basic proof of concept, using RCRef for temporary references. It doesn't handle reallocations - I think to have early diagnostics of potential errors it would need to have a separate RCRef reference count from the main count. That would be used to check there are no RCRef references alive when the main count is one and a reallocation could potentially occur - e.g. when appending. I think with this (hypothetical) RCSlice it's bug-prone to allow the user *not* to make a temporary copy of the RCSlice in this scenario because errors could depend on unknown runtime behaviour, not showing up in testing. I mention this partly because I think this scenario has an impact on the design of a DIP to address when to automatically add reference counting bumps - perhaps a @rcbump attribute is necessary. Otherwise the compiler can't know if an external function taking an RCString performs an append or not.
[Issue 4542] [tdpl] TDPL NVI example results in linker error
https://issues.dlang.org/show_bug.cgi?id=4542 Simon Na.changed: What|Removed |Added Keywords||link-failure CC||eiderd...@gmail.com --- Comment #16 from Simon Na. --- This bug is still in dmd 2.071.2 and 2.072. I ran into this today, here's my reduced case: interface IA { package void f(); } void main() { IA a; a.f(); } Nothing new, but I'd like to nudge for resolution. :-) I dustmited my project due to this bug. The linker error didn't help me. If this is hard to fix, then maybe error out at compile-time as a hack? -- Simon --
Re: Error: function std.stdio.setmode is not accessible from module a
On Wednesday, November 02, 2016 08:58:04 Kirill Kryukov via Digitalmars-d- learn wrote: > Hello, > > dmd 2.072.0 broke my project. I reduced it to following: > > = a.d start = > import std.stdio; > > void main() > { > setmode(stdin.fileno, 0x8000); > } > = a.d end = > > Compiling on Windows 7 64-bit with the following commands: > > C:\utl\dev\D\dmd-2.071.2\windows\bin\dmd.exe a.d -ofa1.exe > C:\utl\dev\D\dmd-2.072.0\windows\bin\dmd.exe a.d -ofa2.exe > > The first one succeeds (producing a working executable), the > second one fails with these messages: > > a.d(6): Deprecation: std.stdio.setmode is not visible from module > a > a.d(6): Error: function std.stdio.setmode is not accessible from > module a > > 2.072.0 changelog does not seem to mention anything relevant. Is > there something obvious I'm missing, or should I file a bug > report? setmode was never publicly documented, and technically, you weren't supposed to be using it from there (since it wasn't documented). It was fixed in 2.072.0 so that all of the undocumented stuff in std.stdio was made private. It was never intended that setmode be part of the public API in std.stdio. But of course, since you were using it in spite of it being undocumented, your code broke. Now, setmode is a C function from Windows, so it should be in druntime where you could easily import it, but unfortunately, it looks like it's currently missing from there. Rather, the bindings for it were just put directly in std.stdio instead of in druntime where they belongs. So, if anything, the bug is that druntime doesn't have it. So, it would make sense to open a bug for that. But if you want to still use it without it being in druntime, you can just declare the bindings yourself, as annoying as that may be. e.g. this is essentially what's in std.stdio: version(DIGITAL_MARS_STDIO) extern(C) int setmode(int, int) nothrow @nogc; else version(MICROSOFT_STDIO) { extern(C) int _setmode(int, int) nothrow @nogc; alias setmode = _setmode; } It really should be put in druntime though. - Jonathan M Davis
Re: Pattern matching in D?
On Friday, 28 October 2016 at 11:53:16 UTC, Nick Treleaven wrote: In the unittest, using with(Color) should help, but I couldn't get that to compile (visit thinks invalid lambdas are being passed). https://issues.dlang.org/show_bug.cgi?id=16655
Re: CTFE Status
On Tuesday, 1 November 2016 at 21:12:06 UTC, Nordlöw wrote: On Tuesday, 1 November 2016 at 19:28:03 UTC, Stefan Koch wrote: Now a phobos unittest miscompiles :( Again passing the unittests does not mean too much. I just means I bail out before I generate invalid code :) Keep up! I am now passing phobos unittests! However please take it with a grain of salt ;) The following line resbonsible for baling out of functions I know are failing. if (fd.ident == Identifier.idPool("isRooted") || fd.ident == Identifier.idPool("__lambda2") || fd.ident == Identifier.idPool("divideRoundUp") || fd.ident == Identifier.idPool("isSameLength") || fd.ident == Identifier.idPool("wrapperParameters") || fd.ident == Identifier.idPool("wrap") || fd.ident == Identifier.idPool("args")) { IGaveUp = true; return ; } I am working on reducing test-cases to figure out why this is failing. The code is burried in templates makeing it hard to see what is going on. Still passing the tests is passing the tests :)
Re: State of issues.dlang.org
On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote: On 10/25/2016 05:17 AM, Jacob wrote: There's no editing one's comments so I often see people making multiple posts to themselves to add more information or to correct themselves. That's just a minor issue. I don't think that's really an issue. Bugzilla sends out notification emails. An edit feature would complicate that. You'd have to read diffs instead of a human-written correction. I think that might be more annoying than having multiple comments. If any kind of discussion happens you're going to have many comments anyway. One thing I miss is the ability to preview posts on Bugzilla, like our forum software. I know there's not much markup that happens for bugzilla posts, but somehow seeing the post rendered helps me to think whether I've forgotten anything or need to make some edits. Not huge but would be nice.
[Issue 16655] lambda with type alias parameter fails std.traits.isSomeFunction
https://issues.dlang.org/show_bug.cgi?id=16655 --- Comment #2 from Nick Treleaven--- BTW parameter names aren't needed because the lambdas are used for Algebraic().visit!Lambdas: http://forum.dlang.org/post/pggfdcttxdpernjbx...@forum.dlang.org --
[Issue 16655] lambda with type alias parameter fails std.traits.isSomeFunction
https://issues.dlang.org/show_bug.cgi?id=16655 --- Comment #1 from Nick Treleaven--- Workaround is to add parameter names: alias ls = (string s) => "string"; alias lc = (Red r) => "red"; --
[Issue 16655] New: lambda with type alias parameter fails std.traits.isSomeFunction
https://issues.dlang.org/show_bug.cgi?id=16655 Issue ID: 16655 Summary: lambda with type alias parameter fails std.traits.isSomeFunction Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: minor Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: n...@geany.org The static asserts below fail: struct Color {struct Red {}} unittest { import std.traits; alias ls = (string) => "string"; static assert(isSomeFunction!ls); with (Color) { alias lc = (Red) => "red"; static assert(isSomeFunction!lc); } } If you define ls, lc like this it works: alias ls = (immutable(char)[]) => "string"; alias lc = (Color.Red) => "red"; --
Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays
On Wednesday, 2 November 2016 at 03:36:42 UTC, Andrei Alexandrescu wrote: Last time I looked our associative arrays were arrays of singly-linked lists. F.Y.I. It now appears to use quadratic probing since druntime PR #1229. Each hashtable would have its own freelist, or alternatively all hashtables of the same types share the same freelist. How do you return memory to the freelist when GC is expected to managed memory of the entries? We no longer GC.free since your PR (#1143.) Without belaboring the point, I think we'd better off with good library AA offerings as well.
Error: function std.stdio.setmode is not accessible from module a
Hello, dmd 2.072.0 broke my project. I reduced it to following: = a.d start = import std.stdio; void main() { setmode(stdin.fileno, 0x8000); } = a.d end = Compiling on Windows 7 64-bit with the following commands: C:\utl\dev\D\dmd-2.071.2\windows\bin\dmd.exe a.d -ofa1.exe C:\utl\dev\D\dmd-2.072.0\windows\bin\dmd.exe a.d -ofa2.exe The first one succeeds (producing a working executable), the second one fails with these messages: a.d(6): Deprecation: std.stdio.setmode is not visible from module a a.d(6): Error: function std.stdio.setmode is not accessible from module a 2.072.0 changelog does not seem to mention anything relevant. Is there something obvious I'm missing, or should I file a bug report? Thanks, Kirill
Re: is there "this"?
On Wednesday, November 02, 2016 02:42:01 Konstantin Kutsevalov via Digitalmars-d-learn wrote: > I tested already and it really works, thank you. > I asked that because I tried once to use "this" in past but I got > error. So I asked on some forum "how to get property of class?" > and peoples said that I may use just a name of property. So I > thought that there isn't "this" word. I don't know why you were having trouble before, but I think that most people never use an explicit this unless they need to, so plenty of folks would have just told you to remove the this from you code, especially if it worked without. - Jonathan M Davis
Re: is there "this"?
On Wednesday, November 02, 2016 07:26:57 Bauss via Digitalmars-d-learn wrote: > Well "this" in D has different meanings as it depends on its > context sometimes. Yes, but it's almost always the same thing that you'd expect from a language like C++ or Java. - Jonathan M Davis
Re: RC buffer
On Wednesday, 2 November 2016 at 05:00:23 UTC, Andrei Alexandrescu wrote: I've eliminated all UTF nonsense from https://github.com/dlang/phobos/pull/4878 resulting in a bare reference counted buffer of (qualified) ubyte. The goal is to get the buffer @safe and be able to have a reasonable explanation for each and every cast. (There are no safety annotations currently, but the code passes unittests and supports qualifiers.) No undefined behavior casts should be used (e.g. that cast away immutability), only simple adjustments for realities that the type system is unable to cover. In order to make opAssign safe, a language change will be necessary. Andrei Great goal, I wish you to do it!
Re: Got a post for the D Blog?
On Monday, 31 October 2016 at 03:51:16 UTC, Mike Parker wrote: So far, getting content for the blog has, with a few exceptions, been a process of sending out emails prompted by activity on my radar. This is no problem when it comes to project highlights or other fairly broad topics, but it's highly inefficient for ginning up technical posts on the implementation of specific algorithms, or optimization details, or how a D feature prevented a nuclear meltdown. I want to publish more posts like Andreas's 'Find Was Too Damn Slow, So We Fixed It` [1] (which, by the way, is the most-viewed post so far, just ahead of Joakim's interview with Walter [2]), or Steven's 'How to Write @trusted Code in D' [3], but I need help. If you, or someone you know, have done something interesting with an algorithm or optimization in D, or have used a D idiom to do things in a way that pleasantly surprised you, please let me know. If I think it's something we can work with, I'll help you in putting together a guest post, or something like I do with the project highlights (where I build a post around whatever info you give me). Also, I need news. If you see or hear any D news anywhere outside of the forums -- new projects, research papers, usage at a company, a game using D -- please drop me a line. I'll either get a post together for it or make sure Adam knows about it for 'This Week in D'. I'm also open to ideas for other types of posts, like project highlights, but I'd really like more of the technical stuff. Please send any suggestions to aldac...@gmail.com. Thanks! [1] http://dlang.org/blog/2016/06/16/find-was-too-damn-slow-so-we-fixed-it/ [2] http://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/ [3] http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/ It's excellent, thanks)
Re: is there "this"?
On Wednesday, 2 November 2016 at 02:42:01 UTC, Konstantin Kutsevalov wrote: On Wednesday, 2 November 2016 at 02:33:10 UTC, Konstantin Kutsevalov wrote: On Wednesday, 2 November 2016 at 02:20:43 UTC, rikki cattermole wrote: On 02/11/2016 3:17 PM, Konstantin Kutsevalov wrote: [...] You forgot an int in the arguments but otherwise that would work fine with your line uncommented. yes I missed "int", but it's just an example. so if I'll write "this.property = value" it will work? I tested already and it really works, thank you. I asked that because I tried once to use "this" in past but I got error. So I asked on some forum "how to get property of class?" and peoples said that I may use just a name of property. So I thought that there isn't "this" word. Well "this" in D has different meanings as it depends on its context sometimes.
Re: Assistance with DUB
On Tuesday, 1 November 2016 at 22:01:23 UTC, Alfred Newman wrote: Greetings, I need some help with dub libraries. Executing "dub list" in my machine, I got the following: Packages present in the system and known to dub: colorize ~master: C:\Users\Alfred\AppData\Roaming\dub\packages\colorize-master\colorize\ ... sqlite-d ~master: C:\Users\Alfred\AppData\Roaming\dub\packages\sqlite-d-master\sqlite-d\ x11 1.0.15: C:\Users\Alfred\AppData\Roaming\dub\packages\x11-1.0.15\x11\ *** Note that sqlite-d is listed there. When I try to run the code in the end of this thread, I got the following error: compiling C:...\Projects\temp2.d C:\Users\Alfred\Dropbox\Dlang\Projects\temp2.d(8,8): Error: module sqlited is in file 'sqlited.d' which cannot be read (***) import path[0] = C:\D\dmd2\src\phobos import path[1] = C:\D\dmd2\src\druntime\import import path[2] = C:\Users\Alfred\AppData\Roaming\dub\packages\colorize-master\colorize\source import path[3] = C:\Users\Alfred\AppData\Roaming\dub\packages\sqlite-d-master\sqlite-d import path[4] = C:\Users\Alfred\AppData\Roaming\dub\packages\d2sqlite3-master\d2sqlite3\source import path[5] = C:\D\dmd2\windows\bin\src\phobos import path[6] = C:\D\dmd2\windows\bin\src\druntime\import error: the process (dmd) has returned the signal 1 C:...\Projects\temp2.d has not been compiled I'm stucked. Please, can you help me out ? To compile a DUB script (It looks like you tried to do that) add this: /+ dub.sdl: name "dub_script" dependency "sqlite-d" version="~>0.1.0" +/ before the module declaration. It acts as a description.