Jump to page: 1 2 3
Thread overview
[dmd-beta] Fighting with 2.059 and not quite winning
Apr 06, 2012
Vladimir Panteleev
Apr 06, 2012
Jonathan M Davis
Apr 06, 2012
Vladimir Panteleev
Apr 06, 2012
Jonathan M Davis
Apr 06, 2012
Jonathan M Davis
Apr 06, 2012
Vladimir Panteleev
Apr 07, 2012
Jonathan M Davis
Apr 07, 2012
Vladimir Panteleev
Apr 07, 2012
Jonathan M Davis
Apr 07, 2012
Jonathan M Davis
Apr 07, 2012
Walter Bright
Apr 07, 2012
Jonathan M Davis
Apr 07, 2012
Vladimir Panteleev
Apr 07, 2012
Vladimir Panteleev
Apr 08, 2012
Jonathan M Davis
Apr 08, 2012
Walter Bright
Apr 09, 2012
Vladimir Panteleev
Apr 09, 2012
Walter Bright
Apr 09, 2012
Vladimir Panteleev
Apr 09, 2012
Walter Bright
Apr 09, 2012
Walter Bright
Apr 09, 2012
Vladimir Panteleev
Apr 09, 2012
Walter Bright
Apr 09, 2012
kenji hara
Apr 09, 2012
kenji hara
Apr 09, 2012
Walter Bright
Apr 07, 2012
Walter Bright
Apr 07, 2012
Don Clugston
Apr 07, 2012
Jonathan M Davis
April 06, 2012
Sorry for creating a new thread, I unsubscribed from this list but subscribed back just so I could post about this.

I'm having a hard time getting my open-source ActionScript 3 disassembler project to compile with the latest DMD git. I've taken three tries at this during the development cycle (3rd being tonight), but every time I've given up in frustration.

The first problem was due to std.conv not being pure-friendly. I don't know why text(1) or to!string(1) aren't pure. (I've left this alone for now to figure out later.)

Now, I'm facing this:

asprogram.d(94): Error: pure function 'processData' cannot call impure function 'opEquals'
asprogram.d(114): Error: pure function 'processData' cannot call impure function 'opEquals'

The only two places that declare opEquals in my program include the "pure" attribute.

I'm a bit tied up lately, so does anyone have any advice before I attempt to minimize it, or try to unwind the layers of metaprogramming to figure out the problem?

The project in question is here (GPL):
https://github.com/CyberShadow/RABCDAsm

My incomplete attempts are on the dmd-2059 branch:
https://github.com/CyberShadow/RABCDAsm/tree/dmd-2059

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 05, 2012
On Friday, April 06, 2012 06:26:19 Vladimir Panteleev wrote:
> The first problem was due to std.conv not being pure-friendly. I don't
> know why text(1) or to!string(1) aren't pure. (I've left this alone for
> now to figure out later.)

They never have been. Neither is std.string.format. Purity and converting to strings don't get along very well at the moment. Various functions that those functions use aren't pure. I believe that _more_ of them are now pure than used to be the case but not necessarily enough. Regardless, if Phobos functions which convert to a string aren't pure, it's nothing new, though it does need to be fixed sometime soon (probably not for this release though).

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 06, 2012
On Fri, 06 Apr 2012 06:43:43 +0300, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Friday, April 06, 2012 06:26:19 Vladimir Panteleev wrote:
>> The first problem was due to std.conv not being pure-friendly. I don't
>> know why text(1) or to!string(1) aren't pure. (I've left this alone for
>> now to figure out later.)
>
> They never have been.

Yes; this is not a regression, but the enforcements of const-pure-@safe-nothrow of the struct methods are forcing me to use only pure/nothrow functions all the way. And I can't even do a number-to-string conversion.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 05, 2012
On Friday, April 06, 2012 06:59:58 Vladimir Panteleev wrote:
> On Fri, 06 Apr 2012 06:43:43 +0300, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > On Friday, April 06, 2012 06:26:19 Vladimir Panteleev wrote:
> >> The first problem was due to std.conv not being pure-friendly. I don't
> >> know why text(1) or to!string(1) aren't pure. (I've left this alone for
> >> now to figure out later.)
> > 
> > They never have been.
> 
> Yes; this is not a regression, but the enforcements of const-pure-@safe-nothrow of the struct methods are forcing me to use only pure/nothrow functions all the way. And I can't even do a number-to-string conversion.

That's enforced now? If so, then the lack of purity for string conversions does become a serious issue which must be sorted out ASAP. Still, while I can understand why classes would enforce them (though last time I looked at Object, it hadn't marked them as such even though that's planned), I don't know why structs would.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 05, 2012
On Thursday, April 05, 2012 21:15:28 Jonathan M Davis wrote:
> On Friday, April 06, 2012 06:59:58 Vladimir Panteleev wrote:
> > On Fri, 06 Apr 2012 06:43:43 +0300, Jonathan M Davis <jmdavisProg@gmx.com>
> > 
> > wrote:
> > > On Friday, April 06, 2012 06:26:19 Vladimir Panteleev wrote:
> > >> The first problem was due to std.conv not being pure-friendly. I don't
> > >> know why text(1) or to!string(1) aren't pure. (I've left this alone for
> > >> now to figure out later.)
> > > 
> > > They never have been.
> > 
> > Yes; this is not a regression, but the enforcements of const-pure-@safe-nothrow of the struct methods are forcing me to use only pure/nothrow functions all the way. And I can't even do a number-to-string conversion.
> 
> That's enforced now? If so, then the lack of purity for string conversions does become a serious issue which must be sorted out ASAP. Still, while I can understand why classes would enforce them (though last time I looked at Object, it hadn't marked them as such even though that's planned), I don't know why structs would.

Okay. I don't know why you think that it's enforced. I just tried having an impure toString in both a struct and a class, and it worked just fine for both.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 06, 2012
On Fri, 06 Apr 2012 07:39:42 +0300, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> Okay. I don't know why you think that it's enforced. I just tried having an
> impure toString in both a struct and a class, and it worked just fine for both.

Ah, apparently I missed that it was actually a warning, sorry for that.

Even so, now I need to choose whether to disable warnings in my project's build script (which is admittedly easier than calling casted method derferences everywhere) or find a way to solve these issues properly.

Bug 7843 is related (-wi still prevents compilation when the new warnings are encountered).

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 06, 2012
On Friday, April 06, 2012 17:01:47 Vladimir Panteleev wrote:
> On Fri, 06 Apr 2012 07:39:42 +0300, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > Okay. I don't know why you think that it's enforced. I just tried having
> > an
> > impure toString in both a struct and a class, and it worked just fine
> > for both.
> 
> Ah, apparently I missed that it was actually a warning, sorry for that.
> 
> Even so, now I need to choose whether to disable warnings in my project's build script (which is admittedly easier than calling casted method derferences everywhere) or find a way to solve these issues properly.
> 
> Bug 7843 is related (-wi still prevents compilation when the new warnings
> are encountered).

But I always compile with -w, and I didn't hit any problems. I'll have to check again...

Nope. It works just fine. For instance,

import std.stdio;

import std.conv;
import std.stdio;

struct S
{
    int i;

    string toString()
    {
        return to!string(i);
    }
}

void main()
{
    writeln(S(5));
}

compiles and runs perfectly with both -w and -wi. If I add pure to toString, it'll fail, but it doesn't insist that toString be pure. The same goes with classes. And I'm running the latest head (or a couple of commits behind, I guess, since it looks like there were a couple of commits since last night, when I updated last). So, I don't know why you're having problems. Could you give code examples? I have no idea why you're seeing anything about pure being required on toString.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 07, 2012
On Sat, 07 Apr 2012 03:25:17 +0300, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> So, I don't know why you're having problems.

Sorry, I should have made this clear:

The issue isn't with toString, but toHash.

The reason this affects me is that both toString and toHash use a common code path, so the called functions' attributes have to follow the lowest common denominator - as set by toHash.

It's also easy to imagine a use case with using the string representation of an object to calculate its hash.

> Could you give code examples?

You can clone the project from the links in my first post.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 06, 2012
On Saturday, April 07, 2012 06:51:53 Vladimir Panteleev wrote:
> On Sat, 07 Apr 2012 03:25:17 +0300, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > So, I don't know why you're having problems.
> 
> Sorry, I should have made this clear:
> 
> The issue isn't with toString, but toHash.
> 
> The reason this affects me is that both toString and toHash use a common code path, so the called functions' attributes have to follow the lowest common denominator - as set by toHash.

Ah. So it has to do with something specific that you're doing. I know that there was an issue with getHash:

http://d.puremagic.com/issues/show_bug.cgi?id=7826

I don't know if the fix for that helps you or not. Honestly, I never would have thought that anyone would have toHash and toString using common code paths, since they do completely different things, but there's certainly nothing stopping you (aside from the purity issues and whatnot). But given that there's not a dependency on toString or conversions to string of any kind in toHash in the general case, I don't think that it's any surprise that wasn't taken into account in making toHash require purity.

My _guess_ as to why toHash now requires purity is because the current AA implementation relies on it as part of the transition to proper constness and purity in Object and whatnot (the implementation isn't currently templated, so it can't take advantage of purity inference).

I don't know that this issue would hold up the release, but I'll try and take a stab at the purity issues in to!string this weekend and see how close we are to make that work. If we're close, it may be possible and reasonable to get it into the next release, but if there are a bunch of changes required, then probably not. It _does_ not get done relatively soon though (and probably by 2.060, because we're probably going to work on toString in Object being const correct with that release).

_Worst_ case, you can use casts to get around the problem. std.datetime now does that with LocalTime and UTC's opCall functions in order to lazily initialize their singletons. So, it's quite possible. Ideally, you wouldn't have to do that though.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

April 06, 2012
On Friday, April 06, 2012 21:04:57 Jonathan M Davis wrote:
> I don't know that this issue would hold up the release, but I'll try and take a stab at the purity issues in to!string this weekend and see how close we are to make that work. If we're close, it may be possible and reasonable to get it into the next release, but if there are a bunch of changes required, then probably not. It _does_ not get done relatively soon though (and probably by 2.060, because we're probably going to work on toString in Object being const correct with that release).

It looks like at minimum, Appender would have to be usable in pure functions, and that's a tough one. For starters, https://github.com/D-Programming- Language/druntime/pull/154 would probably have to be sorted out and merged in (to make reserve and capacity pure), but that's just the beginning. I'll probably have to take the time to make sure that all of the issues wth making Appender pure and to!string are found and sorted out, but that's not necessarily going to be a quick process, since the problem is definitely a bit of onion. You fix one layer only to have to fix the next one and the next one. It will likely take time, and I don't think that Walter is looking to delay the release all that much.

If this is really that big an issue in general, then it would probably be better to temporarily make it so that toHash doesn't insist an being pure until 2.060, but I don't know. As much as you shouldn't have to suffer because of this (it _should_ work), I suspect that having toHash and toString share code isn't all that common (though I could be wrong).

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

« First   ‹ Prev
1 2 3