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:
    Michael Demmer
    @demmer
    This message was deleted
    Michael Demmer
    @demmer
    moreover what are the semantics of :beginning: - :1s: ?
    Will Welch
    @welch
    that one is easier, both moment and javascript reject msecs outside the +-1Mdays range as being invalid.
    without infinity semantics, we need to forbid math with forever and only use it for comparisons
    Will Welch
    @welch
    an easy way to handle all of these is to check if the constructed moment is valid -- both your examples produce invalid moments without any extra work on our part
    Michael Demmer
    @demmer
    i suppose so
    another thought — since the semantics of beginning and end are less than obvious, what if we allow them to be specified by the caller in options to the code generator?
    Will Welch
    @welch
    neutral to negative, as i don't see how to make infinity semantics work (if that's the alternate you're wanting to support).
    Michael Demmer
    @demmer
    juttle/moment-parser@cb26693
    With this change i can remove the copy of moment-parser from juttle and still have it use the infinite moments like it does now. We can then separately consider whether the semantics for beginning and end should change in juttle.
    Will Welch
    @welch
    not a fan, but it's reasonable to supply optional values for the literals, as with 'now'
    Michael Demmer
    @demmer
    :)
    come to think of it though — we should be consistent and have both options be moment objects, not a moment for now but an integer values for beginning / end
    i’ll change that now
    Michael Demmer
    @demmer
    done. see juttle/moment-parser#27
    Will Welch
    @welch
    yep
    Michael Demmer
    @demmer
    excellent. i’ll merge this and push a 0.3.0 release
    Will Welch
    @welch
    to infinity and beyond!
    there's a quick pr languishing
    Michael Demmer
    @demmer
    not any more