Re: tupleof seems to break encapsulation
On Friday, 4 September 2020 at 17:36:00 UTC, Jacob Carlborg wrote: It's useful for serialization and, as you can see in your example, for debugging as well. `writeln` will print the values of the fields in a struct, even for private fields. I wouldn't dispute that it is useful, but that's besides the point. If I declare something private, it's usually because I want to preserve certain invariants and I want the compiler to provide a guarantee that I don't accidentally violate them. As it stands, the compiler cannot guarantee that if I use tupleof. I don't really have an issue with read-only access to private fields (but arguments could be made against it) and then serialization would still be possible. However, if my struct is supposed to maintain invariants, then any attempt at deserialization that naively reads from a tuple without establishing these invariants should fail to compile.
Re: Install multiple executables with DUB
On Thursday, 3 September 2020 at 14:34:48 UTC, Jacob Carlborg wrote: Oh, multiple binaries, I missed that. You can try to add multiple configurations [1]. Or if you have executables depending on only one source file, you can use single-file packages [2]. Thanks, but this still means I would have to write an install-script running `dub build --single` on each script, right? I looked at tsv-utils [1] which seems to be a similar use-case as mine, and they declare each tool as a subpackage. The main package runs a d-file called `dub_build.d` which compiles all subpackages. Fells like an overkill to me, I'll probably just stick to a makefile. [1] https://github.com/eBay/tsv-utils/blob/master/docs/AboutTheCode.md#building-and-makefile
Re: Install multiple executables with DUB
On Thursday, 3 September 2020 at 08:22:25 UTC, glis-glis wrote: Hi, I have a few modules for parsing different file formats and a folder with d-scripts using these parsers to perform manipulations, extract information, ... Until now, I just added #!/usr/bin/env rdmd to the d-scripts and run them that way, but I'd like to make the scripts available to my collaborators without them being required to install dmd & co, so I'll have to compile the scripts. I usually would just write a makefile for that, but I thought I'd give DUB a go. Unfortunately, the DUB-documentation is a little thin and I cannot find a way to tell DUB "compile all the files in the scripts folder and put the binary to the bin folder". How do I do that? Thanks! Option 1: (recommended for multiple single file binaries) use preBuildCommands to invoke dub or dmd for each of your scripts you need Compatibility tip: use the special $DUB and $DC variables, see https://dub.pm/package-format-json.html#environment-variables If built often, consider using rdmd for easy caching or make this a sub-package which you depend on which will therefore only be rebuilt in case of changes to that sub-path folder. Add a glob of "extraDependencyFiles" matching your script files to make the package rebuild on script changes. Option 2: (recommended for multiple larger binaries) use sub-packages and make your root package targetType: none to build all child packages, see https://dub.pm/package-format-json.html#sub-packages root dub.sdl: name "test" targetType "none" dependency ":a" version="*" dependency ":b" version="*" subPackage "a" subPackage "b" a/dub.sdl: name "a" targetType "executable" b/dub.sdl: name "b" targetType "executable" $ dub build Result: a/test_a.exe b/test_b.exe Note: this only works if your package is targetType none, use targetName and targetPath to customize how the exe is called and where it's placed
Re: Install multiple executables with DUB
On 9/4/20 10:27 AM, glis-glis wrote:
On Thursday, 3 September 2020 at 14:34:48 UTC, Jacob Carlborg wrote:
Oh, multiple binaries, I missed that. You can try to add multiple
configurations [1]. Or if you have executables depending on only one
source file, you can use single-file packages [2].
Thanks, but this still means I would have to write an install-script
running
`dub build --single`
on each script, right?
I looked at tsv-utils [1] which seems to be a similar use-case as mine,
and they declare each tool as a subpackage. The main package runs a
d-file called `dub_build.d` which compiles all subpackages. Fells like
an overkill to me, I'll probably just stick to a makefile.
[1]
https://github.com/eBay/tsv-utils/blob/master/docs/AboutTheCode.md#building-and-makefile
I don't know is it suitable for your use case but I do the following:
1. add a recipe in every tool files like:
```
drug@drug: ~/utils$ cat ./tools/count.d
#!/usr/bin/env dub
/+ dub.sdl:
name"count"
targetType "executable"
targetPath "../bin"
targetName "count"
dependency "abcdLibrary" version="*" path="path/to/abcdLibrary"
+/
int main()
{
...
}
```
2. place all tool files into one directory `tools`
3. build them using `dub build --single tools/count.d`
4. Now I have all binary in `bin` directory, all sources in `tools`
directory and have no subpackages at all
Re: Install multiple executables with DUB
On Friday, 4 September 2020 at 07:27:33 UTC, glis-glis wrote: On Thursday, 3 September 2020 at 14:34:48 UTC, Jacob Carlborg wrote: Oh, multiple binaries, I missed that. You can try to add multiple configurations [1]. Or if you have executables depending on only one source file, you can use single-file packages [2]. Thanks, but this still means I would have to write an install-script running `dub build --single` on each script, right? I looked at tsv-utils [1] which seems to be a similar use-case as mine, and they declare each tool as a subpackage. The main package runs a d-file called `dub_build.d` which compiles all subpackages. Fells like an overkill to me, I'll probably just stick to a makefile. [1] https://github.com/eBay/tsv-utils/blob/master/docs/AboutTheCode.md#building-and-makefile The `dub_build.d` is so that people can use `$ dub fetch` to download and build the tools with `$ dub run`, from code.dlang.org. dub fetch/run is the typical dub sequence. But it's awkward. And it geared toward users that have a D compiler plus dub already installed. For building your own binaries you might as well use `make`. However, if you decide to add your tools to the public dub package registry you might consider the technique. My understanding is that the dub developers recognize that multiple binaries are inconvenient at present and have ideas on improvements. Having a few more concrete use cases might help nail down the requirements. The tsv-utils directory layout may be worth a look. It's been pretty successful for multiple binaries in a single repo with some shared code. (Different folks made suggestions leading to this structure.) It works for both make and dub, and works well with other tools, like dlpdocs (Adam Ruppe's doc generator). The tsv-utils `make` setup is quite messy at this point, you can probably do quite a bit better. --Jon
Re: tupleof seems to break encapsulation
On Friday, 4 September 2020 at 10:16:47 UTC, 60rntogo wrote:
Consider the following code.
foo.d
---
module foo;
struct Foo
{
private int i;
}
---
main.d
---
void main()
{
import std.stdio;
import foo;
auto x = Foo();
writeln(x);
// ++x.i;
++x.tupleof[0];
writeln(x);
}
---
As expected, the commented line does not compile. If I
uncomment it, I get the error "no property i for type foo.Foo".
However, the rest of the code compiles just fine and outputs:
---
Foo(0)
Foo(1)
---
This appears to defeat the purpose of declaring i private. What
am I missing?
It's a known issue: https://issues.dlang.org/show_bug.cgi?id=19326
There are some very good reasons to allow some access to private
fields, though it should be more limited than is currently the
case.
--
Simen
tupleof seems to break encapsulation
Consider the following code.
foo.d
---
module foo;
struct Foo
{
private int i;
}
---
main.d
---
void main()
{
import std.stdio;
import foo;
auto x = Foo();
writeln(x);
// ++x.i;
++x.tupleof[0];
writeln(x);
}
---
As expected, the commented line does not compile. If I uncomment
it, I get the error "no property i for type foo.Foo". However,
the rest of the code compiles just fine and outputs:
---
Foo(0)
Foo(1)
---
This appears to defeat the purpose of declaring i private. What
am I missing?
Re: How to use std.net.curl with specific curl query?
Nice, I have been having this problem for quite a while too. Thanks
Re: Problem with gfm.math.matrix (some gamedevs out there ?)
On Thursday, 3 September 2020 at 12:36:35 UTC, Thomas wrote:
-
import std.stdio;
int main()
{
import gfm.math.matrix;
const int width = 800;
const int height = 600;
auto projectionMatrix = mat4!(float).identity();
Note that instead of `mat4!(float)` you can just use `mat4f`.
auto ratio = cast(float)width / cast(float)height;
projectionMatrix = mat4!(float).perspective( 45.0f, ratio,
0.0f, 100.0f );
As others said, zNear is zero so your matrix is not invertible.
I guess perspective should warn about that.
Re: I think Associative Array should throw Exception
On 9/4/20 1:48 AM, Jesse Phillips wrote:
On Thursday, 3 September 2020 at 15:12:14 UTC, Steven Schveighoffer wrote:
int[int] aa;
aa[4] = 5;
auto b = aa[4];
How is this code broken? It's valid, will never throw, and there's no
reason that we should break it by adding an exception into the mix.
int foo() nothrow {
return "1".to!int;
}
The following code is valid, will never throw, why does the compiler
prevent it?
You are still missing the point ;)
Your example doesn't compile today. Mine does. It's not a question of
which way is better, but that we already have code that depends on the
chosen solution, and changing now means breaking all such existing code.
My point of bringing up the example is that your assertion that "it is
already broken" isn't true.
To put it another way, if the above to!int call compiled, and we
switched to exceptions, it would be the same problem, even if the right
choice is to use Exceptions.
-Steve
Re: I think Associative Array should throw Exception
On Tuesday, 1 September 2020 at 18:20:17 UTC, Jesse Phillips wrote: This is going to be a hard one for me to argue but I'm going to give it a try. Today if you attempt to access a key from an associative array (AA) that does not exist inside the array, a RangeError is thrown. This is similar to when an array is accessed outside the bounds. [...] I don't have an issue with the normal array RangeError, there is a clear means for claiming your access is a programming bug. However associative arrays tend to have both the key and value as "input." [...] Is it recoverable? I would say yes. We aren't actually trying to access memory outside the application ownership, we haven't put the system state into a critical situation (out of memory). And a higher portion of the code could easily decide to take a different path due to the failure of its call. Any time you have an operation that can only succeed if some precondition is met, there are two possible ways you can implement it: 1. Make it the caller's responsibility to check the precondition. 2. Make it the function's responsibility to check the precondition. If you have version #1, you can always use it to implement version #2, but the converse is not true. So, while you would ideally provide both versions and let the user choose the one they prefer, you should always *at least* provide version #1. In this case, for D's associative arrays, the [] operator is version #1. You could make a reasonable case that the [] operator should have been reserved for version #2, and version #1 should have been named something else, but at this point, it's not worth breaking backwards compatibility to change it.
Re: tupleof seems to break encapsulation
On Fri, Sep 04, 2020 at 07:36:00PM +0200, Jacob Carlborg via Digitalmars-d-learn wrote: [...] > It's useful for serialization and, as you can see in your example, for > debugging as well. `writeln` will print the values of the fields in a > struct, even for private fields. It's certainly useful, but violates private. I'd propose restricting it to -debug or at the very least @system, so that normal @safe code will behave as expected. T -- It's amazing how careful choice of punctuation can leave you hanging:
Re: tupleof seems to break encapsulation
On Friday, 4 September 2020 at 18:23:09 UTC, H. S. Teoh wrote: On Fri, Sep 04, 2020 at 07:36:00PM +0200, Jacob Carlborg via Digitalmars-d-learn wrote: [...] It's useful for serialization and, as you can see in your example, for debugging as well. `writeln` will print the values of the fields in a struct, even for private fields. It's certainly useful, but violates private. I'd propose restricting it to -debug or at the very least @system, so that normal @safe code will behave as expected. T Previously: https://issues.dlang.org/show_bug.cgi?id=19326 https://issues.dlang.org/show_bug.cgi?id=20941
Re: tupleof seems to break encapsulation
On 2020-09-04 12:16, 60rntogo wrote:
Consider the following code.
foo.d
---
module foo;
struct Foo
{
private int i;
}
---
main.d
---
void main()
{
import std.stdio;
import foo;
auto x = Foo();
writeln(x);
// ++x.i;
++x.tupleof[0];
writeln(x);
}
---
As expected, the commented line does not compile. If I uncomment it, I
get the error "no property i for type foo.Foo". However, the rest of the
code compiles just fine and outputs:
---
Foo(0)
Foo(1)
---
This appears to defeat the purpose of declaring i private. What am I
missing?
It's useful for serialization and, as you can see in your example, for
debugging as well. `writeln` will print the values of the fields in a
struct, even for private fields.
--
/Jacob Carlborg
