Re: Beta 2.084.0
On Monday, 17 December 2018 at 21:38:07 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.084.0 release, ♥ to the 51 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.084.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thanks for another great release. I found a small issue: .\src\druntime\import\core\runtime.d(250,20): Error: undefined identifier `rt_loadLibraryW`, did you mean function `rt_loadLibrary`? Kind regards André
Re: Announcing Elembuf
On Tue, Dec 18, 2018 at 01:13:32AM +, Cyroxin via Digitalmars-d-announce wrote: [...] > I would assume that there is much value in having a mapping that can > be reused instead of having to remap files to the memory when a need > arises to change source. While I cannot comment on the general > efficiency between a mapped file and a circular buffer without > benchmarks, this may be of use: > https://en.wikipedia.org/wiki/Memory-mapped_file#Drawbacks You have a good point that unmapping and remapping would be necessary for large files in a 32-bit arch. > An interesting fact I found out was that std.mmfile keeps a reference > of the memory file handle, instead of relying on the system's handle > closure after unmap. There seems to be quite a lot of globals, which > is odd as Elembuf only has one. I'm not sure I understand what you mean by "globals"; AFAICT MmFile just has a bunch of member variables, most of which are only important on the initial mapping and later unmapping. Once you get a T[] out of MmFile, there's little reason to use the MmFile object directly anymore until you're done with the mapping. > In std.mmfile OpSlice returns a void[] instead of a T[], making it > difficult to work with as it requires a cast, there would also be a > need to do costly conversions should "T.sizeof != void.sizeof" be > true. Are you sure? Casting void[] to T[] only needs to be done once, and the only cost is recomputing .length. (Casting an array does *not* make a copy of the elements or anything of that sort, btw.) Once you have a T[], it's pointless to call Mmfile.opSlice again; just slice the T[] directly. > However, from purely a code perspective Elembuf attempts to have > minimal runtime arguments and variables, with heavy reliance on > compile time arguments. It also uses a newer system call for Linux > (Glibc) that is currently not in druntime, the reason for this system > call is that it allows for faster buffer construction. Read more about > it here: https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/ Hmm. Isn't that orthogonal to mmap(), though? You could just map a memfd descriptor using mmap() to achieve essentially equivalent functionality. Am I missing something obvious? T -- Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert
Re: Announcing Elembuf
On Monday, 17 December 2018 at 22:31:22 UTC, H. S. Teoh wrote: On Mon, Dec 17, 2018 at 09:16:16PM +, Cyroxin via Digitalmars-d-announce wrote: Elembuf is a library that allows writing efficient parsers and readers. It looks as if it were just a regular T[], making it work well with libraries and easy to use with slicing. To avoid copying, the buffer can only be at maximum one page long. [...] What advantage does this have over using std.mmfile to mmap() the input file into the process' address space, and just using it as an actual T[] -- which the OS itself will manage the paging for, with basically no extraneous copying except for what is strictly necessary to transfer it to/from disk, and with no arbitrary restrictions? (Or, if you don't like the fact that std.mmfile uses a class, calling mmap() / the Windows equivalent directly, and taking a slice of the result?) T Hello, I would assume that there is much value in having a mapping that can be reused instead of having to remap files to the memory when a need arises to change source. While I cannot comment on the general efficiency between a mapped file and a circular buffer without benchmarks, this may be of use: https://en.wikipedia.org/wiki/Memory-mapped_file#Drawbacks An interesting fact I found out was that std.mmfile keeps a reference of the memory file handle, instead of relying on the system's handle closure after unmap. There seems to be quite a lot of globals, which is odd as Elembuf only has one. In std.mmfile OpSlice returns a void[] instead of a T[], making it difficult to work with as it requires a cast, there would also be a need to do costly conversions should "T.sizeof != void.sizeof" be true. However, from purely a code perspective Elembuf attempts to have minimal runtime arguments and variables, with heavy reliance on compile time arguments. It also uses a newer system call for Linux (Glibc) that is currently not in druntime, the reason for this system call is that it allows for faster buffer construction. Read more about it here: https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/
Re: D is helping from porch pirates
On Monday, 17 December 2018 at 23:13:18 UTC, Daniel Kozák wrote: https://gma.abc/2zWvXCl https://forum.dlang.org/post/mailman.5569.1501666175.31550.digitalmar...@puremagic.com
D is helping from porch pirates
https://gma.abc/2zWvXCl
Re: Announcing Elembuf
On Mon, Dec 17, 2018 at 09:16:16PM +, Cyroxin via Digitalmars-d-announce wrote: > Elembuf is a library that allows writing efficient parsers and > readers. It looks as if it were just a regular T[], making it work > well with libraries and easy to use with slicing. To avoid copying, > the buffer can only be at maximum one page long. [...] What advantage does this have over using std.mmfile to mmap() the input file into the process' address space, and just using it as an actual T[] -- which the OS itself will manage the paging for, with basically no extraneous copying except for what is strictly necessary to transfer it to/from disk, and with no arbitrary restrictions? (Or, if you don't like the fact that std.mmfile uses a class, calling mmap() / the Windows equivalent directly, and taking a slice of the result?) T -- My program has no bugs! Only undocumented features...
This Week in D is back
Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html
Beta 2.084.0
Glad to announce the first beta for the 2.084.0 release, ♥ to the 51 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.084.0.html As usual please report any bugs at https://issues.dlang.org -Martin
Announcing Elembuf
Elembuf is a library that allows writing efficient parsers and readers. It looks as if it were just a regular T[], making it work well with libraries and easy to use with slicing. To avoid copying, the buffer can only be at maximum one page long. Internally it is a circular buffer with memory mirroring. The garbage collector should not be used for the buffer as it would remove the memory mapping functionality. In the future, work will be done to add support for a dynamic buffer that copies when resized and -betterC compatibility. It currently supports Windows, GlibC 2.27 and Posix systems. You can create your own sources for the buffer, or you can directly write to the buffer. The project also comes with one example source: "NetSource", which can be used as a base for implementing the read interface of your own source, should you want to make one. The example source lacks major features and should only be used as a reference for your own source. Code simplicity and ease of use are major goals for the project. More testing and community additions are needed. A good first contribution would be to add additional sources or fix current ones. Please Check it out on github and consider helping out: https://github.com/Cyroxin/Elembuf
Re: Blog post: What D got wrong
On 12/15/2018 11:53 AM, Atila Neves wrote: @safe and pure though... @safe is not so hard to adopt, since by using @trusted one can proceed incrementally. Going pure, however, is much harder (at least for me) because I'm not used to programming that way. Making a function pure often requires reorganization of how a task is broken up into data structures and functions. For example, https://github.com/dlang/dmd/blob/master/src/dmd/target.d It's nearly all global variables that manipulate other global variables. I recently added a parameter to _init() so that it didn't need to access global.params. Now if the Target.* __gshared's could instead be replaced with fields, then _init() could be made pure.
Re: A brief survey of build tools, focused on D
On Sunday, 16 December 2018 at 00:17:55 UTC, Paul Backus wrote: There's something important you're glossing over here, which is that, in the general case, there's no single obvious or natural way to compose two DAGs together. For example: suppose project A's DAG has two "output" vertices (i.e., they have no outgoing edges), one corresponding to a "debug" build and one corresponding to a "release" build. Now suppose project B would like to depend on project A. For this to happen, our hypothetical DAG import function needs to add one or more edges that connect A's DAG to B's DAG. The question is, how many edges, and which vertices should these edges connect? That doesn't seem right. Surely you could write externalDependencies = [ someSubmodule.release ] in your language-specific build tool, and have it convert to an equivalent import edge targeting the correct vertice in the standardized dependency graph? It might be inconvenient in some cases (eg you have to manually tell your tool to import someSubmodule.release in release mode and someSubmodule.debug in debug mode), but it would still be infinitely more convenient and elegant than the current "multiple incompatible build tools per language, and shell/make scripts to link them together" paradigm. Especially with the increasing usability of WebAsm, it would be nice to have a standard build model to link multiple modules in different languages together into a single wasm binary. A standardized DAG model would also help making a project-wide equivalent to the Language Server Protocol. (I'm not convinced by BSP)
Re: Blog post: What D got wrong
On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote: On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Not quite. It doesn't work the way most people expect for member functions and causes problems for templates.
Re: Fuzzed - a program to find DMDFE parser crash
On Monday, 17 December 2018 at 10:12:44 UTC, Stefan Koch wrote: On Sunday, 16 December 2018 at 14:24:54 UTC, Jacob Carlborg wrote: On 2018-12-15 16:37, Basile B. wrote: This poisoning kills the interest of using a fuzzer. 99% of the crashes will be in hdrgen. Does that matter as long as the bug is found? Well it's hard to tell if it's begin. meant to say benign.
Re: Fuzzed - a program to find DMDFE parser crash
On Sunday, 16 December 2018 at 14:24:54 UTC, Jacob Carlborg wrote: On 2018-12-15 16:37, Basile B. wrote: This poisoning kills the interest of using a fuzzer. 99% of the crashes will be in hdrgen. Does that matter as long as the bug is found? Well it's hard to tell if it's begin. Generally in a compiler which is focused on speed, you accept crashing an really bogus input if it makes the parser run faster, because there is no chance of accepting corrupted code, which is what you need to be worried about.
Re: Blog post: What D got wrong
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed?
Re: Blog post: What D got wrong
On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote: On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Argh, I forgot that you are not supposed to @safe templates away.
Re: Blog post: What D got wrong
On Sat, 2018-12-15 at 19:53 +, Atila Neves via Digitalmars-d-announce wrote: > On Saturday, 15 December 2018 at 02:16:36 UTC, Nathan S. wrote: > > On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves > > wrote: > > > My impression is that it's a consensus that it _should_, but > > > it's not going to happen due to breaking existing code. > > > > I think it would be a bad idea for `immutable` because more > > often than not it would need to be turned off. > > Not the case in Rust, not the case in how I write D. TBH it's not > such a big deal because something has to be typed, I just default > to const now anyway instead of auto. @safe and pure though... Shouldn't be the case in Java either, since it is and always has been a single assignment supporting language – it's just that they made mutable the default, and trained people not use final. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
