Revert back to a working version #538
Conversation
|
For context on this PR, see #535 (comment) |
|
Ok it's been awhile! When I was playing with Pixie alot it was when I wasn't working full time. Unfortunately I still don't have much time spare. There are other people with commit rights to this repository such as the creator @halgari and @heyLu but I'm not sure how much time they have either. I got a lot out of playing round with it, hopefully others will too! I guess that means giving those who have time commit rights or maybe just maintaining your own forks. In regards to getting this merged: The PR that broke things was #534 which passed the CI. Is there something which we are not testing for currently, that should be added to the test suite that would have caught that issue? If so, can it be added to the tests? |
|
I’d love to help get things in working order for this repo again — no only the revert, but testing a branch with the broken change to make sure the build targets we’re using in Travis can catch issues like that in the future. I can even take a look at I think it would be nice for the project if this work could happen here ... it would help give interested Lisp explorers a better experience with Pixie :-) |
|
@thomasmulvaney the CI build doesn't fail when a runtime exception is thrown. That's probably how the error snuck in. See #535 (comment) . I'm super keen to get involved. I think at one point I even mail @halgari |
|
@oubiwann Given I don't even have Pixie environment to play with atm, I'm relying on the CI doing its job. So yes, lets get that in shape. @alekcz mentioned the tests don't fail when there is a runtime exception. Would someone like to open a PR which just makes the current tests fail when this happens? Then this PR passing will actually mean something. |
|
Do we have to wait for the CI-Test to get improved before we get master building again? |
The latest addition to stdlib seems to break pixie startup. Going back allows a clean build to succeed so pixie can be started.