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
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 "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
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 "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 reply "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
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 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 parent reply "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
parent reply 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
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
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