Re: Is there a std.zip.ZipArchive isDir or isFile method?
On Wednesday, 12 February 2020 at 05:59:53 UTC, cc wrote:
On Monday, 3 February 2020 at 13:26:38 UTC, mark wrote:
I'm using std.zip.ZipArchive to read zip files, e.g.:
[snip]
I couldn't find one either, I had to do this:
version(Windows) {
enum uint FILE_ATTRIBUTE_DIRECTORY = 0x10;
}
auto zip = new ZipArchive(buffer);
foreach (fn, am; zip.directory) {
if (am.fileAttributes & FILE_ATTRIBUTE_DIRECTORY)
... is directory
else
... is file
}
I need to work on both Linux and Windows, and on Linux
am.fileAttributes seems to be 0 for both files and directories.
The lack of a cross-platform way of distinguishing whether an
archive member is a directory or file does seem to be a missing
piece of the API.
As I'm looking at my code for this I'm also reminded that
different zip files can internally store path separators as
either \ or / depending on the platform that created them so
you may need to be careful about that too. I have a bit for
this that simply does:
version(StandardizePathSeparators) {
string filename = fn.replace("\\", "/");
} else {
string filename = fn;
}
Yes, I was aware of that, but I use:
string filename = fn.tr("\\", "/"); // tr is from std.string
Re: GtkD on Windows: notes + question
On Tuesday, 11 February 2020 at 20:49:40 UTC, Ron Tarrant wrote: On Sunday, 9 February 2020 at 13:28:59 UTC, mark wrote: I found a much easier way to get GtkD working on windows than that described in https://gtkdcoding.com/2019/01/11/-introduction-to-gtkDcoding.html Just FYI... I don't use dub because I don't have time to understand its foibles well enough to steer new D coders through the maze. Besides that, using tools like dub separates one from the process. Up to you, though, of course. That's understandable. Anyway, once I get back to learning GtkD I'll be starting with your blog.
Re: Is there a std.zip.ZipArchive isDir or isFile method?
On Monday, 3 February 2020 at 13:26:38 UTC, mark wrote:
I'm using std.zip.ZipArchive to read zip files, e.g.:
auto zip = new ZipArchive(read(filename));
// ...
foreach (name, member; zip.directory) {
if (name.endsWith('/')) // skip dirs
continue;
mkdirRecurse(dirName(name));
zip.expand(member);
write(name, member.expandedData());
}
As you can see, I am detecting directories with a crude test.
I really wish there was a method for this: and if there is,
could you give me the link 'cos I can't see one in the docs?
(BTW The code above is slightly simplified: the real code won't
unzip if there's an absolute path or .. present and also
ensures that all members are unzipped into a subdir even if the
zip has top-level names.)
I couldn't find one either, I had to do this:
version(Windows) {
enum uint FILE_ATTRIBUTE_DIRECTORY = 0x10;
}
auto zip = new ZipArchive(buffer);
foreach (fn, am; zip.directory) {
if (am.fileAttributes & FILE_ATTRIBUTE_DIRECTORY)
... is directory
else
... is file
}
As I'm looking at my code for this I'm also reminded that
different zip files can internally store path separators as
either \ or / depending on the platform that created them so you
may need to be careful about that too. I have a bit for this
that simply does:
version(StandardizePathSeparators) {
string filename = fn.replace("\\", "/");
} else {
string filename = fn;
}
Re: GtkD on Windows: notes + question
On Sunday, 9 February 2020 at 13:28:59 UTC, mark wrote: I found a much easier way to get GtkD working on windows than that described in https://gtkdcoding.com/2019/01/11/-introduction-to-gtkDcoding.html Just FYI... I don't use dub because I don't have time to understand its foibles well enough to steer new D coders through the maze. Besides that, using tools like dub separates one from the process. Up to you, though, of course.
Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?
On Tuesday, 11 February 2020 at 19:04:17 UTC, Paul Backus wrote:
On Tuesday, 11 February 2020 at 18:55:45 UTC, wjoe wrote:
What's a compiler list... is that something like a tuple? or
more like a macro expansion?
Or is it only valid to use in a foreach to take advantage of
each item individually and for expansion in a function call ?
Is it possible to partially expand like:
void fn(int, uint) {}
and ARGS(string, int, uint)
and call fn(args[1..$]);
Is that possible?
This article answers all of your questions:
https://dlang.org/articles/ctarguments.html
That's more information than I had hoped for. Thank you :)
Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?
On Tuesday, 11 February 2020 at 19:05:19 UTC, Adam D. Ruppe wrote:
On Tuesday, 11 February 2020 at 18:55:45 UTC, wjoe wrote:
What's a compiler list... is that something like a tuple?
Yea, they are frequently called tuples too. It is basically
just a list of arguments used for a function call that the
compiler treats somewat magically.
Is it possible to partially expand like:
void fn(int, uint) {}
and ARGS(string, int, uint)
and call fn(args[1..$]);
Yes, slicing is the exact syntax for it. You can slice and
index as if it were an array.
Cool. thanks for your reply :)
Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?
On Tuesday, 11 February 2020 at 18:55:45 UTC, wjoe wrote:
What's a compiler list... is that something like a tuple?
Yea, they are frequently called tuples too. It is basically just
a list of arguments used for a function call that the compiler
treats somewat magically.
Is it possible to partially expand like:
void fn(int, uint) {}
and ARGS(string, int, uint)
and call fn(args[1..$]);
Yes, slicing is the exact syntax for it. You can slice and index
as if it were an array.
Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?
On Tuesday, 11 February 2020 at 18:55:45 UTC, wjoe wrote:
What's a compiler list... is that something like a tuple? or
more like a macro expansion?
Or is it only valid to use in a foreach to take advantage of
each item individually and for expansion in a function call ?
Is it possible to partially expand like:
void fn(int, uint) {}
and ARGS(string, int, uint)
and call fn(args[1..$]);
Is that possible?
This article answers all of your questions:
https://dlang.org/articles/ctarguments.html
Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?
On Tuesday, 11 February 2020 at 18:21:11 UTC, Adam D. Ruppe wrote:
On Tuesday, 11 February 2020 at 18:11:44 UTC, wjoe wrote:
In my mind, if something works with foreach, it should also
work with std.algorithm.each.
They are very different, the each thing only works for ranges
whereas foreach works with a variety of things.
How is 1) different from 2) ?
The ARGS... is a compiler list and can have multiple different
types included. Moreover, it will auto-expand when you use it
to call a function etc.
You can sometimes do [args] - with the [] around it to turn
into an array. Then you can .each it and so on. But they must
already be of compatible types to do that since an array
elements must all be the same thing.
I would suggest just using foreach for this.
What's a compiler list... is that something like a tuple? or more
like a macro expansion?
Or is it only valid to use in a foreach to take advantage of each
item individually and for expansion in a function call ?
Is it possible to partially expand like:
void fn(int, uint) {}
and ARGS(string, int, uint)
and call fn(args[1..$]);
Is that possible?
as for the format function...foreach works as expected so I'll
just keep that. Thanks for your fast reply :)
Re: tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?
On Tuesday, 11 February 2020 at 18:11:44 UTC, wjoe wrote: In my mind, if something works with foreach, it should also work with std.algorithm.each. They are very different, the each thing only works for ranges whereas foreach works with a variety of things. How is 1) different from 2) ? The ARGS... is a compiler list and can have multiple different types included. Moreover, it will auto-expand when you use it to call a function etc. You can sometimes do [args] - with the [] around it to turn into an array. Then you can .each it and so on. But they must already be of compatible types to do that since an array elements must all be the same thing. I would suggest just using foreach for this.
tuple(...).each error; why does foreach work and std.algorithms.each doesn't ?
Consider a function to format the parameters of a function call:
pure nothrow string fmtArgs(ARGS...)(ARGS args)
{
string result;
// 1)
foreach(a; args) {
result ~= a.to!string;
}
// 2)
args.each!(a => result ~= a.to!string);
return result;
}
In my mind, if something works with foreach, it should also work
with std.algorithm.each.
However if I try something like 2) the compiler complains with
error: cannot deduce function from argument types !()(uint,
int)...
Technically I'd like to transform args into a range/array of
strings but I'm not smart enough to understand the error messages
these functions in std.algorithms produce.
How is 1) different from 2) ?
Re: Printing LHS and RHS of assert expressions on failure
On Tuesday, 11 February 2020 at 13:45:24 UTC, kinke wrote: On Tuesday, 11 February 2020 at 13:38:32 UTC, Adnan wrote: I just want to know is there any de-facto way of achieving this? See the `-checkaction=context` switch. Exactly what I was after. Thanks.
Re: Printing LHS and RHS of assert expressions on failure
On Tuesday, 11 February 2020 at 13:38:32 UTC, Adnan wrote: I just want to know is there any de-facto way of achieving this? See the `-checkaction=context` switch.
Printing LHS and RHS of assert expressions on failure
Hi, is there any trick to print the RHS and the LHS of the assert expressions when it fails? like `assert(2 == 5)` should fail and print something like: ... assert failed [__LINE__/__MODULE__]: Left hand side: 2 is 2, Right hand side: 5 is 5 Of course, I can design a function to do so myself, but I just want to know is there any de-facto way of achieving this? Is there any unit-testing library that does this for me?
Re: Dynamically calling shared objects from statically build executable allowed
On Monday, 10 February 2020 at 19:39:04 UTC, Ernesto Castellotti wrote: On Monday, 10 February 2020 at 19:00:36 UTC, Andre Pany wrote: [...] Static libraries are simple collections of object files, there is no difference between linking a static library or several object files If you notice when going to compile the executable linka libdl and the static library, then the executable will be linked to dynamic library and will not be a static executable. Thanks for the explanation. Kind regards André
Re: about const ref
On Tuesday, 11 February 2020 at 09:20:11 UTC, Mathias Lang wrote: On Tuesday, 11 February 2020 at 07:51:04 UTC, Ferhat Kurtulmuş wrote: You're correct for 'a' and 'b'. However `in` only entails `const`, so it is not an exact replacement. Additionally, you might want to add `scope` to show that the parameter does not escape. Note that a big limitation on `const ref` parameters at the moment is that it does not accept literals, which is something Andrei talked about a few years ago at DConf (or was it last year?). Thank you for clarification.
Re: about const ref
On Tuesday, 11 February 2020 at 07:51:04 UTC, Ferhat Kurtulmuş
wrote:
I need to be sure about "const ref". Based on the following
function, does it mean:
Type can be string or an integral type.
(a) k1 is not copied on function calls
(b) k1 cannot be modified inside function
Please correct me if I am wrong. Can storage class "in" be used
to satisfy (a) and (b)?
void doIt(const ref Type k1){
}
Type k = ...;
doit(k);
You're correct for 'a' and 'b'. However `in` only entails
`const`, so it is not an exact replacement.
Additionally, you might want to add `scope` to show that the
parameter does not escape.
Note that a big limitation on `const ref` parameters at the
moment is that it does not accept literals, which is something
Andrei talked about a few years ago at DConf (or was it last
year?).
