Re: if auto and method call
On 04/18/2017 02:48 AM, Jethro wrote:
I generally need this for regex stuff and it's quite annoying it doesn't
work.
if (!match(s, "\s*(?P.),").empty())
{
// Need the result of match to do things!
}
but this doesn't work:
if (!(auto r = match(s, "\s*(?P.),")).empty())
{
}
Stanislav Blinov has shown how overloading `cast(bool)` can help here.
In fact, std.regex.RegexMatch does just that. So this works:
if (auto r = match(s, "\s*(?P.),"))
{
/* ... use r here ... */
}
Re: Generating switch at Compile Time
On Thursday, 13 April 2017 at 21:06:52 UTC, Jesse Phillips wrote:
I realize that this is likely really pushing the compile time
generation but a recent change to the switch statement[1] is
surfacing because of this usage.
uninitswitch2.d(13): Deprecation: 'switch' skips declaration of
variable uninits
witch2.main.li at uninitswitch2.d(14)
-
import std.traits;
import std.typecons;
import std.meta;
private static immutable list = AliasSeq!(
tuple("a", "q"),
tuple("b", "r"),
);
void main() {
import std.stdio;
string search;
switch(search) {
--->foreach(li; list) { // li initialization is skipped
mixin("case li[0]:");
mixin("writeln(li[1]);");
return;
}
default:
break;
}
// Works
mixin(genSwitch("search"));
}
-
I realize I can build out the entire switch and mix it in:
-
string genSwitch(string search) {
auto ans = "switch(" ~ search ~ ") {\n";
foreach(li; list) {
ans ~= "case \"" ~ li[0] ~ "\":\n";
ans ~= "writeln(\"" ~ li[1] ~ "\");\n";
ans ~= "return;\n";
}
ans ~= "default:\n";
ans ~= "break;\n";
ans ~= "}";
return ans;
}
-
But I'm just wondering if the new initialization check should
not be triggered from this utilization.
-
// Unrolled based on
//
https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time description
version(none)
void func2243(Tuple param0, Tuple param1) {
{
{
case param0[0]:
writeln(param0[1]);
return;
}
{
case param1[0]:
writeln(param1[1]);
return;
}
}
}
-
Thoughts?
1. https://issues.dlang.org/show_bug.cgi?id=14532
This is what is generated by your example:
switch (search)
{
unrolled {
{ // does not actually open a new scope
immutable
immutable(Tuple!(string, string)) li = __list_field_0;
case "a":
{
}
writeln(li.__expand_field_1);
return 0;
}
{ // same here we do not actually open a
new scope.
immutable
immutable(Tuple!(string, string)) li = __list_field_1;
case "b":
{
}
writeln(li.__expand_field_1);
return 0;
}
}
default:
{
break;
}
}
return 0;
it should be clear to sww why li's initialisation is referred to
as skipped.
Re: SFML gcc - MacOS
On Monday, 17 April 2017 at 08:48:06 UTC, Jacob Carlborg wrote: On 2017-04-16 10:11, Joel wrote: I've got Xcode, do I enter `xcode-select --install` in the terminal? Yes. That will get you access to Clang, the linker and other tools on the command line. It will also create /usr/include needed to build C/C++ code from the command line. Thanks Jacob.
Re: if auto and method call
Would be prettier as a language feature, but still:
template test(alias pred)
{
import std.functional : unaryFun;
alias P = unaryFun!pred;
auto test(R)(R r)
{
struct Test
{
R v;
string toString()
{
import std.conv : to;
return v.to!string;
}
bool opCast(B : bool)() const
{
return P(v);
}
ref inout(R) get() inout
{
return v;
}
alias get this;
}
import std.algorithm : move;
return Test(move(r));
}
}
void main()
{
import std.regex;
import std.stdio;
string s1 = "hello";
string s2 = "world";
if (auto x = test!"!a.empty"(match(s1, "hello")))
{
writeln(x.captures[0]);
}
if (auto x = test!"!a.empty"(match(s2, "hello")))
{
writeln(x.captures[0]);
assert(0);
}
// UFCS:
if (auto x = s1.match("world").test!"!a.empty")
{
writeln(x.captures[0]);
assert(0);
}
if (auto x = s2.match("world").test!"!a.empty")
{
writeln(x.captures[0]);
}
if (auto x = 3.test!"a == 3")
{
writeln(x, " equals 3, huh?");
}
}
Re: Recently added __equal
On Monday, 17 April 2017 at 19:15:06 UTC, Nordlöw wrote: What's the plan for the recent adding __equal overloads at https://github.com/dlang/druntime/pull/1808/files Is it only meant for runtime and phobos to be updated? Or does user-libraries, such as container libraries, need to be updated aswell? __equal is never really mean to be called directly. It's a druntime template that will be used via inserted calls with the complier front end when array comparisons are used.
if auto and method call
How to combine the need to localize a result for an if statement
and have to call a method to get proper comparison:
if (((auto x = X.value()).empty())
{
}
instead of having to do the long and winded way
auto x = X.value();
if (x.empty())
{
}
Many times I need the result of a function inside the if but need
to check on other value of the function:
auto x = foo();
if (foo().valid())
{
// use x
}
which should simplify to
if ((auto x = foo()).valid())
{
}
but this code does not work.
I generally need this for regex stuff and it's quite annoying it
doesn't work.
if (!match(s, "\s*(?P.),").empty())
{
// Need the result of match to do things!
}
but this doesn't work:
if (!(auto r = match(s, "\s*(?P.),")).empty())
{
}
which then requires one to do
auto r = match(s, "\s*(?P.),");
if (!r.empty())
{
}
Doesn't seem like a big deal but seems trivial to implement. We
can't always do a simple boolean test of the variable we are
defining:
if (auto x = something)
so we should be able to do
if ((auto x = something).bar())
which is equivalent to
x = something;
if (x.bar())
or even allow
if ((auto x = something) == 3)
{
}
Re: Recently added __equal
On Monday, 17 April 2017 at 19:15:06 UTC, Nordlöw wrote: What's the plan for the recent adding __equal overloads at https://github.com/dlang/druntime/pull/1808/files Is it only meant for runtime and phobos to be updated? Or does user-libraries, such as container libraries, need to be updated aswell? Well considering that they are templates in druntime, you will need to recompile your code (and any 3rd party code) against the new druntime, with a recent dmd (don't think ldc has the updates yet).
Re: Stuck with DMD, and Unit-Threaded
On Sunday, 16 April 2017 at 08:20:21 UTC, Russel Winder wrote: There are points when you need to ask someone for help… I am trying to get Dub to build integration tests from test-source as a separate thing from building unit tests from source. The latter is easy and works, as does building the application. I cannot however get the integration tests to build, I always get something along the lines of: ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(10,12): Error: function D main conflicts with static import dub_test_root.main at ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(3,15) and I haven't a clue. This is almost certainly just a bad dub.sdl file, but, if anyone can take a look at tell me what I am failing to get right, I'd appreciate it. https://github.com/russel/ApproxGC https://github.com/russel/ApproxGC/pull/2 Unfortunately the auto generated integration test main file doesn't quite work (feel free to file a bug on unit-threaded) so in that PR I disabled auto-generating it and force added my edited version. What I did there in dub.sdl is my current go-to solution for also running integration tests with unit-threaded. Atila
Re: Generating switch at Compile Time
On 04/17/2017 09:29 PM, Jesse Phillips wrote:
On Thursday, 13 April 2017 at 21:33:28 UTC, ag0aep6g wrote:
[...]
By the way, in my opinion, `case li[0]:` shouldn't compile with the
static immutable `list`. `list` and `li[0]` are dynamic values. The
compiler only attempts (and succeeds) to evaluate them at compile time
because they're typed as immutable. The way I see it, that only makes
things more confusing.
This is very interesting. I wonder if the compiler is still unrolling
the loop at compile time since it functions as expected; It certainly
needs that deprecation though.
It's really weird. I thought the loop would just not be unrolled at all.
However, both `case`s seem to be generated as expected. So it behaves
like a static foreach in that regard. But when you use `li` as a dynamic
value (e.g. `writeln(li[1])`), it's suddenly empty. Seems that dmd can't
decide what to do, so it does a little bit of both.
Maybe I was wrong, and the loop in your code is a static foreach, but at
some point there's a bug that makes dmd think it's dealing with run-time
values.
The behavior is also completely inconsistent.
With ints, the program compiles and the assert passes:
alias AliasSeq(stuff ...) = stuff;
immutable list = AliasSeq!(1, 2);
void main()
{
switch(1)
{
foreach(li; list)
{
case li: enum e = li; assert(e == li); return;
}
default:
}
}
With strings, the program doesn't compile:
alias AliasSeq(stuff ...) = stuff;
immutable list = AliasSeq!("foo", "bar");
void main()
{
switch("foo")
{
foreach(li; list)
{
case li: enum e = li; assert(e == li); return;
/* "Error: case must be a string or an integral constant, not li" */
}
default:
}
}
And with structs (your case), it compiles with a deprecation warning and
behaves schizophrenically:
alias AliasSeq(stuff ...) = stuff;
struct S { int x; }
immutable list = AliasSeq!(S(1), S(2));
void main()
{
switch(1)
/* Deprecation: 'switch' skips declaration of variable */
{
foreach(li; list)
{
case li.x: enum e = li; assert(e == li); return;
/* The assert fails. */
}
default:
}
}
In my opinion, they should all simply be rejected. But I have no idea
what's intended by the compiler writers. It's a mess.
With enum/alias, they all compile and work as expected, of course.
Re: Empty Result
On 04/17/2017 12:33 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Mon, Apr 17, 2017 at 12:05:19PM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
[...]
auto byNode(const(Tree) tree) {
alias RangeType = typeof(byNode(tree.root));
Could this possibly be simplified to:
alias RangeType = typeof(return);
?
Thank you. That's much better but only if I restructure the code to use
an if statement:
auto byNode(const(Tree) tree) {
if (tree.root) {
return byNode(tree.root);
}
else {
alias RangeType = typeof(return);
return new RangeType(() {});
}
}
That works because the return type of the function is the first return
statement. (My original code had only one return and that was the problem.)
Ali
Re: refRange with non copyable struct
On Monday, April 17, 2017 19:39:25 Stanislav Blinov via Digitalmars-d-learn wrote: > On Monday, 17 April 2017 at 19:00:44 UTC, Jonathan M Davis wrote: > > Because otherwise, it's not acting like a reference to the > > original range, which is the whole point of RefRange. The > > correct solution would probably be to @disable opAssign in the > > case where the original range can't be overwritten by another > > range. > > This doesn't look quite right. References in D are rebindable. > That is, assigning a reference to a reference does not copy > referenced object, only the reference itself. > It seems that RefRange is trying to impersonate a C++ reference. The term reference in D is a bit overloaded. The whole point of RefRange is to have the original range affected by everything that happens to the new range as if it were the original range - which is what happens with ref (which is not rebindable) except that ref only works on parameters and return types. So, yes, it is similar to a C++ reference. It's not trying to be a pointer, which is more like what a class reference is. - Jonathan M Davis
Re: Empty Result
On Mon, Apr 17, 2017 at 12:05:19PM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
[...]
> auto byNode(const(Tree) tree) {
> alias RangeType = typeof(byNode(tree.root));
Could this possibly be simplified to:
alias RangeType = typeof(return);
?
Or does that cause a circular dependency that makes the compilation
fail?
> return (tree.root
> ? byNode(tree.root)
> : new RangeType(() {}));// ← Empty range
> }
[...]
T
--
WINDOWS = Will Install Needless Data On Whole System -- CompuMan
Re: refRange with non copyable struct
On Monday, 17 April 2017 at 19:00:44 UTC, Jonathan M Davis wrote: Because otherwise, it's not acting like a reference to the original range, which is the whole point of RefRange. The correct solution would probably be to @disable opAssign in the case where the original range can't be overwritten by another range. This doesn't look quite right. References in D are rebindable. That is, assigning a reference to a reference does not copy referenced object, only the reference itself. It seems that RefRange is trying to impersonate a C++ reference.
Re: Generating switch at Compile Time
On Thursday, 13 April 2017 at 21:33:28 UTC, ag0aep6g wrote: That's not a static foreach. It's a normal run-time foreach. The switch jumps into the loop body without the loop head ever executing. The compiler is correct when it says that initialization of li is being skipped. Good good. I did miss that as I was trying different things. Make `list` an enum or alias instead. Then the foreach is unrolled at compile time, you don't get a deprecation message, and it works correctly. Yes it did. By the way, in my opinion, `case li[0]:` shouldn't compile with the static immutable `list`. `list` and `li[0]` are dynamic values. The compiler only attempts (and succeeds) to evaluate them at compile time because they're typed as immutable. The way I see it, that only makes things more confusing. This is very interesting. I wonder if the compiler is still unrolling the loop at compile time since it functions as expected; It certainly needs that deprecation though.
Recently added __equal
What's the plan for the recent adding __equal overloads at https://github.com/dlang/druntime/pull/1808/files Is it only meant for runtime and phobos to be updated? Or does user-libraries, such as container libraries, need to be updated aswell?
Re: Empty Result
On 04/17/2017 11:30 AM, Russel Winder via Digitalmars-d-learn wrote:
I find myself in need of constructing an empty Result object. I tried
takeNone!Result, but obviously the type Result doesn't appear to exist.
Anyone any ideas?
(Not a complete solution; just sharing your pain.)
I had the same problem here:
http://ddili.org/ders/d.en/fibers.html#ix_fibers.Generator,%20std.concurrency
The solution I could use there is less than ideal and may not apply in
all cases. I used typeof and was able to satisfy it with an empty delegate:
/* Returns an InputRange to the nodes of the tree. The
* returned range is empty if the tree has no elements (i.e.
* if 'root' is 'null'). */
auto byNode(const(Tree) tree) {
alias RangeType = typeof(byNode(tree.root));
return (tree.root
? byNode(tree.root)
: new RangeType(() {}));// ← Empty range
}
Ali
Re: refRange with non copyable struct
On Monday, April 17, 2017 18:45:46 Jerry via Digitalmars-d-learn wrote: > On Monday, 17 April 2017 at 18:07:36 UTC, Jonathan M Davis wrote: > > In this particular case, it looks like the main problem is > > RefRange's opAssign. For it to work, the type needs to be > > copyable. It might be reasonable for RefRange to be enhanced so > > that it doesn't compile in opAssign if the range isn't > > copyable, but I'd have to study RefRange in depth to know what > > the exact consequences of that would be, since it's been quite > > a while since I did anything with it. My guess is that such a > > change would be reasonable, but I don't know without studying > > it. > > > > - Jonathan M Davis > > I took a look on RefRange and the reasoning is clearly explained > in the docs like this: > > This does not assign the pointer of $(D rhs) to this $(D > RefRange). > Rather it assigns the range pointed to by $(D rhs) to the range > pointed > to by this $(D RefRange). This is because $(I any) operation on a > RefRange) is the same is if it occurred to the original range. The > exception is when a $(D RefRange) is assigned $(D null) either > or because $(D rhs) is $(D null). In that case, $(D RefRange) > longer refers to the original range but is $(D null). > > > > But what I do not understand is why this is important. Because otherwise, it's not acting like a reference to the original range, which is the whole point of RefRange. The correct solution would probably be to @disable opAssign in the case where the original range can't be overwritten by another range. - Jonathan M Davis
Re: refRange with non copyable struct
On Monday, 17 April 2017 at 18:07:36 UTC, Jonathan M Davis wrote: In this particular case, it looks like the main problem is RefRange's opAssign. For it to work, the type needs to be copyable. It might be reasonable for RefRange to be enhanced so that it doesn't compile in opAssign if the range isn't copyable, but I'd have to study RefRange in depth to know what the exact consequences of that would be, since it's been quite a while since I did anything with it. My guess is that such a change would be reasonable, but I don't know without studying it. - Jonathan M Davis I took a look on RefRange and the reasoning is clearly explained in the docs like this: This does not assign the pointer of $(D rhs) to this $(D RefRange). Rather it assigns the range pointed to by $(D rhs) to the range pointed to by this $(D RefRange). This is because $(I any) operation on a RefRange) is the same is if it occurred to the original range. The exception is when a $(D RefRange) is assigned $(D null) either or because $(D rhs) is $(D null). In that case, $(D RefRange) longer refers to the original range but is $(D null). But what I do not understand is why this is important.
Re: refRange with non copyable struct
On Monday, 17 April 2017 at 18:07:36 UTC, Jonathan M Davis wrote: Non-copyable types tend to wreak havoc with things - Jonathan M Davis Basicly what I use this for is to combine RAII with ranges. Which I find quite useful when doing DB queries and the data is lazily fetched since this allows me to guarantee that the query is "closed" and another query can take place.
Empty Result
I find myself in need of constructing an empty Result object. I tried takeNone!Result, but obviously the type Result doesn't appear to exist. Anyone any ideas? -- 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: refRange with non copyable struct
On Monday, April 17, 2017 17:23:32 Jerry via Digitalmars-d-learn wrote:
> Hello guys, so I wanted to have a noncopyable range on the stack.
> So my thoughts was to make it non copyable and use refRange
> whenever I want to use it with map and others.
>
> But I got a compiler warning when doing so like this:
>
> import std.range;
>
> void main() {
> NonCopyable v;
>
> refRange();
> }
>
> struct NonCopyable
> {
> @disable this(this);
>
> int data;
>
> enum empty = false;
> void popFront() {}
> int front() { return data; }
> }
>
>
>
>
>
> With the error message:
>
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(8941):
> Error: struct reproduction.NonCopyable is not copyable because it
> is annotated with @disable
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(8982):
> Error: mutable method reproduction.NonCopyable.front is not
> callable using a const object
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(9649):
> Error: template instance std.range.RefRange!(NonCopyable) error
> instantiating
> reproduction.d(6):instantiated from here:
> refRange!(NonCopyable)
>
>
>
>
> Is there any workaround?
> Is this a bug?
Well, I don't think that much range-based code in general is going to work
with a disabled postblit constructor, and it's not something that's
generally tested for unless someone is specifically trying to use such a
type with a specific piece of code. Non-copyable types tend to wreak havoc
with things - not that they shouldn't necessarily work, but most stuff tends
to assume that types are copyable, and supporting non-copyable often
complicates things quite a bit. Most of Phobos simply hasn't been tested
with non-copyable types even if the functionality in question should
arguably work with them.
In this particular case, it looks like the main problem is RefRange's
opAssign. For it to work, the type needs to be copyable. It might be
reasonable for RefRange to be enhanced so that it doesn't compile in
opAssign if the range isn't copyable, but I'd have to study RefRange in
depth to know what the exact consequences of that would be, since it's been
quite a while since I did anything with it. My guess is that such a change
would be reasonable, but I don't know without studying it.
- Jonathan M Davis
Re: Stuck with DMD, and Unit-Threaded
On Mon, 2017-04-17 at 11:03 +0200, Jacob Carlborg via Digitalmars-d- learn wrote: Thanks for the pointers to the example, I shall peruse. I now have the SCons build working fine (OK so there are bugs in the application code highlighted by the integration test bugs), so the D code is not wrong. The fact I cannot get a Dub build is clearly to do with my dub.sdl (most likely), or Dub is doing something wrong (highly unlikely I would guess, but…) -- 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
refRange with non copyable struct
Hello guys, so I wanted to have a noncopyable range on the stack.
So my thoughts was to make it non copyable and use refRange
whenever I want to use it with map and others.
But I got a compiler warning when doing so like this:
import std.range;
void main() {
NonCopyable v;
refRange();
}
struct NonCopyable
{
@disable this(this);
int data;
enum empty = false;
void popFront() {}
int front() { return data; }
}
With the error message:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(8941):
Error: struct reproduction.NonCopyable is not copyable because it
is annotated with @disable
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(8982):
Error: mutable method reproduction.NonCopyable.front is not
callable using a const object
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(9649):
Error: template instance std.range.RefRange!(NonCopyable) error
instantiating
reproduction.d(6):instantiated from here:
refRange!(NonCopyable)
Is there any workaround?
Is this a bug?
Re: hidden passing of __FILE__ and __LINE__ into function
On Monday, 17 April 2017 at 14:23:50 UTC, Jonathan M Davis wrote: So, if you're okay with explicitly instantiating your variadic function template instead of having the types inferred, then it Yes, it's my case. That's a game engine, so some kilobytes isn't a problem. Moreover, possible that function will be used only in debug mode. Thank you for explaining, I appreciate it.
Re: hidden passing of __FILE__ and __LINE__ into function
On Monday, April 17, 2017 13:45:18 Dmitry via Digitalmars-d-learn wrote:
> On Monday, 17 April 2017 at 10:55:30 UTC, Jonathan M Davis wrote:
> > They works, but it results in a new template being instantiated
> > for every call, so you really shouldn't use __FILE__ or
> > __LINE__ as template arguments if you can avoid it.
>
> Does it matter if I anyway use template (S...) ?
> And what problem with that new templates for every call?
> Increases .exe size? Needs more memory (runtime? compile-time?)?
> Something else?
Every time there's a new template instantiation, it's essentially
copy-pasting the entire template. So, if you have the templated function
auto foo(T)(T bar)
{
return bar;
}
and then call
foo(5);
foo(true);
foo("hello");
then you get the equivalent of
int foo!int(int bar)
{
return bar;
}
bool foo!bool(bool bar)
{
return bar;
}
string foo!string(string bar)
{
return bar;
}
in your program. If you have
string foo(string file = __FILE__, size_t line = line)(string bar)
{
return bar;
}
and you call that function 17 times, then you get 17 separate functions. If
you call it 120 times you get 120 separate functions. So, if you call the
function very many times, the template bloat would be enormous. The
executable will be _much_ larger and will thus take up much more space on
disk and much more RAM when it's loaded into memory. In some cases, that
makes sense, but it usually doesn't.
> > Usually, the better way to handle it is to use runtime
> > arguments, e.g.
> > void error(string msg, string file = __FILE__, size_t line =
> > __LINE__)
>
> Is possible use this with (S...)? In some cases I use many
> arguments (5-10, mixed strings and numbers) and I tried to avoid
> the concatenation them into string.
>
> What will be better? Concatenation or templates? Or maybe an
> another way?
The short answer is that if you're using variadic templates, you can't use
default arguments. Something like
auto foo(Args...)(Args args, string file = __FILE__, size_t line = __LINE__)
{
...
}
auto result = foo("hello", 42);
does not work. So, if you want to have the file and line number passed
automatically with a variadic template, then you're forced to use template
parameters instead of function paramaters and incur whatever bloat that goes
with that.
Now, that being said, surprisingly, it does look like it works to do
auto foo(Args...)(Args args, string file = __FILE__, size_t line = __LINE__)
{
...
}
auto result = foo!(string, int)("hello", 42);
So, if you're okay with explicitly instantiating your variadic function
template instead of having the types inferred, then it can work, but
otherwise, no. Making it work would require a language enhancement, and even
then, if you ever wanted to explicitly provide the file and line number
arguments instead of using the default arguments, you'd almost certainly be
forced to explicitly instantiate the template, since the compiler would have
no other way of determining whether the file and line arguments on the end
were intended to be the file and line arguments or just more variadic
arguments.
- Jonathan M Davis
Re: Can't pass data from filter to each
On Monday, 17 April 2017 at 10:02:22 UTC, Suliman wrote:
New question. Can I put result of filtering in itself without
creation of new variables like x:
auto x =
MySQLTablesRange.array.filter!(a=>a[0].coerce!string.canFind("_"));
No. filter is simply a wrapper around the source range, it does
not modify it.
As for the problems you are having with ranges seeming empty,
they are all due to the fact that the ResultRange in mysql-native
isn't designed to support such chaining of calls. It's probably
best to first exhaust a ResultRange and put it into an array.
Re: hidden passing of __FILE__ and __LINE__ into function
On Monday, 17 April 2017 at 10:55:30 UTC, Jonathan M Davis wrote: They works, but it results in a new template being instantiated for every call, so you really shouldn't use __FILE__ or __LINE__ as template arguments if you can avoid it. Does it matter if I anyway use template (S...) ? And what problem with that new templates for every call? Increases .exe size? Needs more memory (runtime? compile-time?)? Something else? Usually, the better way to handle it is to use runtime arguments, e.g. void error(string msg, string file = __FILE__, size_t line = __LINE__) Is possible use this with (S...)? In some cases I use many arguments (5-10, mixed strings and numbers) and I tried to avoid the concatenation them into string. What will be better? Concatenation or templates? Or maybe an another way?
Re: check Input
thank you all! i will try
Re: check Input
On Monday, 17 April 2017 at 11:51:45 UTC, dennis wrote: Hi, try to build a little programm, but need to know how to check the input. For example: input only numbers: 0 - 9 but 1.5 for example is ok. thanks I will point you to Ali's book (free), it goes through the basics of input and output. http://ddili.org/ders/d.en/index.html It is better for you to discover, however don't be afraid to ask if you get stuck.
Re: check Input
On Monday, 17 April 2017 at 11:51:45 UTC, dennis wrote:
Hi,
try to build a little programm, but need to know
how to check the input.
For example: input only numbers: 0 - 9 but 1.5 for example is
ok.
thanks
How I would do it:
Run a loop, checking if the characters in input are within the
range (i.e 0-9 and '.' character)
import std.stdio;
import std.conv : to;
import std.algorithm : canFind;
private bool isNum(string s){
bool r=true;
uinteger i;
for (i=0;i 0 && f < 9){
writeln("Number is in range");
}else{
writeln("Out of range");
}
}
}
check Input
Hi, try to build a little programm, but need to know how to check the input. For example: input only numbers: 0 - 9 but 1.5 for example is ok. thanks
Re: Can't build simple project. Very strange errors
On Friday, 14 April 2017 at 15:53:18 UTC, Rene Zwanenburg wrote: On Friday, 14 April 2017 at 15:42:33 UTC, Suliman wrote: On Friday, 14 April 2017 at 15:40:18 UTC, Rene Zwanenburg wrote: On Friday, 14 April 2017 at 15:31:21 UTC, Suliman wrote: On Friday, 14 April 2017 at 15:22:49 UTC, Rene Zwanenburg wrote: On Friday, 14 April 2017 at 09:49:09 UTC, Suliman wrote: on: dub build --compiler=ldc2 link OPTLINK (R) for Win32 Release 8.00.17 Optlink isn't able to link object files produced by ldc. Could you try an x64_86 build? You'll need the Microsoft linker. I do not have VS on my PC :( You don't need VS, the Windows SDK should be fine too. It's a free download :) How to check if it's installed and how to use linker from it? If it's installed you can find it in the programs and features list as 'Windows Software Development Kit for Windows X'. The DMD installer will look for it during installation, so reinstalling DMD after installing the SDK should work. I'm not sure how LDC does it, but last time I installed LDC it also just worked. I checked, it's installed. I reinstall dmd, but got same error with linker.
Re: hidden passing of __FILE__ and __LINE__ into function
On Monday, April 17, 2017 10:58:36 Basile B. via Digitalmars-d-learn wrote:
> On Monday, 17 April 2017 at 10:55:30 UTC, Jonathan M Davis wrote:
> > On Monday, April 17, 2017 10:30:35 Basile B. via
> >
> > Digitalmars-d-learn wrote:
> >> On Monday, 17 April 2017 at 10:22:47 UTC, Dmitry wrote:
> > void error(string msg, string file = __FILE__, size_t line =
> > __LINE__)
> > {
> >
> > ...
> >
> > }
> >
> > That's what Exception's constructor does as well as functions
> > like std.exception.enforce.
> >
> > - Jonathan M Davis
>
> I didn't know that this also works for regular parameters. Then
> it's obviously better.
It doesn't in C++ (which is _really_ annoying), but it does in D. In C++,
it uses the file and line number of the declaration site, whereas in D, it
uses the file and line number of the call site.
- Jonathan M Davis
Re: hidden passing of __FILE__ and __LINE__ into function
On Monday, 17 April 2017 at 10:55:30 UTC, Jonathan M Davis wrote:
On Monday, April 17, 2017 10:30:35 Basile B. via
Digitalmars-d-learn wrote:
On Monday, 17 April 2017 at 10:22:47 UTC, Dmitry wrote:
void error(string msg, string file = __FILE__, size_t line =
__LINE__)
{
...
}
That's what Exception's constructor does as well as functions
like std.exception.enforce.
- Jonathan M Davis
I didn't know that this also works for regular parameters. Then
it's obviously better.
Re: hidden passing of __FILE__ and __LINE__ into function
On Monday, April 17, 2017 10:30:35 Basile B. via Digitalmars-d-learn wrote:
> On Monday, 17 April 2017 at 10:22:47 UTC, Dmitry wrote:
> > Hi there.
> >
> > Currently for messages about errors I use code like this:
> > void add(string name, ref Scene scene)
> > {
> >
> > if (name in listOfScenes)
> > {
> >
> > EError(__FILE__, __LINE__, "scene already
> >
> > exists".L, quoted(name));
> >
> > }
> >
> > ...
> > }
> >
> > Is there way for avoid using (avoid writing) `__FILE__` and
> > `__LINE__` in each call? I.e. I want use simple
> >
> > EError("scene already exists".L, quoted(name));
> >
> > but function `EError` must print info (file and line) of where
> > was called.
> >
> > P.S. `EError` just prints info into console, result for this
> >
> > example is:
> >> [Error] (source\core\EScene.d, 35) Scene already exists:
> >> "Scene 1"
> >
> > and code is:
> > void EError(S...)(S args)
> > {
> >
> > write("[Error] (", args[0], ", ", args[1], ") ",
> >
> > args[2..$], '\n');}
> >
> > }
>
> when used as template value parameter, __FILE__ and
> __LINE__evaluate to the file and line of the call site. So help
> yourself ans use something like this:
>
> void error(string f = __FILE__, int l = __LINE__)(string msg){}
They works, but it results in a new template being instantiated for every
call, so you really shouldn't use __FILE__ or __LINE__ as template arguments
if you can avoid it. Usually, the better way to handle it is to use runtime
arguments, e.g.
void error(string msg, string file = __FILE__, size_t line = __LINE__)
{
...
}
That's what Exception's constructor does as well as functions like
std.exception.enforce.
- Jonathan M Davis
Re: hidden passing of __FILE__ and __LINE__ into function
On Monday, 17 April 2017 at 10:22:47 UTC, Dmitry wrote:
Hi there.
Currently for messages about errors I use code like this:
void add(string name, ref Scene scene)
{
if (name in listOfScenes)
{
EError(__FILE__, __LINE__, "scene already
exists".L, quoted(name));
}
...
}
Is there way for avoid using (avoid writing) `__FILE__` and
`__LINE__` in each call? I.e. I want use simple
EError("scene already exists".L, quoted(name));
but function `EError` must print info (file and line) of where
was called.
P.S. `EError` just prints info into console, result for this
example is:
[Error] (source\core\EScene.d, 35) Scene already exists:
"Scene 1"
and code is:
void EError(S...)(S args)
{
write("[Error] (", args[0], ", ", args[1], ") ",
args[2..$], '\n');}
}
when used as template value parameter, __FILE__ and
__LINE__evaluate to the file and line of the call site. So help
yourself ans use something like this:
void error(string f = __FILE__, int l = __LINE__)(string msg){}
hidden passing of __FILE__ and __LINE__ into function
Hi there.
Currently for messages about errors I use code like this:
void add(string name, ref Scene scene)
{
if (name in listOfScenes)
{
EError(__FILE__, __LINE__, "scene already exists".L,
quoted(name));
}
...
}
Is there way for avoid using (avoid writing) `__FILE__` and
`__LINE__` in each call? I.e. I want use simple
EError("scene already exists".L, quoted(name));
but function `EError` must print info (file and line) of where
was called.
P.S. `EError` just prints info into console, result for this
example is:
[Error] (source\core\EScene.d, 35) Scene already exists: "Scene
1"
and code is:
void EError(S...)(S args)
{
write("[Error] (", args[0], ", ", args[1], ") ",
args[2..$], '\n');}
}
Re: Can't pass data from filter to each
New question. Can I put result of filtering in itself without
creation of new variables like x:
auto x =
MySQLTablesRange.array.filter!(a=>a[0].coerce!string.canFind("_"));
Can't pass data from filter to each
I am writing lambda function. I need filter data at first step
and than do dome operation on them (for start simply print on the
screen. I wrote next code:
MySQLTablesRange.filter!(a=>a[0].coerce!string.canFind("_")).each!(a =>
to!int(a[0].coerce!string.split("_")[1]).writeln);
But it's seem that each do not handle any data. I tested if data
is corectly filtered and next code successfully print it's output.
auto t =
MySQLTablesRange.array.filter!(a=>a[0].coerce!string.canFind("_"));
t.each!(a=>a[0].coerce!string.writeln);
But what is wrong with first code?
Re: Stuck with DMD, and Unit-Threaded
On 2017-04-16 10:20, Russel Winder via Digitalmars-d-learn wrote: There are points when you need to ask someone for help… I am trying to get Dub to build integration tests from test-source as a separate thing from building unit tests from source. The latter is easy and works, as does building the application. I cannot however get the integration tests to build, I always get something along the lines of: ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(10,12): Error: function D main conflicts with static import dub_test_root.main at ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c-2fe37eb83633.d(3,15) and I haven't a clue. This is almost certainly just a bad dub.sdl file, but, if anyone can take a look at tell me what I am failing to get right, I'd appreciate it. https://github.com/russel/ApproxGC I cannot build the tests at all: unit_threaded/runtime.d(47,8): Error: module std.file import 'dirName' not found This [1] is what I've done for one of my projects to have the tests in a separate directory. But I don't have any unit tests among the regular source files. The difference I can see is what you've specified for "sourceFiles". Perhaps remove "source/main.d"? [1] https://github.com/jacob-carlborg/kiwi/blob/dev/dub.sdl#L11-L22 -- /Jacob Carlborg
Re: SFML gcc - MacOS
On 2017-04-16 10:11, Joel wrote: I've got Xcode, do I enter `xcode-select --install` in the terminal? Yes. That will get you access to Clang, the linker and other tools on the command line. It will also create /usr/include needed to build C/C++ code from the command line. -- /Jacob Carlborg
Re: Stuck with DMD, and Unit-Threaded
The report below was about using ldc2 on Fedora Rawhide. I get the same problem using dmd on Debian Sid. So I guess we are looking at Dub (and likely my use it it and dub.sdl file) as the problem. On Sun, 2017-04-16 at 09:20 +0100, Russel Winder wrote: > There are points when you need to ask someone for help… > > I am trying to get Dub to build integration tests from test-source as > a > separate thing from building unit tests from source. The latter is > easy > and works, as does building the application. I cannot however get the > integration tests to build, I always get something along the lines > of: > > ../../../../../../../tmp/dub_test_root-677ee80a-1e29-44c8-b08c- > 2fe37eb83633.d(10,12): Error: function D main conflicts with static > import dub_test_root.main at ../../../../../../../tmp/dub_test_root- > 677ee80a-1e29-44c8-b08c-2fe37eb83633.d(3,15) > > and I haven't a clue. This is almost certainly just a bad dub.sdl > file, > but, if anyone can take a look at tell me what I am failing to get > right, I'd appreciate it. > > https://github.com/russel/ApproxGC > > -- 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: Stuck with DMD, and Unit-Threaded
On Sun, 2017-04-16 at 12:04 +0300, drug via Digitalmars-d-learn wrote:
>
[…]
> Try to add version for `integrationtest` to exclude `main` from
> building
> like you did with unittests version. In dub.sdl add versions
> "integrationtests" for correspondence configuration and in
> `source\main.d` add something like that:
I believe that dub test will set unittest, that integrationtests is not
set as a version symbol. Indeed experiments with ldc2 seem to indicate
that "else version(…)" doesn't seem to work.
> ```
> ...
> unittest {
> auto item = getValue!(Tuple!(string, string));
> assert(debianPackageNumberLessThan(item[0], item[1]),
> format("[%s,
> %s]", item[0], item[1]));
>}
>
> }
> else version(integrationtests){
> // do something here
> }
> else {
> int main(string[] args) {
> ...
> ```
> It works for me. But frankly I failed to reproduce your error - I
> have
> other one like
> ```
> ut_main.d(5,5): Error: only one main allowed. Previously found main
> at
> source/main.d(161,6)
> dmd failed with exit code 1.
> ```
> so very probably I fix wrong problem
Are you on a different platform/compiler combination and so just
getting different views on the same problem. I am on Fedora Rawhide
with ldc2 from packaging. D 2.071 I think.
I'll try Debian where I have dmd (oh that doesn't work for other
reasons as yet uninvestigated), ldc2 (same version as Fedora I believe,
so should not be different), and gdc (but I think I am using D features
not supported yet there, but I will check).
--
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
