Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Monday, 14 November 2022 at 20:37:12 UTC, kdevel wrote: On Monday, 14 November 2022 at 17:08:38 UTC, Gavin Ray wrote: Just came here to say I hit the same bug, here's my import list: * https://issues.dlang.org/show_bug.cgi?id=19937 object._d_assert_fail linker error if compiling with -checkaction=context * https://issues.dlang.org/show_bug.cgi?id=22374 [REG 2.093] 'import std;' with -checkaction=context causes link error * https://issues.dlang.org/show_bug.cgi?id=22902 dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error Does `dmd -allinst ...` help in your case? Hey, it does actually, thanks a bunch!
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Monday, 14 November 2022 at 17:08:38 UTC, Gavin Ray wrote: Just came here to say I hit the same bug, here's my import list: * https://issues.dlang.org/show_bug.cgi?id=19937 object._d_assert_fail linker error if compiling with -checkaction=context * https://issues.dlang.org/show_bug.cgi?id=22374 [REG 2.093] 'import std;' with -checkaction=context causes link error * https://issues.dlang.org/show_bug.cgi?id=22902 dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error Does `dmd -allinst ...` help in your case?
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Saturday, 28 May 2022 at 23:02:45 UTC, kdevel wrote: On Friday, 18 March 2022 at 19:42:02 UTC, Anonymouse wrote: On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote: If ```import std.regex;``` is commented out or if ```-checkaction=context``` is removed from the cmd line the unittest passes. Can anybody reproduce this? https://run.dlang.io/is/GYDUBz File an issue, I'd say. The worst thing that can happen is that someone flags it as a duplicate. Issue 22902 - dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error (edit) https://issues.dlang.org/show_bug.cgi?id=22902 Just came here to say I hit the same bug, here's my import list: ```d import std.typecons : Tuple; import std.container : Array; import std.format : format; import std.stdio; import std.file; import std.conv; import std.outbuffer; import core.stdc.stdio; import core.stdc.stdint; import core.sys.posix.fcntl; import core.sys.posix.unistd; ```
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Friday, 18 March 2022 at 19:42:02 UTC, Anonymouse wrote: On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote: If ```import std.regex;``` is commented out or if ```-checkaction=context``` is removed from the cmd line the unittest passes. Can anybody reproduce this? https://run.dlang.io/is/GYDUBz File an issue, I'd say. The worst thing that can happen is that someone flags it as a duplicate. Issue 22902 - dmd 2.099 regression: unittest -checkaction=context and import std.regex causes link error (edit) https://issues.dlang.org/show_bug.cgi?id=22902
Re: dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
On Thursday, 17 March 2022 at 14:00:45 UTC, kdevel wrote: If ```import std.regex;``` is commented out or if ```-checkaction=context``` is removed from the cmd line the unittest passes. Can anybody reproduce this? https://run.dlang.io/is/GYDUBz File an issue, I'd say. The worst thing that can happen is that someone flags it as a duplicate.
dmd 2.099 regression: unittest -checkaction=context and import std.regex cause lots of undefined references
zstack.d:
```
module zstack;
import std.stdio: writeln;
void bar (int [] i)
{
writeln ("i: ", i);
}
unittest {
int [] arr;
bar (arr);
}
```
zrepo.d:
```
module parser;
import std.regex;
import zstack;
```
```
$ dmd -g -i -unittest -checkaction=context -main -run zrepro
2>&1 | ddemangle
```
gives
```
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(int)._d_assert_fail(scope
const(immutable(char)[]), const(int))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:41:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
zrepro.o: In function `pure nothrow @nogc @safe uint
std.uni.sliceBits!(0uL,
8uL).sliceBits.opCall!(dchar).opCall(dchar)':
[...]/dmd2/linux/bin64/../../src/phobos/std/uni/package.d:5593:
undefined reference to `pure nothrow @nogc @safe
immutable(char)[]
core.internal.dassert._d_assert_fail!(const(uint))._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), ref const(uint), const(int))'
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(bool)._d_assert_fail(scope
const(immutable(char)[]), ref const(bool))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:41:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
zrepro.o: In function `pure nothrow @nogc @safe uint
std.uni.sliceBits!(13uL,
21uL).sliceBits.opCall!(dchar).opCall(dchar)':
[...]/dmd2/linux/bin64/../../src/phobos/std/uni/package.d:5593:
undefined reference to `pure nothrow @nogc @safe
immutable(char)[]
core.internal.dassert._d_assert_fail!(const(uint))._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), ref const(uint), const(int))'
zrepro.o: In function `pure nothrow @nogc @safe uint
std.uni.sliceBits!(8uL,
13uL).sliceBits.opCall!(dchar).opCall(dchar)':
[...]/dmd2/linux/bin64/../../src/phobos/std/uni/package.d:5593:
undefined reference to `pure nothrow @nogc @safe
immutable(char)[]
core.internal.dassert._d_assert_fail!(const(uint))._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), ref const(uint), const(int))'
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(ulong)._d_assert_fail!(ulong)._d_assert_fail(scope const(immutable(char)[]), ref const(ulong), const(ulong))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:70:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:75:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:77:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(ulong)._d_assert_fail!(int)._d_assert_fail(scope const(immutable(char)[]), ref const(ulong), const(int))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:70:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:75:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
zrepro.o: In function `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert._d_assert_fail!(ulong)._d_assert_fail!(ulong)._d_assert_fail(scope const(immutable(char)[]), ref const(ulong), ref const(ulong))':
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:70:
undefined reference to `pure nothrow @nogc @safe bool
core.internal.dassert.inFinalizer!().inFinalizer()'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:75:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
[...]/dmd2/linux/bin64/../../src/druntime/import/core/internal/dassert.d:77:
undefined reference to `pure nothrow @nogc @safe immutable(char)[]
core.internal.dassert.miniFormatFakeAttributes!(ulong).miniFormatFakeAttributes(ref
const(ulong))'
collect2: ld returned 1 exit status
Error: linker exited with status 1
```
If ```import std.regex;``` is commented out or if
```-checkaction=context``` is removed from the cmd line the
unittest passes. Can anybody reproduce this?
Re: druntime 2.087 regression? (was: Old codebase stops compiling at 2.087)
On 12/3/19 12:15 PM, James Blachly wrote:
On 11/17/19 7:15 PM, Steven Schveighoffer wrote:
On 11/17/19 10:45 AM, James Blachly wrote:
/home/james/dmd2.087/dmd2/linux/bin64/../../src/druntime/import/object.d(3453,36):
Error: cannot implicitly convert expression aa of type
shared(GSeqAllele[string]) to const(shared(GSeqAllele)[string])
There's a subtle removing of the shared from the entire AA. Is that on
purpose?
i.e. I see shared(GSeqAllele[string]) in one, and
shared(GSeqAllele)[string] in another.
Steve:
Sorry for the delay in replying. That is the runtime removing the shared
from the entire AA, not our code. I point out the change that induces
this with a link to github.
I admit, this was a drive-by analysis, and I didn't look at the code at
all. Just the error.
Should I move this discussion to the main D group? My primary concerns are:
0. Ask if it is intended behavior that the runtime cannot handle a
shared AA post 2.086.1?
1. Report this as bug
2. Ask why this commit ("object: Declare private struct AA and fix aaA
function signatures ") not mentioned in the changelog for 2.087?
0. learn is fine. I'm never one to care about where someone posts.
1. Bugzilla is the correct place to report. Looks like you have a solid
case and have done all the hard work. Should be fixable.
2. Not all commits are mentioned in the changelog. But if there is a
change that breaks existing code, arguably it should be in there.
-Steve
Re: druntime 2.087 regression? (was: Old codebase stops compiling at 2.087)
On 11/17/19 7:15 PM, Steven Schveighoffer wrote:
On 11/17/19 10:45 AM, James Blachly wrote:
/home/james/dmd2.087/dmd2/linux/bin64/../../src/druntime/import/object.d(3453,36):
Error: cannot implicitly convert expression aa of type
shared(GSeqAllele[string]) to const(shared(GSeqAllele)[string])
There's a subtle removing of the shared from the entire AA. Is that on
purpose?
i.e. I see shared(GSeqAllele[string]) in one, and
shared(GSeqAllele)[string] in another.
-Steve
Steve:
Sorry for the delay in replying. That is the runtime removing the shared
from the entire AA, not our code. I point out the change that induces
this with a link to github.
Should I move this discussion to the main D group? My primary concerns are:
0. Ask if it is intended behavior that the runtime cannot handle a
shared AA post 2.086.1?
1. Report this as bug
2. Ask why this commit ("object: Declare private struct AA and fix aaA
function signatures ") not mentioned in the changelog for 2.087?
Thanks in advance
Re: druntime 2.087 regression? (was: Old codebase stops compiling at 2.087)
On 11/17/19 10:45 AM, James Blachly wrote: /home/james/dmd2.087/dmd2/linux/bin64/../../src/druntime/import/object.d(3453,36): Error: cannot implicitly convert expression aa of type shared(GSeqAllele[string]) to const(shared(GSeqAllele)[string]) There's a subtle removing of the shared from the entire AA. Is that on purpose? i.e. I see shared(GSeqAllele[string]) in one, and shared(GSeqAllele)[string] in another. -Steve
druntime 2.087 regression? (was: Old codebase stops compiling at 2.087)
TL;DR druntime regression?
https://gist.github.com/jblachly/78c5762bbfea65b09e7a1417ad763019
---
Our team has an older codebase that compiled fine up until frontend
version 2.087 (builds with 2.086.1). Now, compiler (DMD2 and LDC2)
complains about implicit conversion of shared(AA) to const(shared(AA)).
The codebase is private (could possibly make it public soon) but the
error involves an AA inside a shared struct.
```
/home/james/dmd2.087/dmd2/linux/bin64/../../src/druntime/import/object.d(3453,36):
Error: cannot implicitly convert expression aa of type
shared(GSeqAllele[string]) to const(shared(GSeqAllele)[string])
source/polytyper/gseq.d(231,33): Error: template instance
`object.values!(shared(GSeqAllele[string]), shared(GSeqAllele), string)`
error instantiating
/home/james/dmd2.087/dmd2/linux/bin64/../../src/druntime/import/object.d(3402,36):
Error: cannot implicitly convert expression aa of type
shared(GSeqAllele[string]) to const(shared(GSeqAllele)[string])
source/polytyper/gseq.d(280,35): Error: template instance
`object.keys!(shared(GSeqAllele[string]), shared(GSeqAllele), string)`
error instantiating
```
(line breaks added for clarity)
The two triggering lines both iterate over a built-in AA
gseq.d:231:foreach (a; this.alleles.values)
gseq.d:208:foreach (key; this.alleles.keys)
Looking at the changelog for 2.087 (
https://dlang.org/changelog/2.087.0.html ) I do not see any obvious
culprits. git blame suggests this is the responsible commit:
https://github.com/dlang/druntime/commit/af86e7db58f4b792e45bdc3ee43c17aadc9d54ab#diff-a68e58fcf0de5aa198fcaceafe4e8cf9L3430-R3454
From this change, it looks like the runtime now cannot handle a shared
AA -- is this right? A minimal reproducible example is here:
https://gist.github.com/jblachly/78c5762bbfea65b09e7a1417ad763019
Thanks in advance for help
James
PS: Why is this commit ("object: Declare private struct AA and fix aaA
function signatures ") not mentioned in the changelog?
Re: Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
On Friday, August 16, 2019 2:16:31 AM MDT Piotr Mitana via Digitalmars-d-
learn wrote:
> On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
>
> wrote:
> > Not being able to implicitly convert to const is a bit odd, but
> > arguably, nothing should ever be called on a shared AA anyway.
> > If an operation isn't thread-safe, then it shouldn't work with
> > shared. To use a shared object safely, you have to protect
> > access to it with a mutex or some other synchronization
> > mechanism, after which you would normally cast away shared to
> > operate on the object as thread-local while the lock is in
> > place and then release the lock when you're done (also making
> > sure that no thread-local references exist when the lock is
> > released). Because keys is not at all thread-safe, I'd strongly
> > argue that it should not work on a shared AA, and if it does,
> > that's a bug.
>
> OK, I get the point. So I should go with something similar to
> this, right?
>
> import core.sync.mutex;
> import std;
>
> shared(string[string]) dict;
> shared(Mutex) mtx;
>
> shared static this()
> {
> mtx = new shared Mutex;
> }
>
> void main()
> {
> mtx.lock;
> (cast(string[string]) dict).keys;
> mtx.unlock;
> }
>
> Or I could use synchronized, if dict was inside a class. Thank
> you!
Yes. Or you can use synchronized blocks. e.g.
synchronized(mtx)
{
(cast(string[string]) dict).keys;
}
- Jonathan M Davis
Re: Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
wrote:
Not being able to implicitly convert to const is a bit odd, but
arguably, nothing should ever be called on a shared AA anyway.
If an operation isn't thread-safe, then it shouldn't work with
shared. To use a shared object safely, you have to protect
access to it with a mutex or some other synchronization
mechanism, after which you would normally cast away shared to
operate on the object as thread-local while the lock is in
place and then release the lock when you're done (also making
sure that no thread-local references exist when the lock is
released). Because keys is not at all thread-safe, I'd strongly
argue that it should not work on a shared AA, and if it does,
that's a bug.
OK, I get the point. So I should go with something similar to
this, right?
import core.sync.mutex;
import std;
shared(string[string]) dict;
shared(Mutex) mtx;
shared static this()
{
mtx = new shared Mutex;
}
void main()
{
mtx.lock;
(cast(string[string]) dict).keys;
mtx.unlock;
}
Or I could use synchronized, if dict was inside a class. Thank
you!
Re: Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
On Thursday, 15 August 2019 at 19:51:30 UTC, Jonathan M Davis
wrote:
n Thursday, August 15, 2019 11:33:06 AM MDT Piotr Mitana via
Digitalmars-d- learn wrote:
Code:
import std;
shared(string[string]) dict;
void main()
{
dict.keys;
}
Error:
/dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3417):
Error: cannot implicitly convert expression aa of type
shared(string[string]) to const(shared(string)[string])
onlineapp.d(7): Error: template instance
`object.keys!(shared(string[string]), shared(string), string)`
error instantiating
Before D 2.087 it compiled - is this a regression?
Not being able to implicitly convert to const is a bit odd, but
arguably, nothing should ever be called on a shared AA anyway.
If an operation isn't thread-safe, then it shouldn't work with
shared. To use a shared object safely, you have to protect
access to it with a mutex or some other synchronization
mechanism, after which you would normally cast away shared to
operate on the object as thread-local while the lock is in
place and then release the lock when you're done (also making
sure that no thread-local references exist when the lock is
released). Because keys is not at all thread-safe, I'd strongly
argue that it should not work on a shared AA, and if it does,
that's a bug.
- Jonathan M Davis
D really needs some official thread-safe implementations of
containers, hashmaps etc.
Re: Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
n Thursday, August 15, 2019 11:33:06 AM MDT Piotr Mitana via Digitalmars-d-
learn wrote:
> Code:
>
> import std;
>
> shared(string[string]) dict;
>
> void main()
> {
> dict.keys;
> }
>
> Error:
>
> /dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3417):
> Error: cannot implicitly convert expression aa of type
> shared(string[string]) to const(shared(string)[string])
> onlineapp.d(7): Error: template instance
> `object.keys!(shared(string[string]), shared(string), string)`
> error instantiating
>
> Before D 2.087 it compiled - is this a regression?
Not being able to implicitly convert to const is a bit odd, but arguably,
nothing should ever be called on a shared AA anyway. If an operation isn't
thread-safe, then it shouldn't work with shared. To use a shared object
safely, you have to protect access to it with a mutex or some other
synchronization mechanism, after which you would normally cast away shared
to operate on the object as thread-local while the lock is in place and then
release the lock when you're done (also making sure that no thread-local
references exist when the lock is released). Because keys is not at all
thread-safe, I'd strongly argue that it should not work on a shared AA, and
if it does, that's a bug.
- Jonathan M Davis
Cannot take the .keys of shared AA. Is this a regression in 2.087 or a feature?
Code:
import std;
shared(string[string]) dict;
void main()
{
dict.keys;
}
Error:
/dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3417):
Error: cannot implicitly convert expression aa of type
shared(string[string]) to const(shared(string)[string])
onlineapp.d(7): Error: template instance
`object.keys!(shared(string[string]), shared(string), string)`
error instantiating
Before D 2.087 it compiled - is this a regression?
Re: Testing D database calls code for regression
On Friday, 16 March 2018 at 20:17:49 UTC, aberba wrote: How will you test D code which makes calls to database to detect bugs and regression. Unlike where you can inject data like assert (2+1 == 3), database interfacing code will be crazy... Or there's some mocking available for such cases. Especially when more features are developed on top. Well, I am not really sure what you are looking for but to test database code, there are frameworks for this Check for example tsqlt ( http://tsqlt.org/ ) this framework is ms sql specific and is the one I have experience with There is also dbfit ( http://dbfit.github.io/dbfit/ ) which seem to support more database management frameworks tsqlt is very good for unit testing, sql procedures or statements at a high this is how it was setup to be used 1. you prepare sql procedure to create your tables that will be used in testing 2. you prepare sql procedure with insert statements to create the data sample you want to be used for testing 3. you write a script execute the two procedures from the first two step then executed the procedure or statement you want to test and then at the end of this script executed some assert statements that is basically your unit test how to setup used those scripts 1. the setup started a transaction 2. the setup dropped everything in the database 3. the setup executed the scripts from point 3 above to create your database, followed by the insert statements scripts or data creation script, followed by executing the statement to be tested and finally executing the assert statements 4. finally the setup rolled back everything this setup was support by the tsqlt framework, but honestly i dont know how much of this was specific to the environment where i worked but you can use tsqlt to have this D is not a database language, D is not sql You should clearly separate testing the D code that call the sql statements and testing the sql statements themselves The above frameworks, will help you test the sql code in isolation
Re: Testing D database calls code for regression
On Mon, Mar 19, 2018 at 06:45:49PM +, aberba via Digitalmars-d-learn wrote: [...] > The thing about functional programming where functions are > decoupled/testable doesn't seem to apply to database call code. I > guess its because databases introduces a different state...another > point of failure. Not necessarily; in some cases it may be possible to design code such that its logic can be tested independently of an actual database. But that may not be practical in your case since it will likely involve a major rewrite. Basically, it's pretty rare for an application to actually need the full range of the SQL language + *all* of the features your database backend provides. Usually, the "business logic", so to speak, boils down to just some simple primitives: uploadFile(), createAccount(), loginUser(), logoutUser(), deleteAccount(), retrieveFile(), etc.. Ideally, the business logic part of the code should not even care about whether there's a database in the back supporting these operations; it should be higher-level code built on top of these high-level primitives. There should definitely not be any literal SQL statements anywhere at this level. The "business logic" side of the code should be completely testable with a mock API (with stubs for uploadFile, createAccount, etc.), and should not need to touch a real database at all. In the middle level where these primitives are implemented, that's where you actually translate these high-level operations into SQL. If the high-level API is well-designed, each operation should be pretty well encapsulated and should not cause unexpected conflicts with other operations. [...] > My code logic is a mix of file uploads which leads to saving file info > into db. And some general queries... my worry has been adding a > feature which might cause a regression in another rearly executed > code...its feels like I have to test all features/rest calls after > every major change. Don't know how others do this...when there's some > tight coupling involved. [...] Sounds like you're not really doing *unit* testing anymore, but it's a large-scale application-wide regression test. For that, probably your best bet is to create test databases and use external testing with a mock network / test DB server. E.g., basically what the dmd testsuite does today: a directory of input files and expected output files, and some simple tools to automatically run through all of them. You could create a library of test cases that you run your program through before release, to make sure nothing that has worked in the past will stop working now. T -- If it breaks, you get to keep both pieces. -- Software disclaimer notice
Re: Testing D database calls code for regression
On Monday, 19 March 2018 at 00:56:26 UTC, H. S. Teoh wrote:
On Sun, Mar 18, 2018 at 07:51:18PM +, aberba via
Digitalmars-d-learn wrote:
On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
> On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via
> Digitalmars-d-learn wrote:
> > [...]
>
> The usual way I do this is to decouple the code from the
> real database backend by templatizing the database driver.
> Then in my unittest I can instantiate the template with a
> mock database driver that only implements the bare minimum
> to run the test.
>
> [...]
Mocking a fake database can also be huge pain. Especially when
something like transactions and prepared statements are
involved.
It depends on what your test is looking for. The idea is that
the mock database only implements a (small!) subset of a real
database, basically just enough for the test to run, and
nothing more. Of course, sometimes it may not be easy to do
this, if the code being tested is very complex.
Imagine testing your mock for introduced by future extension.
If you find yourself needing to test your mock database, then
you're doing it wrong. :-D It's supposed to be helping you
test your code, not to create more code that itself needs to be
tested!
Basically, this kind of testing imposes certain requirements on
the way you write your code. Certain kinds of code are easier
to test than others. For example, imagine trying to test a
complex I/O pipeline implemented as nested loops. It's
basically impossible to test it except as a blackbox testing
(certain input sets must produce certain output sets). It's
usually impractical for the test to target specific code paths
nested deep inside a nested loop. The only thing you can do is
to hope and pray that your blackbox tests cover enough of the
code paths to ensure things are correct. But you're likely to
miss certain exceptional cases.
But if said I/O pipeline is implemented as series of range
compositions, for example, then it becomes very easy to test
each component of the range composition. Each component is
decoupled from the others, so it's easy for the unittest to
check all code paths. Then it's much easier to have the
confidence that the composed pipeline itself is correct.
I/O pipelines are an easy example, but understandably, in
real-world code things are rarely that clean. So you'll have
to find a way of designing your database code such that it's
more easily testable. Otherwise, it's going to be a challenge
The thing about functional programming where functions are
decoupled/testable doesn't seem to apply to database call code. I
guess its because databases introduces a different
state...another point of failure.
no matter what. No matter what you do, testing a function made
of loops nested 5 levels deep is going to be very hard.
Similarly, if your database code has very complex
interdependencies, then it's going to be hard to test no matter
how you try.
My code logic is a mix of file uploads which leads to saving file
info into db. And some general queries... my worry has been
adding a feature which might cause a regression in another rearly
executed code...its feels like I have to test all features/rest
calls after every major change. Don't know how others do
this...when there's some tight coupling involved.
Anyway, on the more practical side of things, depending on what
your test is trying to do, a mock database could be as simple
as:
struct MockDb {
string prebakedResponse;
auto query(string sql) {
if (sql == "SELECT * FROM data")
return prebakedResponse;
else if (sql == "UPDATE * SET ... ")
prebakedResponse = ...
else
assert(0, "Time to rewrite your unittest :-P");
}
}
I.e., you literally only need to implement what the test case
will actually invoke. Anything that isn't strictly required is
fair game to just outright ignore.
Also, keep in mind that MockDb can be a completely different
thing per unittest. Trying to use the same mock DB for all
unittests will just end up with writing your own database
engine, which kinda defeats the purpose. :-P But the ability
to do this depends on how decoupled the code is. Code with
complex interdependencies will generally give you a much harder
time than more modular, decoupled code.
T
Re: Testing D database calls code for regression
On Sun, Mar 18, 2018 at 07:51:18PM +, aberba via Digitalmars-d-learn wrote:
> On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote:
> > On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via Digitalmars-d-learn
> > wrote:
> > > [...]
> >
> > The usual way I do this is to decouple the code from the real
> > database backend by templatizing the database driver. Then in my
> > unittest I can instantiate the template with a mock database driver
> > that only implements the bare minimum to run the test.
> >
> > [...]
>
> Mocking a fake database can also be huge pain. Especially when
> something like transactions and prepared statements are involved.
It depends on what your test is looking for. The idea is that the mock
database only implements a (small!) subset of a real database, basically
just enough for the test to run, and nothing more. Of course, sometimes
it may not be easy to do this, if the code being tested is very complex.
> Imagine testing your mock for introduced by future extension.
If you find yourself needing to test your mock database, then you're
doing it wrong. :-D It's supposed to be helping you test your code,
not to create more code that itself needs to be tested!
Basically, this kind of testing imposes certain requirements on the way
you write your code. Certain kinds of code are easier to test than
others. For example, imagine trying to test a complex I/O pipeline
implemented as nested loops. It's basically impossible to test it except
as a blackbox testing (certain input sets must produce certain output
sets). It's usually impractical for the test to target specific code
paths nested deep inside a nested loop. The only thing you can do is to
hope and pray that your blackbox tests cover enough of the code paths to
ensure things are correct. But you're likely to miss certain exceptional
cases.
But if said I/O pipeline is implemented as series of range compositions,
for example, then it becomes very easy to test each component of the
range composition. Each component is decoupled from the others, so it's
easy for the unittest to check all code paths. Then it's much easier to
have the confidence that the composed pipeline itself is correct.
I/O pipelines are an easy example, but understandably, in real-world
code things are rarely that clean. So you'll have to find a way of
designing your database code such that it's more easily testable.
Otherwise, it's going to be a challenge no matter what. No matter what
you do, testing a function made of loops nested 5 levels deep is going
to be very hard. Similarly, if your database code has very complex
interdependencies, then it's going to be hard to test no matter how you
try.
Anyway, on the more practical side of things, depending on what your
test is trying to do, a mock database could be as simple as:
struct MockDb {
string prebakedResponse;
auto query(string sql) {
if (sql == "SELECT * FROM data")
return prebakedResponse;
else if (sql == "UPDATE * SET ... ")
prebakedResponse = ...
else
assert(0, "Time to rewrite your unittest :-P");
}
}
I.e., you literally only need to implement what the test case will
actually invoke. Anything that isn't strictly required is fair game to
just outright ignore.
Also, keep in mind that MockDb can be a completely different thing per
unittest. Trying to use the same mock DB for all unittests will just end
up with writing your own database engine, which kinda defeats the
purpose. :-P But the ability to do this depends on how decoupled the
code is. Code with complex interdependencies will generally give you a
much harder time than more modular, decoupled code.
T
--
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose
Bierce
Re: Testing D database calls code for regression
On Sunday, March 18, 2018 19:51:18 aberba via Digitalmars-d-learn wrote: > On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote: > > On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via > > > > Digitalmars-d-learn wrote: > >> [...] > > > > The usual way I do this is to decouple the code from the real > > database backend by templatizing the database driver. Then in > > my unittest I can instantiate the template with a mock database > > driver that only implements the bare minimum to run the test. > > > > [...] > > Mocking a fake database can also be huge pain. Especially when > something like transactions and prepared statements are involved. > > Imagine testing your mock for introduced by future extension. The other way would be to create a test database (or databases) and use those with the normal code, though you have less control over some stuff that way. What makes the most sense depends on what you're doing and how much you're able to really unit test the pieces as opposed to component testing large chunks of the code at once. And the reality of the matter is that sometimes testing is a pain, though in the long run, it pretty much always saves time and pain even if it's a pain to get set up. - Jonathan M Davis
Re: Testing D database calls code for regression
On Friday, 16 March 2018 at 21:15:33 UTC, H. S. Teoh wrote: On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via Digitalmars-d-learn wrote: [...] The usual way I do this is to decouple the code from the real database backend by templatizing the database driver. Then in my unittest I can instantiate the template with a mock database driver that only implements the bare minimum to run the test. [...] Mocking a fake database can also be huge pain. Especially when something like transactions and prepared statements are involved. Imagine testing your mock for introduced by future extension.
Re: Testing D database calls code for regression
On Friday, 16 March 2018 at 20:17:49 UTC, aberba wrote: How will you test D code which makes calls to database to detect bugs and regression. Unlike where you can inject data like assert (2+1 == 3), database interfacing code will be crazy... Or there's some mocking available for such cases. Especially when more features are developed on top. would type providers (https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/type-providers/) be posible with ctfe? that would be one way to test at compile time functions that use the db.
Re: Testing D database calls code for regression
On Fri, Mar 16, 2018 at 08:17:49PM +, aberba via Digitalmars-d-learn wrote:
> How will you test D code which makes calls to database to detect bugs
> and regression. Unlike where you can inject data like assert (2+1 ==
> 3), database interfacing code will be crazy... Or there's some mocking
> available for such cases. Especially when more features are developed
> on top.
The usual way I do this is to decouple the code from the real database
backend by templatizing the database driver. Then in my unittest I can
instantiate the template with a mock database driver that only
implements the bare minimum to run the test.
For example, instead of:
import database : Database;
auto myQueryFunc(Args...)(Database db, Args args) {
return db.query(...);
}
Do this:
import database : Database;
auto myQueryFunc(Db = database.Database, Args...)(Db db, Args args) {
return db.query(...);
}
Then regular calls to myQueryFunc will call the real database backend,
as usual. But in the unittest:
unittest {
struct FakeDb {
auto query(...) {
// mock implementation here
}
}
FakeDb db;
// test away
assert(myQueryFunc(db, ...) == ... ); // uses FakeDb
}
This applies not only to database backends, but just about anything you
need to insert mockups for. For example, for testing complicated file
I/O, I've found it useful to do this:
auto myFunc(File = std.stdio.File, Args...)(Args args) {
auto f = File(...);
// do stuff with f
}
unittest
{
struct FakeFile {
this(...) { ... }
// mockup here
}
assert(myFunc!FakeFile(...) == ... );
}
Using this method, you can even create tests for error-handling, like a
simulated filesystem that returns random (simulated) I/O errors, or
exhibits various disk-full conditions (without actually filling up your
real disk!), etc.. I've created tests for code that searches
directories for files, by substituting a fake filesystem that contains
pre-determined sets of files with content that only exist inside the
unittest. This way, I can run these tests without actually modifying my
real filesystem in any way.
If you push this idea far enough, you might be able to write unittests
for simulated syscalls, too. :-D (Maybe that's something we could do in
druntime... :-P)
T
--
May you live all the days of your life. -- Jonathan Swift
Testing D database calls code for regression
How will you test D code which makes calls to database to detect bugs and regression. Unlike where you can inject data like assert (2+1 == 3), database interfacing code will be crazy... Or there's some mocking available for such cases. Especially when more features are developed on top.
Re: is it regression?
On Wednesday, February 28, 2018 14:28:47 bauss via Digitalmars-d-learn wrote: > On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote: > > done https://issues.dlang.org/show_bug.cgi?id=18539 > > I would argue that isn't a regression and that you __should__ use > the .get and that it's not a workaround, because nullable's > shouldn't be treated like that type they encapsulate. > > std.math members such as approxEqual shouldn't have to take > nullable into account. approxEqual shouldn't have to take Nullable into account. The fact that (for better or worse), Nullable's get is alias this-ed should take care of it. Given that alias this, it should just work without approxEqual doing anything. And if get were actually deprecated and removed, then approxEqual still wouldn't take Nullable into account, since at that point, get would be called explicitly. - Jonathan M Davis
Re: is it regression?
I would say it is a still regression, but I agree with you, that it should not work on the first place. On Wed, Feb 28, 2018 at 3:28 PM, bauss via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote: > On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote: > >> done https://issues.dlang.org/show_bug.cgi?id=18539 >> > > I would argue that isn't a regression and that you __should__ use the .get > and that it's not a workaround, because nullable's shouldn't be treated > like that type they encapsulate. > > std.math members such as approxEqual shouldn't have to take nullable into > account. >
Re: is it regression?
On Wednesday, 28 February 2018 at 13:38:56 UTC, drug wrote: done https://issues.dlang.org/show_bug.cgi?id=18539 I would argue that isn't a regression and that you __should__ use the .get and that it's not a workaround, because nullable's shouldn't be treated like that type they encapsulate. std.math members such as approxEqual shouldn't have to take nullable into account.
Re: is it regression?
done https://issues.dlang.org/show_bug.cgi?id=18539
Re: is it regression?
Yes it is a regression, please fill a bug report
On Wed, Feb 28, 2018 at 2:16 PM, drug via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> https://run.dlang.io/is/HJxtvw
>
> ```
> import std.stdio, std.typecons, std.math;
> void main()
> {
> auto foo = nullable(2.0);
> auto bar = nullable(2.0);
>
> assert (foo.approxEqual(bar));
> }
> ```
> Comiling gives the following:
> Up to 2.067.1: Failure with output:
> -
> onlineapp.d(4): Error: undefined identifier nullable, did you mean struct
> Nullable(T)?
> onlineapp.d(5): Error: undefined identifier nullable, did you mean struct
> Nullable(T)?
> -
>
> 2.068.2 to 2.072.2: Failure with output:
> -
> onlineapp.d(4): Error: undefined identifier 'nullable', did you mean
> struct 'Nullable(T)'?
> onlineapp.d(5): Error: undefined identifier 'nullable', did you mean
> struct 'Nullable(T)'?
> -
>
> 2.073.2 to 2.077.1: Success and no output
> Since 2.078.1: Failure with output:
> -
> /path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7575):
> Error: template std.math.approxEqual cannot deduce function from argument
> types !()(Nullable!double, Nullable!double, double, double), candidates are:
> /path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7499):
> std.math.approxEqual(T, U, V)(T lhs, U rhs, V maxRelDiff, V maxAbsDiff =
> 1e-05) if ((isNumeric!T || isInputRange!T && isNumeric!(ElementType!T)) &&
> (isNumeric!U || isInputRange!U && isNumeric!(ElementType!U)) && isNumeric!V)
> /path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7573):
> std.math.approxEqual(T, U)(T lhs, U rhs)
> onlineapp.d(7): Error: template instance
> std.math.approxEqual!(Nullable!double,
> Nullable!double) error instantiating
> -
> tldr - std.math.approxEqual stops deduced its args type when Nullable is
> used.
>
is it regression?
https://run.dlang.io/is/HJxtvw
```
import std.stdio, std.typecons, std.math;
void main()
{
auto foo = nullable(2.0);
auto bar = nullable(2.0);
assert (foo.approxEqual(bar));
}
```
Comiling gives the following:
Up to 2.067.1: Failure with output:
-
onlineapp.d(4): Error: undefined identifier nullable, did you mean
struct Nullable(T)?
onlineapp.d(5): Error: undefined identifier nullable, did you mean
struct Nullable(T)?
-
2.068.2 to 2.072.2: Failure with output:
-
onlineapp.d(4): Error: undefined identifier 'nullable', did you mean
struct 'Nullable(T)'?
onlineapp.d(5): Error: undefined identifier 'nullable', did you mean
struct 'Nullable(T)'?
-
2.073.2 to 2.077.1: Success and no output
Since 2.078.1: Failure with output:
-
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7575):
Error: template std.math.approxEqual cannot deduce function from
argument types !()(Nullable!double, Nullable!double, double, double),
candidates are:
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7499):
std.math.approxEqual(T, U, V)(T lhs, U rhs, V maxRelDiff, V
maxAbsDiff = 1e-05) if ((isNumeric!T || isInputRange!T &&
isNumeric!(ElementType!T)) && (isNumeric!U || isInputRange!U &&
isNumeric!(ElementType!U)) && isNumeric!V)
/path/to/dmd.linux/dmd2/linux/bin64/../../src/phobos/std/math.d(7573):
std.math.approxEqual(T, U)(T lhs, U rhs)
onlineapp.d(7): Error: template instance
std.math.approxEqual!(Nullable!double, Nullable!double) error instantiating
-
tldr - std.math.approxEqual stops deduced its args type when Nullable is
used.
Re: Possible dmd 2.078 regression ?
On Friday, 12 January 2018 at 18:51:31 UTC, Basile B. wrote: On Friday, 12 January 2018 at 18:50:10 UTC, Basile B. wrote: On Friday, 12 January 2018 at 17:58:30 UTC, Stefan Koch wrote: On Friday, 12 January 2018 at 14:13:22 UTC, Basile B. wrote: I have a simple program that only compiles if the dependency is not pre-compiled as a static library. It worked fine before. I guess a mangle problem ? Yes and quite old...apparently it's more a 2.074.x regression. i'm digging right now. digger: Commit 1e7b526b40852e9b85df3684430e371034cdf7ec (1/1) is untestable. digger: There are only untestable commits left to bisect. digger: The first bad commit could be any of: digger: 1e7b526b40852e9b85df3684430e371034cdf7ec digger: 6fecaa8232a427fb3ca29c5a5245e08fc43b71b1 digger: f0410bea1ad2b130884964d603b34e729b3e4f69 object.Exception@bisect.d(186): We cannot bisect more! please file a bug on d.puremagic.com/issues/
Re: Possible dmd 2.078 regression ?
On Friday, 26 January 2018 at 22:15:15 UTC, Basile B. wrote: On Friday, 26 January 2018 at 21:52:30 UTC, timotheecour wrote: On Friday, 12 January 2018 at 18:51:31 UTC, Basile B. wrote: On Friday, 12 January 2018 at 18:50:10 UTC, Basile B. wrote: On Friday, 12 January 2018 at 17:58:30 UTC, Stefan Koch wrote: On Friday, 12 January 2018 at 14:13:22 UTC, Basile B. wrote: I have a simple program that only compiles if the dependency is not pre-compiled as a static library. It worked fine before. I guess a mangle problem ? Yes and quite old...apparently it's more a 2.074.x regression. i'm digging right now. digger: Commit 1e7b526b40852e9b85df3684430e371034cdf7ec (1/1) is untestable. digger: There are only untestable commits left to bisect. digger: The first bad commit could be any of: digger: 1e7b526b40852e9b85df3684430e371034cdf7ec digger: 6fecaa8232a427fb3ca29c5a5245e08fc43b71b1 digger: f0410bea1ad2b130884964d603b34e729b3e4f69 object.Exception@bisect.d(186): We cannot bisect more! please file a bug on d.puremagic.com/issues/ Yeah i did. https://issues.dlang.org/show_bug.cgi?id=18234 I saw a related (but not similar) thing yesterday. the guy has to pass a dummy.d file for linking to succeed. Ah it was you actually: https://forum.dlang.org/thread/mailman.2616.1516919399.9493.digitalmars-d-b...@puremagic.com
Re: Possible dmd 2.078 regression ?
On Friday, 26 January 2018 at 21:52:30 UTC, timotheecour wrote: On Friday, 12 January 2018 at 18:51:31 UTC, Basile B. wrote: On Friday, 12 January 2018 at 18:50:10 UTC, Basile B. wrote: On Friday, 12 January 2018 at 17:58:30 UTC, Stefan Koch wrote: On Friday, 12 January 2018 at 14:13:22 UTC, Basile B. wrote: I have a simple program that only compiles if the dependency is not pre-compiled as a static library. It worked fine before. I guess a mangle problem ? Yes and quite old...apparently it's more a 2.074.x regression. i'm digging right now. digger: Commit 1e7b526b40852e9b85df3684430e371034cdf7ec (1/1) is untestable. digger: There are only untestable commits left to bisect. digger: The first bad commit could be any of: digger: 1e7b526b40852e9b85df3684430e371034cdf7ec digger: 6fecaa8232a427fb3ca29c5a5245e08fc43b71b1 digger: f0410bea1ad2b130884964d603b34e729b3e4f69 object.Exception@bisect.d(186): We cannot bisect more! please file a bug on d.puremagic.com/issues/ Yeah i did. https://issues.dlang.org/show_bug.cgi?id=18234 I saw a related (but not similar) thing yesterday. the guy has to pass a dummy.d file for linking to succeed.
Re: Possible dmd 2.078 regression ?
On Friday, 12 January 2018 at 18:50:10 UTC, Basile B. wrote: On Friday, 12 January 2018 at 17:58:30 UTC, Stefan Koch wrote: On Friday, 12 January 2018 at 14:13:22 UTC, Basile B. wrote: I have a simple program that only compiles if the dependency is not pre-compiled as a static library. It worked fine before. I guess a mangle problem ? Yes and quite old...apparently it's more a 2.074.x regression. i'm digging right now. digger: Commit 1e7b526b40852e9b85df3684430e371034cdf7ec (1/1) is untestable. digger: There are only untestable commits left to bisect. digger: The first bad commit could be any of: digger: 1e7b526b40852e9b85df3684430e371034cdf7ec digger: 6fecaa8232a427fb3ca29c5a5245e08fc43b71b1 digger: f0410bea1ad2b130884964d603b34e729b3e4f69 object.Exception@bisect.d(186): We cannot bisect more!
Re: Possible dmd 2.078 regression ?
On Friday, 12 January 2018 at 14:13:22 UTC, Basile B. wrote: I have a simple program that only compiles if the dependency is not pre-compiled as a static library. It worked fine before. Please test this --- if [ ! -d "iz" ]; then git clone https://www.github.com/BBasile/iz.git fi cd iz/scripts sh compile.sh cd ../ #fails to link dmd samples/dictionnary_suffixarray.d lib/iz.a -Iimport > ddemangle #on the other hand, this works... dub samples/dictionnary_suffixarray.d <<< "q" #or even this... dmd samples/dictionnary_suffixarray.d import/iz/strings.d import/iz/memory.d -Iimport --- and tell me what do you think: regression or not ? I guess a mangle problem ?
Possible dmd 2.078 regression ?
I have a simple program that only compiles if the dependency is not pre-compiled as a static library. It worked fine before. Please test this --- if [ ! -d "iz" ]; then git clone https://www.github.com/BBasile/iz.git fi cd iz/scripts sh compile.sh cd ../ #fails to link dmd samples/dictionnary_suffixarray.d lib/iz.a -Iimport > ddemangle #on the other hand, this works... dub samples/dictionnary_suffixarray.d <<< "q" #or even this... dmd samples/dictionnary_suffixarray.d import/iz/strings.d import/iz/memory.d -Iimport --- and tell me what do you think: regression or not ?
Re: Returning the address of a reference return value in @safe code - 2.072 regression?
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote: The error is: "cannot take address of ref return of this.foo() in @safe function bar". Maybe a bugfix in safety system? Should it go through deprecation process?
Re: Returning the address of a reference return value in @safe code - 2.072 regression?
On Monday, 20 February 2017 at 21:05:17 UTC, Jack Stouffer wrote: On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer wrote: On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote: ... Yeah, this is another regression caused by DIP1000. Christ. For the record, the current list of regressions caused by DIP1000 https://issues.dlang.org/show_bug.cgi?id=17213 https://issues.dlang.org/show_bug.cgi?id=17188 https://issues.dlang.org/show_bug.cgi?id=17123 https://issues.dlang.org/show_bug.cgi?id=17117 17117 and 17123 are already fixed on HEAD, no? So only two regressions remaining - I hope DIP1000 can be used to build new container libraries soon.
Re: Returning the address of a reference return value in @safe code - 2.072 regression?
On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer wrote: On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote: ... Yeah, this is another regression caused by DIP1000. Christ. For the record, the current list of regressions caused by DIP1000 https://issues.dlang.org/show_bug.cgi?id=17213 https://issues.dlang.org/show_bug.cgi?id=17188 https://issues.dlang.org/show_bug.cgi?id=17123 https://issues.dlang.org/show_bug.cgi?id=17117
Re: Returning the address of a reference return value in @safe code - 2.072 regression?
On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote: ... Yeah, this is another regression caused by DIP1000. Christ.
Returning the address of a reference return value in @safe code - 2.072 regression?
This code compiles with 2.071, but not with 2.072 nor 2.073:
```
struct S {
int i;
auto ref foo() @safe {
return i;
}
auto bar() @safe {
return (); // <-- Error
}
}
void main() {
auto s = S();
s.bar();
}
```
The error is: "cannot take address of ref return of this.foo() in
@safe function bar".
Is this a compiler regression, or is it a bug in the D code?
https://issues.dlang.org/show_bug.cgi?id=17213
Thanks,
Johan
Re: isNumeric bugfix or 2.072 regression?
On Thursday, 16 February 2017 at 23:15:09 UTC, Johan Engelen wrote: Hi all, `isNumeric!string` no longer works like it did in 2.071 when both std.string and std.traits are imported. https://issues.dlang.org/show_bug.cgi?id=17190
isNumeric bugfix or 2.072 regression?
Hi all,
`isNumeric!string` no longer works like it did in 2.071 when both
std.string and std.traits are imported.
This code no longer compiles with 2.072:
```d
// RUN: dmd -c test.d
import std.string;
import std.traits;
void foo()
{
static if (isNumeric!string) {}
}
```
The error is (dlang 2.072 and 2.073):
isnum.d(6): Error: std.traits.isNumeric(T) at
/Library/D/dmd/src/phobos/std/traits.d(5350) conflicts with
std.string.isNumeric(S)(S s, bool bAllowSep = false) if
(isSomeString!S || isRandomAccessRange!S && hasSlicing!S &&
isSomeChar!(ElementType!S) && !isInfinite!S) at
/Library/D/dmd/src/phobos/std/string.d(5844)
dlang 2.070 and 2.071 compile it fine.
Is this part of fixing import issues and the above code is just
broken, or is it a bug?
- Johan
Re: Issue with 2.071: Regression or valid error?
Dne 8.4.2016 v 14:56 Steven Schveighoffer via Digitalmars-d-learn napsal(a):
On 4/8/16 2:08 AM, 9il wrote:
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven Schveighoffer wrote:
On 4/6/16 11:10 AM, Andre wrote:
[...]
Just FYI, you don't need a semicolon there.
[...]
Wow, totally agree with you. Compiler shouldn't make you jump through
this hoop:
void foo(Cat cat)
{
Animal a = cat;
a.create();
}
Please file a bug report, not sure why this happened.
Why this is a bug? private methods are not virtual, are they? --Ilya
A Cat is an Animal. The compiler knows this. The 'a' module has access
to Animal private methods.
This isn't a virtual call, but a call to a base class member. Those
are allowed. How can you think this is not a bug?
Would you think it was a bug if create was a final function instead of
private? This is exactly the same thing.
-Steve
Yes ou are right, I see it now :), thanks.
Re: Issue with 2.071: Regression or valid error?
On 4/7/16 11:55 AM, Steven Schveighoffer wrote: Please file a bug report, not sure why this happened. I filed it for you: https://issues.dlang.org/show_bug.cgi?id=15897 -Steve
Re: Issue with 2.071: Regression or valid error?
On 4/8/16 2:08 AM, 9il wrote:
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven Schveighoffer wrote:
On 4/6/16 11:10 AM, Andre wrote:
[...]
Just FYI, you don't need a semicolon there.
[...]
Wow, totally agree with you. Compiler shouldn't make you jump through
this hoop:
void foo(Cat cat)
{
Animal a = cat;
a.create();
}
Please file a bug report, not sure why this happened.
Why this is a bug? private methods are not virtual, are they? --Ilya
A Cat is an Animal. The compiler knows this. The 'a' module has access
to Animal private methods.
This isn't a virtual call, but a call to a base class member. Those are
allowed. How can you think this is not a bug?
Would you think it was a bug if create was a final function instead of
private? This is exactly the same thing.
-Steve
Re: Issue with 2.071: Regression or valid error?
On Friday, 8 April 2016 at 08:26:11 UTC, Daniel Kozak wrote:
On Friday, 8 April 2016 at 06:08:38 UTC, 9il wrote:
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven
Schveighoffer wrote:
Wow, totally agree with you. Compiler shouldn't make you jump
through this hoop:
void foo(Cat cat)
{
Animal a = cat;
a.create();
}
Please file a bug report, not sure why this happened.
-Steve
Why this is a bug? private methods are not virtual, are they?
--Ilya
No they are not virtual, so this is not a bug.
I disagree, virtuality has nothing to do with this. After all,
moving Cat to the same module as Animal, or making create()
public final will make the code compile.
Private symbols can (only) be accessed from the module where they
are defined, so anything in the animal module should be able to
call create() on a Cat just fine.
Re: Issue with 2.071: Regression or valid error?
On Friday, 8 April 2016 at 06:08:38 UTC, 9il wrote:
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven Schveighoffer
wrote:
On 4/6/16 11:10 AM, Andre wrote:
[...]
Just FYI, you don't need a semicolon there.
[...]
Wow, totally agree with you. Compiler shouldn't make you jump
through this hoop:
void foo(Cat cat)
{
Animal a = cat;
a.create();
}
Please file a bug report, not sure why this happened.
-Steve
Why this is a bug? private methods are not virtual, are they?
--Ilya
No they are not virtual, so this is not a bug.
Re: Issue with 2.071: Regression or valid error?
On Thursday, 7 April 2016 at 15:55:16 UTC, Steven Schveighoffer
wrote:
On 4/6/16 11:10 AM, Andre wrote:
[...]
Just FYI, you don't need a semicolon there.
[...]
Wow, totally agree with you. Compiler shouldn't make you jump
through this hoop:
void foo(Cat cat)
{
Animal a = cat;
a.create();
}
Please file a bug report, not sure why this happened.
-Steve
Why this is a bug? private methods are not virtual, are they?
--Ilya
Re: Issue with 2.071: Regression or valid error?
On 4/6/16 11:10 AM, Andre wrote:
Hi,
With 2.071 following coding does not compile anymore and somehow I feel
it should compile.
The issue is with line "cat.create();".
Cat is a sub type of Animal. Animal "owns" method create and I want to
call the method
create within the class Animal for cat.
Is the error message "no property create for type 'b.cat'" valid or not?
Kind regards
André
module a;
import b;
class Animal
{
private void create() {}
void foo(Cat cat)
{
cat.create(); // >> no property create for type 'b.cat'
}
}
void main() {}
--
module b;
import a;
class Cat: Animal {};
Just FYI, you don't need a semicolon there.
compile with
rdmd a b
Wow, totally agree with you. Compiler shouldn't make you jump through
this hoop:
void foo(Cat cat)
{
Animal a = cat;
a.create();
}
Please file a bug report, not sure why this happened.
-Steve
Re: Issue with 2.071: Regression or valid error?
On Wednesday, 6 April 2016 at 19:22:44 UTC, Daniel Kozak wrote: This should not compile. Cat cant access create because it is private. Ok it can access it but only if you move cat into same module as animal Dne 6. 4. 2016 17:16 napsal uživatel "Andre via Digitalmars-d-learn" < digitalmars-d-learn@puremagic.com>: Thanks for the answers. Kind regards André
Re: Issue with 2.071: Regression or valid error?
This should not compile. Cat cant access create because it is private. Ok
it can access it but only if you move cat into same module as animal
Dne 6. 4. 2016 17:16 napsal uživatel "Andre via Digitalmars-d-learn" <
digitalmars-d-learn@puremagic.com>:
> Hi,
>
> With 2.071 following coding does not compile anymore and somehow I feel it
> should compile.
> The issue is with line "cat.create();".
> Cat is a sub type of Animal. Animal "owns" method create and I want to
> call the method
> create within the class Animal for cat.
>
> Is the error message "no property create for type 'b.cat'" valid or not?
>
> Kind regards
> André
>
> module a;
> import b;
>
> class Animal
> {
> private void create() {}
>
> void foo(Cat cat)
> {
> cat.create(); // >> no property create for type 'b.cat'
> }
> }
>
> void main() {}
>
> --
>
> module b;
> import a;
>
> class Cat: Animal {};
>
> compile with
>
>> rdmd a b
>>>
>>
Re: Issue with 2.071: Regression or valid error?
On Wednesday, 6 April 2016 at 19:01:58 UTC, Craig Dillabaugh wrote: On Wednesday, 6 April 2016 at 15:10:45 UTC, Andre wrote: clip Not so up to date on D's OOP stuff, but don't you want create() to be protected, not private. You can typically access a private method through a base class, which is what you are doing with cat.create(). You CAN'T typically access a private ...
Re: Issue with 2.071: Regression or valid error?
On Wednesday, 6 April 2016 at 15:10:45 UTC, Andre wrote:
Hi,
With 2.071 following coding does not compile anymore and
somehow I feel it should compile.
The issue is with line "cat.create();".
Cat is a sub type of Animal. Animal "owns" method create and I
want to call the method
create within the class Animal for cat.
Is the error message "no property create for type 'b.cat'"
valid or not?
Kind regards
André
module a;
import b;
class Animal
{
private void create() {}
void foo(Cat cat)
{
cat.create(); // >> no property create for type 'b.cat'
}
}
void main() {}
--
module b;
import a;
class Cat: Animal {};
compile with
rdmd a b
Not so up to date on D's OOP stuff, but don't you want create()
to be protected, not private. You can typically access a private
method through a base class, which is what you are doing with
cat.create().
Issue with 2.071: Regression or valid error?
Hi,
With 2.071 following coding does not compile anymore and somehow
I feel it should compile.
The issue is with line "cat.create();".
Cat is a sub type of Animal. Animal "owns" method create and I
want to call the method
create within the class Animal for cat.
Is the error message "no property create for type 'b.cat'" valid
or not?
Kind regards
André
module a;
import b;
class Animal
{
private void create() {}
void foo(Cat cat)
{
cat.create(); // >> no property create for type 'b.cat'
}
}
void main() {}
--
module b;
import a;
class Cat: Animal {};
compile with
rdmd a b
Re: Regression vs Bug
V Thu, 14 Jan 2016 17:32:47 + NX via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> napsáno: > Please explain. Regression: something works before does not work anymore Bug: something does not work as expected (regression is one type of bug)
Regression vs Bug
Please explain.
Re: Regression?
On Wednesday, 9 September 2015 at 01:35:26 UTC, Sebastiaan Koppe
wrote:
Thanks for your advice. But that is not what I asked for.
The question was, why doesn't this work anymore with the latest
(2.068.0 and 2.068.1) compiler:
```
auto ls =
File("../languages.json","r").byLineCopy().joiner.parseJSON();
```
It should. Right?
I just ran into this as well. This seems like a regression.
Re: Regression?
On Wednesday, 9 September 2015 at 01:35:26 UTC, Sebastiaan Koppe
wrote:
Thanks for your advice. But that is not what I asked for.
The question was, why doesn't this work anymore with the latest
(2.068.0 and 2.068.1) compiler:
```
auto ls =
File("../languages.json","r").byLineCopy().joiner.parseJSON();
```
It should. Right?
https://issues.dlang.org/show_bug.cgi?id=15423
Re: Regression?
On Tuesday, 8 September 2015 at 04:04:16 UTC, Sebastiaan Koppe
wrote:
Fixed it by changing into:
```
import std.conv : text;
string json =
File("../languages.json","r").byLineCopy().joiner.text;
auto ls = json.parseJSON();
```
Why would you read file by line and then merge all into one
string? You end up with reading the whole file (well, getting rid
of line ends) anyway, so probably the more efficient solution
would be just read the whole file at once with std.file.read and
cast to string.
Re: Regression?
On Tuesday, September 08, 2015 07:12:50 FreeSlave via Digitalmars-d-learn wrote:
> On Tuesday, 8 September 2015 at 04:04:16 UTC, Sebastiaan Koppe
> wrote:
> > Fixed it by changing into:
> >
> > ```
> > import std.conv : text;
> > string json =
> > File("../languages.json","r").byLineCopy().joiner.text;
> > auto ls = json.parseJSON();
> > ```
>
> Why would you read file by line and then merge all into one
> string? You end up with reading the whole file (well, getting rid
> of line ends) anyway, so probably the more efficient solution
> would be just read the whole file at once with std.file.read and
> cast to string.
Or just use std.file.readText:
http://dlang.org/phobos/std_file.html#readText
- Jonathan M Davis
Re: Regression?
On Tuesday, 8 September 2015 at 07:12:52 UTC, FreeSlave wrote:
On Tuesday, 8 September 2015 at 04:04:16 UTC, Sebastiaan Koppe
wrote:
Fixed it by changing into:
```
import std.conv : text;
string json =
File("../languages.json","r").byLineCopy().joiner.text;
auto ls = json.parseJSON();
```
Why would you read file by line and then merge all into one
string? You end up with reading the whole file (well, getting
rid of line ends) anyway, so probably the more efficient
solution would be just read the whole file at once with
std.file.read and cast to string.
Thanks for your advice. But that is not what I asked for.
The question was, why doesn't this work anymore with the latest
(2.068.0 and 2.068.1) compiler:
```
auto ls =
File("../languages.json","r").byLineCopy().joiner.parseJSON();
```
It should. Right?
Re: Regression?
Fixed it by changing into:
```
import std.conv : text;
string json =
File("../languages.json","r").byLineCopy().joiner.text;
auto ls = json.parseJSON();
```
Re: Regression?
Dammit, i am on windows, DMD32 D Compiler v2.068.0
Regression?
This used to work in older compiler (might have been v2.067 or
v2.066, not older).
```
#!rdmd
import std.stdio;
import std.json;
import std.algorithm;
void main() {
auto ls =
File("../languages.json","r").byLineCopy().joiner.parseJSON();
}
```
Error: c:\D\dmd2\windows\bin\..\..\src\phobos\std\json.d(639):
Error: variable std.json.parseJSON!(Result).parseJSON.json has
scoped destruction, cannot build closure
2.068 Regression in EnumMembers?
I tried rebuilding my knowledge graph project at https://github.com/nordlow/justd/tree/master/knet with DMD 2.068 and it seems like we have a regression in std.traits: EnumMembers: /usr/include/dmd/phobos/std/traits.d(3432,21): Error: template instance std.traits.EnumMembers!(Lang).WithIdentifier!fortran recursive expansion scons: *** [knet/traversal.o] Error 1 /usr/include/dmd/phobos/std/traits.d(3432,21): Error: template instance std.traits.EnumMembers!(Lang).WithIdentifier!firstAcademic recursive expansion scons: *** [knet/base.o] Error 1 /usr/include/dmd/phobos/std/traits.d(3432,21): Error: template instance std.traits.EnumMembers!(const(Lang)).WithIdentifier!physics recursive expansion scons: *** [knet/io.o] Error 1 /usr/include/dmd/phobos/std/traits.d(3432,21): Error: template instance std.traits.EnumMembers!(Lang).WithIdentifier!modelica recursive expansion scons: *** [knet/tests.o] Error 1 Sadly the diagnositcs give no help whatsoever on what's wrong. What happened to the instantiation stack trace here? Try cloning https://github.com/nordlow/justd/tree and building for instance scons knet/base.o provided that SCons has been installed (on Ubuntu as `sudo apt-get install scons`) It builds without errors nor warnings on 2.067. Help, please.
Re: 2.068 Regression in EnumMembers?
On Sunday, 16 August 2015 at 11:25:48 UTC, Nordlöw wrote: I tried rebuilding my knowledge graph project at https://github.com/nordlow/justd/tree/master/knet Should be, https://github.com/nordlow/justd.
Re: 2.068 Regression in EnumMembers?
On Sunday, 16 August 2015 at 11:25:48 UTC, Nordlöw wrote: Try cloning https://github.com/nordlow/justd/tree Should be: git clone https://github.com/nordlow/justd
Re: 2.068 Regression in EnumMembers?
On Sunday, 16 August 2015 at 11:25:48 UTC, Nordlöw wrote: I tried rebuilding my knowledge graph project at https://github.com/nordlow/justd/tree/master/knet with DMD 2.068 and it seems like we have a regression in std.traits: EnumMembers: [...] It builds without errors nor warnings on 2.067. Help, please. Did it still work in 2.068a ? If so then it's possible that the resolution of issue 14844, which changed the traits allMembers, is the cause. Because if you look at std.traits 'blame' on GH (https://github.com/D-Programming-Language/phobos/blame/master/std/traits.d , around line 3412) that's clear that the template EnumMembers hasn't changed since February 2014. So it must be one of the call inside... Just an idea.
dmd Regression(?): bigEndianToNative buffer slice allows only literals
The std.batmanip bigEndianToNative has a regression where the
slice range doesn't work with variables (only literals).
Is the syntax incorrect or is this a regression in dmd?
Using this main.d:
import std.bitmanip;
int main(string args[])
{
auto datain = new ubyte[16];
// this syntax works
ushort descriptorLength =
bigEndianToNative!ushort(datain[2..4]);
// this syntax fails (worked in previous version)
int offset = 2;
descriptorLength = bigEndianToNative!ushort(cast(ubyte[2])
datain[offset..offset+2]);
return 0;
}
I get this error on the command line:
main.d(14): Error: cannot cast expression
datain[cast(uint)offset..cast(uint)(offset + 2)] of type ubyte[]
to ubyte[2]
Re: dmd Regression(?): bigEndianToNative buffer slice allows only literals
I reported this as a regression https://issues.dlang.org/show_bug.cgi?id=14582
[dmd 2.066] Is scope with nothrow regression?
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
Re: [dmd 2.066] Is scope with nothrow regression?
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
This is not an error. `scope(failure)` doesn't swallow the
exceptions it catches, it rethrows them when it's done.
Re: [dmd 2.066] Is scope with nothrow regression?
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
This is a bug which was already fixed.
Instead, you can use this:
scope(failure) assert(0);
See: https://issues.dlang.org/show_bug.cgi?id=11542
Re: [dmd 2.066] Is scope with nothrow regression?
On Sunday, 6 July 2014 at 13:04:35 UTC, Marc Schütz wrote:
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
This is not an error. `scope(failure)` doesn't swallow the
exceptions it catches, it rethrows them when it's done.
Thank you, I was expecting different behavior for a long time and
now will use try-catch instead.
Re: [dmd 2.066] Is scope with nothrow regression?
On Sunday, 6 July 2014 at 22:03:21 UTC, hane wrote:
On Sunday, 6 July 2014 at 12:31:42 UTC, NCrashed wrote:
```
void bar()
{
throw new Exception();
}
void foo() nothrow
{
scope(failure) {}
bar();
}
void main() {}
```
Doesn't compile with 2.066:
```
source/app.d(9): Error: 'app.bar' is not nothrow
source/app.d(6): Error: function 'app.foo' is nothrow yet may
throw
```
This is a bug which was already fixed.
Instead, you can use this:
scope(failure) assert(0);
See: https://issues.dlang.org/show_bug.cgi?id=11542
To be exact: a bug I said is that scope(failure) { } breaks
nothrow checking.
Re: Human stupidity or is this a regression?
Lionello Lunesu: Yeah, that's what I ended up doing. But D being D, the default should be safe and correct. I feel we could take this breaking change since it would not silently change the code to do something else. You have to explain such things in the main D newsgroup. D.learn newsgroup is not fit for such requests. Bye, bearophile
Re: Human stupidity or is this a regression?
On 12/26/13, bearophile bearophileh...@lycos.com wrote: You have to explain such things in the main D newsgroup. D.learn newsgroup is not fit for such requests. There have already been a million of these threads, it's worth doing a search as there's probably lots of answers there.
Re: Human stupidity or is this a regression?
On Thursday, 26 December 2013 at 05:39:26 UTC, Lionello Lunesu wrote: On 12/26/13, 11:58, bearophile wrote: Lionello Lunesu: I could have sworn this used to work. Is my memory failing me, or was this a deliberate change at some point? Perhaps a regression? It's not a regression, it's a locked-in design mistake. Write it like this and try again: foreach (dchar d; 你好) Bye, bearophile Yeah, that's what I ended up doing. But D being D, the default should be safe and correct. It is impossible for it to be correct, unless with a very specific definition of correct which makes sense for some languages/locales and not others. As a challenge, try to define a foreach semantic that works correctly with the OP's code for Unicode composite characters, or Hebrew.
Re: Human stupidity or is this a regression?
On Thu, Dec 26, 2013 at 09:38:02PM +, Vladimir Panteleev wrote: On Thursday, 26 December 2013 at 05:39:26 UTC, Lionello Lunesu wrote: On 12/26/13, 11:58, bearophile wrote: Lionello Lunesu: I could have sworn this used to work. Is my memory failing me, or was this a deliberate change at some point? Perhaps a regression? It's not a regression, it's a locked-in design mistake. Write it like this and try again: foreach (dchar d; 你好) Bye, bearophile Yeah, that's what I ended up doing. But D being D, the default should be safe and correct. It is impossible for it to be correct, unless with a very specific definition of correct which makes sense for some languages/locales and not others. As a challenge, try to define a foreach semantic that works correctly with the OP's code for Unicode composite characters, or Hebrew. To be truly correct in the intuitive sense, use std.uni.byGrapheme. (Yes it's slow, but that's the price you pay for intuitive correctness.) T -- It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?
Human stupidity or is this a regression?
Perhaps should have written and/or in the subject line since the two
are not mutually exclusive.
I was showing off D to friends the other day:
import std.stdio;
void main()
{
foreach (d; 你好)
writeln(d);
}
IIRC, this used to work fine, with the variable d getting deduced as
dchar and correctly reassembling the UTF-8 bytes into Unicode codepoints.
But when I run this code in OSX, dmd v2.064, I get this:
$ dmd -run uni.d
�
�
�
�
�
�
It's clearly printing the bytes. When I print the typeof(d) I get
immutable(char), so that confirms the type is not deduced as dchar.
I could have sworn this used to work. Is my memory failing me, or was
this a deliberate change at some point? Perhaps a regression?
L.
Re: Human stupidity or is this a regression?
Lionello Lunesu: I could have sworn this used to work. Is my memory failing me, or was this a deliberate change at some point? Perhaps a regression? It's not a regression, it's a locked-in design mistake. Write it like this and try again: foreach (dchar d; 你好) Bye, bearophile
Re: Human stupidity or is this a regression?
On 12/26/13, 11:58, bearophile wrote: Lionello Lunesu: I could have sworn this used to work. Is my memory failing me, or was this a deliberate change at some point? Perhaps a regression? It's not a regression, it's a locked-in design mistake. Write it like this and try again: foreach (dchar d; 你好) Bye, bearophile Yeah, that's what I ended up doing. But D being D, the default should be safe and correct. I feel we could take this breaking change since it would not silently change the code to do something else. You'll get prompted and we could special case the error message to give a meaningful hint. L
std.typecons.Tuple regression?
The following code used to compile with DMD 2.063.2:
import std.typecons;
struct Foo
{
alias Tuple!(int) NEW_ARGS;
NEW_ARGS args;
void foo ()
{
static if (NEW_ARGS.length == 1) {}
}
}
But compiling the above code with DMD 2.064.2 results in this error:
typecons.d(389): Error: this for _expand_field_0 needs to be type Tuple
not type Foo
Am I doing something wrong or is this a regression? If I do any of the
following the code will compile:
* Move the static-if outside of foo
* Replace NEW_ARGS.length with args.length in the static-if
--
/Jacob Carlborg
Re: Regression or bugfix?
On 2013-09-22 15:49, simendsjo wrote: In 2.063.2, (T!int).stringof == T!(int). In current head, it's T!int. Even (T!(int)).stringof == T!int. So is this a regression bug or a bugfix? Apparently you shouldn't rely on the format of .stringof. See the comment the ones that follow: http://d.puremagic.com/issues/show_bug.cgi?id=10722#c4 -- /Jacob Carlborg
Regression or bugfix?
In 2.063.2, (T!int).stringof == T!(int). In current head, it's T!int. Even (T!(int)).stringof == T!int. So is this a regression bug or a bugfix?
Re: Regression or bugfix?
On Sunday, 22 September 2013 at 13:50:00 UTC, simendsjo wrote: In 2.063.2, (T!int).stringof == T!(int). In current head, it's T!int. Even (T!(int)).stringof == T!int. So is this a regression bug or a bugfix? Added a ticket so it doesn't get lost: http://d.puremagic.com/issues/show_bug.cgi?id=11100
Compiler bug? regression for the template function call syntax
Hi all, Not sure if this is a bug so thought I'd post here. It is very common to use a function template without the call () expecting that it will be called. However with the latest compilers hibernated only compiles when one leaves out the -property dmd command line option. The call: getColumnName!(MemberTest, simple) Has to be changes to: getColumnName!(MemberTest, simple)() Now do that everywhere a template function is used. Any help? Thanks. Rory
Re: Compiler bug? regression for the template function call syntax
On 05/31/2013 07:32 AM, rmc wrote:
It is very common to use a function template without the call ()
expecting that it will be called.
Non-templated functions too.
However with the latest compilers
hibernated only compiles when one leaves out the -property dmd command
line option.
I think it is the same issue with non-templated functions. The best
thing to do is to forget about the -property switch. I did about a year
ago and never looked back. :)
If you need to use the -property switch, then define the function with
the @property attribute:
@property
void getColumnName(T, string s)() {
// ..
}
Ali
Re: Compiler bug? regression for the template function call syntax
On Friday, May 31, 2013 08:27:19 Ali Çehreli wrote: I think it is the same issue with non-templated functions. The best thing to do is to forget about the -property switch. I did about a year ago and never looked back. :) Given the most recent discussions on @property, I think that it's a foregone conclusion that we will never have strict property enforcement (which is what -property is trying to do), and -property will be going away at some point in the future. The general consensus is that folks want optional parens and not have that have anything to do with @property. I think that the only real question at this point is what happens with setters, as some folks want setters to be restricted to @property, and others just want to go to the behavior we had before @property and not need @property at all. For the most part, at this point, @property is looking like a failure. - Jonathan M Davis
shell doesn't throw on error. Is that a regression?
The doc for std.process.shell says If the process could not be
started or exits with an error code, throws an exception.
However on OSX I'm having a different kind of behavior.
Isn't there a unittest to test this?
---
import std.process;
import std.stdio;
void main(){
shell(asfasfasdfasdf);
writeln(ok);
}
---
prints:
in dmd.2.061 - 2.059:
sh: asfasfasdfasdf: command not found
ok
in dmd.2.057:
sh: asfasfasdfasdf: command not found
std.exception.ErrnoException@std/stdio.d(418): Could not close
pipe `asfasfasdfasdf' (Undefined error: 0)
Re: shell doesn't throw on error. Is that a regression?
On 2/3/13, timotheecour thelastmamm...@gmail.com wrote:
Isn't there a unittest to test this?
The only unittest is unfortunately pretty bad:
unittest
{
auto x = shell(echo wyda);
}
Please feel free to file a bug:
http://d.puremagic.com/issues/enter_bug.cgi?product=D
Re: shell doesn't throw on error. Is that a regression?
here goes: http://d.puremagic.com/issues/show_bug.cgi?id=9444 please see my added comment in 9444 regarding capturing std err instead of displaying it.
Re: shell doesn't throw on error. Is that a regression?
On Sunday, 3 February 2013 at 02:28:26 UTC, timotheecour wrote: here goes: http://d.puremagic.com/issues/show_bug.cgi?id=9444 please see my added comment in 9444 regarding capturing std err instead of displaying it. actually the new std.process pull request (http://forum.dlang.org/thread/k5uprq$obu$1...@digitalmars.com) works well. I wonder when that'll get in master?
Re: D1-D2 member call syntax regression?
Nick Sabalausky: That's because my original example accidentally made Foo an uninstantiated class template, so the compiler never bothered to check the semantics... Surely here there is no shortage of ways I can paint myself as a stupid :-) In Python the () after the class name are optional and they do nothing, so I didn't see them in that little D program :-) Bye, bearophile
Still unresolved (Was: D1-D2 member call syntax regression?)
Nick Sabalausky a...@a.a wrote in message news:i2pvvi$2g8...@digitalmars.com... bearophile bearophileh...@lycos.com wrote in message news:i2p4iq$p...@digitalmars.com... Nick Sabalausky: That's because my original example accidentally made Foo an uninstantiated class template, so the compiler never bothered to check the semantics... Surely here there is no shortage of ways I can paint myself as a stupid :-) In Python the () after the class name are optional and they do nothing, so I didn't see them in that little D program :-) *I'm* the one that was dumb enough put them there in the first place! And I can't use extensive Python experience as an excuse ;) It still leaves the question though, Why isn't that working in D2? Bug or legitimate reason?. Jonathan suggested it was deliberate because of the hidden this parameter, but I'm not convinced because 1) D1 has the hidden this param too, but it handles it just fine, and 2) It's just a syntactical issue, so I don't see how semantics could be a problem unless there's some other change in D2 that causes a conflict or ambiguity with that feature. In any case, the error message seems to indicate that, deliberate or not, it's likely some sort of symbol-lookup/visibility issue.
Re: Still unresolved (Was: D1-D2 member call syntax regression?)
Nick Sabalausky wrote: Nick Sabalausky a...@a.a wrote in message news:i2pvvi$2g8...@digitalmars.com... bearophile bearophileh...@lycos.com wrote in message news:i2p4iq$p...@digitalmars.com... Nick Sabalausky: That's because my original example accidentally made Foo an uninstantiated class template, so the compiler never bothered to check the semantics... Surely here there is no shortage of ways I can paint myself as a stupid :-) In Python the () after the class name are optional and they do nothing, so I didn't see them in that little D program :-) *I'm* the one that was dumb enough put them there in the first place! And I can't use extensive Python experience as an excuse ;) It still leaves the question though, Why isn't that working in D2? Bug or legitimate reason?. Jonathan suggested it was deliberate because of the hidden this parameter, but I'm not convinced because 1) D1 has the hidden this param too, but it handles it just fine, and 2) It's just a syntactical issue, so I don't see how semantics could be a problem unless there's some other change in D2 that causes a conflict or ambiguity with that feature. In any case, the error message seems to indicate that, deliberate or not, it's likely some sort of symbol-lookup/visibility issue. It worked in 2.012 and earlier, but failed in 2.020. I don't have any intermediate versions installed.
Re: Still unresolved (Was: D1-D2 member call syntax regression?)
Don nos...@nospam.com wrote in message news:i2q0un$2hu...@digitalmars.com... Nick Sabalausky wrote: It still leaves the question though, Why isn't that working in D2? Bug or legitimate reason?. Jonathan suggested it was deliberate because of the hidden this parameter, but I'm not convinced because 1) D1 has the hidden this param too, but it handles it just fine, and 2) It's just a syntactical issue, so I don't see how semantics could be a problem unless there's some other change in D2 that causes a conflict or ambiguity with that feature. In any case, the error message seems to indicate that, deliberate or not, it's likely some sort of symbol-lookup/visibility issue. It worked in 2.012 and earlier, but failed in 2.020. I don't have any intermediate versions installed. I've gone ahead and filed a bug report: http://d.puremagic.com/issues/show_bug.cgi?id=4525
D1-D2 member call syntax regression?
In converting some D1 code to D2, I noticed this doesn't seem to work
anymore:
module mymodule;
class Foo()
{
void bar(string s) {...}
void foo()
{
string str = hello;
str.bar();
}
}
In D1 that works fine, but in D2 (2.047) it complains that it can't find
mymodule.bar. That's a bit dissapointing, as I keep hoping member call
syntax will eventually get expanded, not reduced. Is this a bug, or is there
some reason for it?
Re: D1-D2 member call syntax regression?
It seems to work, on 2.042, and on dmd 2.047: http://ideone.com/dcsK3 Bye, bearophile
