Is there a way to identfy Windows version?
Is there a way to identify the Windows version? Such as if it's XP, Vista, 7, 8 or 10? Either some way to tweak with version flags or something in the standard library.
Re: Is there a way to identfy Windows version?
On Monday, November 21, 2016 08:57:11 Bauss via Digitalmars-d-learn wrote: > Is there a way to identify the Windows version? Such as if it's > XP, Vista, 7, 8 or 10? Either some way to tweak with version > flags or something in the standard library. Phobos doesn't have anything like that, but you can use the C functions from the Windows API to do it. A quick search turned up GetVersion and GetVersionExA/W: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724439(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx Bindings for those seems to be in core.syse.windows.winbase. So, if you import it, you can call them. There are also these functions https://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx but druntime doesn't seem to have bindings for them at the moment. So, if you want to use them, you'll either have to declare the bindings yourself or find a project that already did. Looking at code.dlang.org, there's this one: http://code.dlang.org/packages/windows-headers Someone may have a better suggestion though if you're looking for a fuller set of Windows bindings (the ones in druntime have improved over time, but they're still missing a lot). Personally, I don't do much with Windows and D. So, I'm not well-versed with the best way to get the bindings for the Windows API. Ultimately though, the answer to your question is that you're going to need to call Microsoft's C functions using D bindings to those functions. - Jonathan M Davis
null this
Hello,
how can calling method on local struct throw "null this"?
struct is initialized by .init and have default values.
struct Foo {
Bar bar;
static struct Bar {
float x, y, z;
}
Bar getBar() {
return bar;
}
}
then
Foo foo = Foo.init;
auto b = foo.getBar(); // throw "null this"
Re: null this
cast(ulong)&foo but is not null. It won't work just in special cases what I cannot reproduce easily.
Re: null this
On 21/11/2016 11:25 PM, Satoshi wrote:
Hello,
how can calling method on local struct throw "null this"?
struct is initialized by .init and have default values.
struct Foo {
Bar bar;
static struct Bar {
float x, y, z;
}
Bar getBar() {
return bar;
}
}
then
Foo foo = Foo.init;
auto b = foo.getBar(); // throw "null this"
Well that code definitely works fine as is.
Perhaps remove that static, it makes me a little queasy just looking at it.
Also no need to set foo to Foo.init, it already is that value.
Re: Memory allocation failed. Why?
On 11/21/2016 08:27 AM, Stefan Koch wrote: Someone could still be hanging on to an old Reference of buf. Who could "someone" be? It's a self-contained example, and buf doesn't leave the test function.
Re: null this
On Monday, 21 November 2016 at 10:25:17 UTC, Satoshi wrote:
Hello,
how can calling method on local struct throw "null this"?
struct is initialized by .init and have default values.
struct Foo {
Bar bar;
static struct Bar {
float x, y, z;
}
Bar getBar() {
return bar;
}
}
then
Foo foo = Foo.init;
auto b = foo.getBar(); // throw "null this"
I had
auto ref getBar() inout {
return bar;
}
in which was problem. When I separated it into 2 funcs get/set it
works fine.
Re: the best language I have ever met(?)
On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote: On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote: Please don't post non-d. it slipped accidentally, sorry. ;-) for OP: `uint[2] a = [42, 69];` is the correct syntax. "uint[$] a = [42, 69];" haha for a moment I thought that this was the way of D to create a fixed-size array without explicit setting the size (like what u can do in c++ :))
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:08:30 UTC, Patric Dexheimer wrote: On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote: On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch wrote: Please don't post non-d. it slipped accidentally, sorry. ;-) for OP: `uint[2] a = [42, 69];` is the correct syntax. "uint[$] a = [42, 69];" haha for a moment I thought that this was the way of D to create a fixed-size array without explicit setting the size (like what u can do in c++ :)) That was a proposal for D that was rejected in the last moment by Andrei. My guess is that ketmar's modified dmd has that feature implemented.
Re: the best language I have ever met(?)
On Monday, November 21, 2016 12:08:30 Patric Dexheimer via Digitalmars-d- learn wrote: > On Saturday, 19 November 2016 at 00:47:00 UTC, ketmar wrote: > > On Saturday, 19 November 2016 at 00:28:36 UTC, Stefan Koch > > > > wrote: > >> Please don't post non-d. > > > > it slipped accidentally, sorry. ;-) > > > > for OP: `uint[2] a = [42, 69];` is the correct syntax. > > "uint[$] a = [42, 69];" > > haha for a moment I thought that this was the way of D to create > a fixed-size array without explicit setting the size (like what u > can do in c++ :)) No. D doesn't have that, though it's easy enough to do the same thing with a helper template. However, Ketmar seems to like to use his own fork of dmd where he made changes to the language based on his preferences. IIRC, it was proposed at one point that $ be used in this manner to create a static array while inferring its size (it might have even had a PR which was rejected), and presumably, Ketmar added it to his own compiler, because he liked the feature. But for better or worse, it's not standard D, and if the PR was rejected like I think it was, then it likely never will become standard D. Someone could create a DIP for it though and argue for it. If they did that convincingly enough, maybe it would become a feature. I suspect that the response will be though that since it's easy enough to just create a template to do the same thing, it's not worth adding to the language. - Jonathan M Davis
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote: On Monday, November 21, 2016 12:08:30 Patric Dexheimer via Digitalmars-d- learn wrote: No. D doesn't have that, though it's easy enough to do the same thing with a helper template. However, Ketmar seems to like to use his own fork of dmd where he made changes to the language based on his preferences. IIRC, it was proposed at one point that $ be used in this manner to create a static array while inferring its size (it might have even had a PR which was rejected), and presumably, Ketmar added it to his own compiler, because he liked the feature. But for better or worse, it's not standard D, and if the PR was rejected like I think it was, then it likely never will become standard D. Someone could create a DIP for it though and argue for it. If they did that convincingly enough, maybe it would become a feature. I suspect that the response will be though that since it's easy enough to just create a template to do the same thing, it's not worth adding to the language. - Jonathan M Davis https://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits
Enumerate CTFE bug...
I'm not sure if it's the same as #15064 bug:
import std.array, std.range, std.algorithm;
immutable static foo = ["a", "b", "c"];
auto bar(R)(R r)
{
string s = r[1];
return s;
}
immutable static res = foo.enumerate.map!bar().array;
std/typecons.d(526): Error: reinterpreting cast from
inout(ulong)* to inout(Tuple!(ulong, immutable(string)))* is not
supported in CTFE
bug.d(9):called from here: r._Tuple_super()
std/algorithm/iteration.d(593):called from here:
bar(this._input.front())
std/array.d(105):called from here: __r2091.front()
bug.d(15):called from here: array(map(enumerate(foo,
0LU)))
---
Paolo
RDMD can't eval code because of missing cstream module
I'm having trouble evaluating basic code with rdmd. It's
complaining that std/cstream.d does not exist. I checked, and
surely enough, it doesn't. My question is why is it looking for
cstream.d? Is rdmd out of date, or is there a problem with my dmd
install? I am on OSX 10.12.1 (Sierra) and installed dmd using
Homebrew.
Here's the terminal output:
$ rdmd --eval="void main(){}"
/var/folders/q_/qpqhvkv57g36j1bq8qpm_mzwgn/T/.rdmd-501/eval.4090CC8525DF4BDD8D9084D5F66EDA46.d(6):
Error: module cstream is in file 'std/cstream.d' which cannot be read
import path[0] =
/var/folders/q_/qpqhvkv57g36j1bq8qpm_mzwgn/T/.rdmd-501
import path[1] = /usr/local/Cellar/dmd/2.072.0/include/dlang/dmd
Failed: ["dmd", "-d", "-v", "-c",
"-of/var/folders/q_/qpqhvkv57g36j1bq8qpm_mzwgn/T/.rdmd-501/rdmd-eval.4090CC8525DF4BDD8D9084D5F66EDA46.d-35D613BB32BCB7BD6CC007543108437C/objs/eval.4090CC8525DF4BDD8D9084D5F66EDA46.o", "/var/folders/q_/qpqhvkv57g36j1bq8qpm_mzwgn/T/.rdmd-501/eval.4090CC8525DF4BDD8D9084D5F66EDA46.d", "-I/var/folders/q_/qpqhvkv57g36j1bq8qpm_mzwgn/T/.rdmd-501"]
Re: Enumerate CTFE bug...
On Monday, 21 November 2016 at 13:22:57 UTC, Paolo Invernizzi
wrote:
I'm not sure if it's the same as #15064 bug:
import std.array, std.range, std.algorithm;
immutable static foo = ["a", "b", "c"];
auto bar(R)(R r)
{
string s = r[1];
return s;
}
immutable static res = foo.enumerate.map!bar().array;
std/typecons.d(526): Error: reinterpreting cast from
inout(ulong)* to inout(Tuple!(ulong, immutable(string)))* is
not supported in CTFE
bug.d(9):called from here: r._Tuple_super()
std/algorithm/iteration.d(593):called from here:
bar(this._input.front())
std/array.d(105):called from here: __r2091.front()
bug.d(15):called from here: array(map(enumerate(foo,
0LU)))
---
Paolo
Yes looks like it.
Adding a special case in phobos should solve the problem.
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:42:34 UTC, ZombineDev wrote: That was a proposal for D that was rejected in the last moment by Andrei. My guess is that ketmar's modified dmd has that feature implemented. exactly. it is handy feature, so i used to it. and it slept into code (i usually test my code with rdmd before posting, but this time i forgot to specify --vanilla flag ;-).
Why don't Function Lambdas Cast to Delegate?
Why don't lambdas cast to a delegate if they are of type R function(Args)? I don't see any reason to that; a lambda should be a delegate type by default, and a function only as a special guarantee/optimization. It just makes them cumbersome to use with toDelegate. Probably there is a good reason why R function(Args) does not implicitly cast to R delegate(Args); I can imagine something internally (memory layout etc.) causes that. I'd just like to know.
Re: Why don't Function Lambdas Cast to Delegate?
On 11/21/16 11:24 AM, Q. Schroll wrote: Why don't lambdas cast to a delegate if they are of type R function(Args)? I don't see any reason to that; a lambda should be a delegate type by default, and a function only as a special guarantee/optimization. It just makes them cumbersome to use with toDelegate. Probably there is a good reason why R function(Args) does not implicitly cast to R delegate(Args); I can imagine something internally (memory layout etc.) causes that. I'd just like to know. The ABI for function calls is different than the ABI for delegate calls. I believe this is a necessary limitation due to ABIs on some platforms, but I'm not 100% sure. It could just be a legacy issue. -Steve
Re: Memory allocation failed. Why?
On Monday, 21 November 2016 at 11:22:40 UTC, ag0aep6g wrote: Who could "someone" be? It's a self-contained example, and buf doesn't leave the test function. Anything in .data and .bss sections and stack. See https://issues.dlang.org/show_bug.cgi?id=15723 As for GC compaction: https://issues.dlang.org/show_bug.cgi?id=3284
Re: Why don't Function Lambdas Cast to Delegate?
On Monday, 21 November 2016 at 16:24:38 UTC, Q. Schroll wrote: Why don't lambdas cast to a delegate if they are of type R function(Args)? I don't see any reason to that; a lambda should be a delegate type by default, and a function only as a special guarantee/optimization. It just makes them cumbersome to use with toDelegate. Probably there is a good reason why R function(Args) does not implicitly cast to R delegate(Args); I can imagine something internally (memory layout etc.) causes that. I'd just like to know. A delegate has the hidden context pointer as parameter in addition to the 'visible' parameters. That causes functions and delegates with the same declared params to look different on the ABI level.
Re: RDMD can't eval code because of missing cstream module
https://github.com/dlang/tools/commit/5ed4f176f41b7559c64cf525c07ccf13ca3a5160 this?
Re: Memory allocation failed. Why?
On Monday, 21 November 2016 at 16:37:32 UTC, Kagamin wrote: Anything in .data and .bss sections and stack. See https://issues.dlang.org/show_bug.cgi?id=15723 Ok, not an actual reference then, but a false pointer.
Converting all enum members to a string fails with version 2.0.72.0
Before 2.0.72.0:
import std.algorithm : map, joiner;
import std.uni : toUpper;
import std.traits : EnumMembers;
import std.stdio : writeln;
import std.conv: to;
private enum Color : string {
RED = "red",
BLUE = "blue",
YELLOW = "yellow"
}
void main(string[] args) {
writeln( [ EnumMembers!Color ].map!( toUpper ).joiner( ", "
).to!string );
}
printed:
RED, BLUE, YELLOW
Now I got the following compiler error:
C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\uni.d(8142,16): Error:
cannot implicitly convert expression (result.data()) of type string to Color
C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\uni.d(9030,51): Error:
template instance std.uni.toCase!(toUpperIndex, 1051, toUpperTab, toUpper,
Color) error instantiating
C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(593,19):
instantiated from here: toUpper!(Color)
C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(488,16):
instantiated from here: MapResult!(toUpper, Color[])
source\enums\enums.d(24,35):instantiated from here:
map!(Color[])
source\enums\enums.d(24,58): Error: template
std.algorithm.iteration.joiner cannot deduce function from
argument types !()(MapResult!(toUpper, Color[]), string),
candidates are:
C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(2050,6):
std.algorithm.iteration.joiner(RoR, Separator)(RoR r, Separator sep) if (isInputRange!RoR &&
isInputRange!(ElementType!RoR) && isForwardRange!Separator && is(ElementType!Separator
: ElementType!(ElementType!RoR)))
C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\algorithm\iteration.d(2333,6):
std.algorithm.iteration.joiner(RoR)(RoR r) if (isInputRange!RoR &&
isInputRange!(ElementType!RoR))
dmd failed with exit code 1.
Any idea how to fix it?
Thanks,
Stefan
Re: Converting all enum members to a string fails with version 2.0.72.0
On Monday, November 21, 2016 17:01:56 Stefan via Digitalmars-d-learn wrote:
> Before 2.0.72.0:
>
> import std.algorithm : map, joiner;
> import std.uni : toUpper;
> import std.traits : EnumMembers;
> import std.stdio : writeln;
> import std.conv: to;
>
> private enum Color : string {
> RED = "red",
> BLUE = "blue",
> YELLOW = "yellow"
> }
>
>
> void main(string[] args) {
> writeln( [ EnumMembers!Color ].map!( toUpper ).joiner( ", "
> ).to!string );
> }
>
> printed:
> RED, BLUE, YELLOW
>
> Now I got the following compiler error:
> C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\uni.d(8142,16):
> Error: cannot implicitly convert expression (result.data()) of type
> string to Color
> C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\uni.d(9030,51):
> Error: template instance std.uni.toCase!(toUpperIndex, 1051, toUpperTab,
> toUpper, Color) error instantiating
> C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\algorithm\iterati
> on.d(593,19):instantiated from here: toUpper!(Color)
> C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\algorithm\iterati
> on.d(488,16):instantiated from here: MapResult!(toUpper, Color[])
> source\enums\enums.d(24,35):instantiated from here:
> map!(Color[])
> source\enums\enums.d(24,58): Error: template
> std.algorithm.iteration.joiner cannot deduce function from
> argument types !()(MapResult!(toUpper, Color[]), string),
> candidates are:
> C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\algorithm\iteratio
> n.d(2050,6):std.algorithm.iteration.joiner(RoR, Separator)(RoR r,
> Separator sep) if (isInputRange!RoR && isInputRange!(ElementType!RoR) &&
> isForwardRange!Separator && is(ElementType!Separator :
> ElementType!(ElementType!RoR)))
> C:\develop\dmd-2.072.0\windows\bin\..\..\src\phobos\std\algorithm\iterati
> on.d(2333,6):std.algorithm.iteration.joiner(RoR)(RoR r) if
> (isInputRange!RoR && isInputRange!(ElementType!RoR)) dmd failed with exit
> code 1.
>
> Any idea how to fix it?
Casting [EnumMembers!Color] to string[] will probably do it as would using
toUpper!string instead of toUpper. I think that the problem has to do with
Color not being an actual range, but it passes isSomeString, resulting in a
an ugly situation where the code basically assumes that it's dealing with a
string when it isn't really, and the code doesn't actually work with an
enum. Prior to 2.072.0, there was an overload for toUpper that took string
as an optimization but that inadvertently meant that types that implicitly
converted to strings worked with it and were converted to string, whereas
with 2.072.0, they now have to pass isSomeString. In the case of a struct
that implicitly converts to string or a static array of characters, it would
now simply fails the template constraint and fail to compile, whereas for an
enum with a base type of string, it's in this weird in between land where it
passes isSomeString but really needs to actually be converted to string to
work as a range. So, instead of failing the template constraint, it hits an
error inside of the std.uni stuff. I think that the change is getting
reverted for 2.072.1, because it broke existing code, but for now at least,
enums aren't going to work with toUpper or toLower.
Unfortunately, templated code that deals with strings needs to be _really_
careful about how it deals with enums with a base type of string, because
they pass isSomeString but aren't actually strings (which is great for code
that doesn't use the range API but falls flat on its face for code that does
use the range API). Static arrays and structs which implicitly convert to
strings have the same problem, but at least they don't pass isSomeString.
In general, any type which implicitly converts to another type really needs
to have that coversion forced with generic code that wants the converted
type; otherwise, it's going to have a tendency to fall flat on its face.
- Jonathan M Davis
Re: RDMD can't eval code because of missing cstream module
On Monday, 21 November 2016 at 16:44:34 UTC, Kagamin wrote: https://github.com/dlang/tools/commit/5ed4f176f41b7559c64cf525c07ccf13ca3a5160 this? That seems like a probable cause, but where is cstream being referenced? I did github search for cstream and all it came up with were references from Undead (legacy Phobos library) and in makefiles. I'm not a make expert, but I don't think these are the cause. https://github.com/search?q=org%3Adlang+cstream&type=Code
Re: RDMD can't eval code because of missing cstream module
On Monday, 21 November 2016 at 17:35:14 UTC, Meta wrote: On Monday, 21 November 2016 at 16:44:34 UTC, Kagamin wrote: https://github.com/dlang/tools/commit/5ed4f176f41b7559c64cf525c07ccf13ca3a5160 this? That seems like a probable cause, but where is cstream being referenced? I did github search for cstream and all it came up with were references from Undead (legacy Phobos library) and in makefiles. I'm not a make expert, but I don't think these are the cause. https://github.com/search?q=org%3Adlang+cstream&type=Code Actually, looks like this problem was fixed in rdmd master so I guess I will just wait for the next release.
Re: Converting all enum members to a string fails with version 2.0.72.0
On Monday, 21 November 2016 at 17:26:37 UTC, Jonathan M Davis wrote: On Monday, November 21, 2016 17:01:56 Stefan via Digitalmars-d-learn wrote: [...] [...] there was an overload for toUpper that took string as an optimization but that inadvertently meant that types that implicitly converted to strings worked with it and were converted to string, whereas with 2.072.0, they now have to pass isSomeString. [...] I think that the change is getting reverted for 2.072.1, because it broke existing code, but for now at least, enums aren't going to work with toUpper or toLower. [...] Indeed: https://issues.dlang.org/show_bug.cgi?id=16663
Re: Converting all enum members to a string fails with version 2.0.72.0
On Monday, 21 November 2016 at 17:26:37 UTC, Jonathan M Davis wrote: [...] Thanks Jonathan for the explanation. The cast works fine but feels "unsafe". I will wait for the next version. Stefan
How to muldiv in D?
Can't find a function for it.
implementing --version?
I would like to implement a "--version" switch for a command line application. Is there a clever way to do that without using the brain on every build? :) A dub-solution would be nice - but i didnt find it.
A simplification of the RvalueRef idiom
First, a reminder that we have this great resource of D idioms:
https://p0nce.github.io/d-idioms/#Rvalue-references:-Understanding-auto-ref-and-then-not-using-it
The link above has an idiom of mixing in a byRef() member function to a
struct. I think I've simplified the template by moving typeof(this)
inside it:
mixin template RvalueRef()// <-- DOES NOT TAKE A PARAMETER ANY MORE
{
alias T = typeof(this);
static assert (is(T == struct));
@nogc @safe
ref const(T) byRef() const pure nothrow return
{
return this;
}
}
struct Vector2f
{
float x, y;
this(float x, float y) pure nothrow
{
this.x = x;
this.y = y;
}
mixin RvalueRef;// <-- SIMPLER USE
}
void foo(ref const Vector2f pos)
{
writefln("(%.2f|%.2f)", pos.x, pos.y);
}
void main()
{
Vector2f v = Vector2f(42, 23);
foo(v); // Works
foo(Vector2f(42, 23).byRef); // Works as well, and use the
same function
}
Let me know if it's not the equivalent of the original.
Ali
Re: implementing --version?
On Monday, 21 November 2016 at 19:33:54 UTC, mab-on wrote: I would like to implement a "--version" switch for a command line application. Is there a clever way to do that without using the brain on every build? :) A dub-solution would be nice - but i didnt find it. There is a package in the dub registry called commando (https://code.dlang.org/packages/commando) for that. Example usage can be found at https://github.com/SirTony/commando/tree/master/examples/find. The README file describes the code found in the src folder.
Re: implementing --version?
On Monday, 21 November 2016 at 20:56:41 UTC, Karabuta wrote: There is a package in the dub registry called commando (https://code.dlang.org/packages/commando) for that. Hm.. maybe i explained it wrong. My problem is not to pass a argument to the application. What i want is a clever mechanism to store the SemVer (or Commit-ID) in the binary at compiletime - automatically. Otherwise i have to think to update a const in the code every time i build a new Version.
Re: How to muldiv in D?
On 11/21/2016 11:16 AM, Kagamin wrote:
Can't find a function for it.
Here is a draft adapted from the following page
http://stackoverflow.com/questions/14872499/is-there-an-equivalent-to-muldiv-for-linux
This draft works for signed types:
T mulDiv(T)(T number, T numerator, T denominator) {
static if (is (T == long)) {
static assert("Sorry, can't support long");
}
else static if (is (T == int)) {
alias InterimT = long;
}
else {
alias InterimT = int;
}
InterimT ret = number;
ret *= numerator;
ret /= denominator;
return cast(T)ret;
}
void main() {
int number = int.max / 2;
int numerator = 42;
int denominator = numerator * 2;
const correctResult = int.max / 4;
const wrongResult = number * numerator / denominator;
assert(mulDiv(number, numerator, denominator) == correctResult);
assert(wrongResult != correctResult);
}
Ali
Re: implementing --version?
On Monday, 21 November 2016 at 21:32:16 UTC, mab-on wrote:
What i want is a clever mechanism to store the SemVer (or
Commit-ID) in the binary at compiletime - automatically.
Otherwise i have to think to update a const in the code every
time i build a new Version.
enum versionData = import("version.dat");
enum min = anyCTFEFunctionThatParsesMin(versionData);
enum maj = anyCTFEFunctionThatParsesMaj(versionData);
// etc... you can even use compile-time regex...
The path to the file "version.dat" must be specified with the -J
DMD command line.
Generating the file is another story, maybe a git script could do
that.
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote: Someone could create a DIP for it though and argue for it. If they did that convincingly enough, maybe it would become a feature. I suspect that the response will be though that since it's easy enough to just create a template to do the same thing, it's not worth adding to the language. - Jonathan M Davis That's definitely what Walter would say. But I think it shouldn't be the only argument to not add a feature to the language itself: if some pattern is useful/frequent, and users implement it themselves every time, it should be either implemented in the compiler or in the standard library. Besides that, it just seems inconsistent that D lacks this particular feature: fixed-sized arrays are there, type deduction is there, so where's type deduction for fixed-sized arrays? Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me: int[_] array = [ 1, 2, 3 ];
Re: implementing --version?
On Monday, 21 November 2016 at 23:46:41 UTC, Basile B. wrote:
On Monday, 21 November 2016 at 21:32:16 UTC, mab-on wrote:
What i want is a clever mechanism to store the SemVer (or
Commit-ID) in the binary at compiletime - automatically.
Otherwise i have to think to update a const in the code every
time i build a new Version.
enum versionData = import("version.dat");
enum min = anyCTFEFunctionThatParsesMin(versionData);
enum maj = anyCTFEFunctionThatParsesMaj(versionData);
// etc... you can even use compile-time regex...
The path to the file "version.dat" must be specified with the
-J DMD command line.
Generating the file is another story, maybe a git script could
do that.
I have an example here:
https://github.com/BBasile/Coedit/blob/master/cesetup/cesetup.d#L165
I don't use semVer but you basically get the method.
Re: shared arrray problem
On 11/20/2016 12:41 PM, ag0aep6g via Digitalmars-d-learn wrote:
On 11/20/2016 09:09 PM, Charles Hixson via Digitalmars-d-learn wrote:
Thinking it over a bit more, the item returned would need to be a
struct, but the struct wouldn't contain the array, it would just contain
a reference to the array and a start and end offset. The array would
need to live somewhere else, in the class (or struct...but class is
better as you don't want the array evaporating by accident) that created
the returned value. This means you are dealing with multiple levels of
indirection, so it's costly compared to array access, but cheap compared
to lots of large copies. So the returned value would be something like:
struct
{
private:
/** this is a reference to the data that lives elsewhere. It should
be a pointer, but I don't like the syntax*/
ubyte[] data;
intstart, end;///first and last valid indicies into data
public:
this (ubyte[] data, int start, int end)
{this.data = data; this.start = start; this.end = end;}
...
// various routines to access the data, but to limit the access to
the spec'd range, and
// nothing to change the bounds
}
Instead of extra 'start' and 'end' fields you can slice the array. A
dynamic array already is just a reference coupled with a length, i.e.
a pointer with restricted indexing. So you can slice the original
array with your offsets and create the struct with that slice.
I feel like there is a misunderstanding somewhere, but I'm not sure on
whose side. As far as I can tell, your understanding of dynamic arrays
may be lacking, or maybe I don't understand what you're getting at.
While you are definitely correct about slices, I really feel more
comfortable with the start and end fields. I keep being afraid some
smart optimizer is going to decide I don't really need the entire
array. This is probably unjustified, but I find start and end fields
easier to think about. I don't think either of us misunderstands what's
going on, we just feel differently about methods that are approximately
equivalent. Slices would probably be marginally more efficient (well,
certainly so as you'd need two less fields), so if this were a public
library there would be an excellent argument for doing it your way. I
keep trying to think of a reason that start and end fields are better,
and failing. All I've got is that I feel more comfortable with them.
Which is really the answer you already posted, but just a bit more
detail on the construct, and what it meant. (Yeah, I could allow types
other than ubyte as the base case, but I don't want to. I'm thinking of
this mainly as a means of sharing a buffer between applications where
different parts have exclusive access to different parts of the buffer,
and where the buffer will be written to a file with a single fwrite, or
since the underlying storage will be an array, it could even be
rawwrite). I don't want to specify any more than I must about how the
methods calling this will format the storage, and this means that those
with access to different parts may well use different collections of
types, but all types eventually map down to ubytes (or bytes), so ubytes
is the common ground. Perhaps I'll need to write inbuffer,outbuffer
methods/wrappings, but that's far in the future.
Sure, go with a specialized type instead of a template, if that makes
more sense for your use case. As far as I see, the concept is
independent of the element type, so it seemed natural to make it a
template, but a special type is perfectly fine and probably has less
pitfalls.
P.S.: The traits that I mentioned previously were those given by:
static assert(!__traits(compiles, cla.length = 3));
static assert(!__traits(compiles, cla ~= 6));
in your main routine. I assumed that they were validity tests. I don't
understand why they were static. I've never happened to use static
asserts, but I would assume that when they ran cla wouldn't be defined.
Those are tests to ensure that cla's length cannot be set and that it
cannot be appended to. The asserts check that the code does not
compile, i.e. that you cannot do those things. They're static simply
because they can be. The code inside is not executed at run-time.
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 23:49:27 UTC, burjui wrote: Though I would argue that it's better to use '_' instead of '$' to denote deduced fixed size, it seems more obvious to me: int[_] array = [ 1, 2, 3 ]; alas, `_` is valid identifier, so `enum _ = 42; int[_] a;` is perfectly valid. dollar is simply most logical non-identifier character.
Re: the best language I have ever met(?)
On Monday, 21 November 2016 at 12:44:47 UTC, Jonathan M Davis wrote: (it might have even had a PR which was rejected), and presumably, Ketmar added it to his own compiler, because he liked the feature. exactly. it is the old patch from Kenji. the patch even survived C++ -> D transition, 'cause i love it so much. ;-)
Re: the best language I have ever met(?)
Dne 21.11.2016 v 13:44 Jonathan M Davis via Digitalmars-d-learn napsal(a): ... it's easy enough to just create a template to do the same thing, it's not worth adding to the language. That's a problem. I belive there is a lot of things which are easy to add by some kind of magic (template or mixins or some combination). But until this is add to standard library and doc, there is no way for other people to know about it. Even when there is a way (in standard library) it is not helpful. Many people (like me) will start learning language from specs. So if there see something like: int[$] x = [1, 2, 3]; // make static array, this make sense but x = [1, 2, 3]; // make dynamic array ,does not make sense
Re: implementing --version?
On Monday, 21 November 2016 at 21:32:16 UTC, mab-on wrote:
On Monday, 21 November 2016 at 20:56:41 UTC, Karabuta wrote:
There is a package in the dub registry called commando
(https://code.dlang.org/packages/commando) for that.
Hm.. maybe i explained it wrong.
My problem is not to pass a argument to the application.
What i want is a clever mechanism to store the SemVer (or
Commit-ID) in the binary at compiletime - automatically.
Otherwise i have to think to update a const in the code every
time i build a new Version.
You could write a little script to generate an increasing version
and save it in a file. Then with Dub you can use a pre-build or
pre-generate command to call that script, and in your D code do
`enum version = import("version.txt");`. You can do whatever you
want with this text; process it, convert it to an internal data
structure, populate settings, etc.
I created a thread a little while ago that's somewhat on this
topic... It was partially about Dub pre-build and pre-generate
commands so you may find it useful.
http://forum.dlang.org/thread/mzipqtnimvexeddjt...@forum.dlang.org
Re: implementing --version?
On Tuesday, 22 November 2016 at 00:41:42 UTC, Meta wrote:
You could write a little script to generate an increasing
version and save it in a file. Then with Dub you can use a
pre-build or pre-generate command to call that script, and in
your D code do `enum version = import("version.txt");`. You can
do whatever you want with this text; process it, convert it to
an internal data structure, populate settings, etc.
I created a thread a little while ago that's somewhat on this
topic... It was partially about Dub pre-build and pre-generate
commands so you may find it useful.
http://forum.dlang.org/thread/mzipqtnimvexeddjt...@forum.dlang.org
Also another thread I created on the Dub subforum where the
creator goes into a little more detail:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/8012/
Re: Memory allocation failed. Why?
On Sunday, 20 November 2016 at 17:47:50 UTC, MGW wrote: core.exception.OutOfMemoryError@src\core\exception.d(693): Memory allocation failed Simple program and error. Why? Windows 7 (32) dmd 2.072.0 Making a 100 million bytes array by appending one byte at a time creates a lot of intermediate-size arrays. Ideally these should be garbage collected away but GC in D is not only slow but also leaky. In 32 bits if you have 1000 random int values on the stack or data segment, with uniform distribution, this is 1000 random locations in memory pinned and seen by GC as live, i.e. one per 4 MB of address space. Which means if your array is 4 MB or larger it's almost doomed to be never collected by GC in this scenario. Your program creates a lot of large arrays and they don't get collected because of false pointers and not precise enough GC. Moral of the story: in 32 bits don't allocate anything big (1 MB or more) in GC heap, otherwise there are good chances it will create a memory leak. Use std.container.array or something similar.
Re: implementing --version?
On 2016-11-21 22:32, mab-on wrote: On Monday, 21 November 2016 at 20:56:41 UTC, Karabuta wrote: There is a package in the dub registry called commando (https://code.dlang.org/packages/commando) for that. Hm.. maybe i explained it wrong. My problem is not to pass a argument to the application. What i want is a clever mechanism to store the SemVer (or Commit-ID) in the binary at compiletime - automatically. Otherwise i have to think to update a const in the code every time i build a new Version. Use "git describe" to get the latest tag and/or commit hash. Use the "preGenerateCommands" field in Dub to generate the version before compiling the application. Write the result of "git describe" to a file and import that file in the application. Use std.getopt to parse the command line arguments. https://github.com/jacob-carlborg/dstep/blob/master/dub.json#L14 https://github.com/jacob-carlborg/dstep/blob/master/dstep/Configuration.d#L18 -- /Jacob Carlborg
