Re: Function parameter type inference: is this example working as intended?
On Tuesday, September 4, 2018 8:33:47 PM MDT Nathan S. via Digitalmars-d-
learn wrote:
> The below writes "uint". Is this working as intended?
> https://run.dlang.io/is/Dx2e7f
>
> ---
> import std.stdio;
>
> auto foo(T = uint)(uint x)
> {
> return T.stringof;
> }
>
> auto foo(T = ulong)(ulong x)
> {
> return T.stringof;
> }
>
> void main()
> {
> writeln(foo(10L));
> }
> ---
Probably, though personally, I'm inclined to think that it should pick the
second. It's clearly using VRP to decide that 10L fits in a uint. If you
pick something like
writeln(foo(99L));
then it will call the ulong overload. Either way, since a long is neither a
uint or a ulong, it has to pick which overload it thinks is better. It would
seem to me that ulong would be closer (and if VRP weren't involved, it would
pick the ulong overload), but given that it knows what the value is, it
knows that either can work.
Unfortunately, searching through the spec, I don't see anything in it
mentioning either VRP or Value Range Propagation, so it doesn't look like
the correct behavior is actually spec-ed out. It could be that it works the
way it does in this case because of an intentional choice, or it could just
be the consequence of logic choices that make sense in other contexts but
not so much here. Personally, I would argue that VRP shouldn't come into
play if it's not necessary, but I don't know what the actual rules for it
are.
I suggest that you report this as a potential bug. At minimum, the spec
needs to be updated with the rules for VRP.
- Jonathan M Davis
Re: Function parameter type inference: is this example working as intended?
On Wednesday, 5 September 2018 at 02:33:47 UTC, Nathan S. wrote: The below writes "uint". Is this working as intended? https://run.dlang.io/is/Dx2e7f Note that it's called not with a `ulong` literal but with a `long` literal.
Function parameter type inference: is this example working as intended?
The below writes "uint". Is this working as intended?
https://run.dlang.io/is/Dx2e7f
---
import std.stdio;
auto foo(T = uint)(uint x)
{
return T.stringof;
}
auto foo(T = ulong)(ulong x)
{
return T.stringof;
}
void main()
{
writeln(foo(10L));
}
---
Re: How to use listener.d example?
https://drive.google.com/open?id=1Qo6BYIZjaoxL_Z0TS9-vAN4ZgbTepkcR I've reinstalled in other location and rewrite whole example. I still get optlink error http://www.digitalmars.com/ctg/optlink.html
Re: Mutable ForwardRange save() method not callable using const object
On Tuesday, September 4, 2018 9:22:26 AM MDT Timoses via Digitalmars-d-learn wrote: > On Tuesday, 4 September 2018 at 14:26:44 UTC, Steven > > Schveighoffer wrote: > > [...] > > As general advice, I wouldn't expect const to work well with > > Ranges anyway -- const ranges are useless (you can't iterate > > them). So not much code is expecting to handle const, including > > the wrappers that Phobos provides. > > Thanks, that sounds like some good advice. I've actually bumped > into this right after when I had an immutable range which was > supposed to fill in its cache when being iterated. > My argument for why this should work is that "from the outside of > the range" it is immutable, since accessing via opIndex will > always give the same value. > ... In the end, that'll lead nowhere. The immutable attribute > would become a "promise" rather than an enforcement (or too hard > for the compiler to enforce). That's simply not how const or immutable work in D though. They're actual compiler guarantees, and it's undefined behavior to ever cast away const or immutable and mutate the object. D's const is fundamentally different from C++'s const in this regard. Not only is a const that doesn't provide compiler guarantees useless according to Walter (though that's obviously debatable), but the nature of immutable pretty much requires it. immutable objects are implicitly shared, and in principle, they could end up in ROM. So, even if your object is const, there's no guarantee that it's actually mutable underneath the hood. The rigidness of D's const and immutable are both a blessing and a curse. But the net result is we really can't have a range API that works with them without more of a head/tail model (whereas the current API mutates in place), and even if we had a head/tail model, it would still get pretty hairy thanks to issues like reference counting. So, as Steven points out, const and ranges don't go together at all. The result is that a number of us use stuff like const and inout pretty sparingly (at least outside of primitive types): http://jmdavisprog.com/articles/why-const-sucks.html - Jonathan M Davis
Re: How to use listener.d example?
https://drive.google.com/open?id=1hC5SZ3VWX0iQoUO7KN0S-743x6FG9ER5 I give up Cant compile this vibe-d Ill get back to phobos
Re: C++ GLM(OpenGL Mathematics) D Equivalent.
On 04.09.2018 22:23, SrMordred wrote: Most C++ game related projects uses GLM as they default math/vector lib (even if not using opengl). In D we have (that I found): gfm.math - https://github.com/d-gamedev-team/gfm dlib.math - https://github.com/gecko0307/dlib Gl3n - https://github.com/Dav1dde/gl3n But i'm not sure which to pick. Can someone point me out some reasons to use one over the other? (or show some differences) I´m expecting something of equivalent functions and performance as c++ glm. Thank you! I use gfm.math. It works great. I used gl3n before but left it for gfm.math. dlib seems pretending to be a framework. I don't like frameworks.
Re: C++ GLM(OpenGL Mathematics) D Equivalent.
On Tuesday, 4 September 2018 at 19:23:16 UTC, SrMordred wrote: Most C++ game related projects uses GLM as they default math/vector lib (even if not using opengl). In D we have (that I found): gfm.math - https://github.com/d-gamedev-team/gfm dlib.math - https://github.com/gecko0307/dlib Gl3n - https://github.com/Dav1dde/gl3n But i'm not sure which to pick. Can someone point me out some reasons to use one over the other? (or show some differences) I´m expecting something of equivalent functions and performance as c++ glm. Thank you! I use dlib.math for my 3D engine. It's working fairly well, can't complain. No clue about gfm. Gl3n is nice, but it has a design flaw - it's using row-major matrix ordering. It may or may not be a big deal for you, but in general, it means that all matrices being sent to OpenGL need to be transposed, and the matrix multiplication order is reversed. Another advantage of dlib.math is that it has some extended features, such as support for calculating tangents for a mesh.
C++ GLM(OpenGL Mathematics) D Equivalent.
Most C++ game related projects uses GLM as they default math/vector lib (even if not using opengl). In D we have (that I found): gfm.math - https://github.com/d-gamedev-team/gfm dlib.math - https://github.com/gecko0307/dlib Gl3n - https://github.com/Dav1dde/gl3n But i'm not sure which to pick. Can someone point me out some reasons to use one over the other? (or show some differences) I´m expecting something of equivalent functions and performance as c++ glm. Thank you!
Re: Mutable ForwardRange save() method not callable using const object
On Tuesday, 4 September 2018 at 14:26:44 UTC, Steven Schveighoffer wrote: [...] As general advice, I wouldn't expect const to work well with Ranges anyway -- const ranges are useless (you can't iterate them). So not much code is expecting to handle const, including the wrappers that Phobos provides. Thanks, that sounds like some good advice. I've actually bumped into this right after when I had an immutable range which was supposed to fill in its cache when being iterated. My argument for why this should work is that "from the outside of the range" it is immutable, since accessing via opIndex will always give the same value. ... In the end, that'll lead nowhere. The immutable attribute would become a "promise" rather than an enforcement (or too hard for the compiler to enforce). Thanks for the clarification, Steve!
Re: Mutable ForwardRange save() method not callable using const object
On 9/4/18 9:53 AM, Timoses wrote: Hey, I'm fiddling around with ranges a bit and am wondering why save is not callable on a const object: ... I could imagine that save is not marked as const because it is uncertain whether any indirections are part of the content..? But couldn't the compiler check that? But you have eliminated any visibility into the range itself -- you stuck it behind an interface. Could anybody explain what exactly is going on? Is there a reason the `save()` is not working on const objects? The trivial reason is because the method is not marked const: https://github.com/dlang/phobos/blob/master/std/range/interfaces.d#L153 The real reason is that given a const interface, everything inside it must be const as well. Making a copy of that makes a const copy, which by definition couldn't be assigned back to the original range (which is likely not const). At the very least, it should be inout. But in either case, the function needs to be properly marked. As general advice, I wouldn't expect const to work well with Ranges anyway -- const ranges are useless (you can't iterate them). So not much code is expecting to handle const, including the wrappers that Phobos provides. -Steve
Mutable ForwardRange save() method not callable using const object
Hey,
I'm fiddling around with ranges a bit and am wondering why save
is not callable on a const object:
class Range
{
ForwardRange!(const uint) offsets;
this(const S s)
{
this.offsets = s.s.map!(e => e.i).inputRangeObject;
}
this(const Range a) // ERROR line 22
{
this.offsets = a.offsets.save;
}
Range save()
{
return new Range(this);
}
}
struct I
{
uint i;
}
struct S
{
I[] s = [I(1), I(2), I(3)];
}
unittest
{
S s;
auto a = new Range(s);
}
onlineapp.d(22): Error: mutable method
std.range.interfaces.ForwardRange!(const(uint)).ForwardRange.save
is not callable using a const object
onlineapp.d(22):Consider adding const or inout to
std.range.interfaces.ForwardRange!(const(uint)).ForwardRange.save
In this case the Forwardrange Offsets is a
ForwardRange of MapResult(I => uint) of I[]
Since the type of MapResult.front is uint, the ForwardRange is
essentially a uint[] array.
I could imagine that save is not marked as const because it is
uncertain whether any indirections are part of the content..? But
couldn't the compiler check that?
Could anybody explain what exactly is going on? Is there a reason
the `save()` is not working on const objects?
Given that I haven't done much with ranges yet, any feedback on
the above implementation is also greatly appreciated (it's just a
reduced example).
Re: Struct immutable data and dict
On Tuesday, 4 September 2018 at 12:27:47 UTC, nkm1 wrote:
I also had this problem recently. I think aa.require() should
allow to add immutables (feature request). Anyway, my
workaround was along the lines of:
final class AA(Key, Value)
{
Value[] _storage;
size_t[Key] _aa;
void opIndexAssign(Value value, Key key)
{
if (key !in _aa)
{
_storage ~= value;
_aa[key] = _storage.length - 1;
}
}
Value opIndex(Key key)
{
if (auto index = key in _aa)
return _storage[*index];
throw new Exception("no key");
}
}
immutable struct S
{
int num;
}
void main()
{
import std.stdio : writeln;
auto aa = new AA!(string, S);
aa["one"] = S(1);
aa["two"] = S(2);
writeln(aa["one"]);
writeln(aa["two"]);
}
Thanks for the replies. It seems quite annoying.
I just use classes for now.
Re: How to use listener.d example?
On 05/09/2018 12:10 AM, Marcin wrote: "" Am i doing it right? I've unpacked vibe.d-master to my "C:\D\dtwo\src" commands in cmd: cd C:\D\dtwo\windows\bin\ echo "vibe.d-master is a folder" dmd -lib C:\D\dtwo\src\vibe.d-master\core\vibe\appmain.d C:\D\dtwo\src\vibe.d-master\http\vibe\http\server.d no wai, Ill just paste the vibe.d-master to my code location and add more arguments. dub fetch vibe-d downloaded something dub run vibe-d runs something dub test vibe-d vibe-d:redis 0.8.4: building configuration "library"... vibe-d:web 0.8.4: building configuration "library"... vibe-d 0.8.4: building configuration "vibe-d-test-vibe-core"... Linking... Error: linker exited with status 1 C:\D\dtwo\windows\bin\dmd.exe failed with exit code 1. still don't work I love programming... after 37 h of tryin to force run compiler. You didn't need to download or manually fetch vibe-d yourself (it won't work this way FYI). Just make sure dmd (windows/bin directory) is on your PATH variable, and you're good to go for the below example. $ cd c:/projects/test_vibed $ dub init json someprojectname my description Marcin proprietary Copyright 2018 vibe-d \n $ dub run
Re: Struct immutable data and dict
On Tuesday, 4 September 2018 at 11:25:15 UTC, Alex wrote:
On Tuesday, 4 September 2018 at 10:30:24 UTC, Timoses wrote:
However, of course this also fails because randomly assigning
the array elements will overwrite it. So the associative array
seems like the better idea. However, not being able to
INITIALIZE an assoc array element disallows its usage.
Is there any solution, trick or workaround??
I tried two workarounds:
1) let the immutable away.
2) preallocate a full array of immutables. Then, misuse the
assoc array by using the keys only. If the key is there, then,
yield the appropriate element from the preallocated array. If
not, yield the "elephant in Cairo".
I also had this problem recently. I think aa.require() should
allow to add immutables (feature request). Anyway, my workaround
was along the lines of:
final class AA(Key, Value)
{
Value[] _storage;
size_t[Key] _aa;
void opIndexAssign(Value value, Key key)
{
if (key !in _aa)
{
_storage ~= value;
_aa[key] = _storage.length - 1;
}
}
Value opIndex(Key key)
{
if (auto index = key in _aa)
return _storage[*index];
throw new Exception("no key");
}
}
immutable struct S
{
int num;
}
void main()
{
import std.stdio : writeln;
auto aa = new AA!(string, S);
aa["one"] = S(1);
aa["two"] = S(2);
writeln(aa["one"]);
writeln(aa["two"]);
}
Re: How to use listener.d example?
"" Am i doing it right? I've unpacked vibe.d-master to my "C:\D\dtwo\src" commands in cmd: cd C:\D\dtwo\windows\bin\ echo "vibe.d-master is a folder" dmd -lib C:\D\dtwo\src\vibe.d-master\core\vibe\appmain.d C:\D\dtwo\src\vibe.d-master\http\vibe\http\server.d no wai, Ill just paste the vibe.d-master to my code location and add more arguments. dub fetch vibe-d downloaded something dub run vibe-d runs something dub test vibe-d vibe-d:redis 0.8.4: building configuration "library"... vibe-d:web 0.8.4: building configuration "library"... vibe-d 0.8.4: building configuration "vibe-d-test-vibe-core"... Linking... Error: linker exited with status 1 C:\D\dtwo\windows\bin\dmd.exe failed with exit code 1. still don't work I love programming... after 37 h of tryin to force run compiler.
Re: Struct immutable data and dict
On Tuesday, 4 September 2018 at 10:30:24 UTC, Timoses wrote:
However, of course this also fails because randomly assigning
the array elements will overwrite it. So the associative array
seems like the better idea. However, not being able to
INITIALIZE an assoc array element disallows its usage.
Is there any solution, trick or workaround??
If the initialization of assoc array is not the matter, but the
initialization of an element of it, then, the question is rather:
"Is the absence of an immutable value in an assoc array worth to
be garanteed, because the values are immutable?" Isn't it?
No idea about this :p
´´´
void main()
{
import std.stdio;
auto r = Range("dummy");
r.fun(3).writeln;
}
struct Res
{
immutable int i;
}
struct Range
{
this(string)
{
c = [0 : Res(42), 5: Res(73), /*3: Res(4)*/];
}
Res[size_t] c;
Res fun(size_t i)
{
if (auto p = i in c)
return *p;
else
{
//c[3] = Res(3); /// ERROR line 26
return Res(int.max);
}
}
}
´´´
I tried two workarounds:
1) let the immutable away.
2) preallocate a full array of immutables. Then, misuse the assoc
array by using the keys only. If the key is there, then, yield
the appropriate element from the preallocated array. If not,
yield the "elephant in Cairo".
Re: How to use listener.d example?
On 04/09/2018 10:57 PM, Marcin wrote: On Friday, 31 August 2018 at 07:38:54 UTC, Marcin wrote: https://github.com/dlang/dmd/blob/master/samples/listener.d Im using Notepad++ as my IDE cuz i dont have administrator privileges on PC Coedit is a good option since it is a simple unzip and ready to go. Although less than ugh "normal" but still a good option when nothing else decent exists. https://github.com/BBasile/Coedit To import modules i use -I option cmd /k cd C:\D\dtwo\windows\bin\ & C:\D\dtwo\windows\bin\dmd.exe -I="$(CURRENT_DIRECTORY)" "$(FULL_CURRENT_PATH)" & C:\D\dtwo\windows\bin\$(NAME_PART).exe -I is only for directories and the modules contained must be already compiled and ready to be linked in. C:\Users\wjelki\Desktop\d\aplikacja.d(2): Error: module `server` is in file 'vibe\http\server.d' which cannot be read import path[0] = C:\Users\wjelki\Desktop\d\vibe.d\core import path[1] = .\..\..\src\phobos import path[2] = .\..\..\src\druntime\import How to import other modules than Phobos? For vibe.d use the build manager dub and yes dmd comes with it already. But the general way to do it straight is: dmd -of mylib.lib -lib a/filea.d a/fileb.d dmd -of myprog.exe mylib.lib b/filec.d -I a Of course that is off the top of my head and I only ever use dub so... take that with a grain of salt.
Re: How to use listener.d example?
On Friday, 31 August 2018 at 07:38:54 UTC, Marcin wrote: https://github.com/dlang/dmd/blob/master/samples/listener.d Im using Notepad++ as my IDE cuz i dont have administrator privileges on PC To import modules i use -I option cmd /k cd C:\D\dtwo\windows\bin\ & C:\D\dtwo\windows\bin\dmd.exe -I="$(CURRENT_DIRECTORY)" "$(FULL_CURRENT_PATH)" & C:\D\dtwo\windows\bin\$(NAME_PART).exe C:\Users\wjelki\Desktop\d\aplikacja.d(2): Error: module `server` is in file 'vibe\http\server.d' which cannot be read import path[0] = C:\Users\wjelki\Desktop\d\vibe.d\core import path[1] = .\..\..\src\phobos import path[2] = .\..\..\src\druntime\import How to import other modules than Phobos?
Re: Struct immutable data and dict
On Thursday, 6 October 2016 at 02:09:44 UTC, Adam D. Ruppe wrote:
On Thursday, 6 October 2016 at 01:23:35 UTC, Patric Dexheimer
wrote:
Why?
Because you'd be overwriting that immutable member. Structs
just put structure around their contents, but it doesn't change
their nature. That struct is no different than if you wrote
`immutable size_t` as the value - and of course, overwriting
that; changing that violates that promise that you won't change
it.
You could store pointers to those structs though, and overwrite
the pointer.
Hm... so is there any way around this?
In my case I have a RandomAccessRange which caches it's results.
Reduced example:
struct Res
{
immutable int i;
}
struct Range
{
Res[size_t] c;
Res fun(size_t i)
{
if (auto p = i in c)
return *p;
else
{
c[3] = Res(3); /// ERROR line 26
return c[3];
}
}
}
unittest
{
auto r = Range();
r.fun(3);
}
which errors at compilation with
onlineapp.d(26): Error: cannot modify struct this.c[3] Res with
immutable members
A workaround I thought could be to use an array
struct Range
{
//Res[size_t] c;
struct Con { Res c; bool valid; }
Con[] c;
Res fun(size_t i)
{
if (c.length > i && c[i].valid)
return c[i].c;
else
{
if (c.length <= i) c.length = i + 1;
auto r = Con(Res(3), true);
c[i] = r; /// same ERROR!
return c[i].c;
}
}
}
However, of course this also fails because randomly assigning the
array elements will overwrite it. So the associative array seems
like the better idea. However, not being able to INITIALIZE an
assoc array element disallows its usage.
Is there any solution, trick or workaround??
Re: Is there any reason to use non-ref foreach?
On Tuesday, 4 September 2018 at 08:17:14 UTC, Andrea Fontana wrote: Waiting for this to be merged: https://github.com/dlang/dmd/pull/8437 Well, it seems Andrei has already approved the concept. well, THAT is a good reason to avoid this paradigm. Thanks for the info.
Re: Is there any reason to use non-ref foreach?
On Tuesday, 4 September 2018 at 07:06:43 UTC, Dukc wrote: On Monday, 3 September 2018 at 13:34:36 UTC, Andrea Fontana wrote: On Friday, 31 August 2018 at 09:59:20 UTC, Dukc wrote: For me, it seems that for generality you should always add ref into foreach loop variable. The reason is this: One good reason: https://forum.dlang.org/thread/dlhrrgvzmhladnphi...@forum.dlang.org I am almost sure it will stay how it is, because of the sheer amount of breakage changing that would cause. I still agree that in princliple, the general way to iterate should be something else (auto ref?). But as with autodecoding, the present way is already in too wide use to be worth changing. But I think we need an official line to confirm whether one can use that without risking a deprectation. Waiting for this to be merged: https://github.com/dlang/dmd/pull/8437
Re: Is there any reason to use non-ref foreach?
On Monday, 3 September 2018 at 13:34:36 UTC, Andrea Fontana wrote: On Friday, 31 August 2018 at 09:59:20 UTC, Dukc wrote: For me, it seems that for generality you should always add ref into foreach loop variable. The reason is this: One good reason: https://forum.dlang.org/thread/dlhrrgvzmhladnphi...@forum.dlang.org I am almost sure it will stay how it is, because of the sheer amount of breakage changing that would cause. I still agree that in princliple, the general way to iterate should be something else (auto ref?). But as with autodecoding, the present way is already in too wide use to be worth changing. But I think we need an official line to confirm whether one can use that without risking a deprectation.
Re: assumeNoGC works but can't get an assumePure to work
On Tuesday, 4 September 2018 at 01:33:52 UTC, Paul Backus wrote: On Monday, 3 September 2018 at 22:07:10 UTC, aliak wrote: Why does it work with nogc but not with pure? Cheers, - Ali You can't define an impure function inside a pure unittest. If you move `modify` outside the unittest block, and change the argument from a lambda to a function pointer, it works: https://run.dlang.io/is/xRS75H Seems you be right. Hmm, I wonder if it's a bug because you can define a non-nogc function inside a nogc block :/
