Re: Beta 2.100.2
Hi, > Can only give an estimate as on top of the eye-watering EV prices As far as I know, EV certificates are only required for device drivers in Windows. An OV certificate plus timestamp should be enough to sign an executable for Windows. Hugo
IEEE Spectrum: The Top Programming Languages 2016
Hi, The subject says most about it, the link is down below [1]. What I find interesting about this interactive ranking is that you can play around with the weighing of the data sources. Also: D is the only language categorised as being used for web and embedded, but not for mobile or enterprise. C/C++ are categorised as embedded, mobile, enterprise, but not web. Rust is categorised as web and enterprise, but not embedded or mobile. Regards, Hugo [1] http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2016
Re: Possible bug in std.path?
On Monday, 20 June 2016 at 12:55:21 UTC, ag0aep6g wrote: On Monday, 20 June 2016 at 12:38:23 UTC, Hugo wrote: Not necessarily, cmd.exe is made in C/C++ AFAIK, most other console applications for Windows behave the same way too. As seen on MSDN, it's how "Microsoft C/C++ startup code" does it. It's what you get in a C main's argv. Populating a D main's args in a different way would be unusual. Of course you can parse the command line yourself, and do it differently then. You can do this in C, in C++, and in D too. But the default is the other way, in all of them. I guess all the console programs I have used for MS products (since MS-DOS) have been unusual then according to MSDN. ;)
Re: Possible bug in std.path?
On Monday, 20 June 2016 at 10:01:25 UTC, ag0aep6g wrote: On the other hand, the way D gets the arguments is the same as in C/C++. Doing it differently than that would be unusual, too. Not necessarily, cmd.exe is made in C/C++ AFAIK, most other console applications for Windows behave the same way too.
Re: Possible bug in std.path?
On Monday, 20 June 2016 at 05:44:53 UTC, Mike Parker wrote: It shouldn't hurt to use the A variant, as Windows will do the necessary conversions under the hood. However, I'd love to know what the problem is with converting wchar* to a string type. This also prints an address: auto foo = "I'm a wstring"w.ptr; writeln(to!wstring(foo)); There was a bug report in std.conv, which was partially fixed in master branch (the one I used). Compiling your code with that fix produces the expected result. However it seems something is still missing. Regarding GetCommandLineA, I could use it but I believe this would exclude several eastern languages, for example.
Re: Possible bug in std.path?
On Sunday, 19 June 2016 at 23:01:26 UTC, Adam D. Ruppe wrote: One potentially simple option would be to preprocess it by doing a .replace(`\"`, `\\"`) then pass to CommandLineToArgvW to hack in the extra slash... The problem with that approach is that replace does not work with wchar*. I might convert it to string, replace and then typecast as wchar* again because that's what CommandLineToArgvW expects, but when I try to convert the output to strings again, all I get are memory addresses instead. It seems something is lost during conversion or typecast.
Re: Possible bug in std.path?
On Sunday, 19 June 2016 at 23:01:26 UTC, Adam D. Ruppe wrote:
On Sunday, 19 June 2016 at 15:36:08 UTC, Hugo wrote:
I thought the proper way to call GetCommandLineW was precisely
through CommandLineToArgvW, now I am lost.
Typically, yes, but you are saying you don't like what
CommandLineToArgvW does (it is responsible for handling quotes
and backslash escapes), so I'm saying you can do it some other
way.
GetCommandLineW will give you a raw string of what the user
typed. From there, you can treat it all as one argument or
split it up however you like.
One potentially simple option would be to preprocess it by
doing a .replace(`\"`, `\\"`) then pass to CommandLineToArgvW
to hack in the extra slash... or you could do a simple little
splitter yourself, something along the lines of:
---
bool inQuote;
size_t startIdx;
string[] args;
foreach(idx, ch; your_command_line) {
if(ch == '"')
inQuote = !inQuote;
else if(ch == ' ') {
if(!inQuote) {
args ~= to!string(your_command_line[startIdx .. idx];
startIdx = idx + 1;
}
}
}
if(startIdx != your_command_line.length)
args ~= to!string(your_command_line[startIdx .. $];
---
or something along those lines, I didn't actually test that.
(btw the to!string is optional, you could just leave them as
wstrings)
But the idea is to just split on space unless you are inside
quotes, doing nothing special on backslashes. That'd be what
you want (I think).
Thanks for the ideas, actually I was trying to do a function
similar to your splitter (but still having some problems with it):
void cleanArgs(in string cmdline, ref string[] args) {
uint argc = 0;
bool inQuotedMode = false;
bool lastCharIsBlank = false;
foreach(char c; cmdline) {
if(c == '"') inQuotedMode = !inQuotedMode;
if(inQuotedMode || (!inQuotedMode && c!=' ')) args[argc] ~= c;
if(!inQuotedMode && c==' ' && !lastCharIsBlank) {
argc++;
lastCharIsBlank = true;
}
}
}
Re: Possible bug in std.path?
On Sunday, 19 June 2016 at 23:12:10 UTC, ag0aep6g wrote:
On 06/20/2016 12:38 AM, Hugo wrote:
What you suggest is non-standard in Windows,
I don't buy this. MSDN says about "Parsing C++ Command-Line
Arguments" [1]:
> A double quotation mark preceded by a backslash (\") is
interpreted as a literal double quotation mark character (").
Perhaps I should have said unusual rather than non-standard. But
if you want to understand better what I mean, try doing this in
the command line, it works correctly:
cd \
mkdir test
cd test\
mkdir "..\second test\"
cd "..\second test\"
While it's true that you can also do this, it's not typical:
mkdir "\third test\\"
cd "\third test\\"
Re: Possible bug in std.path?
On Sunday, 19 June 2016 at 17:49:55 UTC, ag0aep6g wrote: I don't know if you can solve this with regex alone. May depend on what exact behavior you want. Maybe just write a little function instead that splits the command line, handling quotes and such as you want. If you're not comfortable writing this, then maybe you're in over your head here. Of course, all this wouldn't be necessary if you could change the command line instead to conform with the usual syntax. If the weird behavior you're going for is just personal preference, and there's no actual need, I'd suggest to just write the command lines in the normal way with escape sequences (i.e. "foo\\" to get a trailing backlash instead of a trailing quote). What you suggest is non-standard in Windows, and besides I might not be the only user of the application. I was thinking in doing pecisely what you suggest, writing a little function. I like programming little apps now and then as a hobby, but giving up every time I encounter a difficulty is not for me. I was just asking in case some of the experienced D programmer here could recommend an efficient and preferably simple way to do it. ;)
Re: Possible bug in std.path?
On Sunday, 19 June 2016 at 14:29:27 UTC, ag0aep6g wrote:
You're calling Windows' CommandLineToArgvW here. I don't think
that's what Adam meant by "process it yourself". If you don't
like how CommandLineToArgvW parses the command line, don't use
it.
What would be the efficient way to talke this then? I tried regex:
import std.stdio, std.file, std.path;
version (Windows) {
import core.sys.windows.windows, std.conv, std.regex;
pragma(lib, "shell32.lib");
}
enum EXIT_SUCCESS = 0;
enum EXIT_FAILURE = 1;
int main(string[] originalargs) {
string[] args;
version (Windows) {
SetConsoleOutputCP(65001);
static re = regex(`\s+`, "g");
auto wargs = GetCommandLineW();
if (wargs) {
args = split(text(wargs), re);
debug writefln("'%s'", text(wargs));
} else {
writeln("Error getting command line arguments.");
return EXIT_FAILURE;
}
} else args = originalargs;
foreach(uint i, string a; args) writefln("Argument %d: '%s'",
i, a);
return EXIT_SUCCESS;
}
However it doesn't quite work will all cases (besides I fear in
this case a regexp could offer an unnecessary entry point for an
exploit):
mytestapp dir1 ..\ "another dir\"
Argument 0: 'mytestapp'
Argument 1: 'dir1'
Argument 2: '..\'
Argument 3: '"another'
Argument 4: 'dir\"'
Re: Possible bug in std.path?
On Sunday, 19 June 2016 at 14:29:27 UTC, ag0aep6g wrote: [...] auto wargs = CommandLineToArgvW(GetCommandLineW(), ); You're calling Windows' CommandLineToArgvW here. I don't think that's what Adam meant by "process it yourself". If you don't like how CommandLineToArgvW parses the command line, don't use it. I thought the proper way to call GetCommandLineW was precisely through CommandLineToArgvW, now I am lost.
Re: Possible bug in std.path?
Further, notice what happens if I remove the buildNormalizedPath: mytestapp dir1 ..\ "another dir\" Argument 0: 'mytestapp ' Argument 1: 'dir' Argument 2: '..\' Argument 3: 'another dir"' Apparently the backslash is still being interpreted as an escape when followed by a double quote, even if the arguments come from GetCommandLineW.
Re: Possible bug in std.path?
On Friday, 20 May 2016 at 17:41:22 UTC, Adam D. Ruppe wrote:
[...]
Use GetCommandLine to fetch the original thing the user typed,
then process it yourself.
[...]
Then why doesn't the following code produce the expected output?
import std.stdio, std.file, std.path;
version (Windows) {
import core.sys.windows.windows, std.conv;
pragma(lib, "shell32.lib");
}
enum EXIT_SUCCESS = 0;
enum EXIT_FAILURE = 1;
int main(string[] originalargs) {
string[] args;
version (Windows) {
SetConsoleOutputCP(65001);
int wargc;
auto wargs = CommandLineToArgvW(GetCommandLineW(), );
if (wargs) {
for(uint i; i < wargc; i++) args ~=
buildNormalizedPath(text(wargs[i]));
} else {
writeln("Error getting command line arguments.");
return EXIT_FAILURE;
}
} else args = originalargs;
foreach(uint i, string a; args) writefln("Argument %d: '%s'",
i, a);
return EXIT_SUCCESS;
}
Test from Windows:
mytestapp dir1 dir2 "..\my parent dir\"
(all valid arguments)
Output:
Argument 0: 'mytestapp'
Argument 1: 'dir1'
Argument 2: 'dir2'
Argument 3: '..\my parent dir"'
Notice: I had to use std.conv from master branch because
otherwise text() wouldn't dereference wargs (of type wchar**).
PS. Please forgive me the delay.
Re: Possible bug in std.path?
On Friday, 20 May 2016 at 17:41:22 UTC, Adam D. Ruppe wrote: On Friday, 20 May 2016 at 15:18:39 UTC, Hugo wrote: On the other hand, regular console commands and many console applications for Windows work as expected, so there must be a way to deal with this properly It is pretty easy to handle, but must happen at a higher level than buildNormalizedPath. Use GetCommandLine to fetch the original thing the user typed, then process it yourself. https://msdn.microsoft.com/en-us/library/windows/desktop/ms683156%28v=vs.85%29.aspx But buildNormalizedPath cannot do this itself because its argument doesn't necessarily come from the command line. Your main() function could use it to get the string you pass to the other functions though. That's probably what most the Windows built in things do when they need to. Thank you all.
Re: Possible bug in std.path?
On Friday, 20 May 2016 at 03:40:23 UTC, Walter Bright wrote: On 5/19/2016 6:35 PM, Hugo wrote: I assumed the function would deal with the trailing backslash. And it can. It just never received a trailing backslash because that was removed by the Windows argument processing. Yes, I can see the problem. On the other hand, regular console commands and many console applications for Windows work as expected, so there must be a way to deal with this properly, and IMHO this would be usefull in buildNormalizedPath, instead of leaving the programmer the task to find a (perhaps sub-optimal) woraround.
Re: Possible bug in std.path?
On Thursday, 19 May 2016 at 22:44:06 UTC, Walter Bright wrote: On 5/19/2016 3:41 PM, Adam D. Ruppe wrote: So indeed, the OP stumbled upon a weird case of Windows command line, but it is really just this one weird case. It's not at all weird. It's just garden variety double quoted string behavior. Linux has its own quoting scheme on the command line, too. I must confess I was a bit misled then by this portion of the unittest: assert (buildNormalizedPath(`c:\foo\.\bar/..\\baz\`) == `c:\foo\baz`); Since I saw somewhere D could use different quoting styles, I assumed the function would deal with the trailing backslash.
Re: Possible bug in std.path?
On Thursday, 19 May 2016 at 05:06:44 UTC, Vladimir Panteleev wrote: Here you can see the final string value of the program argument in your program. The correct invocation is: mytest "my dir\\" What you suggest is non-standard in Windows, and would require distributing the application with some form of comment saying you have to use double backslashes, which is unprofessional. Software should serve the user and not the other way round. Notice I am not debating the escape character, but the inconsistency of buildNormalizedPath, which IMHO should have worked and fixed the trailing backslash. In the future, consider posting to the learn group. I did not post there because I thought this was not necessarily a newbie question. My apologies.
Possible bug in std.path?
I am having a problem on Windows with the following code:
module mytest;
import std.stdio, std.file, std.path;
enum EXIT_SUCCESS = 0;
enum EXIT_FAILURE = -1;
int main(string[] args) {
string appdir;
switch(args.length-1) {
case 0:
writeln("You must provide an argument with a valid
directory path.");
break;
case 1:
appdir = buildNormalizedPath(args[1]);
if(appdir.exists && appdir.isDir) break;
default:
writefln("Error: '%s' is not a valid directory path.",
appdir);
return EXIT_FAILURE;
}
writeln("OK");
return EXIT_SUCCESS;
}
Suppose I compiled this unit on current dir and then executed
these commands:
mkdir "my dir"
mytest "my dir\"
I should get "OK", but instead I get:
Error: 'my test"' is not a valid directory path.
If the trailing backslash is removed it works as intended, but
IMHO buildNormalizedPath should have worked.
In any case, notice the double quote in the output. To me this
suggests the backslash is acting not as a path terminator but as
an escape sequence.
Re: problems with std.bitmanip.append (bug?)
On Friday, 27 March 2015 at 08:43:56 UTC, John Colvin wrote: Think of it as compile-time arguments and run-time arguments. First set of parenthesis are compile-time, second are run-time. The parenthesis are optional for compile-time arguments iff there's only one of them. I really appreciate this little explanation, now it makes some sense.
Re: problems with std.bitmanip.append (bug?)
On Thursday, 26 March 2015 at 02:39:56 UTC, Steven Schveighoffer wrote: An array as an output range writes to the front. You can use std.array.Appender to get appending behavior. I know, it's weird. Alternatively, you can add more bytes to the array, and append to the slice, but that may be ugly/hard to do. -Steve Hmm... isnt that't what the std.bitmanip.write function is for? It even provides an index. I could make an 8 byte buffer and then make a slice with the last 4 bytes and use append there, but it would be rather a hack around something that should have worked. Perhaps I have found a bug. Actually I am not sure because I am not yet familiar with the way to use templates, so there is the possibility that I am using incorrect arguments. If only the documentation and/or test units were more clear...
Re: problems with std.bitmanip.append (bug?)
On Thursday, 26 March 2015 at 10:07:07 UTC, Hugo wrote:
If only the documentation and/or test units were more clear...
OK, I made a simpler test, using an example from the
documentation:
void main() {
import std.stdio, std.array, std.bitmanip;
auto buffer = appender!(const ubyte[])();
buffer.append!ushort(261);
assert(buffer.data == [1, 5]);
writefln(%s, buffer.data);
}
It seems to work, so apparently one has to explicitly create a
buffer with the appender template. Not terribly useful IMHO.
Wouldn't it be possible for the append function to automaticaly
change the mode of an already existing buffer?
Also, can anyone provide a similar example but using little
endian order? If only to contrast differences between modes of
invocation...
Re: problems with std.bitmanip.append (bug?)
On Thursday, 26 March 2015 at 12:29:03 UTC, John Colvin wrote:
On Thursday, 26 March 2015 at 12:21:23 UTC, Hugo wrote:
Also, can anyone provide a similar example but using little
endian order? If only to contrast differences between modes of
invocation...
void main() {
import std.stdio, std.array, std.bitmanip, std.system;
auto buffer = appender!(const ubyte[])();
buffer.append!(ushort, Endian.littleEndian)(261);
assert(buffer.data == [5, 1]);
writefln(%s, buffer.data);
}
Thanks, although it puzzles me that one has to move the type
inside the parenthesis and the value after them, otherwise it
doesn't compile.
It looks quite irregular, at least to someone like me, more used
to function than templates. :(
I wish one could simply append a buffer using the concatenation
operator, which would be the obvious choice, but it doesn't seem
to work for ubytes...
problems with std.bitmanip.append
Hi,
I need to append an uint as an array of ubytes (in little endian)
to an existing array of ubytes. I tried to compile this code
(with dmd 2.066.1 under Windows 7 x86-64):
void main() {
ubyte[] buffer = [0x1f, 0x8b, 0x08, 0x00];
import std.system;
import std.datetime : Clock, stdTimeToUnixTime;
import std.bitmanip : append;
buffer.append!ubyte(cast(uint)stdTimeToUnixTime(Clock.currStdTime),
Endian.littleEndian);
}
But it gives me this error: template std.bitmanip.append cannot
deduce function from argument types !(ubyte)(ubyte[], uint,
Endian)
Supposedly append Takes an integral value, converts it to the
given endianness, and appends it to the given range of ubytes
(using put) as a sequence of T.sizeof ubytes, so I thought I
could use it, but after reading the documentation page for the
function and the examples, I honestly can't understand where is
the problem is.
Please, help!
Regards, Hugo
Re: problems with std.bitmanip.append
On Wednesday, 25 March 2015 at 17:09:05 UTC, John Colvin wrote: As per the signature in the docs: void append(T, Endian endianness = Endian.bigEndian, R)(R range, T value) The endianness is the second template argument. What you need to write is buffer.append!(uint, Endian.littleEndian)(cast(uint)stdTimeToUnixTime(Clock.currStdTime)); or append!(uint, Endian.littleEndian)(buffer, cast(uint)stdTimeToUnixTime(Clock.currStdTime)); Note that you don't need to specify the third template argument, that will be inferred automatically from the type of `buffer` Hmm... the examples for append in the documentation look very different from the syntax you have suggested. No wonder. In any case, I have tried the code with the first way you suggested, and append actually does not append to the buffer, but... rewrites the buffer! Since the buffer is not static, shouldn't append actually do that?
