www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.file read with start position

reply Etienne <etcimon gmail.com> writes:
I'm currently brainstorming a persistent database scheme and it 
surprised me that random-access reading/writing isn't implemented in 
std.file. With SSDs becoming more commonplace, this practice is just 
fine. Any other reason for this?
Jun 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 24, 2014 at 12:23:08PM -0400, Etienne via Digitalmars-d wrote:
 I'm currently brainstorming a persistent database scheme and it
 surprised me that random-access reading/writing isn't implemented in
 std.file. With SSDs becoming more commonplace, this practice is just
 fine. Any other reason for this?

std.file? Shouldn't you be looking at std.stdio? T -- I think the conspiracy theorists are out to get us...
Jun 24 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-06-24 12:56 PM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jun 24, 2014 at 12:23:08PM -0400, Etienne via Digitalmars-d wrote:
 I'm currently brainstorming a persistent database scheme and it
 surprised me that random-access reading/writing isn't implemented in
 std.file. With SSDs becoming more commonplace, this practice is just
 fine. Any other reason for this?

std.file? Shouldn't you be looking at std.stdio? T

I did, couldn't find a way to read a specific length (serialized data) so std.file seemed more of a fit for that.
Jun 24 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-06-24 1:46 PM, H. S. Teoh via Digitalmars-d wrote:
 Easy:

 	auto f = File(myDataFile, "r");
 	f.seek(someOffset);
 	ubyte[] buf;
 	buf.length = sizeOfData;
 	ubyte[] dataRead = f.rawRead(buf);
 	if (dataRead.length != sizeOfData)
 		throw new Exception("Unexpected truncated data");
 	// do whatever you want with dataRead

 Hope this helps.

 And yes, the documentation should use some improvement. A lot of
 improvement even. :P  Please feel free to submit a pull request, or at
 least file a bug against the docs.


 T

Well, that solves it for me ;) I think the documentation could use more code samples, and a smarter table of contents. e.g. http://dlang.org/phobos/std_stdio.html clicking on the "read" keyword redirects to... enum LockType.read There's no mention about reading in the struct File; example ugh :/
Jun 24 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/24/14, 12:39 PM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jun 24, 2014 at 12:36:12PM -0700, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jun 24, 2014 at 02:07:20PM -0400, Etienne via Digitalmars-d wrote:
 [...]
 I think the documentation could use more code samples, and a smarter
 table of contents. e.g. http://dlang.org/phobos/std_stdio.html
 clicking on the "read" keyword redirects to... enum LockType.read

 There's no mention about reading in the struct File; example

 ugh :/

Please file a bug in the bugtracker so that we don't forget about this issue.

P.S. the problem with the table of contents links pointing to the wrong place is a known bug: https://issues.dlang.org/show_bug.cgi?id=11575 This badly needs to be fixed; as things stand, it makes ddoc look like a joke (it generates non-unique HTML element ID's, which both violates the HTML spec and causes erratic browser behaviour when you click on said links).

This has been a long-standing issue that I actually fixed a long time ago in https://github.com/D-Programming-Language/dlang.org/pull/271. Of course, it's now bit rotting in peace. -- Andrei
Jun 24 2014
prev sibling parent Etienne Cimon <etcimon gmail.com> writes:
On 2014-06-24 20:33, H. S. Teoh via Digitalmars-d wrote:
 Once this goes in, ddoc anchors should be*much*  saner. While I don't
 have the confidence this is the last we'll hear of ddoc anchor issues, I

Well, that was quick! I might contribute some documentation in phobos, there's obviously a little bit of work to do in there =)
Jun 24 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/24/14, 10:07 AM, Etienne wrote:
 On 2014-06-24 12:56 PM, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jun 24, 2014 at 12:23:08PM -0400, Etienne via Digitalmars-d
 wrote:
 I'm currently brainstorming a persistent database scheme and it
 surprised me that random-access reading/writing isn't implemented in
 std.file. With SSDs becoming more commonplace, this practice is just
 fine. Any other reason for this?

std.file? Shouldn't you be looking at std.stdio? T

I did, couldn't find a way to read a specific length (serialized data) so std.file seemed more of a fit for that.

std.file -> files are handled as a unit (file is opened and closed within the same function) std.stdio -> files are first-class Andrei
Jun 24 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 24, 2014 at 01:07:42PM -0400, Etienne via Digitalmars-d wrote:
 On 2014-06-24 12:56 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jun 24, 2014 at 12:23:08PM -0400, Etienne via Digitalmars-d wrote:
I'm currently brainstorming a persistent database scheme and it
surprised me that random-access reading/writing isn't implemented in
std.file. With SSDs becoming more commonplace, this practice is just
fine. Any other reason for this?

std.file? Shouldn't you be looking at std.stdio? T

I did, couldn't find a way to read a specific length (serialized data) so std.file seemed more of a fit for that.

Easy: auto f = File(myDataFile, "r"); f.seek(someOffset); ubyte[] buf; buf.length = sizeOfData; ubyte[] dataRead = f.rawRead(buf); if (dataRead.length != sizeOfData) throw new Exception("Unexpected truncated data"); // do whatever you want with dataRead Hope this helps. And yes, the documentation should use some improvement. A lot of improvement even. :P Please feel free to submit a pull request, or at least file a bug against the docs. T -- In theory, there is no difference between theory and practice.
Jun 24 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 24, 2014 at 02:07:20PM -0400, Etienne via Digitalmars-d wrote:
[...]
 I think the documentation could use more code samples, and a smarter
 table of contents. e.g. http://dlang.org/phobos/std_stdio.html
 clicking on the "read" keyword redirects to... enum LockType.read
 
 There's no mention about reading in the struct File; example
 
 ugh :/

Please file a bug in the bugtracker so that we don't forget about this issue. T -- Acid falls with the rain; with love comes the pain.
Jun 24 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 24, 2014 at 12:36:12PM -0700, H. S. Teoh via Digitalmars-d wrote:
 On Tue, Jun 24, 2014 at 02:07:20PM -0400, Etienne via Digitalmars-d wrote:
 [...]
 I think the documentation could use more code samples, and a smarter
 table of contents. e.g. http://dlang.org/phobos/std_stdio.html
 clicking on the "read" keyword redirects to... enum LockType.read
 
 There's no mention about reading in the struct File; example
 
 ugh :/

Please file a bug in the bugtracker so that we don't forget about this issue.

P.S. the problem with the table of contents links pointing to the wrong place is a known bug: https://issues.dlang.org/show_bug.cgi?id=11575 This badly needs to be fixed; as things stand, it makes ddoc look like a joke (it generates non-unique HTML element ID's, which both violates the HTML spec and causes erratic browser behaviour when you click on said links). T -- EMACS = Extremely Massive And Cumbersome System
Jun 24 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
 Sent: Tuesday, June 24, 2014 at 12:39 PM
 From: "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>
 To: digitalmars-d puremagic.com
 Subject: Re: std.file read with start position

 P.S. the problem with the table of contents links pointing to the wrong
 place is a known bug:
 
 	https://issues.dlang.org/show_bug.cgi?id=11575
 
 This badly needs to be fixed; as things stand, it makes ddoc look like
 a joke (it generates non-unique HTML element ID's, which both violates
 the HTML spec and causes erratic browser behaviour when you click on
 said links).

ddoc is very useful, but with regards to links, it _is_ a joke. It has no understanding of code hierarchy whatsoever, making it just plain stupid when it generates links. - Jonathan M Davis
Jun 24 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 24, 2014 at 10:23:45PM +0200, Jonathan M Davis via Digitalmars-d
wrote:
 From: "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>


 P.S. the problem with the table of contents links pointing to the wrong
 place is a known bug:
 
 	https://issues.dlang.org/show_bug.cgi?id=11575
 
 This badly needs to be fixed; as things stand, it makes ddoc look
 like a joke (it generates non-unique HTML element ID's, which both
 violates the HTML spec and causes erratic browser behaviour when you
 click on said links).

ddoc is very useful, but with regards to links, it _is_ a joke. It has no understanding of code hierarchy whatsoever, making it just plain stupid when it generates links.

Actually, https://github.com/D-Programming-Language/dmd/pull/1174 appears to have fixed this issue (see also bug 6017). However, the fix is incomplete: it doesn't work with template members, so members of template structs/classes will still get global unqualified anchors instead of qualified anchors. I've traced the problem to src/dmd/doc.c's emitAnchorName() function. It appears that template members' DSymbol nodes have their .parent pointer set to NULL, so it doesn't know to emit the parent template's name. I'm no DMD expert, so if someone could kindly explain to me why this is so, and how I can get at the parent template's name, I should be able to fix this. :-) T -- "Real programmers can write assembly code in any language. :-)" -- Larry Wall
Jun 24 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 24, 2014 at 10:23:45PM +0200, Jonathan M Davis via Digitalmars-d
wrote:
[...]
 From: "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>


 P.S. the problem with the table of contents links pointing to the
 wrong place is a known bug:
 
 	https://issues.dlang.org/show_bug.cgi?id=11575
 
 This badly needs to be fixed; as things stand, it makes ddoc look
 like a joke (it generates non-unique HTML element ID's, which both
 violates the HTML spec and causes erratic browser behaviour when you
 click on said links).

ddoc is very useful, but with regards to links, it _is_ a joke. It has no understanding of code hierarchy whatsoever, making it just plain stupid when it generates links.

Actually, that's not entirely true: https://github.com/D-Programming-Language/dmd/pull/1174 Qualified anchor names have been with us for a while; it's just that the std.algorithm docs haven't been properly updated to reference them correctly. However, pull 1174 leaves out something: https://issues.dlang.org/show_bug.cgi?id=10366 But, have no fear! I've managed to figure out how to fix it: https://github.com/D-Programming-Language/dmd/pull/3693 Once this goes in, ddoc anchors should be *much* saner. While I don't have the confidence this is the last we'll hear of ddoc anchor issues, I think it should improve the situation significantly. T -- They pretend to pay us, and we pretend to work. -- Russian saying
Jun 24 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 24, 2014 at 10:06:51PM -0400, Etienne Cimon via Digitalmars-d wrote:
 On 2014-06-24 20:33, H. S. Teoh via Digitalmars-d wrote:
Once this goes in, ddoc anchors should be*much*  saner. While I don't
have the confidence this is the last we'll hear of ddoc anchor
issues, I

Well, that was quick!

Quick, but not quite complete: https://github.com/D-Programming-Language/dmd/pull/3695
 I might contribute some documentation in phobos, there's obviously a
 little bit of work to do in there =)

Please do, the state of phobos docs in many places are quite sad. Any help in facelifting them would be appreciated. :) T -- Change is inevitable, except from a vending machine.
Jun 25 2014