Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Rodney Lopes Gomes
    @rlgomes
    fixed the gitter badge on moment parser as I merged the PR from gitter without noticing their slight mistake.
    Will Welch
    @welch
    oh hai
    Will Welch
    @welch
    any clues for me about the test failures here? juttle/moment-parser#20
    (it seems a misunderstanding about testing exceptions, rather than buggy code)
    Michael Demmer
    @demmer
    I just pushed a 0.2.0 release with the latest set of changes. This should enable us to remove the moment-parser from juttle itself. PR for that forthcoming.
    Michael Demmer
    @demmer
    @welch The problem was that you were defining a second SyntaxError class which wasn’t the same one that PEG was using. I just pushed a commit that removes the duplicate and just has a single one.
    Will Welch
    @welch
    thanks!
    Will Welch
    @welch
    hrm. how about instead I have errors export parser.SyntaxError as its own
    Michael Demmer
    @demmer
    yep. that seems like the right plan.
    Michael Demmer
    @demmer
    @welch re your comment: on juttle/moment-parser#25 "i'd favor removing begin/end from the grammar before requiring that every moment operation do this creaky test of ._i's value. “
    It seems to me like the only problem with _i comes up when trying to print the moment as a string
    for example, moment does math with infinite dates as you would expect, in that if you add a duration to an infinite moment you still get Infinity
    Will Welch
    @welch
    comparison is broken
    Michael Demmer
    @demmer
    Removing beginning and end from the grammar is going to have ripple effects on juttle that I’d rather avoid.
    Will Welch
    @welch
    thats kind of the only reason to use these values
    Michael Demmer
    @demmer
    i see
    Will Welch
    @welch
    what did you think of +-100Mdays?
    Michael Demmer
    @demmer
    i was mulling that over — i feel like beginning would be more logical as the dawn of unix time
    i.e. '1970-01-01T00:00:00.000Z’
    then I guess we could make end be
    > new Date(100000000000 * 24 * 3600).toISOString()
    '+275760-09-13T00:00:00.000Z’
    Will Welch
    @welch
    you need ms
    Michael Demmer
    @demmer
    i did that
    Will Welch
    @welch
    we already allow the epoch to be written as "0"
    having begin/end be the maximum js date values is more symmetric
    Michael Demmer
    @demmer
    that’s true — but i’m having a hard time envisioning the practical use for a date like:
    > new Date(-100 * 1000000 * 1000 * 24 * 3600).toISOString()
    '-271821-04-20T00:00:00.000Z’
    Will Welch
    @welch
    its less than any date you'll ever encounter
    Michael Demmer
    @demmer
    no doubt. then again so is the epoch (most likely)
    in any event, i’m starting to agree that both of these seem better than the Infinity hacks.
    Will Welch
    @welch
    it was particularly strange of java/js to define their date ranges in terms of days instead of the units accepted by their constructor. should we take leap seconds and daylight savings into account when converting?
    Michael Demmer
    @demmer
    not sure what you mean
    Michael Demmer
    @demmer
    one issue with the above plan is that :now: - :forever: != :beginning: