Thank you for this!!
Feedback
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/55a4e6de-1e08-4219-9675-31e5c598a38dn%40googlegroups.com.
- MIME types: Yes, I should use/add a more complete extension→type mapping, though I probably will continue not to validate MIME types against the IANA list. (My somewhat erroneous note in the docs notwithstanding, it turns out having a non-IANA MIME type or a valid but mismatched type in an enclosure doesn’t actually cause feed validation errors.)
- language-codes: yes this should be a value, not a procedure. Will change it.
- Removing dependencies: yes, I see the appeal. I’m really not eager to reimplement all the timezone handling and temporal comparison stuff in gregor, though.
I'm not totally clear about all of the different sets of requirements (RSS, Atom, and, de facto, Apple), but I thought there were more language codes permitted than ISO 639-1 (e.g. https://www.rssboard.org/rss-language-codes points to ISO 639-2, and https://validator.w3.org/feed/docs/rfc4287.html#rfc.section.4.2.7.4 for Atom points to RFC 3066. These standards also allow for the assignment of new codes (and, at least for ISO 639-3, deprecation). I hope the right set of codes might be in the one of the CLDR packages (also used by Gregor): if so, I'd recommend getting it from there.
On a different topic, for the XML stuff, is there a requirement that embedded HTML be represented with the CDATA lexical syntax?
everyone manipulating these feeds in Racket
(Tangentially, AIUI the convention is to use `#f` for the start and stop fields when creating cdata and p-i structures in code, though apparently the docs for `source` say something about symbols.)
rather than using an ad-hoc encoding scheme for the entities Apple has odd rules about, you can just replace them with symbols or `valid-char?`s and let the library take care of everything. Well, my example code for that has grown complete enough that I'll just make a PR shortly :)
- Removing dependencies: yes, I see the appeal. I’m really not eager to reimplement all the timezone handling and temporal comparison stuff in gregor, though.
Joel
On Monday, October 25, 2021 at 6:36:30 PM UTC-5 Sage Gerard wrote:Thank you for this!!
Feedback
- I like your podcast-specific entries
- The validation logic is refreshing to see
- Re: boolean arguments, I'd stick to keyword arguments and ask for any/c, not boolean?, in contracts. That way forms like (and ... (member ...)) won't bug users about a non-threatening contract violation, and it's trivial to cast the value yourself.
- Unsure what licenses are compatible with Blue Oak. If you want more licensing options re: IANA media type to extension mappings, here are some.
- MIT: https://github.com/mime-types/mime-types-data
- Apache 2.0 (From the horse's mouth): https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
- CC-BY-SA: Scrape MDN's table using the console on https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
- I normally don't use functions like splitflap-version because I can't assume that a package will define one. I'd use a program that returns a version of a given package.
- Why is language-codes a procedure?
- You have a lot of local contract boundaries, so values may get checked more than necessary.
- Prefer example.com so you don't have to leak your URLs or make up email addresses that actually go to an inbox.
- txexpr, gregor, and web-server dependencies don't look terribly difficult to remove
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/cb2927c7-3d21-41c3-89c7-d6b73a9e53f9n%40googlegroups.com.
I can understand wanting gregor for timezone offsets when constructing moments, but...
My comment was not meant to say that timezone math is easy to
replace, or even that gregor isn't a fit. It's to say that I'm
not seeing correct answers without a name lookup in front of tz/c,
and the latest data from the IANA.
But if you were going to do all that in the first place, then I'm
not sure what I'd use gregor for outside of relative arithmetic.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKoc93-d6gUXYEhA_L-bM%3DzqWBbu9UG2TtvX-nqTHaKA_jA%40mail.gmail.com.
- The IANA's timezone database changed this month, and gregor's last commit was 2 years ago.
My comment was not meant to say that timezone math is easy to replace, or even that gregor isn't a fit. It's to say that I'm not seeing correct answers without a name lookup in front of tz/c, and the latest data from the IANA.
- Assuming I have the right repository link, gregor's tz/c contract is only (or/c string? (integer-in -64800 64800)) [1]. I can set the feed-timezone parameter in Splitflap to an arbitrary string and the guard won't stop me.
- Assuming I have the right repository link, gregor's tz/c contract is only (or/c string? (integer-in -64800 64800)) [1]. I can set the feed-timezone parameter in Splitflap to an arbitrary string and the guard won't stop me.
> The timezone database lookup logic is in the `tzinfo`
package (https://docs.racket-lang.org/tzinfo/index.html)
Thanks.
> Jon: I'm guessing you haven't actually tried this
> Phillip: I guess the check doesn't happen as part of `tz/c`,
but I can tell you that this program
Yes, but I'm talking about code we were asked to give feedback on. I focus on `tz/c` because it is documented as a flat contract that checks for "an identifier from the IANA tz database", but it does not parse the timezone name to check correctness.
My feedback says no validation occurs for the timezone name in a
parameter for Splitflap. Joel indicated that parameter will go
away below, and I'm glad to know of the tzinfo package. But if a
limitation in gregor's contracts would oblige you to use tzinfo
for validation, then I'd want to know that so that I can assess
how much of gregor I really need. It still seems like the timezone
data is the hard part, so use a timezone dependency instead of a
dependency that misleads the user into incomplete validation.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/d202c537-0173-42fd-b75f-082275c57426n%40googlegroups.com.
> Jon: I'm guessing you haven't actually tried this
> Phillip: I guess the check doesn't happen as part of `tz/c`, but I can tell you that this program
Yes, but I'm talking about code we were asked to give feedback on. I focus on `tz/c` because it is documented as a flat contract that checks for "an identifier from the IANA tz database", but it does not parse the timezone name to check correctness.
My feedback says no validation occurs for the timezone name in a parameter for Splitflap. Joel indicated that parameter will go away below, and I'm glad to know of the tzinfo package.
Yes, but I'm talking about code we were asked to give feedback on. I focus on `tz/c` because it is documented as a flat contract that checks for "an identifier from the IANA tz database", but it does not parse the timezone name to check correctness.
My feedback says no validation occurs for the timezone name in a parameter for Splitflap. Joel indicated that parameter will go away below, and I'm glad to know of the tzinfo package. But if a limitation in gregor's contracts would oblige you to use tzinfo for validation, then I'd want to know that so that I can assess how much of gregor I really need. It still seems like the timezone data is the hard part, so use a timezone dependency instead of a dependency that misleads the user into incomplete validation
To the extent that validation is a concern, gregor is (despite the
`tz/c` issue) much better, on the whole, than racket/base's `date` and
`date*` structs, which will happily let you construct things like "the
31st of February."