Re: refactoring issues
On Tuesday, 17 March 2015 at 15:11:02 UTC, Ivan Kazmenko wrote: For the former problem, is there a tool which jumps out and tells you use Phobos without importing things properly, or suggests a Phobos import by the name of the stuff. I did make something simple for myself, but it doesn't work in the more complicated cases you mentioned (contracts failing because of missing imports). http://dump.thecybershadow.net/e91be687ebaeb0171d830025adf82848/autofix.gif I could post the code but the editor integration part is pretty specific to my editor.
Lazy functions, lazy arrays
Hi, Is it possible for D to create lazy functions, lazy arrays? Or in addition to the function arguments can't be lazy in D?
Re: buffer to struct type conversion...TArrayStream?
On Thu, 19 Mar 2015 10:47:05 -0700, Charles Hixson via Digitalmars-d-learn wrote: turn it 90 degrees. ;-) auto cvt = cast(Node_*)buf.ptr; n = cvt[0]; signature.asc Description: PGP signature
Re: buffer to struct type conversion...TArrayStream?
On 03/19/2015 12:05 PM, via Digitalmars-d-learn wrote:
On Thursday, 19 March 2015 at 18:42:03 UTC, Marc Schütz wrote:
3) Using std.bitmap.peek(), which also supports conversion between
big- and little-endian:
import std.bitmap;
n.self = buf.peek!(Node.Node_, Endian.bigEndian);
(The examples are untested, it's possible you'll need to make some
adjustments to make them work.)
You should probably use option 3). It is safe, because it checks that
the buffer has the right size, and it also allows you to specify the
endian-ness (many file formats have a standardized endian-ness).
While you're at it, you can also try std.bitmanip.read(). It can be
applied to any range, so you can probably do something like this
(also untested):
auto input = btFile.byChunk(4096).joiner;
while(!input.empty) {
auto node = input.read!(Node.Node_, Endian.bigEndian);
// use `node`
}
Urgh... it seems `peek()` and `read()` only work with numerical types
:-( Is this intentional? It would be quite useful for arbitrary types,
IMO, even if care must be taken with regard to pointers.
Note: Thanks for the prior comment about where to place the array
markers. I keep forgetting.
Umnf...I don't plan on needing conversion between Endian versions, but I
guess that's important. But more significant if it only handles numeric
types I wonder about handling arrays of structs, even if those structs
*are* composed entirely of numerical types. Being secure against a
future need to handle Endian variations would be good, but not enough to
both increase the complexity that way and deal with possible unexpected
errors.
P.S.: Looking at the std.bitmanip documentation causes me to feel that
the restriction to integral types was intentional, though admittedly it
doesn't seem to be stated explicitly, but all of the examples seem to be
simple arrays. I'll grant that this could be just to keep things
simple. And the wording of the docs causes me to think it would
probably only work for integral values, as in not even floats. This is
reasonable if you are thinking of it as a set of routines for bit
manipulation.
At all events, I think that it involves excessive overhead (in code
verbosity) and that I'ld likely need to use a loop to read the array
within the struct. A simple bit copy is much more straightforwards (I
was already checking that the read was the correct length, though I
haven't decided what to do if that ever fails. Currently it's an assert
statement, but this clearly needs to be changed to either an enforce
statement or to a thrown exception...but I haven't yet thought of a
valid case where the block would be an incorrect length.
Re: Should this work: export extern(C) auto ...
On Thursday, 19 March 2015 at 12:58:42 UTC, Robert M. Münch wrote: On 2015-03-18 21:50:39 +, Adam D. Ruppe said: It will not work because a function with an auto return value is actually a template, and unused templates won't be put into a dll. Ok, that makes it clear. Thanks. Generally don't expect to many things to work with DLLs at the moment. Generally speaking only exporting global functions works. Don't try to export classes / structs or anything fancy.
Re: Should this work: export extern(C) auto ...
On 2015-03-18 21:50:39 +, Adam D. Ruppe said: It will not work because a function with an auto return value is actually a template, and unused templates won't be put into a dll. Ok, that makes it clear. Thanks. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: variadic mixin - the right tool for the job?
On 2015-03-18 15:27:03 +, Daniel Kozák via Digitalmars-d-learn said:
You probably does not need mixins:
void log(string file = __FILE__, size_t line = __LINE__, T...)
(T variadic_arg) {
some_fun(variadic_arg[0], file, line, variadic_arg[1 .. $]);
}
Hi, ha, forgot about default arguments. Great that this works and take
the file line number where the tempate function is used.
Thanks.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
buffer to struct type conversion...TArrayStream?
I've read a chunk of data into a buffer and want to convert it into a
struct. The reading routine is in a class that doesn't know about the
struct, but the size should be exactly the same. (I.e., I want to use
the converse procedure to write it.)
Is there a better way to do this than using TArrayStream?
The idea here is to have a file of fixed length records (rather like
Fortran binary records, except that there's a header record which is a
different size and which specifies various things about the file). The
class (well, struct) that handles the fixed length records only knows
what the record size is, and a couple of other quite general things.
The class which uses it holds each record in a fixed length struct with
no indirections. So I thought I could just cast the buffer to the
struct...but this doesn't work. Every straightforward way I've tried of
doing it yields:
Error: cannot cast from Node_ to ubyte[]
or something reasonably analogous. The current version of the
(non-working) code is:
ubytebuf[];
autolen=btFile.read(nodeId, buf);
assert(len == n.self.sizeof);
n.self=to!(Node.Node_)(buf);
//TODOwrite the code
which yields the error:
Error: template instance std.conv.to!(Node_).to!(ubyte[]) error
instantiating
Node_ is (approximately, I've renamed aliased values to their base value):
structNode_
{ ulongidvalue;
ulongkeyvalue;
inteLen;
Entry e[23];
}
and Entry is (approximately):
structEntry
{ ulongkey;
ulongd;
ulongd2;
}
Re: refactoring issues
On Thursday, 19 March 2015 at 10:21:09 UTC, Vladimir Panteleev wrote: On Tuesday, 17 March 2015 at 15:11:02 UTC, Ivan Kazmenko wrote: For the former problem, is there a tool which jumps out and tells you use Phobos without importing things properly, or suggests a Phobos import by the name of the stuff. I did make something simple for myself, but it doesn't work in the more complicated cases you mentioned (contracts failing because of missing imports). http://dump.thecybershadow.net/e91be687ebaeb0171d830025adf82848/autofix.gif I could post the code but the editor integration part is pretty specific to my editor. Hey, I also happen to use Far Manager and its internal editor, at least for simple projects. Is that dcheck triggering a Far plugin? I have a bit of experience with Far recording macros, but didn't try to write a plugin.
Re: buffer to struct type conversion...TArrayStream?
On Thursday, 19 March 2015 at 17:48:00 UTC, Charles Hixson wrote:
I've read a chunk of data into a buffer and want to convert it
into a struct. The reading routine is in a class that doesn't
know about the struct, but the size should be exactly the same.
(I.e., I want to use the converse procedure to write it.)
Is there a better way to do this than using TArrayStream?
The idea here is to have a file of fixed length records (rather
like Fortran binary records, except that there's a header
record which is a different size and which specifies various
things about the file). The class (well, struct) that handles
the fixed length records only knows what the record size is,
and a couple of other quite general things. The class which
uses it holds each record in a fixed length struct with no
indirections. So I thought I could just cast the buffer to the
struct...but this doesn't work. Every straightforward way I've
tried of doing it yields:
Error: cannot cast from Node_ to ubyte[]
or something reasonably analogous. The current version of the
(non-working) code is:
ubytebuf[];
Please use D-style array declarations, the syntax you're using is
deprecated:
ubyte[] buf;
autolen=btFile.read(nodeId, buf);
assert(len == n.self.sizeof);
n.self=to!(Node.Node_)(buf);
//TODOwrite the code
which yields the error:
Error: template instance std.conv.to!(Node_).to!(ubyte[]) error
instantiating
If you want to reinterpret a byte array as another type, there
are three ways:
1) Using a cast (unsafe):
n.self = *cast(Node.Node_*)buf.ptr;
2) With a union:
union {
ubyte[Node.Node_.sizeof] asBytes;
Node.Node_ asNode;
} buf;
auto len = btFile.read(nodeId, buf.asBytes[]);
assert(len == n.self.sizeof);
n.self = buf.asNode
3) Using std.bitmap.peek(), which also supports conversion
between big- and little-endian:
import std.bitmap;
n.self = buf.peek!(Node.Node_, Endian.bigEndian);
(The examples are untested, it's possible you'll need to make
some adjustments to make them work.)
You should probably use option 3). It is safe, because it checks
that the buffer has the right size, and it also allows you to
specify the endian-ness (many file formats have a standardized
endian-ness).
While you're at it, you can also try std.bitmanip.read(). It can
be applied to any range, so you can probably do something like
this (also untested):
auto input = btFile.byChunk(4096).joiner;
while(!input.empty) {
auto node = input.read!(Node.Node_, Endian.bigEndian);
// use `node`
}
Re: buffer to struct type conversion...TArrayStream?
On Thursday, 19 March 2015 at 18:42:03 UTC, Marc Schütz wrote:
3) Using std.bitmap.peek(), which also supports conversion
between big- and little-endian:
import std.bitmap;
n.self = buf.peek!(Node.Node_, Endian.bigEndian);
(The examples are untested, it's possible you'll need to make
some adjustments to make them work.)
You should probably use option 3). It is safe, because it
checks that the buffer has the right size, and it also allows
you to specify the endian-ness (many file formats have a
standardized endian-ness).
While you're at it, you can also try std.bitmanip.read(). It
can be applied to any range, so you can probably do something
like this (also untested):
auto input = btFile.byChunk(4096).joiner;
while(!input.empty) {
auto node = input.read!(Node.Node_, Endian.bigEndian);
// use `node`
}
Urgh... it seems `peek()` and `read()` only work with numerical
types :-( Is this intentional? It would be quite useful for
arbitrary types, IMO, even if care must be taken with regard to
pointers.
Re: buffer to struct type conversion...TArrayStream?
On 03/19/2015 11:42 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Please use D-style array declarations, the syntax you're using is deprecated: I fin the following compiler switches useful: -deshow use of deprecated features as errors (halt compilation) -w warnings as errors (compilation will halt) Ali
Re: buffer to struct type conversion...TArrayStream?
On 03/19/2015 11:18 AM, ketmar via Digitalmars-d-learn wrote: On Thu, 19 Mar 2015 10:47:05 -0700, Charles Hixson via Digitalmars-d-learn wrote: turn it 90 degrees. ;-) auto cvt = cast(Node_*)buf.ptr; n = cvt[0]; Whee! Thanks, I don't think I *ever* would have thought of that. I got as far as getting a pointer to buf, but then couldn't figure out how to turn the Node_* into a Node. (Obvious now that you showed me, and I even think I've seen that trick done before.)
Re: refactoring issues
On Thursday, 19 March 2015 at 14:32:53 UTC, Ivan Kazmenko wrote: Hey, I also happen to use Far Manager and its internal editor, at least for simple projects. Is that dcheck triggering a Far plugin? I have a bit of experience with Far recording macros, but didn't try to write a plugin. It's all a bit of a mess... A FAR Lua macro[1] runs dcheck, which is just a batch file that runs DMD piped through colorout[2], which in turn parses the compiler output and records the results to a temporary file, that's read by a second program that parses and caches the .json files generated as part of my D build process and then generates editing instructions read back by the Lua macro. [1]http://dump.thecybershadow.net/5c0afb5c0f4306b1368dd8528c838133/F9.lua [2]http://blog.thecybershadow.net/2013/07/27/colorize-your-compilers-output/
