Update to v0.14.0-rc3

[JordanMartinez]

Backlinking to purescript/purescript#3942

[JordanMartinez]

I'm pretty sure this is blocked by web-dom-parser

[thomashoneyman]

This is failing because of https://github.com/LiamGoodacre/purescript-naturals

[JordanMartinez]

See LiamGoodacre/purescript-naturals#7

[hdgarrood]

I think we should try to avoid depending on libraries which are outside of core, web, and possibly also contrib in this org. I think we should consider replacing the uses of Natural with Int.

[thomashoneyman]

I don’t mind switching to Int.

[bbarker]

I think in this context that's fine, though I wonder if it would make sense to have a core library represent natural numbers in some form, in the same fashion that we have NonEmptyString, and NonEmptyArray (iirc).

…

On Fri, Dec 11, 2020 at 6:01 PM Thomas Honeyman ***@***.***> wrote: I don’t mind switching to Int. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Brandon Barker brandon.barker@gmail.com

[thomashoneyman]

I think it's sensible for the natural library to move into core, but that's really a decision for @LiamGoodacre to make. If it does move, then we can keep the dependency here.

[hdgarrood]

I would prefer that we not move natural into core while it's a wrapper around Int. I think a natural number type should ideally be backed by BigInt.

[bbarker]

Probably getting a bit far afield here, but I will also mention that Idris has special support for Peano numbers, so that they act like you would expect a Peano number implementation to act, but under the hood they are optimized to effectively be the equivalent of BigInts ... at least, I'm pretty sure I saw that, somewhere. Probably less useful in PureScript to have Peano numbers anyhow.

…

On Fri, Dec 11, 2020 at 7:56 PM Harry Garrood ***@***.***> wrote: I would prefer that we not move natural into core while it's a wrapper around Int. I think a natural number type should ideally be backed by BigInt. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG7XDQ62MFMI4ZCED3BPZDSUK5VFANCNFSM4UV336RA> .

-- Brandon Barker brandon.barker@gmail.com

[hdgarrood]

Right, the other reason I'm not particularly keen on Natural is that I think that in most cases the extra safety it gives you is difficult to take advantage of with the type system we have. With Idris having dependent types, I think having Peano numbers built in makes a whole lot more sense, so that you can have good ergonomics for operations like a vector append function for vectors whose length is tracked in the types. You can technically do this in PureScript too but we generally don't; the ergonomics are horrible and you often have to tell the type system "trust me, this is fine" in cases where you wouldn't have to do that in Idris.

[JordanMartinez]

Looks like CI still fails because of the non-Type kind annotation I put on ReaderT. Thoughts?

[natefaubion]

I don’t think that’s why it’s failing. It’s failing to unify Aff with ReaderT. A missing lift?

[JordanMartinez]

Nope. It was due to hard-coded signatures elsewhere...

[JordanMartinez]

CI now fails with this:

ReferenceError: XPathResult is not defined
    at Object.<anonymous> (/home/runner/work/purescript-web-dom-xpath/purescript-web-dom-xpath/output/Web.DOM.Document.XPath.ResultType/foreign.js:3:20)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/home/runner/work/purescript-web-dom-xpath/purescript-web-dom-xpath/output/Web.DOM.Document.XPath.ResultType/index.js:3:16)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
* ERROR: Subcommand terminated with exit code 1
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @ test: `eslint src && pulp test -- --censor-lib && node test/node.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @ test script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

[JordanMartinez]

Issue seems due to jsdom?

test/node.js file content:

const { JSDOM } = require("jsdom");
const { XPathResult, DOMParser } = new JSDOM().window;

Object.assign(global, { XPathResult, DOMParser })

require("../output/Test.Main/index.js").main({ browser: false })();

[thomashoneyman]

Hm. @kl0tl introduced jsdom to fix this specific error:
#6 (comment)

[JordanMartinez]

Just FYI. Originally, the tests were never run during CI

[kl0tl]

I pushed some commits to address the issue. We cannot run tests with pulp like we usually do because we have to emulate XPathResult and DOMParser with jsdom first, and configure the browser flag to disable the tests that fail with the emulated DOM provided by jsdom.

[bbarker]

Thanks @kl0tl and everyone.

[JordanMartinez]

Whoops!

[bbarker]

@JordanMartinez hmm, good catch - if you're referring to the "Left" in the message, I think that was probably a typo on my part, but it should have read "Value was not RIght", as it does now.

[JordanMartinez]

@bbarker Not quite. "Value was not Left" would only appear if the value was Left, so it doesn't make sense. "Value was not Right" would only appear if the value was Left, not right. Thus, this message is more accurate. I was saying 'whoops' in regards to what I originally wrote here because it's not correct.