search

brownplt / lambda-py

Other
58 stars 10 forks source link

Embarrassing Address bug #48

Closed jpolitz closed 11 years ago

jpolitz commented 11 years ago

OK, this one is just ridiculous. (Random irritated comment redacted). We need to figure out what's going on with this Address nonsense pronto.

ret = None
ret = 3
assert(None == 3)
print(None) # prints 3
jpolitz commented 11 years ago

Commit in question was 695c20b82f9a038407deeccf57be9e5d69fe758e

The problem is that we don't distinguish b/w object addresses and variable addresses, so deep-lookup doesn't stand a chance.

The problem is also that 695c20b82f9a038407deeccf57be9e5d69fe758e also fixes a similarly embarrassing failure to handle aliasing correctly... so it's not just the fault of that commit.

amtriathlon commented 11 years ago

This was fixed in the new regime for addresses and VPointer's https://github.com/brownplt/lambda-py/commit/eebf668cabf57bf9dad47732055d5fd07d58346c

jpolitz commented 11 years ago

Sorry again for my angry reporting of this bug. I didn't intend to come across so mean :-( On Mar 28, 2013 6:01 PM, "Alejandro Martinez" notifications@github.com wrote:

This was fixed in the new regime for addresses and VPointer's eebf668https://github.com/brownplt/lambda-py/commit/eebf668cabf57bf9dad47732055d5fd07d58346c

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/48#issuecomment-15618046 .

amtriathlon commented 11 years ago

No problem but, I think the mother of all problems was the lack of a design review of base code before starting to add features: we assumed it was ok except for the scope and the reality was very different:

2013/3/28 Joe Politz notifications@github.com

Sorry again for my angry reporting of this bug. I didn't intend to come across so mean :-( On Mar 28, 2013 6:01 PM, "Alejandro Martinez" notifications@github.com wrote:

This was fixed in the new regime for addresses and VPointer's eebf668< https://github.com/brownplt/lambda-py/commit/eebf668cabf57bf9dad47732055d5fd07d58346c>

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/48#issuecomment-15618046> .

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/48#issuecomment-15618342 .

Alejandro.

jpolitz commented 11 years ago

Yup, that was my fault!

I should have been more vigilant and had us clean up before moving forward. FWIW, I picked this implementation to start with because it seemed to desugar many things to method calls (e.g. setitem), which I thought was a really important feature. I'm not sure if that was really critical or not; there were other implementations with fewer hacky features but that did less of the desugaring that I thought was going to be important down the road... oh well.

I sometimes if we wouldn't have had an easier time if we'd just started from scratch, knowing that we had an excellent team to draw a new design from, but we'll never know! Just have to go from here.

On Thu, Mar 28, 2013 at 6:26 PM, Alejandro Martinez < notifications@github.com> wrote:

No problem but, I think the mother of all problems was the lack of a design review of base code before starting to add features: we assumed it was ok except for the scope and the reality was very different:

  • the address model was not the only design mistake
  • the use of class names as unique Id's also was a design fault
  • method invocation was completely wrong from the start
  • there were several test cases that were just forced to pass with hacks without no generality (e.g. the macro expansion of ___assertRaises to make the filter test to pass when the problem was that filter doesn't implement the iterator protocol).
  • etc.
  • etc.

2013/3/28 Joe Politz notifications@github.com

Sorry again for my angry reporting of this bug. I didn't intend to come across so mean :-( On Mar 28, 2013 6:01 PM, "Alejandro Martinez" notifications@github.com

wrote:

This was fixed in the new regime for addresses and VPointer's eebf668<

https://github.com/brownplt/lambda-py/commit/eebf668cabf57bf9dad47732055d5fd07d58346c>

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/48#issuecomment-15618046> .

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/48#issuecomment-15618342> .

Alejandro.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/48#issuecomment-15619143 .