perpetual: new module for mapping value types into memory #3625
Conversation
erge branch 'master' of https://github.com/D-Programming-Language/phobos
|
Why |
| @@ -0,0 +1,192 @@ | |||
| module std.perpetual; | |||
There was a problem hiding this comment.
Modules need to have proper ddoc header.
There was a problem hiding this comment.
module std.experimental.perpetual;
And please remove the extra perpetual folder - it's a module not a package.
|
Also, please conform to the Phobos style guide: http://dlang.org/dstyle.html (note especially the last section on Additional Requirements for Phobos). |
|
Since this PR is proposing to add a new Phobos module, I think it should at least be discussed on the forum and go through the Phobos review process. |
|
@quickfur Certainly, I still need to fix some urgent issues, plus, a little more detailed documentation would be useful |
|
Another thing to note - get rid of merge commits and use git rebase to squash minor edits and things like moving files around. |
|
Why are there two PRs for the same thing? #3562 |
|
|
||
|
|
||
|
|
||
| private import std.exception; |
There was a problem hiding this comment.
Please put all imports at the top of the file.
|
Also, please change all of your tab indentation to four spaces. |
|
Will do, thanks. I love this, will use: static assert(!is(typeof(..expr..)));On Sat, 9/19/15, Jack Stouffer notifications@github.com wrote: |
| core | ||
| Makefile | ||
| perpetual.html | ||
|
|
There was a problem hiding this comment.
Is this file needed once it would be in Phobos? All the other modules are fine without this.
There was a problem hiding this comment.
No, of course not.
|
I would suggest this be closed until this module is ready for prime time. Right now all it is doing is using autotester time needlessly. |
|
It is actually ready, I don't see what else I can do with it. |
| // scalar value or static array | ||
| else | ||
| { | ||
| alias Element=T; |
@sdegtiarev can you please make the NG annoucement then? |
|
Sorry, I don't have time right now. |
I wouldn't mind handling the review - so move this forward and start the discussion ;-) |
|
I think this is a prime candidate for Dub. There is a gazillion ways of interfacing memory-mapped I/O, and this is just one of them. |
|
I started discussion thread. Hopefully, it will push things forward.On Tue, 5/10/16, Sebastian Wilzbach notifications@github.com wrote: |
@klickverbot i will stay neutral as review manager - my point is that such pending PRs don't help anyone. Either dub or Phobos, but not pending ;-) |
|
What happens with pointers in the embedded objects when the file is restored from file or used by multiple processes? |
No, pointers are not of course allowed in stored data, this is general limitation for such code. You have to use serialization if you need such functionality.On Wed, 5/11/16, Marco Leise notifications@github.com wrote: What happens with pointers in the |
Believe it or not, I can't build dfmt... One of my machines has 2Gb ram (+swap) and dmd reports insufficient memory, another one has 8Gb ram but version dmd-2.67 and reports compilation error: template 'AliasSeq' is not defined. Incredible.On Wed, 5/11/16, Sebastian Wilzbach notifications@github.com wrote: Subject: Re: [dlang/phobos] perpetual: new module for mapping value types into memory (#3625)
@klickverbot i will — |
Have you tried with a recent dmd version like 2.070 or 2.071? |
|
@wilzbach: You are right, pending PRs don't help anybody. I'm thus closing it for now. As stated above, it strikes me as fundamentally too narrow in scope, and its quality of implementation isn't particularly high. The API would be of the smallest in Phobos, yet the documentation is inexcusably lacking (if the module had been properly added to the build system, this would be obvious; see e.g. the single 100+ lines documented unit test). The conclusion of the various standard library discussions at DConf was that we want things in the standard library that are either pivotal to the implementation of a consistent set of other functionality (containers, Big-O, etc.), or exploit D's potential for the task in question to its fullest (e.g. std.regex). This module matches neither of the criteria. Of course, you are still free to decide and push this through the review process. In that case, however, please make sure to follow the format of the previous iterations. There isn't a lot of formal criteria, but the review manager should be the one to announce the begin of the review on both newsgroups, together with a summary of the module, links to source code and documentation, the end of the review period, particular points of interest/discussion, etc. Hopefully there is more on this somewhere the wiki, but the basic idea is to act as a mediator and manager to make it easy for community members to start evaluating the library. @sdegtiarev: Please don't become discouraged by this. I've had a look at your other code here on GitHub, and you unquestionably have some interesting ideas. For a language standard library, however, the barrier of entry is quite a bit higher than "could be useful for somebody". We've previously accepted code that we shouldn't have, and are still busy sorting out the consequences. At DConf, we also discussed that we want to introduce a process by which we can highlight solid libraries to stand out from the anonymous crowd, as it were. The details are still being worked out, but maybe this module could be one of the first examples. |
dmd 2.07 is as memory greedy as as older version. Will try to install and build on more powerful machine tomorrow.On Sun, 5/15/16, Sebastian Wilzbach notifications@github.com wrote: Have you tried with a recent dmd version like 2.070 or |
I rewrote std.perpetual module to be based on top of std.mmfile.
It becomes clear that high-level data handling should be separate from low-level shared memory allocation. In addition to architectural advantages, this also clearly answers the question: what new the perpetual module added to existing functionality.