Re: incorrect data when returning static array in place of dynamic
On Sunday, 5 July 2015 at 18:57:46 UTC, sigod wrote: Why does function return incorrect data? Using `.dup` in return expression or using `ubyte[20]` as return type fixes problem, but why? Because sha1Of() returns ubyte[20], this is a stack-allocated array, a value type. If you put correct return type there, it will be returned by value and everything's fine. If your return type is ubyte[] (a reference type), a slice of stack-allocated array is returned which creates a reference to stack data that doesn't exist anymore.
Re: Array operations with array of structs
On Monday, 6 July 2015 at 03:02:59 UTC, Nicholas Wilson wrote:
On Monday, 6 July 2015 at 01:16:54 UTC, Peter wrote:
Hi,
I have a struct with arithmetic operations defined using
opBinary but array operations with arrays of it don't work.
struct Vector3 {
public double[3] _p;
...
Vector3 opBinary(string op)(in Vector3 rhs) const
if (op == "+"){
Vector3 result;
result._p[] = this._p[] + rhs._p[];
return result;
}
...
}
unittest{
auto a = Vector3([2.0, 2.0, 0.0]);
auto b = Vector3([1.0, 2.0, 1.0]);
Vector3[] c = [a];
Vector3[] d = [b];
Vector3 e = a + b; // works
Vector3[] f;
f[] = c[] + d[]; // Error: invalid array operation 'f[] =
c[] + d[]' because Vector3 doesn't support necessary
arithmetic operations
}
how can I get this to work?
Thanks
you need to define the slice operators. e.g.
auto opSlice() // no parameters to get whole slice eg. a[]
// can also define with opSlice(size_t i,
size_t j)
// for access like a[ i .. j]
{
return _p;
}
whoops. it may be complaining about lack of opSliceAssign
i.e. `f[] =`
again define this with no parameters for the whole slice or two
for a[i .. j] =
also note that you need to give memory for this array assignment
to go.
eg.
auto a = Vector3([2.0, 2.0, 0.0]);
auto b = Vector3([1.0, 2.0, 1.0]);
Vector3[] c = [a];
Vector3[] d = [b];
Vector3 e = a + b; // works
Vector3[] f;
f[] = c[] + d[];
will likely crash because `f` doesn't point to any allocated
memory.
initialising like
Vector3[] f = [Vector3()];
Enhancement Request to tell you the names of the missing methods
required
filed at
https://issues.dlang.org/show_bug.cgi?id=14772
Re: Array operations with array of structs
On Monday, 6 July 2015 at 01:16:54 UTC, Peter wrote:
Hi,
I have a struct with arithmetic operations defined using
opBinary but array operations with arrays of it don't work.
struct Vector3 {
public double[3] _p;
...
Vector3 opBinary(string op)(in Vector3 rhs) const
if (op == "+"){
Vector3 result;
result._p[] = this._p[] + rhs._p[];
return result;
}
...
}
unittest{
auto a = Vector3([2.0, 2.0, 0.0]);
auto b = Vector3([1.0, 2.0, 1.0]);
Vector3[] c = [a];
Vector3[] d = [b];
Vector3 e = a + b; // works
Vector3[] f;
f[] = c[] + d[]; // Error: invalid array operation 'f[] =
c[] + d[]' because Vector3 doesn't support necessary arithmetic
operations
}
how can I get this to work?
Thanks
you need to define the slice operators. e.g.
auto opSlice() // no parameters to get whole slice eg. a[]
// can also define with opSlice(size_t i,
size_t j)
// for access like a[ i .. j]
{
return _p;
}
Array operations with array of structs
Hi,
I have a struct with arithmetic operations defined using opBinary
but array operations with arrays of it don't work.
struct Vector3 {
public double[3] _p;
...
Vector3 opBinary(string op)(in Vector3 rhs) const
if (op == "+"){
Vector3 result;
result._p[] = this._p[] + rhs._p[];
return result;
}
...
}
unittest{
auto a = Vector3([2.0, 2.0, 0.0]);
auto b = Vector3([1.0, 2.0, 1.0]);
Vector3[] c = [a];
Vector3[] d = [b];
Vector3 e = a + b; // works
Vector3[] f;
f[] = c[] + d[]; // Error: invalid array operation 'f[] = c[]
+ d[]' because Vector3 doesn't support necessary arithmetic
operations
}
how can I get this to work?
Thanks
std.experimental.allocator destructor safe?
Can I call theAllocator.dispose from a struct destructor? None of the things pointed to by the root will be allocated directly by GC. Laeeth.
Re: bigint compile time errors
On Friday, 3 July 2015 at 04:08:32 UTC, Paul D Anderson wrote: On Friday, 3 July 2015 at 03:57:57 UTC, Anon wrote: On Friday, 3 July 2015 at 02:37:00 UTC, Paul D Anderson wrote: enum BigInt test1 = BigInt(123); enum BigInt test2 = plusTwo(test1); public static BigInt plusTwo(in bigint n) Should be plusTwo(in BigInt n) instead. Yes, I had aliased BigInt to bigint. And I checked and it compiles for me too with Windows m64. That makes it seem more like a bug than a feature. I'll open a bug report. Paul The point here is that x86 uses an assembler-optimized implementation (std.internal.math.biguintx86) and every other cpu architecture (including x64) uses a D version (std.internal.math.biguintnoasm). Because of the inline assembler, the x86 version is not CTFE-enabled. Regards, Kai
Re: How to setup GDC with Visual D?
Am Sat, 04 Jul 2015 11:15:57 +
schrieb "Guy Gervais" :
> On Saturday, 4 July 2015 at 08:34:00 UTC, Johannes Pfau wrote:
>
> > It's kinda fascinating that GDC/MinGW seems to work for some
> > real world applications.
>
> I haven't really tried a "real world application" as of yet;
> mostly small puzzle-type problems to get a feel for D.
>
> I did run into a problem with this code:
>
> int answer = to!(int[])(split("7946590 6020978")).sum;
>
> It compiles fine under DMD but gives the error "Error: no
> property 'sum' for type 'int[]'" with GDC.
>
GDC uses a slightly older phobos version. It seems quite some imports
changed in the last phobos version. You need to import std.algorithm
and your code should work with gdc:
http://goo.gl/l4zKki
incorrect data when returning static array in place of dynamic
Consider this code:
```
import std.digest.digest;
import std.stdio;
ubyte[] hmac_sha1(const(ubyte)[] key, const(ubyte)[] message)
{
import std.digest.sha;
enum block_size = 64;
if (key.length > block_size)
key = sha1Of(key);
if (key.length < block_size)
key.length = block_size;
ubyte[] o_key_pad = key.dup;
ubyte[] i_key_pad = key.dup;
o_key_pad[] ^= 0x5c;
i_key_pad[] ^= 0x36;
sha1Of(o_key_pad ~ sha1Of(i_key_pad ~
message)).toHexString.writeln; // prints correct string
return sha1Of(o_key_pad ~ sha1Of(i_key_pad ~ message));
}
void main()
{
hmac_sha1(cast(ubyte[])"", cast(ubyte[])"").toHexString.writeln;
// incorrect
"---".writeln;
hmac_sha1(cast(ubyte[])"key", cast(ubyte[])"The quick brown fox
jumps over the lazy dog").toHexString.writeln;
}
```
prints:
```
FBDB1D1B18AA6C08324B7D64B71FB76370690E1D
18AA6C08140038FD18001000
---
DE7C9B85B8B78AA6BC8A7A36F70A90701C9DB4D9
B8B78AA6140038FD18001000
```
Why does function return incorrect data? Using `.dup` in return
expression or using `ubyte[20]` as return type fixes problem, but
why?
Re: How to strip struct/class invariants?
On Sunday, 5 July 2015 at 14:44:30 UTC, John Colvin wrote:
struct A
{
ubyte[B.sizeof] mem;
@property ref B b()
{
return *cast(B*)(mem.ptr);
}
mixin std.typecons.Proxy!b;
}
Thanks, I followed your suggestion and effectively rolled out my
own union implementation. Ugly but it works.
struct A
{
ubyte[maxSizeof] _data;
@property ref T _as(T)() inout { return *cast(T*)(_data.ptr);
}
alias b = _as!uint;
alias c = _as!size_t;
alias d = _as!double;
}
Re: How to strip struct/class invariants?
On Sunday, 5 July 2015 at 12:15:32 UTC, Artem Tarasov wrote:
OK, so there was an old bug fixed in 2.067
(https://issues.dlang.org/show_bug.cgi?id=4421) so that now
unions apparently can't contain a struct that has invariants.
It kinda makes sense, although I don't see why the invariants
can be simply ignored, as they don't have as much importance as
destructors/postblits.
But more to the point. I have a struct that has an invariant,
and I wish to use it as a member of an union. With the latest
compiler, I have to somehow remove the invariant. Is there some
compile-time magic that I can use for this?
Not perfect, but I think you can do:
struct A
{
ubyte[B.sizeof] mem;
@property ref B b()
{
return *cast(B*)(mem.ptr);
}
mixin std.typecons.Proxy!b;
}
where B has an invariant. Even better, the invariant should still
get called.
Re: Switching rows with columns
On Sunday, 5 July 2015 at 11:35:14 UTC, Marc Schütz wrote: Maybe it's the last condition, `hasAssignableElements`. I don't know whether that one is really necessary... It probably is. The last check returned false. Since I already would have to implement "r.front = ", I'll just use arrays. Thanks for the help.
How to strip struct/class invariants?
OK, so there was an old bug fixed in 2.067 (https://issues.dlang.org/show_bug.cgi?id=4421) so that now unions apparently can't contain a struct that has invariants. It kinda makes sense, although I don't see why the invariants can be simply ignored, as they don't have as much importance as destructors/postblits. But more to the point. I have a struct that has an invariant, and I wish to use it as a member of an union. With the latest compiler, I have to somehow remove the invariant. Is there some compile-time magic that I can use for this?
Re: Switching rows with columns
On Sunday, 5 July 2015 at 00:18:18 UTC, Tanel Tagaväli wrote: On Saturday, 4 July 2015 at 16:29:44 UTC, Marc Schütz wrote: Try std.range.transposed: http://dlang.org/phobos/std_range.html#.transposed Does this work with user-defined types? I defined two structs that implement the InputRange(possibly ForwardRange) interface, an integer range and a range of those integer ranges. DMD tells me the "transposed" template cannot deduce function from the arguments, which is a range of integer ranges. The template does, however, work on a two-dimensional array. The "save" method is implemented using a simple "return this", could this be to blame? This should be fine. Which of the ranges is the ForwardRange? It should be the range-of-ranges. You can check which of the template constraints fails: import std.range; alias RangeOfRanges = typeof(myRangeOfRanges); pragma(msg, isForwardRange!RangeOfRanges); pragma(msg, isInputRange!(ElementType!RangeOfRanges)); pragma(msg, hasAssignableElements!RangeOfRanges); Maybe it's the last condition, `hasAssignableElements`. I don't know whether that one is really necessary...
Re: code review based on what I learned from D
On Sun, 05 Jul 2015 21:39:23 +1200, Rikki Cattermole wrote: > Of course of course. > Valid options in failing gracefully include resetting the data and > informing the user. Also giving them an option to send a bug report to > the devs. > Point being, having it just fail on start each time is not a valid end > result or something else awful. ah, i see and i fully agree. signature.asc Description: PGP signature
Re: code review based on what I learned from D
On 5/07/2015 9:37 p.m., ketmar wrote: On Sun, 05 Jul 2015 19:01:59 +1200, Rikki Cattermole wrote: Failing gracefully. Not something most developers do. usually that is not related. i mean that if program entered invalid state, it may be too late to save user data. it may be even undesirable to do so, as the data may be already corrupted. what the good program should do (i think) is storing "working log", so if it crashed, the log can be replayed from the last saved state, restoring all the work. maybe with the option that allows the log to be replayed partially, to avoid endless crashes. besides, it will be possible to send the document and the log to developers, so they can reproduce the exact bug. Of course of course. Valid options in failing gracefully include resetting the data and informing the user. Also giving them an option to send a bug report to the devs. Point being, having it just fail on start each time is not a valid end result or something else awful.
Re: code review based on what I learned from D
On 5/07/2015 9:32 p.m., ketmar wrote: On Sun, 05 Jul 2015 06:53:34 +, Szabo Bogdan wrote: For both of these issues I was told that swift is not Java and if the situations that I described happens, you don't want to crash the user app, because this will make the user unhappy. i completely agree. it's way better to keep going and silently corrupt user data. i mean, well, nobody cares about corrupted data if a program is not crashed, right? happy users with invalid data will buy version 2, for sure. Ahhh sarcastic ketmar, one of the best ketmar's selfs. Welcome back. It was what I was saying anyway :)
Re: code review based on what I learned from D
On Sun, 05 Jul 2015 19:01:59 +1200, Rikki Cattermole wrote: > Failing gracefully. Not something most developers do. usually that is not related. i mean that if program entered invalid state, it may be too late to save user data. it may be even undesirable to do so, as the data may be already corrupted. what the good program should do (i think) is storing "working log", so if it crashed, the log can be replayed from the last saved state, restoring all the work. maybe with the option that allows the log to be replayed partially, to avoid endless crashes. besides, it will be possible to send the document and the log to developers, so they can reproduce the exact bug. signature.asc Description: PGP signature
Re: code review based on what I learned from D
On Sun, 05 Jul 2015 06:53:34 +, Szabo Bogdan wrote: > For both of these issues I was told that swift is not Java and if the > situations that I described happens, you don't want to crash the user > app, because this will make the user unhappy. i completely agree. it's way better to keep going and silently corrupt user data. i mean, well, nobody cares about corrupted data if a program is not crashed, right? happy users with invalid data will buy version 2, for sure. signature.asc Description: PGP signature
Re: code review based on what I learned from D
On 5/07/2015 6:53 p.m., Szabo Bogdan wrote:
Hi,
Recently while I was reviewing some swift code, a colleague left me the
impression that I am the one with the bad habits and these were learned
while coding in D. I still think that I proposed some changes to avoid
some bugs but I was told that I am focusing on defensive programming and
that is a bad thing.
The first issue that I raised was this one:
func renderCell(item: AnyObject, index: Int) {
-fatalError("renderCell has not been implemented")
+
}
where I proposed to make that method abstract or let's not remove the
fatalError message because this method it should be never called.
The second issue was this:
+init(dataSource: WUPTableDataSource) {
+
+self.dataSource = dataSource
+dataSource.tableView = tableView
where I asked what happens if someone passes a dataSource that has a
tableView set. I this class, there were set some events bind to the view
and it was unclear what happened in that case and I proposed to add an
assert to check if dataSource.tableView is not set before we set it.
For both of these issues I was told that swift is not Java and if the
situations that I described happens, you don't want to crash the user
app, because this will make the user unhappy.
Those things are for me, good habits that I do when I am programming
with D. What do you think? and if I had bad ideas with those issues,
what I can do to improve my skills?
thanks,
Bogdan
Your collages are arguing that if they exist, they could be called and
make program fail. Which is a valid point of view.
However, from a development point of view, you kinda want to know if
they are being called.
I think you are arguing for slightly something different then to what
you think.
I recommend arguing for a function that allows you to log during
development in some form (maybe exceptions) to find where code paths are
being used where you did not expect.
Another thought is defensive programming is _not_ a bad thing. Its an
amazing thing really. It's great to do, to make sure an application does
not get into an erroneous state. But you know what also is great?
Failing gracefully. Not something most developers do.
Anyway just my thoughts on it.
