Re: good form? posting semi D-related part-time contract job to announce?
On Monday, 29 February 2016 at 01:05:55 UTC, Laeeth Isharc wrote: Hi. Just to check if it's good form. I'm looking for someone to help (initially) part-time with linux server admin. Happy if scripts are written in D and it's for a project where most code is in D. Is it okay to post to announce? Laeeth. How can one contact you about that offer ?
Re: Hotfix release vibe.d 0.7.28
Am 29.02.2016 um 00:47 schrieb sigod: On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig wrote: This is a small bugfix release that mainly fixes two critical regressions: - FreeListRef!T, which is used heavily in the HTTP server code, stored its reference count in an unallocated memory region, leading to possible memory leaks or memory corruption - A TCP connection with a non-empty write buffer that got closed by the remote peer and locally at the same time could result in the calling task to starve (i.e. it got never resumed after yielding execution). In particular, this could happen when accessing HTTPS servers with the HTTP client in conjunction with "Connection: close". http://vibed.org/blog/posts/vibe-release-0.7.28 You forgot to update site header. Thanks, also forgot the documentation (even if nothing has changed). Is there any plans on when big split will happen? It will be a step-by-step process. I'm currently working on a new version of the `vibe.core` package that contains some large changes under the hood. Once that is in a functional state, I'll look into how to enable optional replacement of the existing vibe:core package by this new, separately hosted vibe-core package. vibe:core, at that point, will only receive bug fixes and continues to live for a while (let's say a year or one and a half). The same procedure will then happen for vibe:http (the new package will include HTTP/2 support) and the other sub packages. All of the new packages will get a version number of 1.0.0, once they can be considered reasonably stable. One unfortunate aspect of my current work on vibe-core is that I'm building on a new event loop abstraction that I built as a prototype to see where the performance bottlenecks of the current system are. libasync was too slow and it had a too complicated structure to make quick tests for improving performance. Now I'm leaning towards finalizing the new prototype library and proposing it for Phobos inclusion at some point.
Re: State of the Compiler
On Monday, 29 February 2016 at 04:53:16 UTC, Jack Stouffer wrote: On Monday, 29 February 2016 at 00:10:33 UTC, Walter Bright wrote: 12. start retrofitting with phobos algorithms Other DMD devs have taken a hard line stance that Phobos code cannot and should not be used in ddmd. What's your opinion on that? Please, explain the situation...
Re: State of the Compiler
On 2016-02-29 05:57, Walter Bright wrote: There are good reasons for that. But there's no reason why std.algorithm.sort, for example, cannot still be used (cut & paste). Unfortunately Phobos has quite a complex dependency graph. Pulling in std.algorithm.sort will most likely pull in half of Phobos. -- /Jacob Carlborg
Re: Why is mangling different for separate compilation?
On 2016-02-28 22:03, Chris Wright wrote: Or like there's a global counter that is incremented for each unittest. A different order of traversal of unittests would result in a different mangled name for the same unittest in different runs. The question is why it would be different. Here's a guess: * The compiler will perform semantic analysis of the code in the current module before processing any imports * It will also process all files on the command line before processing any imports * The compiler will process object.d before processing any other imports That would mean in the case when compiling foo.d during separate compilation it would process object.d before processing bar.d. That would mean the compiler is processing a lot unittest blocks through object.d and its imports before processing the unittest block in bar.d. -- /Jacob Carlborg
Re: A suggestion for dub
On Monday, 29 February 2016 at 05:59:56 UTC, mahdi wrote: On Monday, 29 February 2016 at 05:16:50 UTC, Brad Anderson wrote: On Monday, 29 February 2016 at 04:46:13 UTC, mahdi wrote: [...] A neat feature would be to deploy it using the github releases feature. There is an API for it: https://developer.github.com/v3/repos/releases/ Being able to upload program binaries for end users (non-programmers) to use would be killer. But definitely those binaries won't be cross-platform! That's why I think uploading/downloading source code is more robust. You can upload multiple platform binaries. I'm pretty sure LDC or GDC can do some cross compiling too. It's not reasonable to expect all end users to compile a program.
Re: A suggestion for dub
On Mon, 29 Feb 2016 04:46:13 +, mahdi wrote: > I just want to get some feedback to see if this is a good idea or no. > > I propose adding a new command to dub (`dub dist` or `dub package`) > which will produce a zipped version of the current package. This zip > file can be uploaded to a central repository (code.dlang.com maybe), and > others can use this package in their `dub.json` file by adding relevant > dependency (Behind the scene, dub will fetch and decompress the > package). In other words, you want to distribute your source code, but you don't want to host a publicly accessibly git repository and don't want to use any of the free git hosting services around. I'm not sure how this would be an advantage. You don't have to learn git, I guess? It's less VCS lockin? Though it probably wouldn't be so hard to add mercurial and svn plugins for dub. Something that *would* be useful is a command that produces binaries and, in the case of libraries, D interface files so people can depend on the library even if the full source code isn't available. The obvious problem: D is typically compiled to native code. That means you have to compile once for each platform. Also, you need a different binary for every set of version() flags the thing supports. That makes binary distribution tricky in the general case.
Re: Terminix 0.51.0 Released
On Sunday, 28 February 2016 at 22:33:23 UTC, Mike Wey wrote: Great work. Thanks Mike, coming from you that's a real compliment. I really appreciate all your work on GtkD and the support you've given me in answering questions and dealing with issues.
Re: A suggestion for dub
On Monday, 29 February 2016 at 05:16:50 UTC, Brad Anderson wrote: On Monday, 29 February 2016 at 04:46:13 UTC, mahdi wrote: I just want to get some feedback to see if this is a good idea or no. I propose adding a new command to dub (`dub dist` or `dub package`) which will produce a zipped version of the current package. This zip file can be uploaded to a central repository (code.dlang.com maybe), and others can use this package in their `dub.json` file by adding relevant dependency (Behind the scene, dub will fetch and decompress the package). A neat feature would be to deploy it using the github releases feature. There is an API for it: https://developer.github.com/v3/repos/releases/ Being able to upload program binaries for end users (non-programmers) to use would be killer. But definitely those binaries won't be cross-platform! That's why I think uploading/downloading source code is more robust.
Re: good form? posting semi D-related part-time contract job to announce?
On Monday, 29 February 2016 at 01:52:38 UTC, Walter Bright wrote: On 2/28/2016 5:05 PM, Laeeth Isharc wrote: Hi. Just to check if it's good form. I'm looking for someone to help (initially) part-time with linux server admin. Happy if scripts are written in D and it's for a project where most code is in D. Is it okay to post to announce? Laeeth. For the time being, yes. If such starts getting a lot of traffic, we can create another n.g. for it. Thanks, Walter and Mike.
Re: A suggestion for dub
On Monday, 29 February 2016 at 04:46:13 UTC, mahdi wrote: I just want to get some feedback to see if this is a good idea or no. I propose adding a new command to dub (`dub dist` or `dub package`) which will produce a zipped version of the current package. This zip file can be uploaded to a central repository (code.dlang.com maybe), and others can use this package in their `dub.json` file by adding relevant dependency (Behind the scene, dub will fetch and decompress the package). A neat feature would be to deploy it using the github releases feature. There is an API for it: https://developer.github.com/v3/repos/releases/ Being able to upload program binaries for end users (non-programmers) to use would be killer.
Re: State of the Compiler
On 2/28/2016 8:53 PM, Jack Stouffer wrote: On Monday, 29 February 2016 at 00:10:33 UTC, Walter Bright wrote: 12. start retrofitting with phobos algorithms Other DMD devs have taken a hard line stance that Phobos code cannot and should not be used in ddmd. What's your opinion on that? There are good reasons for that. But there's no reason why std.algorithm.sort, for example, cannot still be used (cut & paste).
Re: A suggestion for dub
On 29/02/16 5:46 PM, mahdi wrote: I just want to get some feedback to see if this is a good idea or no. I propose adding a new command to dub (`dub dist` or `dub package`) which will produce a zipped version of the current package. This zip file can be uploaded to a central repository (code.dlang.com maybe), and others can use this package in their `dub.json` file by adding relevant dependency (Behind the scene, dub will fetch and decompress the package). Most of the work is already done. code.dlang.org already grabs a zip of the contents of the repo from e.g. Github. Dub then just downloads + extracts it. However I don't think its cached on code.dlang.org side. Basically the hard part is writing a new provider and adding the ability to upload via api. Of course the implementation may have changed in the last year or so.
Re: State of the Compiler
On Monday, 29 February 2016 at 00:10:33 UTC, Walter Bright wrote: 12. start retrofitting with phobos algorithms Other DMD devs have taken a hard line stance that Phobos code cannot and should not be used in ddmd. What's your opinion on that?
A suggestion for dub
I just want to get some feedback to see if this is a good idea or no. I propose adding a new command to dub (`dub dist` or `dub package`) which will produce a zipped version of the current package. This zip file can be uploaded to a central repository (code.dlang.com maybe), and others can use this package in their `dub.json` file by adding relevant dependency (Behind the scene, dub will fetch and decompress the package).
Re: State of the Compiler
On Mon, 29 Feb 2016 15:13:28 +1300, Rikki Cattermole wrote: > I have to suggest this, but how much work do you believe it would take > to switch over to sdc's frontend instead? (Keeping in mind it isn't > compiling much right now). Not impossible, just difficult. The first step is to catch SDC up to the latest DMD release. That's for what it compiles, what it errors about, what it warns about, and ddoc, at a minimum. That's for FreeBSD, Linux, OSX, and Windows. After that, we keep SDC up to date with DMD for some amount of time. We announce that we're cutting over and people should migrate their PRs to SDC. In the meantime, the SDC team is just porting changes from DMD to SDC. Refactoring in place means your PR might need changes to apply correctly, but it won't need to be rewritten from scratch. It's far less of an interruption.
Re: State of the Compiler
On 29/02/16 1:10 PM, Walter Bright wrote: I'm pretty unhappy with the state of dmd. I think the best that can be said for it at the moment is that it works. 1. every time we fix something, there are unexpected regressions. 2. the code is a hopeless tangle. 3. too much global state (like global.errors, which is itself a source of repeated regressions) 4. it's slowed down substantially. 5. near complete lack of encapsulation 6. my ideas on how software should be written have evolved a lot since it was laid out This cannot be fixed overnight, but I've been working on it off and on in between doing other more urgent things, and submitting PRs for them. The goals of all this are (and this includes the back end): 1. elimination of all conditional compilation, and macros. All that code should be encapsulated and banished to Port or Target. 2. encapsulation of all memory management. For example, StringExp's instance of string data is allocated and free'd all over the place. I've made some progress in encapsulating it. Getting it properly encapsulated means we can do Small String Optimization in it, which should get us a nice boost. SSO for all these sorts of structures needs to be done. 3. retrofit in const as much as possible, and later try to use pure. 4. get rid of all global state variables, except for configuration stuff set by command line switches 5. convert back end to D. 6. use nested functions to improve encapsulation. 7. remove C++ artifacts, like the fake delegates, and replace them with real delegates 8. replace symbol tables and custom hash code with builtin hashes, and fix the builtin hashes if they aren't as fast 9. change to "full lazy" semantic analysis of imports, i.e. only parse them far enough to build the symbol table. Do semantic analysis of the symbols only on demand. I did this for enums a while back, and the results have been very pleasing. 10. use rc memory for CTFE, or even stack memory. this is already done to a small extent, but should go much further 11. encapsulate, encapsulate, encapsulate 12. start retrofitting with phobos algorithms 13. use ranges One benefit of all this is we could start using multicores to compile! This will all take years, but we've already made good progress such as the conversion of the source code to D. I have to suggest this, but how much work do you believe it would take to switch over to sdc's frontend instead? (Keeping in mind it isn't compiling much right now).
Re: good form? posting semi D-related part-time contract job to announce?
On Monday, 29 February 2016 at 01:05:55 UTC, Laeeth Isharc wrote: Hi. Just to check if it's good form. I'm looking for someone to help (initially) part-time with linux server admin. Happy if scripts are written in D and it's for a project where most code is in D. Is it okay to post to announce? Laeeth. Yes
Re: good form? posting semi D-related part-time contract job to announce?
On 2/28/2016 5:05 PM, Laeeth Isharc wrote: Hi. Just to check if it's good form. I'm looking for someone to help (initially) part-time with linux server admin. Happy if scripts are written in D and it's for a project where most code is in D. Is it okay to post to announce? Laeeth. For the time being, yes. If such starts getting a lot of traffic, we can create another n.g. for it.
good form? posting semi D-related part-time contract job to announce?
Hi. Just to check if it's good form. I'm looking for someone to help (initially) part-time with linux server admin. Happy if scripts are written in D and it's for a project where most code is in D. Is it okay to post to announce? Laeeth.
[Issue 15735] std.algorithm.iteration.splitter returns empty range
https://issues.dlang.org/show_bug.cgi?id=15735 --- Comment #1 from Dragos Carp--- Fixed with https://github.com/D-Programming-Language/phobos/pull/4030 --
State of the Compiler
I'm pretty unhappy with the state of dmd. I think the best that can be said for it at the moment is that it works. 1. every time we fix something, there are unexpected regressions. 2. the code is a hopeless tangle. 3. too much global state (like global.errors, which is itself a source of repeated regressions) 4. it's slowed down substantially. 5. near complete lack of encapsulation 6. my ideas on how software should be written have evolved a lot since it was laid out This cannot be fixed overnight, but I've been working on it off and on in between doing other more urgent things, and submitting PRs for them. The goals of all this are (and this includes the back end): 1. elimination of all conditional compilation, and macros. All that code should be encapsulated and banished to Port or Target. 2. encapsulation of all memory management. For example, StringExp's instance of string data is allocated and free'd all over the place. I've made some progress in encapsulating it. Getting it properly encapsulated means we can do Small String Optimization in it, which should get us a nice boost. SSO for all these sorts of structures needs to be done. 3. retrofit in const as much as possible, and later try to use pure. 4. get rid of all global state variables, except for configuration stuff set by command line switches 5. convert back end to D. 6. use nested functions to improve encapsulation. 7. remove C++ artifacts, like the fake delegates, and replace them with real delegates 8. replace symbol tables and custom hash code with builtin hashes, and fix the builtin hashes if they aren't as fast 9. change to "full lazy" semantic analysis of imports, i.e. only parse them far enough to build the symbol table. Do semantic analysis of the symbols only on demand. I did this for enums a while back, and the results have been very pleasing. 10. use rc memory for CTFE, or even stack memory. this is already done to a small extent, but should go much further 11. encapsulate, encapsulate, encapsulate 12. start retrofitting with phobos algorithms 13. use ranges One benefit of all this is we could start using multicores to compile! This will all take years, but we've already made good progress such as the conversion of the source code to D.
Re: [WIP] Native SQLite Database reader (works at CTFE)
On Sunday, 28 February 2016 at 01:55:50 UTC, Stefan Koch wrote: On Sunday, 28 February 2016 at 01:45:48 UTC, Laeeth Isharc wrote: Great project, Stefan. Any idea what kind of maximum database size will be feasible ? I realise it is early days so far and not your main focus. Laeeth The limits will be almost the same as in sqlite. So a few 100TB nice. and thanks. Laeeth.
Re: Hotfix release vibe.d 0.7.28
On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig wrote: This is a small bugfix release that mainly fixes two critical regressions: - FreeListRef!T, which is used heavily in the HTTP server code, stored its reference count in an unallocated memory region, leading to possible memory leaks or memory corruption - A TCP connection with a non-empty write buffer that got closed by the remote peer and locally at the same time could result in the calling task to starve (i.e. it got never resumed after yielding execution). In particular, this could happen when accessing HTTPS servers with the HTTP client in conjunction with "Connection: close". http://vibed.org/blog/posts/vibe-release-0.7.28 You forgot to update site header. Is there any plans on when big split will happen?
Re: Cannot link using DMD nightly
On Sunday, 28 February 2016 at 22:16:39 UTC, Rene Zwanenburg wrote: On Sunday, 28 February 2016 at 19:02:21 UTC, Matt Elkins wrote: Any suggestions? I don't know how to fix that error, but 2.070.1 has been released and contains a fix for your issue: http://dlang.org/changelog/2.070.1.html ...I don't know how I missed this. Thanks! It works like a champ, including the fix!
Re: Official compiler
On 2/28/2016 1:35 AM, Iain Buclaw via Digitalmars-d wrote: Surely with Fibers everything would be deterministic though? I don't see the point of fibers if: 1. they are running on the same core 2. none of them do any waiting, such as waiting on I/O requests The only I/O a compiler does is reading the source files and writing the object file. At one time, dmd did have an async thread to read the source files, but that was removed as discussed in this thread. To speed up dmd, using multicores is necessary, and that requires synchronization.
[Issue 15735] New: std.algorithm.iteration.splitter returns empty range
https://issues.dlang.org/show_bug.cgi?id=15735 Issue ID: 15735 Summary: std.algorithm.iteration.splitter returns empty range Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: dragosc...@gmail.com The docs say "If the empty range is given, the result is a range with one empty element." --- unittest { import std.algorithm : equal, splitter; assert("".splitter('_').equal([""])); // asserts: returned range is empty } --
Re: Installing DUB on OSX
On Sunday, 28 February 2016 at 11:06:26 UTC, Jacob Carlborg wrote: On 2016-02-28 04:33, Joel wrote: Things just silently not work. Joels-MacBook-Pro:packages joelcnz$ ls -l -a ~/ | grep dub drwxr-xr-x4 joelcnz staff 136 26 Sep 12:47 .dub Joels-MacBook-Pro:packages joelcnz$ That looks correct. If you don't get any error message it's very hard to help. Yes, it does look better. Thanks Jacob.
Re: VisualD/cv2pdb doesn't display AA's properly in the watch window.
On Thursday, 18 February 2016 at 23:01:24 UTC, Rainer Schuetze wrote: On 18.02.2016 01:36, Lewis wrote: Test code (in a newly created project): import std.stdio; int main(string[] argv) { writeln("Hello Blah!"); string[string] testAA = null; testAA["test1"] = "Hello"; testAA["test2"] = "Goodbye"; testAA["blah"] = "string"; testAA["bloop"] = "another string"; testAA["words"] = "test string"; int[] testArray = null; testArray ~= 3; testArray ~= 10; testArray ~= 11; testArray ~= -2; testArray ~= 14; readln(); // Breakpoint on this line return 0; } When I check the watch window, I see the following: http://imgur.com/mxOxitP I'm using DMD 2.069.0. The project is set to use the VS debugger and cv2pdb. I'm using VS2015, with native compatibility and edit and continue enabled: http://imgur.com/6mBDtN4 The debugger displays the dynamic array just fine. It correctly identifies the AA as an aa2, complete with types, and knows its size. It just doesn't display its contents correctly. I've tried reinstalling VisualD with no luck. I've checked the autoexp.dat and the VisualD entries are there as expected. I tried mucking with autoexp.dat a bit to see if I could make it work myself, but to no avail, although that tells me VS is indeed using autoexp.dat as I'd expect. Any ideas what's going on? My suspicion is that something in D's representation of AAs changes slightly, and now the autoexp.dat just needs a tweak, but I don't know nearly enough to know what to fix myself. Thanks in advance! cv2pdb has not been updated to the new AA implementation in dmd 2.068 (http://dlang.org/changelog/2.068.0.html#aa-open-addressing) yet. That's why the type information generated by cv2pdb does not fit and autoexp.dat cannot extract the info. IIRC mago has been updated, so you might want to use this debugger engine instead. Gotcha, thanks for the reply! Just tested with Mago, and it indeed shows AAs as expected. As an aside, I noticed a quirk when viewing AAs with Mago in VS. If I have an AA of strings to structs, I can see all the keys and struct addresses no problem. However, I can't drill down further and inspect the contents of an individual struct. That being said, I can create a second watch of the form 'testAA["key"]', and now I can see the contents of that struct. Just curious if there is a technical or design limitation preventing this, or if it just never got implemented. If it's the latter, may I humbly add this as a feature request for whenever yourself or another developer who knows Mago has time? I'm guessing I'd just add an issue on the github page? Thanks! Lewis
Re: Terminix 0.51.0 Released
On 02/28/2016 12:13 AM, Gerald wrote: Terminix is a tiling Linux terminal emulator I've been working on designed for the Gnome 3 environment and using GtkD. This newest release fixes a number of bugs and adds some new features. I'm announcing it here primarily for D programmers interested in development using GtkD since this might be useful as a real world GtkD program that exercises a significant percentage of the GTK API. Also, if anyone wants to contribute to the effort I'm always looking for help. Terminix can be found here: https://github.com/gnunn1/terminix Great work. -- Mike Wey
Re: Official compiler
On 02/28/2016 11:15 AM, Márcio Martins wrote: There is no reason why it should be limited to these forums, is there? Such a survey should be fairly more "realistic" and "representative" than feelings, emotions and anecdotal evidence. I think it would be interesting and useful to know what is important for: -users just starting to use D -users already heavily invested in the language -users in each distinct usage (gamedev, web, scripts, real-time, ...) -users proficient in alternative languages -companies of different sizes -size of D codebase Putting the horses on the proper end of the cart is to first make sure we make it easy to align the three compiler versions together. Only then, choosing which compiler is more promoted, default etc. becomes a simple matter of branding. Márcio, we are a small enough community that we can't enact things by fiat. We've tried before, invariably with bad results. Of course you are free to speculate that this time may be different, but it's just that - speculation. Andrei
Re: Cannot link using DMD nightly
On Sunday, 28 February 2016 at 19:02:21 UTC, Matt Elkins wrote: Any suggestions? I don't know how to fix that error, but 2.070.1 has been released and contains a fix for your issue: http://dlang.org/changelog/2.070.1.html
Re: scone 0.1.0 super-alpha
On Sunday, 28 February 2016 at 20:49:19 UTC, asdf wrote: [...] The 7-Day Roguelike Challenge is coming up. http://7drl.org/2016/01/13/7drl-2016-announced-for-5-13-march/ Maybe someone could use this. As of now it would only work for Windows. However, thanks for notifying me!
[Issue 15734] New: Need this for map
https://issues.dlang.org/show_bug.cgi?id=15734 Issue ID: 15734 Summary: Need this for map Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: temta...@gmail.com import std.algorithm; class S { int foo(int a) { return a; } void test() { [ 1, 2, 3 ].map!foo; } } Error: this for foo needs to be type S not type MapResult!(foo, int[]) changing foo to (a => foo(a)) makes it compileable --
Re: Why is mangling different for separate compilation?
On Sun, 28 Feb 2016 20:23:59 +0100, Jacob Carlborg wrote: > On 2016-02-27 04:51, Walter Bright wrote: > >> It uses a sequence number to generate different ids for the unit tests. >> In the former, it's the 531st unit test, the latter, the first. > > It sounds like the compiler is seeing different unit tests during the > different compilation. But why is that the case. Or like there's a global counter that is incremented for each unittest. A different order of traversal of unittests would result in a different mangled name for the same unittest in different runs.
Re: scone 0.1.0 super-alpha
On Sunday, 28 February 2016 at 17:50:38 UTC, Vladimirs Nordholm wrote: Scone (Simple CONsole Engine) is a small library to make it easier for developers to make CLI applications efficiently (intentionally/originally for console games), cross-platform. (Please note that it is not fully cross-platform yet, currently only working properly on Windows). Features: * Efficient writing to the console/terminal * Keyboard input (currently only Windows) Yoyo, vladde The 7-Day Roguelike Challenge is coming up. http://7drl.org/2016/01/13/7drl-2016-announced-for-5-13-march/ Maybe someone could use this.
Re: nanomsg for Deimos collection
On Saturday, 27 February 2016 at 15:48:53 UTC, Ilya Yaroshenko wrote: Hi all, D interface to nanomsg library http://nanomsg.org/ was released. This bindings follows Deimos style. 90% of tests was ported to D. github: https://github.com/9il/nanomsg dub: http://code.dlang.org/packages/nanomsg BTW, what should I do to include it to Deimos collection? https://github.com/D-Programming-Deimos See also https://github.com/Laeeth/d-nanomsg Best regards, Ilya Nice work, Ilya. I mentioned on the nanomsg gitter channel, but you might want to mention on the mailing list too (nanomsg.org then community), so it gets added to the list of bindings on the main page.
Re: Why is mangling different for separate compilation?
On 2016-02-27 04:51, Walter Bright wrote: It uses a sequence number to generate different ids for the unit tests. In the former, it's the 531st unit test, the latter, the first. It sounds like the compiler is seeing different unit tests during the different compilation. But why is that the case. -- /Jacob Carlborg
Re: nanomsg for Deimos collection
On Sunday, 28 February 2016 at 19:21:04 UTC, Jacob Carlborg wrote: On 2016-02-27 16:48, Ilya Yaroshenko wrote: BTW, what should I do to include it to Deimos collection? https://github.com/D-Programming-Deimos I don't see a point in doing that. Just make sure it's put in the correct category at code.dlang.org. 0mq already in Deimos collection --Ilya
Re: nanomsg for Deimos collection
On 2016-02-27 16:48, Ilya Yaroshenko wrote: BTW, what should I do to include it to Deimos collection? https://github.com/D-Programming-Deimos I don't see a point in doing that. Just make sure it's put in the correct category at code.dlang.org. -- /Jacob Carlborg
[Issue 14327] Unhandled exception from writeln() in C++/D application
https://issues.dlang.org/show_bug.cgi?id=14327 --- Comment #18 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/de2788d911129545531e0e42d1c8630b3f406e7c Merge pull request #1412 from rainers/issue_14327 https://github.com/D-Programming-Language/druntime/commit/82715d0589d815a77c7139a59193899866a35f02 fixed Issue 14327 - Unhandled exception from writeln() --
[Issue 15430] [REG2.069] amdMmx hangs up
https://issues.dlang.org/show_bug.cgi?id=15430 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/97d3999a4f3ab3c8409060bc6bb381fcc2a43c54 fix Issue 15430 - amdMmx hangs up https://github.com/D-Programming-Language/druntime/commit/d0e4dc96a265ae562e98ad81d0a7d56b752b48ef Merge pull request #1463 from MartinNowak/fix15430 --
[Issue 15334] [REG 2.069] OS X core.time ticksPerSecond calculation is incorrect
https://issues.dlang.org/show_bug.cgi?id=15334 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/fdad9f502dc3a5cac0bac0cfa7d55fc4b7c273b5 Merge pull request #1432 from smolt/ticksPerSecOSXFixStable --
Cannot link using DMD nightly
I'm attempting to use the DMD nightly build (because this fix matters a lot to my project: https://issues.dlang.org/show_bug.cgi?id=15661), but the build fails at the link step. Here is my full output: [output] "C:\Program Files (x86)\dub\dub.exe" run --force --build debug --build-mode separate Performing "debug" build using dmd for x86. cake ~master: building configuration "library"... derelict-util 2.0.4: building configuration "library"... derelict-ft 1.0.2: building configuration "library"... derelict-gl3 1.0.18: building configuration "library"... derelict-glfw3 1.1.1: building configuration "library"... gl3n 1.3.1: building configuration "library"... cakegl ~master: building configuration "library"... common ~master: building configuration "library"... client ~master: building configuration "application"... Linking... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html ..\cakegl\out\cakegl.lib(utf) Error 163: Cannot CVPACK Type 0002 --- errorlevel 1 dmd failed with exit code 1. [/output] "cakegl" is one of my libraries used by the application. I have manually removed every trace of any object file or library I could find which was compiled with my previous install of DMD (including the third-party ones pulled by dub, such as derelict), and am also building with the --force flag; I should note that I am using dub for my builds rather than dmd directly. If I swap back in the released version of DMD it all builds fine. This is on 64-bit Windows 7, using the 32-bit DMD nightly build downloaded today, Feb 28th. Any suggestions?
Re: Clojure vs. D in creating immutable lists that are almost the same.
On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote: Clojure supports immutable lists that allow adding and removing elements, and yet still have excellent performance. For D language, what are the recommended techniques to use functional programming, without massive copying of data and garbage collection, so that it remains immutable. That is, how to create one-off changes to an immutable data structure, while keeping the original immutable, as well as the one-off change, and maintain good performance. Thank you As a user of Clojure i can tell that "excellent" is an overstatement. Still persistent data structures are much better than naive copy (unless you really, REALLY need all data in cache) and copy on write (unless you only very rarely modify an object). That said, I've seen nobody programming with all-immutable objects in D. People mostly use immutable objects only for objects never modified, and use const as an immutable view of a modifiable object. No clojure-style applying method calls with reduce. With some metaprogramming you could probably write update-in function which would work with nested class objects. With that and having your classes return new object instead of modifying existing one you could have a somewhat clojurish experience. For cool stuff like records clojure uses persistent maps, which would be much less convenient to use because of static typing. I know no implementation of persistent data structures (hell, phobos lacks even some regular data structures). I'm implementing transducers for D though, which could be useful if someone implemented the datastructures.
scone 0.1.0 super-alpha
Once upon a time, in a repository long deleted, there was a project called "clayers" which was a programmers summer project, in which to create an easy way to make games that relied on the console. The repo start of nicely, but after more and more developing the project started to get messier and messier, while still being unfinished and containing many bugs. The author (me) decided that he would start a new project, which he named "scone" https://github.com/vladdeSV/scone --- Scone (Simple CONsole Engine) is a small library to make it easier for developers to make CLI applications efficiently (intentionally/originally for console games), cross-platform. (Please note that it is not fully cross-platform yet, currently only working properly on Windows). Features: * Efficient writing to the console/terminal * Keyboard input (currently only Windows) For anyone on a Windows machine, you can test a few examples that gives the basic idea of what scone can do here: https://github.com/vladdeSV/scone/tree/master/examples However, I have one big problem which I cannot overcome, namely keyboard input on POSIX. I would very much ask for help in this area. Judging from Adam's terminal.d, input on POSIX seems to be this huge beast which I cannot slay myself. Feedback and/or help very much appreciated! Yoyo, vladde
Re: Clojure vs. D in creating immutable lists that are almost the same.
On Sat, 27 Feb 2016 22:31:28 +, Brother Bill wrote: > Clojure supports immutable lists that allow adding and removing > elements, and yet still have excellent performance. > > For D language, what are the recommended techniques to use functional > programming, without massive copying of data and garbage collection, so > that it remains immutable. > > That is, how to create one-off changes to an immutable data structure, > while keeping the original immutable, as well as the one-off change, and > maintain good performance. > > Thank you It's pretty straightforward for arrays: immutable(T[]) array = ...; auto inserted = chain(array[0..5], [new T], array[5..$]); auto dropped = chain(array[0..5], array[6..$]); auto appended = chain(array, [new T, new T]); After K mutations, you have a tree of chain!(...).Result structs; this tree is of height K and contains O(2**K) Result structs (if you're removing or inserting items in the middle of the array). That's not too bad if you're rarely mutating the array. Maybe choose a period; after that many mutations, you copy the data into a new collection. But there's a bigger problem. In the above example, there are four variables, and each has a different type. That's fine if you're declaring new variables. If you are dealing with aggregate fields, it's trouble.
Re: Official compiler
On Sunday, 28 February 2016 at 15:02:24 UTC, Mike Parker wrote: On Sunday, 28 February 2016 at 13:31:17 UTC, Márcio Martins wrote: Could we maybe create a quick informative survey, (surveymonkey?), so we can get a glimpse of why people like D and what they believe would improve their experience with the language? Perhaps also why they have chosen to or not to adopt D more seriously or professionally? Given that there is such a wide diversity of people currently using it, I think it would be nice for the project leadership and all of us in the community to get a more realistic view on this matter, to better understand what's important, chose the future direction and what are the real selling points. Right now it seems like there are a lot of mixed signals even among long-time users and contributors. Such a survey wouldn't be anywhere near "realistic." The number and types of users who regularly keep up with the forums are highly unlikely to be a representative sample of D users. There is no reason why it should be limited to these forums, is there? Such a survey should be fairly more "realistic" and "representative" than feelings, emotions and anecdotal evidence. I think it would be interesting and useful to know what is important for: -users just starting to use D -users already heavily invested in the language -users in each distinct usage (gamedev, web, scripts, real-time, ...) -users proficient in alternative languages -companies of different sizes -size of D codebase
Re: Official compiler
On Sunday, 28 February 2016 at 12:59:01 UTC, Dibyendu Majumdar wrote: Should LLVM move to an Apache License would that help in migrating to an LLVM backend as the standard backend? Regards Dibyendu LLVM is great but you wouldn't want to be locked down to only one backend, probably. LLVM does have good support for a variety of architectures though... A bytecode code generator might be good for bootstrapping (after the nuclear apocalypse) but everyone just cross-compiles.
Re: Normal distribution
On Saturday, 20 February 2016 at 14:01:22 UTC, Andrei Alexandrescu wrote: Do we have a good quality converter of uniform numbers to Gaussian-distributed numbers around? -- Andrei Forth Engineering Practice™ is to add a few uniform distributions together... http://www.colorforth.com/e-x2.htm Accurate to 2 decimal places!
Re: Terminix 0.51.0 Released
On Saturday, 27 February 2016 at 23:13:47 UTC, Gerald wrote: Terminix is a tiling Linux terminal emulator I've been working on designed for the Gnome 3 environment and using GtkD. This newest release fixes a number of bugs and adds some new features. I'm announcing it here primarily for D programmers interested in development using GtkD since this might be useful as a real world GtkD program that exercises a significant percentage of the GTK API. Also, if anyone wants to contribute to the effort I'm always looking for help. Terminix can be found here: https://github.com/gnunn1/terminix Sweet! Hope you will announce it in the elementary, Ubuntu and Linux G+ community, right?
Re: Release D 2.070.1
On Saturday, 27 February 2016 at 20:07:04 UTC, Martin Nowak wrote: Glad to announce D 2.070.1. http://dlang.org/download.html This point release fixes a few issues over 2.070.1, see the changelog for more details. http://dlang.org/changelog/2.070.1.html -Martin Thanks!
Re: nanomsg for Deimos collection
On 02/27/2016 04:48 PM, Ilya Yaroshenko wrote: > Hi all, > > D interface to nanomsg library http://nanomsg.org/ was released. This > bindings follows Deimos style. 90% of tests was ported to D. > > github: https://github.com/9il/nanomsg > dub: http://code.dlang.org/packages/nanomsg > > BTW, what should I do to include it to Deimos collection? > https://github.com/D-Programming-Deimos Send a mail to Walter and ask him to create a repo. You could also transfer your existing repo. This would leave you w/ full commit access, reducing friction when fixing sth. or tagging a new release.
Re: Official compiler
On Sunday, 28 February 2016 at 15:02:24 UTC, Mike Parker wrote: Such a survey wouldn't be anywhere near "realistic." The number and types of users who regularly keep up with the forums are highly unlikely to be a representative sample of D users. Not to mention that only a fraction of people who view the forums would actually take the survey.
Re: Official compiler
On Sunday, 28 February 2016 at 13:31:17 UTC, Márcio Martins wrote: Could we maybe create a quick informative survey, (surveymonkey?), so we can get a glimpse of why people like D and what they believe would improve their experience with the language? Perhaps also why they have chosen to or not to adopt D more seriously or professionally? Given that there is such a wide diversity of people currently using it, I think it would be nice for the project leadership and all of us in the community to get a more realistic view on this matter, to better understand what's important, chose the future direction and what are the real selling points. Right now it seems like there are a lot of mixed signals even among long-time users and contributors. Such a survey wouldn't be anywhere near "realistic." The number and types of users who regularly keep up with the forums are highly unlikely to be a representative sample of D users.
Re: ErrnoException
On Sunday, 28 February 2016 at 13:10:20 UTC, Jirka wrote: I have a question about ErrnoException. When I throw it (throw new ErrnoException()), won't it overwrite the errno value before it can capture it? Its constructor [1] simply fetches the current errno and gets an error message from it. [1] https://github.com/D-Programming-Language/phobos/blob/master/std/exception.d#L1491
Re: Normal distribution
On Friday, 26 February 2016 at 20:15:10 UTC, Andrei Alexandrescu wrote: On 2/26/16 2:32 PM, Joseph Rushton Wakeling wrote: Yup. The basic problem of getting this stuff into phobos are the architectural problems discussed in that talk. Unlike uniform distribution (which is straightforward to implement as a function, no questions asked), the normal distribution is best implemented as a range which keeps some state. So the reference-type/non-reference-type issues start becoming a factor. Would it work to define Gaussian generators as regular generators (same as the existing ones), which keep the uniform engine as a member? -- Andrei This C implementation of the Marsaglia/Tsang Ziggurat method keeps no state except for that of the uniform rng and 3 small static lookup tables that can be initialized in the module's shared constructor: http://people.sc.fsu.edu/~jburkardt/cpp_src/ziggurat_inline/ziggurat_inline.cpp I wrote a D implementation of that with the uniform rngs factored out, leaving it at ~50 loc - not up to Phobos' standards for sure - but I suppose but it could be a starting point. If someone is interested in that let me know.
Re: Official compiler
On Thursday, 25 February 2016 at 01:53:51 UTC, Walter Bright wrote: On 2/17/2016 4:35 PM, Chris Wright wrote: And since DMD is something like twice as fast as LDC, there's at least some argument in favor of keeping it around. When I meet someone new who says they settled on D in their company for development, I casually ask why they selected D? "Because it compiles so fast." It's not a minor issue. Could we maybe create a quick informative survey, (surveymonkey?), so we can get a glimpse of why people like D and what they believe would improve their experience with the language? Perhaps also why they have chosen to or not to adopt D more seriously or professionally? Given that there is such a wide diversity of people currently using it, I think it would be nice for the project leadership and all of us in the community to get a more realistic view on this matter, to better understand what's important, chose the future direction and what are the real selling points. Right now it seems like there are a lot of mixed signals even among long-time users and contributors.
ErrnoException
I have a question about ErrnoException. When I throw it (throw new ErrnoException()), won't it overwrite the errno value before it can capture it?
Re: Why is mangling different for separate compilation?
On Sunday, 28 February 2016 at 12:59:53 UTC, Atila Neves wrote: On Saturday, 27 February 2016 at 11:31:53 UTC, Joakim wrote: On Saturday, 27 February 2016 at 11:27:39 UTC, Walter Bright wrote: On 2/27/2016 1:12 AM, Atila Neves wrote: I've had similar problems in the past with template mixins. It seems D's compile-time features don't mix with any kind of separate compilation, which is a shame. Any ideas on how unit tests should be named? Why has the additional count been added? You're already using the line number to differentiate unit test blocks. For unit test blocks that are all on one line? ;) I guess that makes sense. And it'd link! Atila You could always add an additional number to uniquely identify them if there are multiple unittests on one line. It would seem weird to have a special case in the grammar for unittests.
Re: Why is mangling different for separate compilation?
On Saturday, 27 February 2016 at 11:31:53 UTC, Joakim wrote: On Saturday, 27 February 2016 at 11:27:39 UTC, Walter Bright wrote: On 2/27/2016 1:12 AM, Atila Neves wrote: I've had similar problems in the past with template mixins. It seems D's compile-time features don't mix with any kind of separate compilation, which is a shame. Any ideas on how unit tests should be named? Why has the additional count been added? You're already using the line number to differentiate unit test blocks. For unit test blocks that are all on one line? ;) I guess that makes sense. And it'd link! Atila
Re: Official compiler
On Friday, 26 February 2016 at 22:20:09 UTC, Walter Bright wrote: I am referring to this thread: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html Thanks for the pointer. If anyone wants to chip in on that thread, feel free! Hi Walter, Should LLVM move to an Apache License would that help in migrating to an LLVM backend as the standard backend? Regards Dibyendu
[Issue 15590] 0 coverage should be ignored in __ctfe branches
https://issues.dlang.org/show_bug.cgi?id=15590 b2.t...@gmx.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --
[Issue 15590] 0 coverage should be ignored in __ctfe branches
https://issues.dlang.org/show_bug.cgi?id=15590 b2.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID Summary|the coverage fails in |0 coverage should be |__ctfe branches |ignored in __ctfe branches --- Comment #1 from b2.t...@gmx.com --- Since coverage is generated by the target application, it cannot know if the compiler has run it. --
Re: SQLite-D alpha is here
On Saturday, 27 February 2016 at 16:08:21 UTC, Stefan Koch wrote: Hello, I am happy to announce the official alpha version of sqlite-d! sqlite-d is a reader for the SQLite File Format 3. In the future I will implement a SQL-like API on top of it. Top-notch performance is one of the explicit goals of this project! please note that currently only the ctfe branch is populated. I welcome contributions! Repo-URL : https://github.com/UplinkCoder/sqlite-d Update I just found another case that cannot be handled properly. It just happens with insanely huge databases. Also I commited my test-data now... I wonder why nobody said anything about the app failing on startup ...
Re: Is DUB the best place to get examples of "Best of" D code?
On Sunday, 28 February 2016 at 05:59:39 UTC, WhatMeWorry wrote: If so, is there a way to do a global search of all projects in DUB? If you just want to search through package names and descriptions you can use the search box at the top right of code.dlang.org. If you want to search through code. Most packages are on github, so you could search there (limit by D projects).
Re: Installing DUB on OSX
On 2016-02-28 04:33, Joel wrote: Things just silently not work. Joels-MacBook-Pro:packages joelcnz$ ls -l -a ~/ | grep dub drwxr-xr-x4 joelcnz staff 136 26 Sep 12:47 .dub Joels-MacBook-Pro:packages joelcnz$ That looks correct. If you don't get any error message it's very hard to help. -- /Jacob Carlborg
[Issue 15730] invalid template merging in tuple foreach
https://issues.dlang.org/show_bug.cgi?id=15730 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --
Re: Clojure vs. D in creating immutable lists that are almost the same.
On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote: That is, how to create one-off changes to an immutable data structure, while keeping the original immutable, as well as the one-off change, and maintain good performance. Clojure uses bit-partitioned hash tries. I recommend this video (Clojure Concurrency) https://www.youtube.com/watch?v=dGVqrGmwOAw slides here: https://github.com/dimhold/clojure-concurrency-rich-hickey/blob/master/ClojureConcurrencyTalk.pdf?raw=true (slide 21 about bit-partitioned hash tries)
Re: Hotfix release vibe.d 0.7.28
Am 28.02.2016 um 02:51 schrieb Sebastiaan Koppe: On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig wrote: This is a small bugfix release that mainly fixes two critical regessions Great. Thanks for the quick release! Thanks for taking the time to do an in-depth analysis!
[Issue 15596] strip with delimiter?
https://issues.dlang.org/show_bug.cgi?id=15596 --- Comment #6 from ag0ae...@gmail.com --- (In reply to ag0aep6g from comment #5) > (In reply to b2.temp from comment #4) > > Maybe a note in the std.string doc: "see also: for more generic strip > > funcyion..." > > Already there: "There is a rich set of functions for string handling defined > in other modules. Functions related to Unicode and ASCII are found in > std.uni and std.ascii, respectively. Other functions that have a wider > generality than just strings can be found in std.algorithm and std.range." Whoops, you were talking about strip's docs specifically. Sorry for the noise. --
[Issue 15596] strip with delimiter?
https://issues.dlang.org/show_bug.cgi?id=15596 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #5 from ag0ae...@gmail.com --- (In reply to b2.temp from comment #4) > Maybe a note in the std.string doc: "see also: for more generic strip > funcyion..." Already there: "There is a rich set of functions for string handling defined in other modules. Functions related to Unicode and ASCII are found in std.uni and std.ascii, respectively. Other functions that have a wider generality than just strings can be found in std.algorithm and std.range." --
Re: Clojure vs. D in creating immutable lists that are almost the same.
On Saturday, 27 February 2016 at 23:19:51 UTC, w0rp wrote: On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote: Clojure supports immutable lists that allow adding and removing elements, and yet still have excellent performance. For D language, what are the recommended techniques to use functional programming, without massive copying of data and garbage collection, so that it remains immutable. That is, how to create one-off changes to an immutable data structure, while keeping the original immutable, as well as the one-off change, and maintain good performance. Thank you I think this is a property of linked lists which could possibly be advantageous. However, I would keep in mind that memory layout is very important when it comes to execution speed, and that slices of memory are unbeatable in that regard. That's worth stating first. I think for linked lists, you can always create a new node which points to another node. So you start with element a as immutable, then you take a head element b and point to a, so you get b : a, then c : b : a, etc. So you can create larger and large immutable linked lists because you never actually change a list, you just produce a new list with an element pointing the head of a previous list. I'm not sure if Phobos has something suitable for this, but you could always implement your own singly linked list in such a manner pretty easily. I would be tempted just to use slices instead, though. Linked lists are rarely better. Often people use a lot more advanced structures than linked lists for immutable data structures. http://www.infoq.com/presentations/Functional-Data-Structures-in-Scala
Re: Official compiler
On 27 February 2016 at 23:30, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On 2/27/2016 12:05 PM, Timon Gehr wrote: > >> On 26.02.2016 23:41, Walter Bright wrote: >> >>> On 2/26/2016 1:10 PM, Timon Gehr wrote: >>> Different passes are not really required once semantic analysis becomes asynchronous. Just keep track of semantic analysis dependencies, with strong and weak dependencies and different means to resolve cycles of weak dependencies. Then write the semantic analysis of each component in a linear fashion and pause it whenever it depends on information that has not yet been obtained, until that information is computed. >>> >>> I'll put you in charge of debugging that :-) >>> >> >> I am/was (I have not worked on it a lot lately). I haven't found it to be >> particularly hard to debug. >> > > It'll get 100 times harder if it's a heisenbug due to synchronization > issues. > > Surely with Fibers everything would be deterministic though?