Re: D's Continous Changing
On Thursday, 4 March 2021 at 06:43:57 UTC, user1234 wrote: otherwise another solution is to check every two monthes the sanity of your projects. E.g a montly cronjob on a CI service and that uses latest DMD Docker image. If it fails you got an email... It certainly cooler to take 5 mins every two monthes than 7 hours 4 years. Nice idea. Try do it with all hundreds of used in your projects libraries.
Re: D's Continous Changing
On Thursday, 4 March 2021 at 09:21:12 UTC, Siemargl wrote: On Thursday, 4 March 2021 at 06:43:57 UTC, user1234 wrote: otherwise another solution is to check every two monthes the sanity of your projects. E.g a montly cronjob on a CI service and that uses latest DMD Docker image. If it fails you got an email... It certainly cooler to take 5 mins every two monthes than 7 hours 4 years. Nice idea. Try do it with all hundreds of used in your projects libraries. isObject, isArray, etc ;) ?
Re: D's Continous Changing
On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:
Every time I come back to a D program I wrote over a year ago,
it seems like there are numerous breaking changes and it takes
me a while to get it to compile again.
I am porting a large code base from Extended Pascal to D and I
know that there will be changes in the language in the future
that will take an effort to adapt to. Yet, I am still in the camp
of wanting these changes to happen because we don't want to port
from a dead language to another dead language, we need the
language to be alive.
The way I deal with this is to lock down version numbers with the
revision number of our code base. By having dub.selections.json
under revision control we make sure that the same version of
dependencies are used every time until we upgrade, and by having
this in dub.json:
```
"toolchainRequirements": {
"frontend": "==2.096"
},
```
we ensure that the code simply refuses to compile with any other
language version.
So, if two years from now we were to check out a revision that
was two years old, yes we would have to downgrade the compiler
but it would still work. Upgrading to a newer language version or
dependency version can be done outside of the main development
branch, where it can be properly tested before merging.
Ideally I want the build system to automatically install and/or
activate the compiler specified in the code base so that a
toolchain upgrade becomes just like a regular feature commit,
possibly using one of the existing compiler version managers [1,
2] or by extending dub itself. Then, fellow developers will
hardly notice compiler upgrades, the build farm doesn't need
attention, and bisecting revisions to pin down the occurrence of
a regression can be done without complications.
I think it is important that warts in the language and standard
library are removed, and luckily we have a proper deprecation
mechanism. My advice is, if you pick up a two-year old project
and don't want to deal with breakages, you just continue with the
versions from that time; Until you choose to use newer features,
but you can plan for the work that this requires.
-- Bastiaan.
[1] https://dlang.org/install.html
[2] https://code.dlang.org/packages/dvm
Re: D's Continous Changing
On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:
Contrast to me trying to figure out how to format a number in
binary. format!"%b"(number) does not work but is very similar
to what is suggested in the documentation. I was able to figure
out it's format("%b", number) but it took a few minutes.
This works for me:
rdmd --eval="writeln(format!`%b`(5));"
101
rdmd --eval="writeln(__VERSION__);"
2096
-- Bastiaan.
Re: Vibe.d tutorial
On Monday, 1 March 2021 at 22:25:39 UTC, Rey Valeza wrote: Hi, I wrote a tutorial on Vibe.d while trying to re-learn Vibe.d. I find that most of Kai Nacke's book need updating, so I wrote a tutorial while trying to re-learn it. Here it is. https://github.com/reyvaleza/vibed/commit/27ec3678f25d1dd414fae1390677397a7bc57721 I would be glad if you can give me some feedback so I can improve it. Thanks! https://github.com/reyvaleza/vibed/blob/main/Build%20Web%20Apps%20in%20Vibe.pdf
Opaque type (struct) with a static immutable fails to compile without constructor - why?
Hi all,
I want to make an opaque type that simply contains an integer
with some immutable constants and toString pretty printing. Like
this:
struct Foo_t
{
private long foo;
alias foo this;
static immutable long Inf = long.max; //1)
void toString(...){}
}
On dmd 2.092.1 this fails with:
1) Error: cannot implicitly convert expression 9223...L of type
immutable(long) to Foo_t
I simply want to initialize an immutable long with long.max.
Why the conversion to Foo_t ?
If I add a constructor:
private this(long f)
{
foo = f;
}
It compiles but according to code coverage this constructor is
never called.
What's going on?
Re: Opaque type (struct) with a static immutable fails to compile without constructor - why?
On Thursday, 4 March 2021 at 13:58:48 UTC, frankp wrote:
Hi all,
I want to make an opaque type that simply contains an integer
with some immutable constants and toString pretty printing.
Like this:
struct Foo_t
{
private long foo;
alias foo this;
static immutable long Inf = long.max; //1)
void toString(...){}
}
On dmd 2.092.1 this fails with:
1) Error: cannot implicitly convert expression 9223...L of
type immutable(long) to Foo_t
I simply want to initialize an immutable long with long.max.
Why the conversion to Foo_t ?
If I add a constructor:
private this(long f)
{
foo = f;
}
It compiles but according to code coverage this constructor is
never called.
What's going on?
This is the text of my program
import std.stdio;
struct Foo_t
{
private long foo;
alias foo this;
static immutable long Inf = long.max; //1)
void toString(...){ writeln(foo); }
}
void main()
{
Foo_t sample;
sample.foo = 100;
sample.toString();
}
This is the results of running the program:
PS C:\Users\someone\source\tests> dmd forum1.d
PS C:\Users\someone\source\tests> ./forum1.exe
100
PS C:\Users\someone\source\tests> dmd --version
DMD32 D Compiler v2.095.1-dirty
Copyright (C) 1999-2020 by The D Language Foundation, All Rights
Reserved written by Walter Bright
So I was not able to reproduce your issue. Is it possible that
error is coming from somewhere else?
Re: Opaque type (struct) with a static immutable fails to compile without constructor - why?
On Thursday, 4 March 2021 at 13:58:48 UTC, frankp wrote:
Hi all,
I want to make an opaque type that simply contains an integer
with some immutable constants and toString pretty printing.
Like this:
struct Foo_t
{
private long foo;
alias foo this;
static immutable long Inf = long.max; //1)
void toString(...){}
}
On dmd 2.092.1 this fails with:
1) Error: cannot implicitly convert expression 9223...L of
type immutable(long) to Foo_t
I simply want to initialize an immutable long with long.max.
Why the conversion to Foo_t ?
If I add a constructor:
private this(long f)
{
foo = f;
}
It compiles but according to code coverage this constructor is
never called.
What's going on?
I tried compiling your code locally on DMD 2.094.1, and had no
issues. Again with 2.095.0, no issues. On run.dlang.io, with all
dmd compilers from 2.060, and it just plain works.
Now, that's after removing ... from toString. With that present,
it fails with some variation of 'Error: undefined identifier
'__va_list_tag''.
Most likely, you have shortened your program for clarity, and
removed the issue you're experiencing in the process. Can we have
another one, with the issue still there?
--
Simen
Re: Opaque type (struct) with a static immutable fails to compile without constructor - why?
On Thursday, 4 March 2021 at 14:18:07 UTC, harakim wrote:
[...]
This is the text of my program
import std.stdio;
struct Foo_t
{
private long foo;
alias foo this;
static immutable long Inf = long.max; //1)
void toString(...){ writeln(foo); }
}
void main()
{
Foo_t sample;
sample.foo = 100;
sample.toString();
}
This is the results of running the program:
PS C:\Users\someone\source\tests> dmd forum1.d
PS C:\Users\someone\source\tests> ./forum1.exe
100
PS C:\Users\someone\source\tests> dmd --version
DMD32 D Compiler v2.095.1-dirty
Copyright (C) 1999-2020 by The D Language Foundation, All
Rights Reserved written by Walter Bright
So I was not able to reproduce your issue. Is it possible that
error is coming from somewhere else?
I wouldn't know, that's why I'm asking here :)
But since it compiles on dmd 2.095.1 I doubt it. I would upgrade
the compiler but I fear if I do all sorts of other things are
going to break. I'll keep my workaround and attach a todo note.
Thanks for testing.
Re: Opaque type (struct) with a static immutable fails to compile without constructor - why?
On Thursday, 4 March 2021 at 14:31:23 UTC, Simen Kjærås wrote:
On Thursday, 4 March 2021 at 13:58:48 UTC, frankp wrote:
Hi all,
I want to make an opaque type that simply contains an integer
with some immutable constants and toString pretty printing.
Like this:
struct Foo_t
{
private long foo;
alias foo this;
static immutable long Inf = long.max; //1)
void toString(...){}
}
On dmd 2.092.1 this fails with:
1) Error: cannot implicitly convert expression 9223...L of
type immutable(long) to Foo_t
I simply want to initialize an immutable long with long.max.
Why the conversion to Foo_t ?
If I add a constructor:
private this(long f)
{
foo = f;
}
It compiles but according to code coverage this constructor is
never called.
What's going on?
I tried compiling your code locally on DMD 2.094.1, and had no
issues. Again with 2.095.0, no issues. On run.dlang.io, with
all dmd compilers from 2.060, and it just plain works.
Now, that's after removing ... from toString. With that
present, it fails with some variation of 'Error: undefined
identifier '__va_list_tag''.
Most likely, you have shortened your program for clarity, and
removed the issue you're experiencing in the process. Can we
have another one, with the issue still there?
--
Simen
toString was actually added at a later point. The compiler
complained prior to that.
So if I rename the struct to Foo_t in my program it compiles.
However, the compiler complains if the struct is called
"cycle_t". That's curious. Is that a reserved name?
I don't import anything by that name. Not to my knowledge at
least - I'm strictly using named imports.
Re: Opaque type (struct) with a static immutable fails to compile without constructor - why?
On Thursday, 4 March 2021 at 14:42:16 UTC, frankp wrote: However, the compiler complains if the struct is called "cycle_t". That's curious. Is that a reserved name? I don't import anything by that name. Not to my knowledge at least - I'm strictly using named imports. False alarm. If I remove the constructor from cycle_t the compiler now complains about the same thing in Foo_t or any other name I try. I give up. This makes no sense. I just accept this is the work of gremlins. I revert to a plain alias and an enum. Sorry for wasting your time.
Re: Opaque type (struct) with a static immutable fails to compile without constructor - why?
On Thursday, 4 March 2021 at 14:54:11 UTC, frankp wrote: I give up. This makes no sense. I just accept this is the work of gremlins. I revert to a plain alias and an enum. Sorry for wasting your time. Not gremlins after all. It was simply a matter of the compiler pointing to the wrong line. Everything makes sense now. Anyways, thanks for your help.
Re: Opaque type (struct) with a static immutable fails to compile without constructor - why?
On Thursday, 4 March 2021 at 15:19:16 UTC, frankp wrote: On Thursday, 4 March 2021 at 14:54:11 UTC, frankp wrote: I give up. This makes no sense. I just accept this is the work of gremlins. I revert to a plain alias and an enum. Sorry for wasting your time. Not gremlins after all. It was simply a matter of the compiler pointing to the wrong line. Everything makes sense now. Anyways, thanks for your help. "15 minutes of gremlins" 😉
dub support for Mac M1?
I got a company MacBook with M1 chip and gradually migrate all the stuff from Linux machine. I got precompiled ldc binary installed without any problem now is the time for dub since I have couple of D projects I use at work and all of them use dub. I can only see the dub-v1.23.0-osx-x86_64.tar.gz package so it should at least run via Rosetta. I also tried compiling it via MacPorts but looks like dub pulls dmd as a dependency and dmd fails to build currently. For example: """ $ sudo port install dub Warning: The macOS 11.2 SDK does not appear to be installed. Ports may not build correctly. Warning: You can install it as part of the Xcode Command Line Tools package by running `xcode-select --install'. ---> Computing dependencies for dub The following dependencies will be installed: dmd dmd-tools druntime phobos Continue? [Y/n]: y Warning: The macOS 11.2 SDK does not appear to be installed. Ports may not build correctly. Warning: You can install it as part of the Xcode Command Line Tools package by running `xcode-select --install'. ---> Fetching archive for dmd ---> Attempting to fetch dmd-2.088.0_0.darwin_20.arm64.tbz2 from https://lil.fr.packages.macports.org/dmd ---> Attempting to fetch dmd-2.088.0_0.darwin_20.arm64.tbz2 from https://mse.uk.packages.macports.org/dmd ---> Attempting to fetch dmd-2.088.0_0.darwin_20.arm64.tbz2 from https://packages.macports.org/dmd ---> Building dmd Error: Failed to build dmd: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_dmd/dmd/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port dub failed """ We look into the logs and see """ :info:build (maybe you meant: dt_writeToObj(Obj*, dt_t*, int, unsigned long long&), file_write(char*, void*, unsigned int) , Obj_write_pointerRef(Symbol*, unsigned int) , Obj_write_bytes(seg_data*, unsigned int, void*) , __D3dmd4glue18obj_write_deferredRCQBf3lib7LibraryZ5counti , Obj_write_zeros(seg_data*, unsigned long long) , obj_write_deferred(Library*) , Obj_write_byte(seg_data*, unsigned int) ) :info:build ld: symbol(s) not found for architecture i386 :info:build clang: error: linker command failed with exit code 1 (use -v to see invocation) :info:build Error: linker exited with status 1 :info:build make: *** [../generated/osx/release/32/dmd] Error 1 """ Are there any plans to support M1 for dub?
Re: dub support for Mac M1?
On Thursday, 4 March 2021 at 22:30:17 UTC, tastyminerals wrote: I got a company MacBook with M1 chip and gradually migrate all the stuff from Linux machine. I got precompiled ldc binary installed without any problem now is the time for dub since I have couple of D projects I use at work and all of them use dub. [...] If someone with an M1 wants to get it working the patch is appreciated but I (for one) don't have one so I can't.
Re: dub support for Mac M1?
On Thursday, 4 March 2021 at 22:30:17 UTC, tastyminerals wrote: I got a company MacBook with M1 chip and gradually migrate all the stuff from Linux machine. I got precompiled ldc binary installed without any problem now is the time for dub since I have couple of D projects I use at work and all of them use dub. I can only see the dub-v1.23.0-osx-x86_64.tar.gz package so it should at least run via Rosetta. The official prebuilt LDC package comes with prebuilt dub, dustmite, ddemangle and rdmd, just like any other package.
How do I run multiple unittests with rdmd?
Hello,
I'm trying to run multiple unittest files with rdmd.
So far I use `find` to just pipe in the files. Eg:
time find source -name *__tests.d -exec rdmd -unittest --main
-I../libprelude/source -I../libparser/source
-I../libgeometry/source -Isource {} \;
Is there an easier way to do this?
Re: How do I run multiple unittests with rdmd?
On Fri, Mar 05, 2021 at 01:47:41AM +, Anthony via Digitalmars-d-learn wrote:
> Hello,
>
> I'm trying to run multiple unittest files with rdmd.
> So far I use `find` to just pipe in the files. Eg:
>
>
> time find source -name *__tests.d -exec rdmd -unittest --main
> -I../libprelude/source -I../libparser/source -I../libgeometry/source
> -Isource {} \;
>
> Is there an easier way to do this?
Do you have multiple applications, or a single application spread across
multiple sources?
In the latter case, you could just use `rdmd -unittest -i -run main.d`
(replace `main.d` with whatever source file contains main()) to
automatically compile all modules including their unittests *and* run
'em all in one shot.
Only in the former case would you need to use your `find` pipeline
above. :-)
T
--
Computers aren't intelligent; they only think they are.
Is there any generic iteration function that stops at first match?
something like filter[1] but that stops at first match? are there any native functions for this in D or I have to write one? just making sure to not reinvent the wheel [1]: https://devdocs.io/d/std_algorithm_iteration#filter
Re: Is there any generic iteration function that stops at first match?
On Fri, Mar 05, 2021 at 02:13:39AM +, Jack via Digitalmars-d-learn wrote: > something like filter[1] but that stops at first match? are there any > native functions for this in D or I have to write one? just making > sure to not reinvent the wheel [...] Why not just .front? E.g.: int[] data = [ 1,2,3,4,5 ]; auto r = data.filter!(v => v % 2 == 0); assert(r.front == 2); T -- There is no gravity. The earth sucks.
Re: D's Continous Changing
```
"toolchainRequirements": {
"frontend": "==2.096"
},
```
Thanks! I didn't know you could specify a toolchain version. I
agree it would be cool if it automatically downloaded the correct
version of compiler, but this will be helpful. Is it possible to
download old versions of the compiler somewhere?
On Thursday, 4 March 2021 at 10:22:51 UTC, Bastiaan Veelo wrote:
On Wednesday, 3 March 2021 at 23:30:20 UTC, harakim wrote:
Contrast to me trying to figure out how to format a number in
binary. format!"%b"(number) does not work but is very similar
to what is suggested in the documentation. I was able to
figure out it's format("%b", number) but it took a few minutes.
This works for me:
rdmd --eval="writeln(format!`%b`(5));"
101
rdmd --eval="writeln(__VERSION__);"
2096
-- Bastiaan.
I want this almost every week at work. When I run into some
trivial statement that I need to know for sure how it works, it's
rarely worth it to create a whole new file and make a main method
and all that. I just edit and run the entire program again, which
is a waste of time.
So about ten seconds later:
PS> rdmd --eval="writeln(format!`%b`(5));"
~\AppData\Local\Temp\.rdmd\eval.F4ADE5F0F88B126B82870415B197BF60.d(18): Error:
template argument expected following `!`
Failed: ["C:\\Program Files\\D\\dmd2\\windows\\bin\\dmd.exe",
"-d", "-v", "-o-",
"~\\AppData\\Local\\Temp\\.rdmd\\eval.F4ADE5F0F88B126B82870415B197BF60.d", "-I~\\AppData\\Local\\Temp\\.rdmd"]
PS> rdmd --eval="writeln(__VERSION__);"
2095
That was pretty sweet. However, it kind of goes to the point of
my post. A one-revision difference means the documentation is not
accurate for my compiler.
I'm not saying the language shouldn't evolve, I'm just saying it
might make sense to keep compatibility changes to every 6 months
or a year. Then you could keep the old documentation around for
the old version, and create new documentation for the new version
and no matter which version someone is using they would have
documentation (within limits.)
Depending on how long I can keep at this project, I would be down
to host my source wherever it needs to be hosted (provided it's
git) to get the new-version-check feature. I might even pay a bit
for it. I doubt that makes it worth it, but I thought I'd throw
that out there in case more people agree.
I like D. I like that D is changing. To go along with that, I
would like a little more predictability with major version
releases. I see there is a lot more documentation than the last
time I checked so I'll take a deeper look at that.
Re: D's Continous Changing
On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote: correct version of compiler, but this will be helpful. Is it possible to download old versions of the compiler somewhere? From this page you can follow a trail all the way back to 0.00 if you're so inclined: https://dlang.org/changelog/index.html
Re: D's Continous Changing
On Friday, 5 March 2021 at 03:35:31 UTC, Mike Parker wrote: On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote: correct version of compiler, but this will be helpful. Is it possible to download old versions of the compiler somewhere? From this page you can follow a trail all the way back to 0.00 if you're so inclined: https://dlang.org/changelog/index.html Okay, maybe not. A number of the oldest versions aren't available. Anyway, there's also: http://ftp.digitalmars.com/
Re: How do I run multiple unittests with rdmd?
On Friday, 5 March 2021 at 02:08:37 UTC, H. S. Teoh wrote: In the latter case, you could just use `rdmd -unittest -i -run main.d` (replace `main.d` with whatever source file contains main()) to automatically compile all modules including their unittests *and* run 'em all in one shot. I didn't know that. Good to know. Thanks Only in the former case would you need to use your `find` pipeline above. :-) I should have mentioned, this is for a library that is used by multiple applications. So I guess the find pipeline is the way to go then.
Re: Is there any generic iteration function that stops at first match?
On Friday, 5 March 2021 at 02:13:39 UTC, Jack wrote: something like filter[1] but that stops at first match? are there any native functions for this in D or I have to write one? just making sure to not reinvent the wheel [1]: https://devdocs.io/d/std_algorithm_iteration#filter std.algorithm.searching.until -Steve
Can't I allocate at descontructor?
The following code returns a memory error. I did notice it did
happens whenever I did a memory allocation. Is this not possible
in the descontrutor? if so, why?
core.exception.InvalidMemoryOperationError@src\core\exception.d(647): Invalid
memory operation
import std.stdio;
int main()
{
auto a = new A;
return 0;
}
class A
{
this() { }
~this()
{
f();
}
}
void f()
{
auto str = new string[100];
}
Re: Is there any generic iteration function that stops at first match?
On Friday, 5 March 2021 at 02:43:36 UTC, H. S. Teoh wrote: On Fri, Mar 05, 2021 at 02:13:39AM +, Jack via Digitalmars-d-learn wrote: something like filter[1] but that stops at first match? are there any native functions for this in D or I have to write one? just making sure to not reinvent the wheel [...] Why not just .front? E.g.: int[] data = [ 1,2,3,4,5 ]; auto r = data.filter!(v => v % 2 == 0); assert(r.front == 2); T it loops over the entire array then returns, I'd like to stop as soon as the predicate return true
Re: Is there any generic iteration function that stops at first match?
On Friday, 5 March 2021 at 05:32:27 UTC, Jack wrote:
On Friday, 5 March 2021 at 02:43:36 UTC, H. S. Teoh wrote:
On Fri, Mar 05, 2021 at 02:13:39AM +, Jack via
Digitalmars-d-learn wrote:
something like filter[1] but that stops at first match? are
there any native functions for this in D or I have to write
one? just making sure to not reinvent the wheel
[...]
Why not just .front? E.g.:
int[] data = [ 1,2,3,4,5 ];
auto r = data.filter!(v => v % 2 == 0);
assert(r.front == 2);
T
it loops over the entire array then returns, I'd like to stop
as soon as the predicate return true
void main() {
import std.stdio, std.algorithm, std.range;
int[] data = iota(5).map!"a+1".array;
auto r = data.filter!(function (v) { writeln(v); return v %
2 == 0; });
assert(r.front == 2);
}
output:
1
2
'r' is an iterator. To force it to loop over the entire array that
would need a .array like I'm using for 'data'.
Re: Is there any generic iteration function that stops at first match?
On Friday, 5 March 2021 at 04:22:23 UTC, Steven Schveighoffer wrote: On Friday, 5 March 2021 at 02:13:39 UTC, Jack wrote: something like filter[1] but that stops at first match? are there any native functions for this in D or I have to write one? just making sure to not reinvent the wheel [1]: https://devdocs.io/d/std_algorithm_iteration#filter std.algorithm.searching.until -Steve thanks, totally overlooked this searching section
Re: Can't I allocate at descontructor?
On Friday, 5 March 2021 at 05:31:38 UTC, Jack wrote: The following code returns a memory error. I did notice it did happens whenever I did a memory allocation. Is this not possible in the descontrutor? if so, why? GC prohibits allocation during collection, since this dtor is likely called by GC this is what happens. If you REALLY need this just allocate using other mechanisms.
Re: D's Continous Changing
On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote: I want this almost every week at work. When I run into some trivial statement that I need to know for sure how it works, it's rarely worth it to create a whole new file and make a main method and all that. I just edit and run the entire program again, which is a waste of time. So about ten seconds later: PS> rdmd --eval="writeln(format!`%b`(5));" ~\AppData\Local\Temp\.rdmd\eval.F4ADE5F0F88B126B82870415B197BF60.d(18): Error: template argument expected following `!` Failed: ["C:\\Program Files\\D\\dmd2\\windows\\bin\\dmd.exe", "-d", "-v", "-o-", "~\\AppData\\Local\\Temp\\.rdmd\\eval.F4ADE5F0F88B126B82870415B197BF60.d", "-I~\\AppData\\Local\\Temp\\.rdmd"] PS> rdmd --eval="writeln(__VERSION__);" 2095 That was pretty sweet. However, it kind of goes to the point of my post. A one-revision difference means the documentation is not accurate for my compiler. This is problem with Powershell. (May by need to create bugreport ?) This example runs fine from CMD (but i recommend FAR for conveniety) and fails from PS. Tested Win10.1909, dmd 2.095
