Re: Command Line Parsing
On Wednesday, 12 April 2017 at 09:51:34 UTC, Russel Winder wrote: Are Argon https://github.com/markuslaker/Argon or darg https://github. com/jasonwhite/darg getting traction as the default command line handling system for D or are they just peripheral and everyone just uses std.getopt https://dlang.org/phobos/std_getopt.html ? there is also Vladimir Panteleev's ae.funopt https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt/ https://github.com/CyberShadow/ae/blob/master/utils/funopt.d
Command Line Parsing
Are Argon https://github.com/markuslaker/Argon or darg https://github. com/jasonwhite/darg getting traction as the default command line handling system for D or are they just peripheral and everyone just uses std.getopt https://dlang.org/phobos/std_getopt.html ? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Command Line Parsing
On 12/04/2017 10:51 AM, Russel Winder via Digitalmars-d-learn wrote: Are Argon https://github.com/markuslaker/Argon or darg https://github. com/jasonwhite/darg getting traction as the default command line handling system for D or are they just peripheral and everyone just uses std.getopt https://dlang.org/phobos/std_getopt.html ? std.getopt is a little clunky, but it is what I would prefer most of the time. They are basically just different ways to do the same exact thing. So most of the time it is simply a preference thing.
Re: Command Line Parsing
On Wednesday, 12 April 2017 at 09:51:34 UTC, Russel Winder wrote:
Are Argon https://github.com/markuslaker/Argon or darg
https://github. com/jasonwhite/darg getting traction as the
default command line handling system for D or are they just
peripheral and everyone just uses std.getopt
https://dlang.org/phobos/std_getopt.html ?
std.getopt always, also since a few weeks i think that a better
version could be done. The expected options are defined in a
run-time parameters. This can definitively be some template
parameters, which would allow complex static checks and more
optimal code.
Now:
GetOptResult r = getopt(args, "o|option", , "p|param",
);
The future:
GetOptResult r = getopt!("o|option", o, "p|param",
param))(args);
Practical difference between template "alias" arguments/normal generic arguments in this case?
Hi!
With "alias this" accepting runtime variables I'm struggling to
understand the difference between a generic function with an
"alias this" parameter and another one with a "runtime" parameter
of template type.
Example:
// example code
import std.stdio: writeln;
void writevalue1(alias param)() { writeln(param); }
void writevalue2(T)(T param) { writeln(param); }
void main() {
import std.random: uniform;
auto someNum = uniform(0, 1000); // runtime value
writevalue1(someNum);
someNum = uniform(0, 1000);
writevalue2(someNum);
}
// example end -
Since both versions work with runtime values, what's are the
differences? When I should prefer one version over the other?
If objdump is not lying to me, both calls jump to the same
assembly and the only diffence is that the call to writevalue1
does a "mov -0x8(%rdi),%edi" just before the callq instruction.
Re: CTFE using of replaceAll from std.regex posible?
On Wednesday, 12 April 2017 at 12:00:27 UTC, Martin Tschierschke wrote: It there a way to use "replaceAll" at compile time? Regards mt. Not yet :) I assume it would bring the current system to it's needs. I you want to experiment you could replace malloc with new.
Re: ctfe append too slow, but can't speed up
On Tuesday, 11 April 2017 at 02:20:37 UTC, Jethro wrote: ctfe string appending is way to slow, I have tried the suggested methods and nothing works and slows down by at least an order of magnitude. I need a drop in replacement(no other changes) that can take over the duties of string and allow for memory reuse. reserve, cpacity, assumeSafeAppend cannot be used by ctfe so are useless. I've tried to shadow a pre-allocated buffer but that doens't work either. You can give me your code, and I'll see what has to be done to run it with newCTFE.
Re: Use of "T"
On Wednesday, 12 April 2017 at 13:54:11 UTC, qznc wrote: On Wednesday, 12 April 2017 at 13:17:42 UTC, solidstate1991 wrote: How can I make use of T? I've seen it being used many times for this application. What "T"? This letter is often used as a generic template parameter. Are you talking about templates? Maybe you can give some examples of the "many times" you have seen it used? Yes, templates. I've looked this up a bit, and I found it. I want to use it to use the dictionaries for different things than string<->int conversion. This should be the Dictionary(int), string<->string conversion should be done with Dictionary(string). Int<->string should be done as Dictionary(string,int) if possible.
Use of "T"
Some utilities of my game engine needs a two-way "dictionary", mainly for increasing the readability of configuration files, but I was thinking on letting the end-user to use it for certain things and I don't want to recreate the encode/decode/load from SDLang file functions every time I have to use a similar thing. Currently I need to use it for int<->string conversion only (key names, button names, axis names, etc.), in the future I might use it for even more purpose (language files are planned to use XML due to the possibility of using UTF16, as the engine's native character handling is using it, not to mention the easier formatting via markup). How can I make use of T? I've seen it being used many times for this application.
Re: Use of "T"
On Wednesday, 12 April 2017 at 13:17:42 UTC, solidstate1991 wrote: How can I make use of T? I've seen it being used many times for this application. What "T"? This letter is often used as a generic template parameter. Are you talking about templates? Maybe you can give some examples of the "many times" you have seen it used?
Re: Use of "T"
On Wednesday, 12 April 2017 at 14:46:20 UTC, solidstate1991 wrote: Yes, templates. I've looked this up a bit, and I found it. I want to use it to use the dictionaries for different things than string<->int conversion. T is just the common name of a (type) parameter, mostly whenever the template is more generic that you can't think of a more informative (template) parameter name. Just like you could use "str" for a string or "i" for an int name. But in you case you could use a more informative name such as "keyType" since you are describing keyType -> valueType dictionaries, also called associative arrays. Moreover these dictionaries are built-in basic types in D: https://dlang.org/spec/hash-map.html This should be the Dictionary(int), string<->string conversion should be done with Dictionary(string). Int<->string should be done as Dictionary(string,int) if possible. So according to the spec linked above, those examples would be declared: string[int] dict1; string[string] dict2; int[string] dict3;
CTFE using of replaceAll from std.regex posible?
Hello, when trying to process an string at compile time with ... auto reg = ctRegex!`as\ [a-z]+`; enum replaced = replaceAll(call,reg,""); I get: /usr/include/dmd/phobos/std/regex/package.d(708,34): Error: malloc cannot be interpreted at compile time, because it has no available source code /usr/include/dmd/phobos/std/regex/package.d(708,27): called from here: enforce(malloc(size), delegate const(char)[]() => "malloc failed", "/usr/include/dmd/phobos/std/regex/package.d", 708LU) /usr/include/dmd/phobos/std/regex/package.d(832,34): called from here: ((RegexMatch!(string, BacktrackingMatcher) __slRegex3165 = RegexMatch(BacktrackingMatcher(Regex(null, null, null, 0u, 0u, 0u, 0u, 0u, null, null, null, ShiftOr(null, 0u, 0u)), null, Input(null, 0LU), 0LU, '\U', false, 0u, 0u, 0LU, null, null, null, null), null, Captures(null, 0, null, , 0u, 0u, 0u, null), null);) , __slRegex3165).this(input, re) /usr/include/dmd/phobos/std/regex/package.d(1049,48): called from here: matchMany(input, re) /usr/include/dmd/phobos/std/regex/package.d(906,26): called from here: matchAll(input, re) /usr/include/dmd/phobos/std/regex/package.d(1345,69): called from here: replaceAllWith(input, re) src/app.d(13,29):called from here: replaceAll(call, reg, "") It there a way to use "replaceAll" at compile time? Regards mt.
Re: Practical difference between template "alias" arguments/normal generic arguments in this case?
On Wednesday, 12 April 2017 at 11:06:13 UTC, Juanjo Alvarez wrote:
Hi!
With "alias this" accepting runtime variables I'm struggling to
FYI, you are not talking about "alias this", but "alias template
parameters", two very different concepts.
understand the difference between a generic function with an
"alias this" parameter and another one with a "runtime"
parameter of template type.
Example:
// example code
import std.stdio: writeln;
void writevalue1(alias param)() { writeln(param); }
void writevalue2(T)(T param) { writeln(param); }
void main() {
import std.random: uniform;
auto someNum = uniform(0, 1000); // runtime value
writevalue1(someNum);
someNum = uniform(0, 1000);
writevalue2(someNum);
}
// example end -
Since both versions work with runtime values, what's are the
differences? When I should prefer one version over the other?
Neither template cares or knows anything about runtime values.
When the compiler encounters them, it instantiates an instance of
each by creating functions that work with runtime values. But it
does so differently for each.
In your instantiation of writevalue1, you are passing the symbol
"someNum" as an alias template parameter. This instantiation will
only ever be used with "someNum". If you pass it a different
symbol, you'll get a separate instantiation, even if it has the
same type as "someNum".
In your instantiation of writevalue2, you are getting a function
that takes a single argument of `typeof(someNum)`. This
instantiation will be used for any value you pass to it that has
the same type.
If you're only interested in the value of a variable, you almost
certainly want to use template type parameters most of the time,
especially if you are going to be calling the function with
multiple variables. That way, variables of the same type all have
one instantiation and you avoid bloat.
Use alias parameters when you actually care about the *symbol*
and not the value.
Re: Practical difference between template "alias" arguments/normal generic arguments in this case?
On Wednesday, 12 April 2017 at 11:06:13 UTC, Juanjo Alvarez wrote:
Hi!
With "alias this" accepting runtime variables I'm struggling to
understand the difference between a generic function with an
"alias this" parameter and another one with a "runtime"
parameter of template type.
Example:
// example code
import std.stdio: writeln;
void writevalue1(alias param)() { writeln(param); }
void writevalue2(T)(T param) { writeln(param); }
void main() {
import std.random: uniform;
auto someNum = uniform(0, 1000); // runtime value
writevalue1(someNum);
someNum = uniform(0, 1000);
writevalue2(someNum);
}
// example end -
Since both versions work with runtime values, what's are the
differences? When I should prefer one version over the other?
If objdump is not lying to me, both calls jump to the same
assembly and the only diffence is that the call to writevalue1
does a "mov -0x8(%rdi),%edi" just before the callq instruction.
(As noted by Mike the examples you present are actually template
alias parameters, not alias this which affects name lookup.)
There are three kinds of template parameters types, values and
aliases.
I assume you understand what the first two _do_ in terms of
parameterisation.
Alias parameters are for symbols, and are used generally when the
thing you want to template on not a value or a type (although
alias parameters can accept anything).
These typically include lambdas e.g. the predicate to
std.algorithm.filter or the transformation to std.algorithm.map,
(global) variables to do introspection (for e.g. logging).
Re: Practical difference between template "alias" arguments/normal generic arguments in this case?
Thanks to both, I got it. Type templates for generic types, and alias for other things knowing that the instantiation is by symbol. Yes, the "alias this" in my message was a (double) brainfart, I actually wanted to write "alias template". In this case both functions had the same assembler body which was part of what had me confused but I guess that's a compiler optimization.
Re: warning: pointer not aligned at address
On Wednesday, 12 April 2017 at 03:18:32 UTC, Matt Whisenhunt wrote: ld: warning: pointer not aligned at address 0x100050C7D Are you running macOS and recently installed an update to Xcode? I ran into this today as well. Looks like other have too: https://issues.dlang.org/show_bug.cgi?id=17289 Yes, I do indeed use macOS and am on the latest version. I spun up a Ubuntu vm and in works correctly there. Thanks.
ctRegex with variable?
Can regex's have variables in them? I'd like to create a ctRegex
but match on runtime strings that are known at runtime.
e.g.,
auto c = ctRegex~("x{var}")
where var is a variable that is passed at runtime. e.g., match(s,
c, "test") will replace var with test.
The reason is I basically have the same regex to match but each
one differs in a specific way. It would be nice to be able to use
a fast way to search since most of the regex is the same but only
the a single token differs(and these tokens are only known at
runtime).
I obviously can build the regex string at runtime like
auto var = "test"
auto c = Regex("x{"~var~"}");
or whatever... but this is much slower when only var changes.
Re: Use of "T"
On Wednesday, 12 April 2017 at 16:05:23 UTC, XavierAP wrote: On Wednesday, 12 April 2017 at 14:46:20 UTC, solidstate1991 wrote: T is just the common name of a (type) parameter, mostly whenever the template is more generic that you can't think of a more informative (template) parameter name. Just like you could use "str" for a string or "i" for an int name. But in you case you could use a more informative name such as "keyType" since you are describing keyType -> valueType dictionaries, also called associative arrays. Moreover these dictionaries are built-in basic types in D: https://dlang.org/spec/hash-map.html So according to the spec linked above, those examples would be declared: string[int] dict1; string[string] dict2; int[string] dict3; I know the existence of those and I'm frequently using them, however I need a two-way one. (Might be using two hash-tables instead if I can't find a better solution)
Re: ctRegex with variable?
On 04/12/2017 02:25 PM, Jethro wrote:
Can regex's have variables in them? I'd like to create a ctRegex but
match on runtime strings that are known at runtime.
e.g.,
auto c = ctRegex~("x{var}")
where var is a variable that is passed at runtime. e.g., match(s, c,
"test") will replace var with test.
Sounds reasonable but the string would have to be constructed each time
match is called. It could reuse the same buffer... So, one needs to
profile to see how it performs and we expect you to implement and test
it please. ;)
Ali
Re: Use of "T"
On Wednesday, 12 April 2017 at 22:56:25 UTC, solidstate1991 wrote: I know the existence of those and I'm frequently using them, however I need a two-way one. (Might be using two hash-tables instead if I can't find a better solution) So, you're looking for a generic way to store objects of arbitrary types in a file, and later retrieve those objects from that file? If that's the case, try looking at some existing serialization solutions (i.e. https://wiki.dlang.org/Serialization_Libraries).
