Re: Is this a bug? +goto
On Wednesday, November 7, 2018 10:50:29 PM MST Michelle Long via
Digitalmars-d-learn wrote:
> On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via
> >
> > Digitalmars- d-learn wrote:
> >> Don't let their psychobabble fool you. They are wrong and you
> >> were right from the start.
> >
> > ...
> >
> >> Case A:
> >> {
> >>
> >> if (true) goto X;
> >> int x;
> >>
> >> }
> >> X:
> >>
> >>
> >> Case B:
> >> {
> >>
> >> if (true) goto X;
> >> {
> >>
> >>int x;
> >>
> >> }
> >>
> >> }
> >> X:
> >>
> >>
> >> These two cases are EXACTLY the same semantically. It's like
> >> writing A + B and (A + B).
> >
> > That's not the situation that the OP was describing. If adding
> > braces in a situation where the braces have no semantic effect
> > has any impact on goto, then it's a compiler bug. It's adding a
> > new scope that affects the lifetime of a variable whose
> > declaration is being jumped over by a goto that matters.
> >
> > I know that you're frustrated, because you've hit a problem
> > with goto in complex code, and you don't have a simple example
> > that shows the compiler bug, but the approach that D takes with
> > goto (and any construct that potentially requires code flow
> > analysis) of avoiding requiring that the compiler be smart is
> > precisely to reduce the risk of there being cases where the
> > compiler is going to screw it up in complex code even though it
> > gets it right in the simple cases. If the language required the
> > compiler to be smart about such things, we'd have a lot more
> > problems with subtle, hard to track down compiler bugs in
> > complex code. So, we'd just have _more_ cases where people
> > would be hitting frustrating bugs like you are.
>
> That's fine. The D compiler writers can decide to do whatever
> they want. I can simply take my "business" elsewhere if I don't
> like it.
>
> What I am talking about is about an obvious error(Ok, I haven't
> produced a simplified test case but dustmite or visual D is not
> working for me to do so at this point in time, but it would be
> nice for sake of argument to assume I'm right...).
>
> > Regardless, if you want to actually have your problem fixed,
> > you're going to need to provide a reproducible test case in a
> > bugzilla report, even if it's large, otherwise no one is going
> > to be able to track it down for you.
>
> That's easier said than done. I wasn't expecting anyone to be
> able to fix a bug that can't be reproduced.
>
> What I expect is that, given my assumptions that I'm right, that
> people can agree the compiler does have a bug or flaw that can
> easily be fixed give then two simplified test cases basic purely
> what I have done in my own code.
>
> 1.
>
> foreach(...)
> {
>if (x) goto Y:
>int z;
> }
> Y:
>
> Fails.
>
> foreach(...)
> {
>if (x) goto Y:
>{
> int z;
>}
> }
> Y:
>
> Passes.
>
> THAT IS FACT! It doesn't matter if the examples work above. I
> have simplified what I have done and in my code I simply add
> brackets and it works! That is what people should be thinking
> about... not test cases, MWE's, compiler versions, etc.
>
> Is it logical that the compiler **should** error out in the first
> case and no in the second?
>
> That is what the discussion is ALL about. Once that is dealt with
> then we can move on to finding out more specifics. There is no
> reason to build the windows of a house before the foundation,
> it's just far more work without any benefit.
>
>
> Once people can say: If that is all you are doing is adding
> brackets around what follows the goto and break out of
> scope(which is what the code above says) and you can compile,
> then it is a compiler bug or flaw.
>
> Once people verify that, rather than trying to create rabbit
> holes, then I can do more work on finding out more specifics.
> Until then, it is pointless to do anything on my side because if
> people come back and say "No, it is suppose to work that way"
> then what the hell am I trying to simplify and fix? It's not a
> bug then.
If you have code where you get a compiler error about a goto skipping the
initializiation of a variable, and you add braces that should have no
semantic effect on the code whatsoever, and the error goes away, then yes,
that's a compiler bug. If, however, the braces do affect the semantics of
the code, then that's not necessarily a compiler bug. At that point, whether
it's a compiler bug or not would depend on what exactly the code was.
In an example such as
while(1)
{
if(cond)
goto label;
int x;
}
label:
adding braces such as
while(1)
{
if(cond)
{
goto label;
}
int x;
}
label:
or
while(1)
{
if(cond)
goto label;
{
int x;
}
}
label:
should have no effect. However, in an example such as
goto label;
int x;
label:
adding braces such as
goto label;
{
int x;
}
label:
changes the c
Re: is opOpAssign returning a value less than ideal ?
On Wednesday, November 7, 2018 10:45:07 PM MST Jonathan M Davis via Digitalmars-d-learn wrote: > On Wednesday, November 7, 2018 9:28:19 PM MST Codifies via Digitalmars-d- > > learn wrote: > > I noticed that opOpAsign allows you to return a value... > > > > this means I can do this (return a node from my list class when > > adding a new node) > > ``` > > anode = alist ~= &someData; > > ``` > > to me this looks a little unusual (but to be fair I can live with > > it) > > > > being as when its used like this: > > ``` > > alist ~= &someData; > > ``` > > you need to find out what the ~ operator does anyway, I don't > > think it harms readability > > > > any thoughts? > > It's common practice in C++ to have the various assignment operators > return a reference to the object being assigned to so that the operations > can be chained, and I don't see why the situation in D would be any > different. But if for whatever reason, you don't want to do the same with > your types, you can always just make those operators void. Either way, > the fact that an assignment operator returns a reference to the object > doesn't require you to then actually use it for anything. It just allows > folks to do so if they think that it's appropriate in a particular piece > of code. Sometimes, it's useful; often it isn't, but if the return type > is void, then you can't do it even in the cases where it would be useful. Rereading what you wrote, are you asking whether it's reasonable to return a value instead of a reference? Personally, I don't think that that's good design at all, but I also don't see any reason for the compiler to prevent it. Personally, I think that the default design should be to return by ref. Returning void is less than ideal but isn't necessarily bad, depending on the situation (especially if we're not talking about a general purpose library). However, I expect that returning non-void by value rather than by ref is rarely -if ever - going to be a good design choice. It's just going to be confusing and not particularly useful. - Jonathan M Davis
Re: Is this a bug? +goto
On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis
wrote:
On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via
Digitalmars- d-learn wrote:
Don't let their psychobabble fool you. They are wrong and you
were right from the start.
...
Case A:
{
if (true) goto X;
int x;
}
X:
Case B:
{
if (true) goto X;
{
int x;
}
}
X:
These two cases are EXACTLY the same semantically. It's like
writing A + B and (A + B).
That's not the situation that the OP was describing. If adding
braces in a situation where the braces have no semantic effect
has any impact on goto, then it's a compiler bug. It's adding a
new scope that affects the lifetime of a variable whose
declaration is being jumped over by a goto that matters.
I know that you're frustrated, because you've hit a problem
with goto in complex code, and you don't have a simple example
that shows the compiler bug, but the approach that D takes with
goto (and any construct that potentially requires code flow
analysis) of avoiding requiring that the compiler be smart is
precisely to reduce the risk of there being cases where the
compiler is going to screw it up in complex code even though it
gets it right in the simple cases. If the language required the
compiler to be smart about such things, we'd have a lot more
problems with subtle, hard to track down compiler bugs in
complex code. So, we'd just have _more_ cases where people
would be hitting frustrating bugs like you are.
That's fine. The D compiler writers can decide to do whatever
they want. I can simply take my "business" elsewhere if I don't
like it.
What I am talking about is about an obvious error(Ok, I haven't
produced a simplified test case but dustmite or visual D is not
working for me to do so at this point in time, but it would be
nice for sake of argument to assume I'm right...).
Regardless, if you want to actually have your problem fixed,
you're going to need to provide a reproducible test case in a
bugzilla report, even if it's large, otherwise no one is going
to be able to track it down for you.
That's easier said than done. I wasn't expecting anyone to be
able to fix a bug that can't be reproduced.
What I expect is that, given my assumptions that I'm right, that
people can agree the compiler does have a bug or flaw that can
easily be fixed give then two simplified test cases basic purely
what I have done in my own code.
1.
foreach(...)
{
if (x) goto Y:
int z;
}
Y:
Fails.
foreach(...)
{
if (x) goto Y:
{
int z;
}
}
Y:
Passes.
THAT IS FACT! It doesn't matter if the examples work above. I
have simplified what I have done and in my code I simply add
brackets and it works! That is what people should be thinking
about... not test cases, MWE's, compiler versions, etc.
Is it logical that the compiler **should** error out in the first
case and no in the second?
That is what the discussion is ALL about. Once that is dealt with
then we can move on to finding out more specifics. There is no
reason to build the windows of a house before the foundation,
it's just far more work without any benefit.
Once people can say: If that is all you are doing is adding
brackets around what follows the goto and break out of
scope(which is what the code above says) and you can compile,
then it is a compiler bug or flaw.
Once people verify that, rather than trying to create rabbit
holes, then I can do more work on finding out more specifics.
Until then, it is pointless to do anything on my side because if
people come back and say "No, it is suppose to work that way"
then what the hell am I trying to simplify and fix? It's not a
bug then.
But what it seems is that people cannot reason about the purely
theoretical underpinnings of the problem and need proof that
there is even a problem in the first place, as if I'm making it
up and then they create all kinds of obfuscation that doesn't
help anyone.
If you can agree that removing the brackets in the two test cases
should work in ALL regular cases then I can attempt to provide
more information.
Again, until then, it is pointless. I could waste 10 hours trying
to track the issue down to provide a test case and you can just
come back and say "Oh, no, that is not a bug, it's suppose to be
that way. We will not change anything". I know from previous
history that is the typical mentality.
Until We can agree that it is a bug, it is pointless for me to
treat it as a bug.
Now, a goto-related regression has recently been reported for
joiner:
https://issues.dlang.org/show_bug.cgi?id=19213
where some code worked with joiner in 2.081.2 but does not work
with 2.082.0 or later, so you may want to test your code with
an older compiler release to see if you've hit a compiler
regression. If so, that could be a starting point for tracking
down the problem.
Until I can simplify the code I have, it won't matter. If it is
the sam
Re: is opOpAssign returning a value less than ideal ?
On Wednesday, November 7, 2018 9:28:19 PM MST Codifies via Digitalmars-d- learn wrote: > I noticed that opOpAsign allows you to return a value... > > this means I can do this (return a node from my list class when > adding a new node) > ``` > anode = alist ~= &someData; > ``` > to me this looks a little unusual (but to be fair I can live with > it) > > being as when its used like this: > ``` > alist ~= &someData; > ``` > you need to find out what the ~ operator does anyway, I don't > think it harms readability > > any thoughts? It's common practice in C++ to have the various assignment operators return a reference to the object being assigned to so that the operations can be chained, and I don't see why the situation in D would be any different. But if for whatever reason, you don't want to do the same with your types, you can always just make those operators void. Either way, the fact that an assignment operator returns a reference to the object doesn't require you to then actually use it for anything. It just allows folks to do so if they think that it's appropriate in a particular piece of code. Sometimes, it's useful; often it isn't, but if the return type is void, then you can't do it even in the cases where it would be useful. - Jonathan M Davis
is opOpAssign returning a value less than ideal ?
I noticed that opOpAsign allows you to return a value... this means I can do this (return a node from my list class when adding a new node) ``` anode = alist ~= &someData; ``` to me this looks a little unusual (but to be fair I can live with it) being as when its used like this: ``` alist ~= &someData; ``` you need to find out what the ~ operator does anyway, I don't think it harms readability any thoughts?
Re: Is this a bug? +goto
On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via Digitalmars-
d-learn wrote:
> Don't let their psychobabble fool you. They are wrong and you
> were right from the start.
...
> Case A:
> {
> if (true) goto X;
> int x;
> }
> X:
>
>
> Case B:
> {
> if (true) goto X;
> {
>int x;
> }
> }
> X:
>
>
> These two cases are EXACTLY the same semantically. It's like
> writing A + B and (A + B).
That's not the situation that the OP was describing. If adding braces in a
situation where the braces have no semantic effect has any impact on goto,
then it's a compiler bug. It's adding a new scope that affects the lifetime
of a variable whose declaration is being jumped over by a goto that matters.
I know that you're frustrated, because you've hit a problem with goto in
complex code, and you don't have a simple example that shows the compiler
bug, but the approach that D takes with goto (and any construct that
potentially requires code flow analysis) of avoiding requiring that the
compiler be smart is precisely to reduce the risk of there being cases where
the compiler is going to screw it up in complex code even though it gets it
right in the simple cases. If the language required the compiler to be smart
about such things, we'd have a lot more problems with subtle, hard to track
down compiler bugs in complex code. So, we'd just have _more_ cases where
people would be hitting frustrating bugs like you are.
Regardless, if you want to actually have your problem fixed, you're going to
need to provide a reproducible test case in a bugzilla report, even if it's
large, otherwise no one is going to be able to track it down for you.
Now, a goto-related regression has recently been reported for joiner:
https://issues.dlang.org/show_bug.cgi?id=19213
where some code worked with joiner in 2.081.2 but does not work with 2.082.0
or later, so you may want to test your code with an older compiler release
to see if you've hit a compiler regression. If so, that could be a starting
point for tracking down the problem.
- Jonathan M Davis
Re: question about bitfields to decode websocket header
On Wednesday, 7 November 2018 at 14:22:43 UTC, lithium iodate wrote: On Wednesday, 7 November 2018 at 13:05:49 UTC, test wrote: I am confused about the bitfields order. The bitfields start with the least significant bits: fin -> 1 rsv1 -> 0 rsv2 -> 0 rsv3 -> 0 opcode -> 1000 = 8 mask -> 1 _size -> 101 = 65 This order will likely be what you want: mixin(bitfields!( opcode, "opcode", 4, bool, "rsv3", 1, bool, "rsv2", 1, bool, "rsv1", 1, bool, "fin",1, ubyte, "_size", 7, bool, "mask", 1, )); Also beware of endianness when mapping bytes to it. After I use your code it working now. my other question is: if the opcode bit cross byte, how do we define the bitfields ? for example if the opcode is a 6 bit number instead 4bit : F1|R1|R1|R1|opcode6|Mask1|Size5 I has to split the opcode here ? mixin(bitfields!( opcode, "opcode4", 4, bool, "rsv3", 1, bool, "rsv2", 1, bool, "rsv1", 1, bool, "fin",1, ubyte, "_size", 5, bool, "mask", 1, bool, "opcode2", 1, ));
Re: updated mir interface
On Wednesday, 7 November 2018 at 19:40:57 UTC, 9il wrote: On Wednesday, 7 November 2018 at 19:09:50 UTC, Alex wrote: Ok... sorry for being penetrant, but there is still something strange. Having dependencies as you had, [...] Well, fixed in v2.1.3 Thanks again! Works for now.
Re: Checking for CTFE at compile-time
On Wed, Nov 07, 2018 at 10:01:15PM +, Per Nordlöw via Digitalmars-d-learn
wrote:
> Opposite to run-time checking via
>
> if (__ctfe)
> {
> //
> }
It's actually not a "run-time" check, because the backend optimizer will
optimize out the true branch (check the emitted asm to confirm this).
> is there no way of checking at compile-time whether the current scope
> of a function is being executed in CTFE?
`if (__ctfe)` *is* a compile-time check.
I think you're getting confused by the blanket term "compile-time", that
actually means (at least) two different things. See:
https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
T
--
Real men don't take backups. They put their source on a public FTP-server and
let the world mirror it. -- Linus Torvalds
Checking for CTFE at compile-time
Opposite to run-time checking via
if (__ctfe)
{
//
}
is there no way of checking at compile-time whether the current
scope of a function is being executed in CTFE?
Re: Module function conflicting with reserve function
On Tuesday, 6 November 2018 at 21:29:17 UTC, Stanislav Blinov wrote: On Tuesday, 6 November 2018 at 21:19:29 UTC, Peter Campbell wrote: Given your second example that makes me think that, because object functions are provided by the runtime without me explicitly importing it, this is likely only an issue for object functions? Or can this behaviour happen with any free functions with the same name but completely different parameter types? Not with completely different parameter types, no. But it can happen with functions imported from different modules, as they're from different overload sets. There's an example in that Overload Sets section of the spec. I see what you both mean now and understand what's going on. Thanks for clearing it up
Re: Is this a bug? +goto
On Wednesday, 7 November 2018 at 20:03:47 UTC, Michelle Long
wrote:
Case A:
int x;
{
if (true) goto X;
//int x;
}
~x;
X:
That is not "Case A". This one is:
{
if (true) goto X;
T x;
X:
} // x.__dtor
That should error as an easy cop-out, nothing wrong with that
approach. However, this:
{
if (true) goto X;
T x;
} // x.__dtor
X:
should not error at all, since goto skips both initialization and
use. No one is disputing that. From your posts if I understand
correctly it's that second case that errors in your code. If it
does, there's a bug, but it's on you to provide a test case.
Simple as that. Yet you're all wound up as if the world is out to
get you.
Re: Is this a bug? +goto
On Tuesday, 6 November 2018 at 13:53:41 UTC, MatheusBN wrote:
On Tuesday, 6 November 2018 at 05:46:40 UTC, Jonathan M Davis
wrote:
On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via
Digitalmars-d-learn wrote:
On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis
wrote:
>> And I found a bit strange that in such code, since "x" is
>> never used, why it isn't skipped.
>
> It's skipped right over. The goto jumps out of the scope,
> and the line with
>
> int x;
>
> is never run. In fact, if you compile with -w or -wi, the
> compiler will give you a warning about unreachable code.
That is exactly my point.
Since "x" it's skipped and never used, it shouldn't just be a
warning (unreachable code) instead of an error?
I'm trying to understand why/when such code could give any
problem.
On the other hand if the code were:
{
goto Q:
int x;
Q:
x = 10; // <- Now you are accessing an uninitialized
variable.
}
Then I think an error would be ok.
D tries to _very_ little with code flow analysis, because once
you start having to do much with it, odds are that the
compiler implementation is going to get it wrong. As such, any
feature that involves code flow analysis in D tends to be
_very_ simple. So, D avoids the issue here by saying that you
cannot skip the initialization of a variable with goto. The
compiler is not going to do the complicated logic of keeping
track of where you access the variable in relation to the
goto. That's exactly the sort of thing that might be obvious
in the simple case but is highly likely to be buggy in more
complex code. Code such as
{
goto Q;
int x;
}
Q:
or
{
if(foo)
goto Q;
int x;
}
Q:
is fine, because the compiler can trivially see that it is
impossible for x to be used after it's been skipped, whereas
with something like
goto Q;
int x;
Q:
the compiler has to do much more complicated analysis of what
the code is doing in order to determine that, and when the
code isn't trivial, that can get _really_ complicated.
You could argue that it would be nicer if the language
required that the compiler be smarter about it, but by having
the compiler be stupid, it reduces the risk of compiler bugs,
and most people would consider code doing much with gotos like
this to be poor code anyway. Most of the cases where goto is
reasonable tend to be using goto from inside braces already,
because it tends to be used as a way to more efficiently exit
deeply nested code. And with D's labeled break and continue,
the need for using goto outside of switch statements also
tends to be lower than it is in C/C++.
- Jonathan M Davis
It's clear now about this decision and by the way thanks for
replying all my doubts.
MatheusBN.
Don't let their psychobabble fool you. They are wrong and you
were right from the start.
There is no initialization of the variable, or, if there
is(because it's "on the tack, which is "initialized" at the start
of the function"), the variable is still never used and that is
the whole problem.
What you will find with some of these guys is they start with the
assumption that everything D does is correct then they try to
disprove anything that goes against it by coming up with reasons
that explain why D does it the way it does. It is circular
reasoning and invalid. Each step they come up with some new
explanation when you pick holes in their previous ones.
Eventually it's either "It's because D is not designed to do
that" or "write an enhancement yourself" type of answer.
The fact is simple: Who ever implemented the goto statement did
not create code to handle this case and chose the easiest route
which is to error out. This was either oversight or "laziness".
It's really simple as that. Not once has anyone proven that the
semantics are illogical, which is what it would require for the
compiler to be absolutely correct in it's error.
In this case, they are simple wrong because it requires no flow
analysis or any complex logic to determine. It's not because C is
stupid and is unsafe, it's unreachable, etc...
The compiler simply knows what line and scope a variable is
initialized on(since it can determine if a variable is used for
initialization, which is a logic error) and it simply has to
determine if the goto escapes the scope before using any
initialized variable.
It can do this easily but the logic was not added.
Case A:
{
if (true) goto X;
int x;
}
X:
Case B:
{
if (true) goto X;
{
int x;
}
}
X:
These two cases are EXACTLY the same semantically. It's like
writing A + B and (A + B).
What the extra scope does though is create a new scope in the
compiler AST and this separates the goto logic, which is properly
implemented to handle that case.
The fact that one produces one error and the other is valid
proves that the compiler is incomplete. Adding scopes does not
change semantics no different than adding pare
Re: updated mir interface
On Wednesday, 7 November 2018 at 19:09:50 UTC, Alex wrote: Ok... sorry for being penetrant, but there is still something strange. Having dependencies as you had, [...] Well, fixed in v2.1.3
Re: updated mir interface
On 07.11.2018 22:09, Alex wrote:
Ok... sorry for being penetrant, but there is still something strange.
Having dependencies as you had,
´´´
import mir.random.algorithm;
import mir.algorithm.iteration;
import mir.ndslice;
import mir.random;
void fun(size_t s){}
void main()
{
size_t[] arr;
arr.length = 42;
rne.sample(arr, 1).each!(el => fun(el));
foreach(i; rne.sample(arr, 1)) { i.fun; }
}
´´´
I get
/Users/alex/.dub/packages/mir-random-2.1.2/mir-random/source/mir/random/algorithm.d(573,48):
Error: no property front for type ulong[]
/Users/alex/.dub/packages/mir-algorithm-3.0.3/mir-algorithm/source/mir/algorithm/iteration.d-mixin-922(922,5):
Error: template instance
`mir.random.algorithm.RandomSample!(MersenneTwisterEngine!(ulong, 64LU,
312LU, 156LU, 31LU, 13043109905998158313LU, 29LU, 6148914691236517205LU,
17LU, 8202884508482404352LU, 37LU, 1873444759240704LU, 43LU,
6364136223846793005LU), ulong[]).RandomSample.front!()` error instantiating
/Users/alex/.dub/packages/mir-algorithm-3.0.3/mir-algorithm/source/mir/algorithm/iteration.d(966,25):
instantiated from here: eachImpl!(__lambda1,
RandomSample!(MersenneTwisterEngine!(ulong, 64LU, 312LU, 156LU, 31LU,
13043109905998158313LU, 29LU, 6148914691236517205LU, 17LU,
8202884508482404352LU, 37LU,1873444759240704LU, 43LU,
6364136223846793005LU), ulong[]))
source/app.d(13,20): instantiated from here:
each!(RandomSample!(MersenneTwisterEngine!(ulong, 64LU, 312LU, 156LU,
31LU, 13043109905998158313LU, 29LU, 6148914691236517205LU, 17LU,
8202884508482404352LU, 37LU, 1873444759240704LU, 43LU,
6364136223846793005LU), ulong[]))
dmd failed with exit code 1.
If I import in mir.random.algorithm.d (2.1.2) in line 534 std.range, the
error goes away. But I assume, that's not the way it should be solved,
is it?
It's not a full answer, but try to add `import std.array;` or its analog
in mir if exists
Re: updated mir interface
Ok... sorry for being penetrant, but there is still something
strange. Having dependencies as you had,
´´´
import mir.random.algorithm;
import mir.algorithm.iteration;
import mir.ndslice;
import mir.random;
void fun(size_t s){}
void main()
{
size_t[] arr;
arr.length = 42;
rne.sample(arr, 1).each!(el => fun(el));
foreach(i; rne.sample(arr, 1)) { i.fun; }
}
´´´
I get
/Users/alex/.dub/packages/mir-random-2.1.2/mir-random/source/mir/random/algorithm.d(573,48):
Error: no property front for type ulong[]
/Users/alex/.dub/packages/mir-algorithm-3.0.3/mir-algorithm/source/mir/algorithm/iteration.d-mixin-922(922,5):
Error: template instance
`mir.random.algorithm.RandomSample!(MersenneTwisterEngine!(ulong, 64LU, 312LU,
156LU, 31LU, 13043109905998158313LU, 29LU, 6148914691236517205LU, 17LU,
8202884508482404352LU, 37LU, 1873444759240704LU, 43LU,
6364136223846793005LU), ulong[]).RandomSample.front!()` error instantiating
/Users/alex/.dub/packages/mir-algorithm-3.0.3/mir-algorithm/source/mir/algorithm/iteration.d(966,25):
instantiated from here: eachImpl!(__lambda1,
RandomSample!(MersenneTwisterEngine!(ulong, 64LU, 312LU, 156LU, 31LU,
13043109905998158313LU, 29LU, 6148914691236517205LU, 17LU,
8202884508482404352LU, 37LU,1873444759240704LU, 43LU,
6364136223846793005LU), ulong[]))
source/app.d(13,20):instantiated from here:
each!(RandomSample!(MersenneTwisterEngine!(ulong, 64LU, 312LU,
156LU, 31LU, 13043109905998158313LU, 29LU, 6148914691236517205LU,
17LU, 8202884508482404352LU, 37LU, 1873444759240704LU, 43LU,
6364136223846793005LU), ulong[]))
dmd failed with exit code 1.
If I import in mir.random.algorithm.d (2.1.2) in line 534
std.range, the error goes away. But I assume, that's not the way
it should be solved, is it?
Re: updated mir interface
On Wednesday, 7 November 2018 at 17:05:31 UTC, 9il wrote:
I have updated template constraints.
http://docs.random.dlang.io/latest/mir_random_algorithm.html#.sample
The problem that looks like Phobos map does not define all
required primitives like popFrontExactly.
Ok... didn't have this on my radar.
I suggest using Mir instead of Phobos if possible:
https://run.dlang.io/is/NBTfwF
/+dub.sdl:
dependency "mir-algorithm" version="~>3.0.3"
dependency "mir-random" version="~>2.1.1"
+/
import mir.random.algorithm;
import mir.algorithm.iteration;
import mir.ndslice: sliced, iota, map, member;
void main()
{
S[] arr;
arr.length = 42;
// using each
arr.length.iota.each!((i, ref el) => el.i = i)(arr);
// or using each and member
arr.length.iota.each!"b = a"(arr.member!"i");
// or using assign
arr.member!"i"[] = arr.length.iota;
auto res0 = rne.sample(arr.map!((ref el) => el.i), 1);
// or using member
auto res1 = rne.sample(arr.member!"i", 1);
}
struct S { size_t i; }
I will try to adopt this... Thanks a lot!
Re: updated mir interface
On Wednesday, 7 November 2018 at 14:46:17 UTC, Alex wrote:
On Wednesday, 7 November 2018 at 14:07:32 UTC, 9il wrote:
This is a regression. It is fixed in mir-random v2.1.2.
Thanks. But I have another one:
´´´
import mir.random.algorithm;
import std.experimental.all;
void main()
{
S[] arr;
arr.length = 42;
arr.each!((i, ref el) => el.i = i);
auto res = rne.sample(arr.map!((ref el) => el.i), 1);
}
struct S { size_t i; }
´´´
Does not depend, on whether I use (ref el) or just el... And
should not depend on that ;)
I have updated template constraints.
http://docs.random.dlang.io/latest/mir_random_algorithm.html#.sample
The problem that looks like Phobos map does not define all
required primitives like popFrontExactly. I suggest using Mir
instead of Phobos if possible:
https://run.dlang.io/is/NBTfwF
/+dub.sdl:
dependency "mir-algorithm" version="~>3.0.3"
dependency "mir-random" version="~>2.1.1"
+/
import mir.random.algorithm;
import mir.algorithm.iteration;
import mir.ndslice: sliced, iota, map, member;
void main()
{
S[] arr;
arr.length = 42;
// using each
arr.length.iota.each!((i, ref el) => el.i = i)(arr);
// or using each and member
arr.length.iota.each!"b = a"(arr.member!"i");
// or using assign
arr.member!"i"[] = arr.length.iota;
auto res0 = rne.sample(arr.map!((ref el) => el.i), 1);
// or using member
auto res1 = rne.sample(arr.member!"i", 1);
}
struct S { size_t i; }
Re: updated mir interface
On Wednesday, 7 November 2018 at 14:07:32 UTC, 9il wrote:
This is a regression. It is fixed in mir-random v2.1.2.
Thanks. But I have another one:
´´´
import mir.random.algorithm;
import std.experimental.all;
void main()
{
S[] arr;
arr.length = 42;
arr.each!((i, ref el) => el.i = i);
auto res = rne.sample(arr.map!((ref el) => el.i), 1);
}
struct S { size_t i; }
´´´
Does not depend, on whether I use (ref el) or just el... And
should not depend on that ;)
Re: Native PDB Error
On Wednesday, 7 November 2018 at 01:37:29 UTC, Chris M. wrote: On Tuesday, 29 May 2018 at 07:47:07 UTC, Begah wrote: [...] This works fine on my home Win10 machine, dmd 2.082/2.083 + dub 1.11.0, installed using the executable from the downloads page. However I've had this same issue on my work PC for which I'll have to double-check my setup tomorrow. Reproduced the issue on my work machine with dmd 2.082, dub 1.9.0/1.11.0, so it seems to be a dmd issue. The only difference is that my work machine is using mingw libraries rather than Microsoft build tools.
Re: question about bitfields to decode websocket header
On Wednesday, 7 November 2018 at 13:05:49 UTC, test wrote: I am confused about the bitfields order. mixin(bitfields!( bool, "fin",1, bool, "rsv1", 1, bool, "rsv2", 1, bool, "rsv3", 1, Opcode, "opcode", 4, bool, "mask", 1, ubyte, "_size", 7, )); output for first byte is 1001 , the 2st byte 1011 my code output: opcode=8 mask=true size=65 the real size is 3 byte, and opcode is 1; how to fix this ? The bitfields start with the least significant bits: fin -> 1 rsv1 -> 0 rsv2 -> 0 rsv3 -> 0 opcode -> 1000 = 8 mask -> 1 _size -> 101 = 65 This order will likely be what you want: mixin(bitfields!( opcode, "opcode", 4, bool, "rsv3", 1, bool, "rsv2", 1, bool, "rsv1", 1, bool, "fin",1, ubyte, "_size", 7, bool, "mask", 1, )); Also beware of endianness when mapping bytes to it.
Re: updated mir interface
On Wednesday, 7 November 2018 at 09:33:32 UTC, Alex wrote: I'm referring to the example http://docs.random.dlang.io/latest/mir_random_algorithm.html#.sample [...] This is a regression. It is fixed in mir-random v2.1.2.
question about bitfields to decode websocket header
I am confused about the bitfields order. mixin(bitfields!( bool, "fin",1, bool, "rsv1", 1, bool, "rsv2", 1, bool, "rsv3", 1, Opcode, "opcode", 4, bool, "mask", 1, ubyte, "_size", 7, )); output for first byte is 1001 , the 2st byte 1011 my code output: opcode=8 mask=true size=65 the real size is 3 byte, and opcode is 1; how to fix this ?
updated mir interface
I'm referring to the example
http://docs.random.dlang.io/latest/mir_random_algorithm.html#.sample
Could somebody tell me, why
´´´
import mir.random.algorithm;
import std.range; //import mir.range;
void main()
{ // line 5
size_t[] arr;
arr.length = 42;
arr = arr.length.iota.array;
auto res = rne.sample(arr, 1);
} // line 10
´´´
refuses to compile?
The error message is
/Users/alex/.dub/packages/mir-random-2.1.1/mir-random/source/mir/random/algorithm.d(551,23):
Error: no property popFrontExactly for type ulong[]
/Users/alex/.dub/packages/mir-random-2.1.1/mir-random/source/mir/random/algorithm.d(558,13):
Error: template instance
`mir.random.algorithm.RandomSample!(MersenneTwisterEngine!(ulong, 64LU, 312LU,
156LU, 31LU, 13043109905998158313LU, 29LU, 6148914691236517205LU, 17LU,
8202884508482404352LU, 37LU, 1873444759240704LU, 43LU,
6364136223846793005LU), ulong[]).RandomSample.__ctor!()` error instantiating
/Users/alex/.dub/packages/mir-random-2.1.1/mir-random/source/mir/random/algorithm.d(448,35):
instantiated from here: __ctor!()
source/app.d(9,23):instantiated from here:
sample!(MersenneTwisterEngine!(ulong, 64LU, 312LU, 156LU, 31LU,
13043109905998158313LU, 29LU, 6148914691236517205LU, 17LU,
8202884508482404352LU, 37LU, 1873444759240704LU, 43LU,
6364136223846793005LU), ulong[])
dmd failed with exit code 1.
