Re: Native PDB Error
On Tuesday, 29 May 2018 at 07:47:07 UTC, Begah wrote:
I have recently reinstalled a fresh version of Windows 10. I
installed DMD 1.9.0 and compiled my code ( that was compiling
before reinstalling Windows ).
I get this error at the linking phase :
Native PDB Error: The entry already exists. The specified
module already exists
I made a simplified project that gets the same error :
import imageformats;
import derelict.glfw3;
void main() {
IFImage i0;
}
and dub.json :
"dependencies": {
"derelict-glfw3": "4.0.0-beta.1",
"imageformats": "~>7.0.0"
}
Compiling for 32-bit works.
Compiling for 64-bit gives that error : dub --arch=x86_64
Changing imageformats version to 5.2.0 compiles but any higher
doesn't.
I tried compiling the code with and without admin privileges
but it doesn't do anything.
I know that PDB is used for debugging but I don't understand
this error.
Any ideas?
This works fine on my home Win10 machine, dmd 2.082/2.083 + dub
1.11.0, installed using the executable from the downloads page.
However I've had this same issue on my work PC for which I'll
have to double-check my setup tomorrow.
Re: Module function conflicting with reserve function
On Tuesday, 6 November 2018 at 21:19:29 UTC, Peter Campbell wrote: Given your second example that makes me think that, because object functions are provided by the runtime without me explicitly importing it, this is likely only an issue for object functions? Or can this behaviour happen with any free functions with the same name but completely different parameter types? Not with completely different parameter types, no. But it can happen with functions imported from different modules, as they're from different overload sets. There's an example in that Overload Sets section of the spec.
Re: Module function conflicting with reserve function
On 11/6/18 4:19 PM, Peter Campbell wrote:
On Tuesday, 6 November 2018 at 21:03:01 UTC, Stanislav Blinov wrote:
It's not a bug, just the way name resolution works. Better have
collision than silent overloads. Possible solutions:
```
void reserve(ref Bob system, in size_t capacity) {
// explicitly disambiguate
object.reserve(system._data, capacity);
}
```
or:
// pull in the runtime 'reserve' into this module's scope
alias reserve = object.reserve;
void reserve(ref Bob system, in size_t capacity) {
// call reserve as usual
system._data.reserve(capacity);
}
Given your second example that makes me think that, because object
functions are provided by the runtime without me explicitly importing
it, this is likely only an issue for object functions? Or can this
behaviour happen with any free functions with the same name but
completely different parameter types?
It has nothing to do with the parameters, it has to do with visibility
preference. Basically, the current module trumps any imported modules
(including object). As Stanislav mentions, you can alias the imported
reserve into your module namespace so they have equal footing.
-Steve
Re: Module function conflicting with reserve function
On Tuesday, 6 November 2018 at 21:03:01 UTC, Stanislav Blinov
wrote:
It's not a bug, just the way name resolution works. Better have
collision than silent overloads. Possible solutions:
```
void reserve(ref Bob system, in size_t capacity) {
// explicitly disambiguate
object.reserve(system._data, capacity);
}
```
or:
// pull in the runtime 'reserve' into this module's scope
alias reserve = object.reserve;
void reserve(ref Bob system, in size_t capacity) {
// call reserve as usual
system._data.reserve(capacity);
}
Given your second example that makes me think that, because
object functions are provided by the runtime without me
explicitly importing it, this is likely only an issue for object
functions? Or can this behaviour happen with any free functions
with the same name but completely different parameter types?
Re: Module function conflicting with reserve function
Sorry, forgot to put the spec link into my previous resonse: https://dlang.org/spec/function.html#overload-sets
Re: Module function conflicting with reserve function
On Tuesday, 6 November 2018 at 20:40:11 UTC, Peter Campbell wrote:
Hi there. I've been playing with D and have encountered this
really awkward behaviour. Basically I'm getting a compiler
error inside a function I wrote in my module as it thinks I'm
trying to call itself with invalid parameters, when actually I
want it to call the reserve function on the array itself. Is
this a bug or expected behaviour? It seems quite strange and
potentially annoying to me.
It's not a bug, just the way name resolution works. Better have
collision than silent overloads. Possible solutions:
```
void reserve(ref Bob system, in size_t capacity) {
// explicitly disambiguate
object.reserve(system._data, capacity);
}
```
or:
// pull in the runtime 'reserve' into this module's scope
alias reserve = object.reserve;
void reserve(ref Bob system, in size_t capacity) {
// call reserve as usual
system._data.reserve(capacity);
}
Module function conflicting with reserve function
Hi there. I've been playing with D and have encountered this
really awkward behaviour. Basically I'm getting a compiler error
inside a function I wrote in my module as it thinks I'm trying to
call itself with invalid parameters, when actually I want it to
call the reserve function on the array itself. Is this a bug or
expected behaviour? It seems quite strange and potentially
annoying to me.
https://run.dlang.io/is/9YyAI9
module bob;
struct Bob
{
private ubyte[] _data;
}
void reserve(ref Bob system, in size_t capacity)
{
// bob.reserve(ref Bob system, const(ulong) capacity) is not
callable with (ubyte[], const(ulong)).
system._data.reserve(capacity);
}
void main()
{
}
Re: Native PDB Error
plain works too
On Tue, Nov 6, 2018 at 7:15 PM WebFreak001 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Tuesday, 29 May 2018 at 07:47:07 UTC, Begah wrote:
> > I have recently reinstalled a fresh version of Windows 10. I
> > installed DMD 1.9.0 and compiled my code ( that was compiling
> > before reinstalling Windows ).
> > I get this error at the linking phase :
> > Native PDB Error: The entry already exists. The specified
> > module already exists
> >
> > I made a simplified project that gets the same error :
> >
> > import imageformats;
> > import derelict.glfw3;
> >
> > void main() {
> > IFImage i0;
> > }
> >
> > and dub.json :
> > "dependencies": {
> > "derelict-glfw3": "4.0.0-beta.1",
> > "imageformats": "~>7.0.0"
> > }
> >
> > Compiling for 32-bit works.
> > Compiling for 64-bit gives that error : dub --arch=x86_64
> > Changing imageformats version to 5.2.0 compiles but any higher
> > doesn't.
> > I tried compiling the code with and without admin privileges
> > but it doesn't do anything.
> > I know that PDB is used for debugging but I don't understand
> > this error.
> > Any ideas?
>
> for others who come across this (because this is what you find if
> you google this error):
>
> I haven't found any solution or reason yet, but you can compile
> in release mode (--build=release for dub) to work around this
> issue
>
Re: Native PDB Error
On Tuesday, 29 May 2018 at 07:47:07 UTC, Begah wrote:
I have recently reinstalled a fresh version of Windows 10. I
installed DMD 1.9.0 and compiled my code ( that was compiling
before reinstalling Windows ).
I get this error at the linking phase :
Native PDB Error: The entry already exists. The specified
module already exists
I made a simplified project that gets the same error :
import imageformats;
import derelict.glfw3;
void main() {
IFImage i0;
}
and dub.json :
"dependencies": {
"derelict-glfw3": "4.0.0-beta.1",
"imageformats": "~>7.0.0"
}
Compiling for 32-bit works.
Compiling for 64-bit gives that error : dub --arch=x86_64
Changing imageformats version to 5.2.0 compiles but any higher
doesn't.
I tried compiling the code with and without admin privileges
but it doesn't do anything.
I know that PDB is used for debugging but I don't understand
this error.
Any ideas?
for others who come across this (because this is what you find if
you google this error):
I haven't found any solution or reason yet, but you can compile
in release mode (--build=release for dub) to work around this
issue
Re: Is this a bug? +goto
On Tuesday, 6 November 2018 at 05:46:40 UTC, Jonathan M Davis
wrote:
On Monday, November 5, 2018 7:55:46 PM MST MatheusBN via
Digitalmars-d-learn wrote:
On Tuesday, 6 November 2018 at 01:55:04 UTC, Jonathan M Davis
wrote:
>> And I found a bit strange that in such code, since "x" is
>> never used, why it isn't skipped.
>
> It's skipped right over. The goto jumps out of the scope,
> and the line with
>
> int x;
>
> is never run. In fact, if you compile with -w or -wi, the
> compiler will give you a warning about unreachable code.
That is exactly my point.
Since "x" it's skipped and never used, it shouldn't just be a
warning (unreachable code) instead of an error?
I'm trying to understand why/when such code could give any
problem.
On the other hand if the code were:
{
goto Q:
int x;
Q:
x = 10; // <- Now you are accessing an uninitialized
variable.
}
Then I think an error would be ok.
D tries to _very_ little with code flow analysis, because once
you start having to do much with it, odds are that the compiler
implementation is going to get it wrong. As such, any feature
that involves code flow analysis in D tends to be _very_
simple. So, D avoids the issue here by saying that you cannot
skip the initialization of a variable with goto. The compiler
is not going to do the complicated logic of keeping track of
where you access the variable in relation to the goto. That's
exactly the sort of thing that might be obvious in the simple
case but is highly likely to be buggy in more complex code.
Code such as
{
goto Q;
int x;
}
Q:
or
{
if(foo)
goto Q;
int x;
}
Q:
is fine, because the compiler can trivially see that it is
impossible for x to be used after it's been skipped, whereas
with something like
goto Q;
int x;
Q:
the compiler has to do much more complicated analysis of what
the code is doing in order to determine that, and when the code
isn't trivial, that can get _really_ complicated.
You could argue that it would be nicer if the language required
that the compiler be smarter about it, but by having the
compiler be stupid, it reduces the risk of compiler bugs, and
most people would consider code doing much with gotos like this
to be poor code anyway. Most of the cases where goto is
reasonable tend to be using goto from inside braces already,
because it tends to be used as a way to more efficiently exit
deeply nested code. And with D's labeled break and continue,
the need for using goto outside of switch statements also tends
to be lower than it is in C/C++.
- Jonathan M Davis
It's clear now about this decision and by the way thanks for
replying all my doubts.
MatheusBN.
Re: Why use while if only iterating once ?
On Saturday, 3 November 2018 at 21:13:49 UTC, Jonathan M Davis
wrote:
There's a continue right above the default case. So, if the
code hits that point, it will loop back to the top.
- Jonathan M Davis
There's also the benefit that FLAGS f exists only until the end
of the loop, and thus won't be polluting the namespace later in
the function.
Personally, when I want to make a block just for grouping code, I
use if (true){} or static if (true){} depending on whether I want
to it's variables go away afterwards.
IIRC, I could just use braces without any header intead of if
(true){}, but the code block just isn't as easily distinquishable
without anything at the top IMO.
Re: Profiling with DUB?
On Monday, 29 October 2018 at 10:14:23 UTC, Dukc wrote: When I run the program, where is the performance profile file supposed to appear? I can find nothing new in the program/project root directory. The same thing happens when I try to get a coverage report: No file appears.
Re: Implicit cast to const of result returned from findSplit()
On 2018-11-05 14:26, Per Nordlöw wrote:
Why does
@safe pure unittest
{
import std.algorithm.searching : findSplit;
if (const split = "a b".findSplit(" "))
{
}
}
error as
f.d(4,5): Error: mutable method `std.algorithm.searching.findSplit!("a
== b", string, string).findSplit.Result!(string,
string).Result.opCast!bool.opCast` is not callable using a `const` object
f.d(4,5): Consider adding `const` or `inout` to
std.algorithm.searching.findSplit!("a == b", string,
string).findSplit.Result!(string, string).Result.opCast!bool.opCast
when
@safe pure unittest
{
import std.algorithm.searching : findSplit;
if (auto split = "a b".findSplit(" "))
{
}
}
doesn't?
AFAICT, it looks like a missing bool qualifier on `opCast!bool`, right?
If the first example you declare a const variable of the type that
"findSplit" returns. Then the compiler will call opCast since the
variable is defined in the if condition. But you can only call methods
marked as "const" if you have a const variable. The opCast method in
the struct returned by "findSplit" is missing a const attribute.
--
/Jacob Carlborg
