Re: Bug in std.json or my problem
On Wednesday, 22 April 2020 at 18:35:49 UTC, CraigDillabaugh wrote: On Wednesday, 22 April 2020 at 18:23:48 UTC, Anonymouse wrote: On Wednesday, 22 April 2020 at 17:48:18 UTC, Craig Dillabaugh wrote: clip File an issue if you have the time, maybe it will get attention. Unreported bugs can only be fixed by accident. I thought it might be worth filing a bug, but wanted to confirm if others thought this was actually a bug. I had encountered an identical issue with vibe-d years ago. Thanks for the feedback. After some digging it appears there is already a fix for this (though a bit old) … maybe I am the only person who cares about std.json after all :o) https://github.com/dlang/phobos/pull/5005/commits/e7d8fb83d2510b252cd8cfd2b744310de6fa84e5
Re: Bug in std.json or my problem
On Wednesday, 22 April 2020 at 18:23:48 UTC, Anonymouse wrote: On Wednesday, 22 April 2020 at 17:48:18 UTC, Craig Dillabaugh wrote: The crash is caused because the 'income' field with value 0.0 is output as 0 (rather than 0.0) and when it is read this is interpreted as an integer. Shouldn't this work? Yes, it's just buggy. Giving it a value of an even 1.0 will make it throw the same exception (js["income"].type is JSONType.integer), but a value of 1.1 will make it pass (.type properly becomes JSONType.float_). I don't know of a solution other than to check js["income"].type beforehand and use .floating or .integer as befits, or simply use an alternative JSON library (asdf?). File an issue if you have the time, maybe it will get attention. Unreported bugs can only be fixed by accident. I thought it might be worth filing a bug, but wanted to confirm if others thought this was actually a bug. I had encountered an identical issue with vibe-d years ago. Thanks for the feedback.
Re: Bug in std.json or my problem
On Wednesday, 22 April 2020 at 17:48:18 UTC, Craig Dillabaugh wrote: The crash is caused because the 'income' field with value 0.0 is output as 0 (rather than 0.0) and when it is read this is interpreted as an integer. Shouldn't this work? Yes, it's just buggy. Giving it a value of an even 1.0 will make it throw the same exception (js["income"].type is JSONType.integer), but a value of 1.1 will make it pass (.type properly becomes JSONType.float_). I don't know of a solution other than to check js["income"].type beforehand and use .floating or .integer as befits, or simply use an alternative JSON library (asdf?). File an issue if you have the time, maybe it will get attention. Unreported bugs can only be fixed by accident.
Bug in std.json or my problem
So perhaps I am the only person in the world using std.json, but
I was wondering
if the following code should work.
=
import std.json;
import std.conv;
import std.stdio;
struct Person {
string name;
float income;
this (string name, float income) {
this.name = name;
this.income = income;
}
this(JSONValue js) {
this.name = to!string(js["name"]);
/* This next line crashes with .. JSONValue is not
floating type.
* to!float( js["income"].toString()) works.
*/
this.income = js["income"].floating;
}
JSONValue toJSON() {
JSONValue json;
json["name"] = JSONValue(this.name);
json["income"] = JSONValue(this.income);
return json;
}
}
int main(string[] argv) {
Person bob = Person("Bob", 0.0);
string bob_json = bob.toJSON().toString();
Person sonofbob = Person(parseJSON(bob_json));
writeln(sonofbob.toJSON().toPrettyString());
return 0;
}
===
The crash is caused because the 'income' field with value 0.0 is
output as 0 (rather than 0.0) and when it is read this is
interpreted
as an integer.
Shouldn't this work?
Attribute inference within template functions
I was trying to write a function has different behavior depending
on whether it is called from @nogc code or not. However, I am
noticing that this does not seem possible because of the timing
of attribute inference.
If I call getFunctionAttributes within foo below, then it is
system but then when called from main they are correctly
inferred. It is as if the attribute inference happens after the
getFunctionAttributes is called.
Is there any way to get the correct function attributes within a
template function?
auto foo(T)(T x) {
pragma(msg, __traits(getFunctionAttributes, foo!T));
pragma(msg, __traits(getFunctionAttributes, foo!int));
return x;
}
void main() {
auto x = foo(1);
pragma(msg, __traits(getFunctionAttributes, foo!int));
}
Re: Enum conversion
On 4/22/20 6:36 AM, Russel Winder wrote: Though for converting a ulong to a ubyte, I am assuming to!ubyte(x) is the right tool for the job. It depends! If you know that the long will fit in a ubyte, by all means just use a cast. It's the fastest option. If you have no idea the value of the long, but it's *supposed* to fit into a ubyte, use to if you want an exception for those outside the range. And if you don't care, and just want a ubyte, use a cast. But the compiler isn't going to accept ubyte(someLong). -Steve
Re: Integration tests
On Wednesday, 22 April 2020 at 10:32:48 UTC, Russel Winder wrote: Now I discover Python, Rust, and Go have far nicer abstractions for writing Internet code than D does. Does D really not have a TcpListener abstraction? It really doesn't :( And D has so much potential as server tech with the potential combination of fibers + TLS + shared + static introspection. The package Vibe-d is quite nice though. I don't know if you've tried it but it's very simple to get a listener up with it. To date all I can get is: std.socket.SocketOSException@std/socket.d(2792): Unable to bind socket: Bad file descriptor when trying to open a TCP server on 127.0.0.1:5, with Python, Rust, or Go it all worked first time. This is really sad given D has so many advantages over Rust. :-(
Re: Enum conversion
On Tue, 2020-04-21 at 15:48 -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[…]
>
> 1. it's shorter and prettier.
> 2. No cast (I avoid using cast whenever I can).
> 3. No gotcha type conversions.
Works for me, you have me convinced. :-)
> e.g. for point 3:
>
> enum ZoneMember { // : int
>One = 1,
>Two = 2,
>ReallyBig = 4567,
> }
>
> auto b1 = ubyte(ZoneNumber.One); // 1 (compiler uses VRP to make this
> work)
> auto b2 = ubyte(ZoneNumber.ReallyBig); // Compiler error
>
> vs.
>
> auto b1 = cast(ubyte)ZoneNumber.One; // 1
> auto b2 = cast(ubyte)ZoneNumber.ReallyBig; // b2 == 215 (truncated)
>
> vs.
>
> auto b1 = to!ubyte(ZoneNumber.One); // 1
> auto b2 = to!ubyte(ZoneNumber.ReallyBig); // runtime error
QED.
Though for converting a ulong to a ubyte, I am assuming to!ubyte(x) is
the right tool for the job.
[…]
> pragma(msg, typeof(ZoneNumber.One).stringof); // ZoneNumber
Which is as it should be really. I was clearly having a mental
aberration. Anyway, the probem is now solved! :-) Thanks for your
input, much appreciated.
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Re: Integration tests
I ended up creating the following project structure:
.
├── dub.sdl
├── dub.selections.json
├── source
│ ├── arcam_protocol.d
│ └── main.d
├── tests
│ └── integration_tests.d
└── test_support
└── mock_avr850
└── main.d
with the following Dub control file:
name "arcamclient"
description "arcamclient is a Rust/gtk-rs/GTK+ desktop application to control
an Arcam amplifier over the Ethernet connection."
authors "Russel Winder"
copyright "Copyright © 2020 Russel Winder."
license "GPL-3.0"
targetType "executable"
targetPath "bin"
configuration "application" {
}
configuration "unittest" {
targetName "arcamclient_test"
dependency "unit-threaded" version="*"
mainSourceFile "bin/ut.d"
excludedSourceFiles "source/main.d"
preBuildCommands "$DUB run --compiler=$$DC unit-threaded -c gen_ut_main --
-f bin/ut.d -d $DUB"
preBuildCommands "$DUB build arcamclient:mock_avr850"
importPaths "tests"
sourcePaths "tests"
}
subPackage {
name "mock_avr850"
targetName "mock_avr850"
targetType "executable"
targetPath "bin"
sourcePaths "source" "test_support/mock_avr850"
importPaths "source" "test_support/mock_avr850"
excludedSourceFiles "source/main.d"
}
This seems a bit more sensible that what I have been able to achieve
with Rust, but is still second rate compared to how easy things are
using Python.
Now I discover Python, Rust, and Go have far nicer abstractions for
writing Internet code than D does. Does D really not have a TcpListener
abstraction?
To date all I can get is:
std.socket.SocketOSException@std/socket.d(2792): Unable to bind socket: Bad
file descriptor
when trying to open a TCP server on 127.0.0.1:5, with Python, Rust,
or Go it all worked first time. This is really sad given D has so many
advantages over Rust. :-(
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
