RE: ANN: jedi-time 0.1.4
> The only way to have `nav` selectively recognise keys based on their
> existence in the map, is to put its whole logic behind a `contains?` check.
> However that sounds counter-intuitive/productive...
Remember that nav is called with the key _and the value_ so it will be passed
whatever value is associated with the key in the data structure. So (nav data
:format nil) means either the key exists with the value nil or the key doesn’t
exist, but either way nil isn’t a valid format so your nav should just return
the value unchanged.
If (get data k) produces v, then nav will be called as (nav data k (get data
k)) – if v is part of data via some other “path”, then nav will be called as
(nav data nil v) so you always get v from data and you may get k from data. The
key, if passed, comes from the data structure – not some fabricated key.
If I do this:
(assoc (d/datafy (java.time.LocalDateTime/now)) :month {:name "MARCH" :value 3
:length 31})
When I navigate through the fields of that data structure to :month, I should
get a java.time.Month for March – because that’s the value passed into nav.
Your current implementation still returns February. That’s why nav should pay
attention to the value v that is passed in (again, per the docstring, nav
“Returns (possibly transformed) v, in the context of coll and k”).
The nav docstring:
“Returns (possibly transformed) v in the context of coll and k (a
key/index or nil). Callers should attempt to provide the key/index
context k for Indexed/Associative/ILookup colls if possible, but not
to fabricate one e.g. for sequences (pass nil). nav returns the
value of clojure.core.protocols/nav.”
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
From: dimitris
Sent: Monday, February 10, 2020 2:20 PM
To: clojure@googlegroups.com
Subject: Re: ANN: jedi-time 0.1.4
On 10/02/2020 20:45, Sean Corfield wrote:
> I’m suggesting that if you add certain key/value pairs to the datafied
> Java Time values, nav could recognize those as navigation from data to
> “stuff”. This gets you much closer to your original concept while
> staying within the datafy/nav confines.
The keys recognised by `nav` have been manually hard-coded to match the
keys in the map (in my current implementation), so if I add :format it
will always be recognised regardless of whether it exists in the map.
The only way to have `nav` selectively recognise keys based on their
existence in the map, is to put its whole logic behind a `contains?`
check. However that sounds counter-intuitive/productive...
> What I didn’t like about the original was that your nav function
> accepted arbitrary keys and values that weren’t related to the datait
> was “magic” and had extended navigation arbitrarily outside of the
> Clojure navigation of the data
I'm surprised you said that right after having shown exactly how I had
navigation for :format up until yesterday. What makes :format not
arbitrary or magic? How could `nav` possibly know that a new key has
been added (or removed/updated for that matter), and dynamically add the
corresponding behaviour?
> I don’t know how I would feel about the add/subtract time periods
> being done this way
Again, I find that interesting because if there is one operation that
naturally leads you from data to another Java object, that is shifting.
For example, the :format capability we're discussing leads you to a
String, whereas `(nav datafied :+ [2 :weeks])` leads you back to a
(datafiable) java object (i.e. a nicer fit for going from data to
stuff). The `:at-zone` and `:at-offset` navigation paths were similarly
good fits for the same reason. To me, :format although convenient and
all, is totally arbitrary.
> if you take data (the hash map produced by datafying a Java Time
> object) and manipulate the data in ways that preserves the nav
> metadata, then calling nav on that new data could do more things than
> calling nav on the original data
I honestly don't see how that is possible in the open way that you seem
to imply...Someone needs to define upfront what the `nav` capabilities
will be (what keys will be recognised), and those are not tied in any
way to the keys/values in the map at any given point in time. As I said
in my first point above, one could manually force that a navigation path
only fires if the key is actually contained in the data, but that sounds
like an anti-pattern if I'm honest.
I would love to understand a bit deeper why you thought that my original
nav keys felt arbitrary and magic, whereas you clearly think that
:format isn't...To me they all are, or none are.
Thanks again...
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to t
Re: ANN: jedi-time 0.1.4
On 10/02/2020 20:45, Sean Corfield wrote: I’m suggesting that if you add certain key/value pairs to the datafied Java Time values, nav could recognize those as navigation from data to “stuff”. This gets you much closer to your original concept while staying within the datafy/nav confines. The keys recognised by `nav` have been manually hard-coded to match the keys in the map (in my current implementation), so if I add :format it will always be recognised regardless of whether it exists in the map. The only way to have `nav` selectively recognise keys based on their existence in the map, is to put its whole logic behind a `contains?` check. However that sounds counter-intuitive/productive... What I didn’t like about the original was that your nav function accepted arbitrary keys and values that weren’t related to the datait was “magic” and had extended navigation arbitrarily outside of the Clojure navigation of the data I'm surprised you said that right after having shown exactly how I had navigation for :format up until yesterday. What makes :format not arbitrary or magic? How could `nav` possibly know that a new key has been added (or removed/updated for that matter), and dynamically add the corresponding behaviour? I don’t know how I would feel about the add/subtract time periods being done this way Again, I find that interesting because if there is one operation that naturally leads you from data to another Java object, that is shifting. For example, the :format capability we're discussing leads you to a String, whereas `(nav datafied :+ [2 :weeks])` leads you back to a (datafiable) java object (i.e. a nicer fit for going from data to stuff). The `:at-zone` and `:at-offset` navigation paths were similarly good fits for the same reason. To me, :format although convenient and all, is totally arbitrary. if you take data (the hash map produced by datafying a Java Time object) and manipulate the data in ways that preserves the nav metadata, then calling nav on that new data could do more things than calling nav on the original data I honestly don't see how that is possible in the open way that you seem to imply...Someone needs to define upfront what the `nav` capabilities will be (what keys will be recognised), and those are not tied in any way to the keys/values in the map at any given point in time. As I said in my first point above, one could manually force that a navigation path only fires if the key is actually contained in the data, but that sounds like an anti-pattern if I'm honest. I would love to understand a bit deeper why you thought that my original nav keys felt arbitrary and magic, whereas you clearly think that :format isn't...To me they all are, or none are. Thanks again... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/4bdcef09-71db-b67d-796f-604e209f8a10%40gmail.com.
RE: ANN: jedi-time 0.1.4
> Ok, I'm glad datafy/nav works as expected, but the rest of you response
> confuses me again :)
Sorry ☹
> You now seem to implying going back to "doing too much" with `nav` - or have
> I misunderstood you (again)?
I’m suggesting that if you add certain key/value pairs to the datafied Java
Time values, nav could recognize those as navigation from data to “stuff”. This
gets you much closer to your original concept while staying within the
datafy/nav confines.
Let’s take a concrete example:
(d/datafy (java.time.LocalDateTime/now)) -> a hash map like this:
{:second-milli 114, :hour 14, :second-micro 114866, :second 47,
:month {:name "FEBRUARY", :value 2, :length 29, :day 9},
:year {:value 2020, :leap? true, :length 366, :week 6, :day 40},
:weekday {:name "SUNDAY", :value 7}, :second-nano 114866000, :minute 42}
(get data :month) -> {:name "FEBRUARY", :value 2, :length 29, :day 9}
(nav data :month (get data :month)) -> a java.time.Month object for “FEBRUARY”
(losing the day – which suggests :day should be part of the datafication
separately BTW)
Now lets look for :format:
(get data :format) -> nil
(nav data :format (get data :format)) -> nil
As expected. But it’s data and we can augment it with other keys:
(let [data’ (assoc data :format :iso)] (get data’ :format)) -> :iso
At this point, we have a key and a value so we can call nav with those:
(let [data’ (assoc data :format :iso)] (nav data’ :format (get data’ :format))
-> could navigate to an ISO-formatted version of the local date time
> Moreover, if `:format` is recognised by `nav`, you wouldn't need to `assoc`
> it in order to use it
What I didn’t like about the original was that your nav function accepted
arbitrary keys and values that weren’t related to the datait was “magic” and
had extended navigation arbitrarily outside of the Clojure navigation of the
data (see the nav docstring below):. I’m not suggesting that all of your
original functionality maps down naturally to get/nav like this – I don’t know
how I would feel about the add/subtract time periods being done this way but if
you take data (the hash map produced by datafying a Java Time object) and
manipulate the data in ways that preserves the nav metadata, then calling nav
on that new data could do more things than calling nav on the original data, if
it follows the get/nav path that is intended by the datafy/nav mappings:
Foo -> datafy -> data
(get data k) -> v
(nav data k v) -> v or some new Foo or…
But the expectation is that nav will get called as if (nav data k (get data k))
or (nav data nil v) if there’s no natural key/index associated with the value v.
Here’s the docstring for nav – I’ve added some emphasis:
“Returns (possibly transformed) v in the context of coll and k (a
key/index or nil). Callers should attempt to provide the key/index
context k for Indexed/Associative/ILookup colls if possible, but not
to fabricate one e.g. for sequences (pass nil). nav returns the
value of clojure.core.protocols/nav.”
Hopefully this clarifies what I was trying to express, but I’m happy to have
another few goes around if we’re not both there yet 😊
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
From: dimitris
Sent: Monday, February 10, 2020 4:50 AM
To: clojure@googlegroups.com
Subject: Re: ANN: jedi-time 0.1.4
Ok, I'm glad datafy/nav works as expected, but the rest of you response
confuses me again :)
The reason I removed support for navigating to `:format` was because we
established in previous conversations that I was doing too much with `nav`. I
was using it for comparing, shifting, formatting & converting. I've put all of
that behind separate protocols and extending them via metadata (similarly to
`nav`). You now seem to implying going back to "doing too much" with `nav` - or
have I misunderstood you (again)?
Moreover, if `:format` is recognised by `nav`, you wouldn't need to `assoc` it
in order to use it - it would just work (as it used to work before my commit
last night), so that bit confuses me too. In any case, I do massively
appreciate the time you're putting into this...There is great confusion on-line
about datafy/nav, whether they are useful on their own (vs being complementary
to each other), the right arguments, where we draw the line in terms of doing
too much etc etc.
Thanks again :)
On 09/02/2020 22:57, Sean Corfield wrote:
That is starting to work nicely with REBL for the basic datafy/nav
functionality. Thank you!
Once I'd verified that, I tried this: (assoc (d/datafy
(java.time.LocalDateTime/now)) :format :iso) hoping that if I nav'd to the new
:format key, it would "navigate" to a formatted version but it didn
Re: ANN: jedi-time 0.1.4
mpil1...@gmail.com>> wrote:
Hi Sean,
Admittedly, I’ve never used REBL, and I did
struggle with the shape and name of the `nav`
arguments...
In particular I’m struggling to understand why
would anyone use `nav` to navigate to a key that
already exists in the map...Can’t we just use
`get` or `get-in`?
You used the :format as an example, which works
with nil, :iso, or a String pattern as the last
arg to nav. But again, :format is NOT in the
datafied representation.
In essence, I’ve tried to use `nav` to navigate
to things that can be expensive and don’t
necessarily belong in the actual datafied
representation.
If the second argument to `nav`, is expected to
be a key already present in the map, then I
really don’t understand what is the point of `nav`.
kind regards,
Dimitris
*From: *Sean Corfield <mailto:s...@corfield.org>
*Sent: *02 February 2020 07:36
*To: *Clojure Mailing List
<mailto:clojure@googlegroups.com>
*Subject: *Re: ANN: jedi-time 0.1.4
This is very cool but I would strongly recommend
you try using this with REBL so you can figure
out how to make the `nav` part work in a more
natural way.
nav is intended to work with a key and value
(from the datafied structure), but your nav
expects special values so it doesn't work with
REBL.
You can put (java.time.Instant/now) into REBL
and your datafication produces a great data
representation, but you can't navigate into it
using the keys (and values) of the data
structure itself. You can put :format into the
nav-> bar and it defaults to a format you can
get a string back, but none of the other nav
calls will work.
You might consider combining the :format key
with the actual format, e.g., :format-iso,
:format-yy-MM-dd and if the key is something
your don't recognize, just let it behave like
regular data navigation.
I think you're trying to do too much with nav,
beyond "navigation". I think you could split
some of the "clever" navigation out into a
transform function that takes a datafied time
and produces a new datafied time, and then let
nav do the "conversion" back to Java objects.
You've complected the transforms and the
conversion right now.
If you're on Slack, I'm happy to DM about this
in more detail (when you're back from traveling).
Sean
On Sat, Feb 1, 2020 at 6:02 AM dimitris
mailto:jimpil1...@gmail.com>> wrote:
Hi folks,
The first public release of `jedi-time`
should be hitting clojars any
minute now. I am traveling next week so may
be slow to reply to
feedback/bugs/PRs...
https://github.com/jimpil/jedi-time
Kind regards,
Dimitris
--
You received this message because you are
subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to
clojure@googlegroups.com
<mailto:clojure@googlegroups.com>
Note that posts from new members are
moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
<mailto:clojure%2bunsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You rece
Re: ANN: jedi-time 0.1.4
eas navigating to objects (via >> `nav`) will be done with bogus keys (e.g. `:month-of-year`). >> >> As things stand (with my current nested representation), only LocalDate, >> LocalDateTime, OffsetDateTime & ZonedDateTime can have useful navigations: >> >> - LocalDate => :week-day , :year-month >> >> - LocalDateTime => :local-date, :local-time >> >> - OffsetDateTime => :local-datetime, :instant >> >> - ZonedDateTime => :offset-datetime, :local-datetime, :instant >> >> That is pretty much it in terms of `nav`... >> >> Does that make (more) sense? >> >> >> Many thanks in advance... >> >> Dimitris >> >> ps: Sean I can be on slack but with my work email >> >> >> On 04/02/2020 05:18, Sean Corfield wrote: >> >> You're misunderstanding me. I'll try again. >> >> I'm not saying you can't navigate to keys that don't exist in the data -- >> but since there would be no corresponding value, the nav call would be (nav >> coll k nil) essentially. >> >> If (get coll k) produces some value v, then (nav coll k v) will take you >> from the right side (pure data) to the left side (objects) to the object >> that "corresponds" to the equivalent navigation on the right (i.e., within >> the data). >> >> object -> datafy -> pure data >> pure data -> get etc -> new pure data >> pure data -> nav -> new object "corresponding" to new pure data >> >> On Mon, Feb 3, 2020 at 3:38 AM Dimitrios Jim Piliouras < >> jimpil1...@gmail.com> wrote: >> >>> This is what I've done but it contradicts what we said earlier... >>> >>> If I navigate to some existing key and it gives me back a Java object, >>> then it means that the datafied representation had a key pointing to non >>> data! >>> >>> I have read your blog post multiple times ;), but I think the situation >>> you're describing with the foreign keys is rather unique... >>> >>> The datafied datetime cannot possibly include all its possible formats, >>> nor all the possible alternatives - that would be extremely wasteful and >>> meaningless the way I see it. >>> >>> >>> Let's take an Instant as an example...it datafies to map of two keys >>> (:epoch, :second). Does it make sense to add a :format-iso key in there >>> pointing to a String? Is there any point navigating to that key? Is there >>> any point navigating to :epoch or :second? The answer is no, right? Is >>> there a point in navigating to :zoned-datetime given a zone id? I would >>> think yes... >>> >>> On Mon, 3 Feb 2020, 04:47 Sean Corfield, wrote: >>> >>>> Think of it as a square: >>>> >>>> You start with an object of some sort (left side) -> datafy -> turns it >>>> into pure Clojure data (including metadata). (right side) >>>> >>>> Given pure Clojure data, you can navigate through it with get etc and >>>> you stay in the right side (pure data). >>>> >>>> Given that pure Clojure data, you can navigate back to the left hand >>>> wide with nav, mimicking how get etc work. >>>> >>>> So datafy is L -> R, get is R -> R, nav is R -> L on a "diagonal" that >>>> takes you back to the object world on the left, corresponding to the place >>>> on the right that you'd get to via get etc. >>>> >>>> See if this blog post helps >>>> https://corfield.org/blog/2018/12/03/datafy-nav/ >>>> >>>> >>>> On Sun, Feb 2, 2020 at 1:22 AM Dimitrios Jim Piliouras < >>>> jimpil1...@gmail.com> wrote: >>>> >>>>> Hi Sean, >>>>> >>>>> >>>>> >>>>> Admittedly, I’ve never used REBL, and I did struggle with the shape >>>>> and name of the `nav` arguments... >>>>> >>>>> >>>>> >>>>> In particular I’m struggling to understand why would anyone use `nav` >>>>> to navigate to a key that already exists in the map...Can’t we just use >>>>> `get` or `get-in`? >>>>> >>>>> You used the :format as an example, which works with nil, :iso, or a >>>>> String pattern as the last arg to nav. But again, :format is NOT in the >>>>> datafied representation. >>>>> >>>>> >
Re: ANN: jedi-time 0.1.4
pure data -> get etc -> new pure data pure data -> nav -> new object "corresponding" to new pure data On Mon, Feb 3, 2020 at 3:38 AM Dimitrios Jim Piliouras mailto:jimpil1...@gmail.com>> wrote: This is what I've done but it contradicts what we said earlier... If I navigate to some existing key and it gives me back a Java object, then it means that the datafied representation had a key pointing to non data! I have read your blog post multiple times ;), but I think the situation you're describing with the foreign keys is rather unique... The datafied datetime cannot possibly include all its possible formats, nor all the possible alternatives - that would be extremely wasteful and meaningless the way I see it. Let's take an Instant as an example...it datafies to map of two keys (:epoch, :second). Does it make sense to add a :format-iso key in there pointing to a String? Is there any point navigating to that key? Is there any point navigating to :epoch or :second? The answer is no, right? Is there a point in navigating to :zoned-datetime given a zone id? I would think yes... On Mon, 3 Feb 2020, 04:47 Sean Corfield, mailto:s...@corfield.org>> wrote: Think of it as a square: You start with an object of some sort (left side) -> datafy -> turns it into pure Clojure data (including metadata). (right side) Given pure Clojure data, you can navigate through it with get etc and you stay in the right side (pure data). Given that pure Clojure data, you can navigate back to the left hand wide with nav, mimicking how get etc work. So datafy is L -> R, get is R -> R, nav is R -> L on a "diagonal" that takes you back to the object world on the left, corresponding to the place on the right that you'd get to via get etc. See if this blog post helps https://corfield.org/blog/2018/12/03/datafy-nav/ On Sun, Feb 2, 2020 at 1:22 AM Dimitrios Jim Piliouras mailto:jimpil1...@gmail.com>> wrote: Hi Sean, Admittedly, I’ve never used REBL, and I did struggle with the shape and name of the `nav` arguments... In particular I’m struggling to understand why would anyone use `nav` to navigate to a key that already exists in the map...Can’t we just use `get` or `get-in`? You used the :format as an example, which works with nil, :iso, or a String pattern as the last arg to nav. But again, :format is NOT in the datafied representation. In essence, I’ve tried to use `nav` to navigate to things that can be expensive and don’t necessarily belong in the actual datafied representation. If the second argument to `nav`, is expected to be a key already present in the map, then I really don’t understand what is the point of `nav`. kind regards, Dimitris *From: *Sean Corfield <mailto:s...@corfield.org> *Sent: *02 February 2020 07:36 *To: *Clojure Mailing List <mailto:clojure@googlegroups.com> *Subject: *Re: ANN: jedi-time 0.1.4 This is very cool but I would strongly recommend you try using this with REBL so you can figure out how to make the `nav` part work in a more natural way. nav is intended to work with a key and value (from the datafied structure), but your nav expects special values so it doesn't work with REBL. You can put (java.time.Instant/now) into REBL and your datafication produces a great data representation, but you can't navigate into it using the keys (and values) of the data structure itself. You can put :format into the nav-> bar and it defaults to a format you can get a string back, but none of the other nav calls will work. You might consider combining the :format key with the actual format, e.g., :format-iso, :format-yy-MM-dd and if the key is something your don't recognize, just let it behave like regular data navigation. I think you're trying to do too much with nav, beyond "navigation". I think you could split some of the "clever" navig
Re: ANN: jedi-time 0.1.4
re any point navigating to that key? Is there >> any point navigating to :epoch or :second? The answer is no, right? Is >> there a point in navigating to :zoned-datetime given a zone id? I would >> think yes... >> >> On Mon, 3 Feb 2020, 04:47 Sean Corfield, wrote: >> >>> Think of it as a square: >>> >>> You start with an object of some sort (left side) -> datafy -> turns it >>> into pure Clojure data (including metadata). (right side) >>> >>> Given pure Clojure data, you can navigate through it with get etc and >>> you stay in the right side (pure data). >>> >>> Given that pure Clojure data, you can navigate back to the left hand >>> wide with nav, mimicking how get etc work. >>> >>> So datafy is L -> R, get is R -> R, nav is R -> L on a "diagonal" that >>> takes you back to the object world on the left, corresponding to the place >>> on the right that you'd get to via get etc. >>> >>> See if this blog post helps >>> https://corfield.org/blog/2018/12/03/datafy-nav/ >>> >>> >>> On Sun, Feb 2, 2020 at 1:22 AM Dimitrios Jim Piliouras < >>> jimpil1...@gmail.com> wrote: >>> >>>> Hi Sean, >>>> >>>> >>>> >>>> Admittedly, I’ve never used REBL, and I did struggle with the shape and >>>> name of the `nav` arguments... >>>> >>>> >>>> >>>> In particular I’m struggling to understand why would anyone use `nav` >>>> to navigate to a key that already exists in the map...Can’t we just use >>>> `get` or `get-in`? >>>> >>>> You used the :format as an example, which works with nil, :iso, or a >>>> String pattern as the last arg to nav. But again, :format is NOT in the >>>> datafied representation. >>>> >>>> >>>> >>>> In essence, I’ve tried to use `nav` to navigate to things that can be >>>> expensive and don’t necessarily belong in the actual datafied >>>> representation. >>>> >>>> If the second argument to `nav`, is expected to be a key already >>>> present in the map, then I really don’t understand what is the point of >>>> `nav`. >>>> >>>> >>>> >>>> kind regards, >>>> >>>> Dimitris >>>> >>>> >>>> >>>> >>>> >>>> *From: *Sean Corfield >>>> *Sent: *02 February 2020 07:36 >>>> *To: *Clojure Mailing List >>>> *Subject: *Re: ANN: jedi-time 0.1.4 >>>> >>>> >>>> >>>> This is very cool but I would strongly recommend you try using this >>>> with REBL so you can figure out how to make the `nav` part work in a more >>>> natural way. >>>> >>>> >>>> >>>> nav is intended to work with a key and value (from the datafied >>>> structure), but your nav expects special values so it doesn't work with >>>> REBL. >>>> >>>> >>>> >>>> You can put (java.time.Instant/now) into REBL and your datafication >>>> produces a great data representation, but you can't navigate into it using >>>> the keys (and values) of the data structure itself. You can put :format >>>> into the nav-> bar and it defaults to a format you can get a string back, >>>> but none of the other nav calls will work. >>>> >>>> >>>> >>>> You might consider combining the :format key with the actual format, >>>> e.g., :format-iso, :format-yy-MM-dd and if the key is something your don't >>>> recognize, just let it behave like regular data navigation. >>>> >>>> >>>> >>>> I think you're trying to do too much with nav, beyond "navigation". I >>>> think you could split some of the "clever" navigation out into a transform >>>> function that takes a datafied time and produces a new datafied time, and >>>> then let nav do the "conversion" back to Java objects. You've complected >>>> the transforms and the conversion right now. >>>> >>>> >>>> >>>> If you're on Slack, I'm happy to DM about this in more detail (when >>>> you're back from traveling). >>>> >>>> >>>> >>>> Sean
Re: ANN: jedi-time 0.1.4
o navigate to a key that already exists in the map...Can’t we just use `get` or `get-in`? You used the :format as an example, which works with nil, :iso, or a String pattern as the last arg to nav. But again, :format is NOT in the datafied representation. In essence, I’ve tried to use `nav` to navigate to things that can be expensive and don’t necessarily belong in the actual datafied representation. If the second argument to `nav`, is expected to be a key already present in the map, then I really don’t understand what is the point of `nav`. kind regards, Dimitris *From: *Sean Corfield <mailto:s...@corfield.org> *Sent: *02 February 2020 07:36 *To: *Clojure Mailing List <mailto:clojure@googlegroups.com> *Subject: *Re: ANN: jedi-time 0.1.4 This is very cool but I would strongly recommend you try using this with REBL so you can figure out how to make the `nav` part work in a more natural way. nav is intended to work with a key and value (from the datafied structure), but your nav expects special values so it doesn't work with REBL. You can put (java.time.Instant/now) into REBL and your datafication produces a great data representation, but you can't navigate into it using the keys (and values) of the data structure itself. You can put :format into the nav-> bar and it defaults to a format you can get a string back, but none of the other nav calls will work. You might consider combining the :format key with the actual format, e.g., :format-iso, :format-yy-MM-dd and if the key is something your don't recognize, just let it behave like regular data navigation. I think you're trying to do too much with nav, beyond "navigation". I think you could split some of the "clever" navigation out into a transform function that takes a datafied time and produces a new datafied time, and then let nav do the "conversion" back to Java objects. You've complected the transforms and the conversion right now. If you're on Slack, I'm happy to DM about this in more detail (when you're back from traveling). Sean On Sat, Feb 1, 2020 at 6:02 AM dimitris mailto:jimpil1...@gmail.com>> wrote: Hi folks, The first public release of `jedi-time` should be hitting clojars any minute now. I am traveling next week so may be slow to reply to feedback/bugs/PRs... https://github.com/jimpil/jedi-time Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com <mailto:clojure@googlegroups.com> Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com <mailto:clojure%2bunsubscr...@googlegroups.com> For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com <mailto:clojure%2bunsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/8dbb9c5b-0ab0-fc76-6dc6-5e75b93d452a%40gmail.com. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles Networks, LLC. -- https://worldsinglesnetworks.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com <mailto:clojure@googlegroups.com>
Re: ANN: jedi-time 0.1.4
You're misunderstanding me. I'll try again. I'm not saying you can't navigate to keys that don't exist in the data -- but since there would be no corresponding value, the nav call would be (nav coll k nil) essentially. If (get coll k) produces some value v, then (nav coll k v) will take you from the right side (pure data) to the left side (objects) to the object that "corresponds" to the equivalent navigation on the right (i.e., within the data). object -> datafy -> pure data pure data -> get etc -> new pure data pure data -> nav -> new object "corresponding" to new pure data On Mon, Feb 3, 2020 at 3:38 AM Dimitrios Jim Piliouras wrote: > This is what I've done but it contradicts what we said earlier... > > If I navigate to some existing key and it gives me back a Java object, > then it means that the datafied representation had a key pointing to non > data! > > I have read your blog post multiple times ;), but I think the situation > you're describing with the foreign keys is rather unique... > > The datafied datetime cannot possibly include all its possible formats, > nor all the possible alternatives - that would be extremely wasteful and > meaningless the way I see it. > > > Let's take an Instant as an example...it datafies to map of two keys > (:epoch, :second). Does it make sense to add a :format-iso key in there > pointing to a String? Is there any point navigating to that key? Is there > any point navigating to :epoch or :second? The answer is no, right? Is > there a point in navigating to :zoned-datetime given a zone id? I would > think yes... > > On Mon, 3 Feb 2020, 04:47 Sean Corfield, wrote: > >> Think of it as a square: >> >> You start with an object of some sort (left side) -> datafy -> turns it >> into pure Clojure data (including metadata). (right side) >> >> Given pure Clojure data, you can navigate through it with get etc and you >> stay in the right side (pure data). >> >> Given that pure Clojure data, you can navigate back to the left hand wide >> with nav, mimicking how get etc work. >> >> So datafy is L -> R, get is R -> R, nav is R -> L on a "diagonal" that >> takes you back to the object world on the left, corresponding to the place >> on the right that you'd get to via get etc. >> >> See if this blog post helps >> https://corfield.org/blog/2018/12/03/datafy-nav/ >> >> >> On Sun, Feb 2, 2020 at 1:22 AM Dimitrios Jim Piliouras < >> jimpil1...@gmail.com> wrote: >> >>> Hi Sean, >>> >>> >>> >>> Admittedly, I’ve never used REBL, and I did struggle with the shape and >>> name of the `nav` arguments... >>> >>> >>> >>> In particular I’m struggling to understand why would anyone use `nav` to >>> navigate to a key that already exists in the map...Can’t we just use `get` >>> or `get-in`? >>> >>> You used the :format as an example, which works with nil, :iso, or a >>> String pattern as the last arg to nav. But again, :format is NOT in the >>> datafied representation. >>> >>> >>> >>> In essence, I’ve tried to use `nav` to navigate to things that can be >>> expensive and don’t necessarily belong in the actual datafied >>> representation. >>> >>> If the second argument to `nav`, is expected to be a key already >>> present in the map, then I really don’t understand what is the point of >>> `nav`. >>> >>> >>> >>> kind regards, >>> >>> Dimitris >>> >>> >>> >>> >>> >>> *From: *Sean Corfield >>> *Sent: *02 February 2020 07:36 >>> *To: *Clojure Mailing List >>> *Subject: *Re: ANN: jedi-time 0.1.4 >>> >>> >>> >>> This is very cool but I would strongly recommend you try using this with >>> REBL so you can figure out how to make the `nav` part work in a more >>> natural way. >>> >>> >>> >>> nav is intended to work with a key and value (from the datafied >>> structure), but your nav expects special values so it doesn't work with >>> REBL. >>> >>> >>> >>> You can put (java.time.Instant/now) into REBL and your datafication >>> produces a great data representation, but you can't navigate into it using >>> the keys (and values) of the data structure itself. You can put :format >>> into the nav-> bar and it defaults to a format you can get a string
Re: ANN: jedi-time 0.1.4
This is what I've done but it contradicts what we said earlier... If I navigate to some existing key and it gives me back a Java object, then it means that the datafied representation had a key pointing to non data! I have read your blog post multiple times ;), but I think the situation you're describing with the foreign keys is rather unique... The datafied datetime cannot possibly include all its possible formats, nor all the possible alternatives - that would be extremely wasteful and meaningless the way I see it. Let's take an Instant as an example...it datafies to map of two keys (:epoch, :second). Does it make sense to add a :format-iso key in there pointing to a String? Is there any point navigating to that key? Is there any point navigating to :epoch or :second? The answer is no, right? Is there a point in navigating to :zoned-datetime given a zone id? I would think yes... On Mon, 3 Feb 2020, 04:47 Sean Corfield, wrote: > Think of it as a square: > > You start with an object of some sort (left side) -> datafy -> turns it > into pure Clojure data (including metadata). (right side) > > Given pure Clojure data, you can navigate through it with get etc and you > stay in the right side (pure data). > > Given that pure Clojure data, you can navigate back to the left hand wide > with nav, mimicking how get etc work. > > So datafy is L -> R, get is R -> R, nav is R -> L on a "diagonal" that > takes you back to the object world on the left, corresponding to the place > on the right that you'd get to via get etc. > > See if this blog post helps > https://corfield.org/blog/2018/12/03/datafy-nav/ > > > On Sun, Feb 2, 2020 at 1:22 AM Dimitrios Jim Piliouras < > jimpil1...@gmail.com> wrote: > >> Hi Sean, >> >> >> >> Admittedly, I’ve never used REBL, and I did struggle with the shape and >> name of the `nav` arguments... >> >> >> >> In particular I’m struggling to understand why would anyone use `nav` to >> navigate to a key that already exists in the map...Can’t we just use `get` >> or `get-in`? >> >> You used the :format as an example, which works with nil, :iso, or a >> String pattern as the last arg to nav. But again, :format is NOT in the >> datafied representation. >> >> >> >> In essence, I’ve tried to use `nav` to navigate to things that can be >> expensive and don’t necessarily belong in the actual datafied >> representation. >> >> If the second argument to `nav`, is expected to be a key already present >> in the map, then I really don’t understand what is the point of `nav`. >> >> >> >> kind regards, >> >> Dimitris >> >> >> >> >> >> *From: *Sean Corfield >> *Sent: *02 February 2020 07:36 >> *To: *Clojure Mailing List >> *Subject: *Re: ANN: jedi-time 0.1.4 >> >> >> >> This is very cool but I would strongly recommend you try using this with >> REBL so you can figure out how to make the `nav` part work in a more >> natural way. >> >> >> >> nav is intended to work with a key and value (from the datafied >> structure), but your nav expects special values so it doesn't work with >> REBL. >> >> >> >> You can put (java.time.Instant/now) into REBL and your datafication >> produces a great data representation, but you can't navigate into it using >> the keys (and values) of the data structure itself. You can put :format >> into the nav-> bar and it defaults to a format you can get a string back, >> but none of the other nav calls will work. >> >> >> >> You might consider combining the :format key with the actual format, >> e.g., :format-iso, :format-yy-MM-dd and if the key is something your don't >> recognize, just let it behave like regular data navigation. >> >> >> >> I think you're trying to do too much with nav, beyond "navigation". I >> think you could split some of the "clever" navigation out into a transform >> function that takes a datafied time and produces a new datafied time, and >> then let nav do the "conversion" back to Java objects. You've complected >> the transforms and the conversion right now. >> >> >> >> If you're on Slack, I'm happy to DM about this in more detail (when >> you're back from traveling). >> >> >> >> Sean >> >> >> >> On Sat, Feb 1, 2020 at 6:02 AM dimitris wrote: >> >> Hi folks, >> >> The first public release of `jedi-time` should be hitting
Re: ANN: jedi-time 0.1.4
Think of it as a square: You start with an object of some sort (left side) -> datafy -> turns it into pure Clojure data (including metadata). (right side) Given pure Clojure data, you can navigate through it with get etc and you stay in the right side (pure data). Given that pure Clojure data, you can navigate back to the left hand wide with nav, mimicking how get etc work. So datafy is L -> R, get is R -> R, nav is R -> L on a "diagonal" that takes you back to the object world on the left, corresponding to the place on the right that you'd get to via get etc. See if this blog post helps https://corfield.org/blog/2018/12/03/datafy-nav/ On Sun, Feb 2, 2020 at 1:22 AM Dimitrios Jim Piliouras wrote: > Hi Sean, > > > > Admittedly, I’ve never used REBL, and I did struggle with the shape and > name of the `nav` arguments... > > > > In particular I’m struggling to understand why would anyone use `nav` to > navigate to a key that already exists in the map...Can’t we just use `get` > or `get-in`? > > You used the :format as an example, which works with nil, :iso, or a > String pattern as the last arg to nav. But again, :format is NOT in the > datafied representation. > > > > In essence, I’ve tried to use `nav` to navigate to things that can be > expensive and don’t necessarily belong in the actual datafied > representation. > > If the second argument to `nav`, is expected to be a key already present > in the map, then I really don’t understand what is the point of `nav`. > > > > kind regards, > > Dimitris > > > > > > *From: *Sean Corfield > *Sent: *02 February 2020 07:36 > *To: *Clojure Mailing List > *Subject: *Re: ANN: jedi-time 0.1.4 > > > > This is very cool but I would strongly recommend you try using this with > REBL so you can figure out how to make the `nav` part work in a more > natural way. > > > > nav is intended to work with a key and value (from the datafied > structure), but your nav expects special values so it doesn't work with > REBL. > > > > You can put (java.time.Instant/now) into REBL and your datafication > produces a great data representation, but you can't navigate into it using > the keys (and values) of the data structure itself. You can put :format > into the nav-> bar and it defaults to a format you can get a string back, > but none of the other nav calls will work. > > > > You might consider combining the :format key with the actual format, e.g., > :format-iso, :format-yy-MM-dd and if the key is something your don't > recognize, just let it behave like regular data navigation. > > > > I think you're trying to do too much with nav, beyond "navigation". I > think you could split some of the "clever" navigation out into a transform > function that takes a datafied time and produces a new datafied time, and > then let nav do the "conversion" back to Java objects. You've complected > the transforms and the conversion right now. > > > > If you're on Slack, I'm happy to DM about this in more detail (when you're > back from traveling). > > > > Sean > > > > On Sat, Feb 1, 2020 at 6:02 AM dimitris wrote: > > Hi folks, > > The first public release of `jedi-time` should be hitting clojars any > minute now. I am traveling next week so may be slow to reply to > feedback/bugs/PRs... > > https://github.com/jimpil/jedi-time > > > Kind regards, > > Dimitris > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/8dbb9c5b-0ab0-fc76-6dc6-5e75b93d452a%40gmail.com > . > > > > > -- > > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > World Singles Networks, LLC. -- https://worldsinglesnetworks.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > -- > You received this message because you are subscribe
RE: ANN: jedi-time 0.1.4
I think I need to clarify the following points in my head: 1. Was `nav` conceived to complement `datafy` specifically in the context of REBL (and not really anywhere else)? 2. How useful is a datafied datetime (outside the context of REBL), if it can’t be easily formatted, queried, shifted or converted to an alternate version? 3. Why would I ever navigate the existing keys of a map via `nav` (as opposed to the standard functions)? Kind regards, Dimitris From: Dimitrios Jim Piliouras Sent: 02 February 2020 09:22 To: clojure@googlegroups.com Subject: RE: ANN: jedi-time 0.1.4 Hi Sean, Admittedly, I’ve never used REBL, and I did struggle with the shape and name of the `nav` arguments... In particular I’m struggling to understand why would anyone use `nav` to navigate to a key that already exists in the map...Can’t we just use `get` or `get-in`? You used the :format as an example, which works with nil, :iso, or a String pattern as the last arg to nav. But again, :format is NOT in the datafied representation. In essence, I’ve tried to use `nav` to navigate to things that can be expensive and don’t necessarily belong in the actual datafied representation. If the second argument to `nav`, is expected to be a key already present in the map, then I really don’t understand what is the point of `nav`. kind regards, Dimitris From: Sean Corfield Sent: 02 February 2020 07:36 To: Clojure Mailing List Subject: Re: ANN: jedi-time 0.1.4 This is very cool but I would strongly recommend you try using this with REBL so you can figure out how to make the `nav` part work in a more natural way. nav is intended to work with a key and value (from the datafied structure), but your nav expects special values so it doesn't work with REBL. You can put (java.time.Instant/now) into REBL and your datafication produces a great data representation, but you can't navigate into it using the keys (and values) of the data structure itself. You can put :format into the nav-> bar and it defaults to a format you can get a string back, but none of the other nav calls will work. You might consider combining the :format key with the actual format, e.g., :format-iso, :format-yy-MM-dd and if the key is something your don't recognize, just let it behave like regular data navigation. I think you're trying to do too much with nav, beyond "navigation". I think you could split some of the "clever" navigation out into a transform function that takes a datafied time and produces a new datafied time, and then let nav do the "conversion" back to Java objects. You've complected the transforms and the conversion right now. If you're on Slack, I'm happy to DM about this in more detail (when you're back from traveling). Sean On Sat, Feb 1, 2020 at 6:02 AM dimitris wrote: Hi folks, The first public release of `jedi-time` should be hitting clojars any minute now. I am traveling next week so may be slow to reply to feedback/bugs/PRs... https://github.com/jimpil/jedi-time Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/8dbb9c5b-0ab0-fc76-6dc6-5e75b93d452a%40gmail.com. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles Networks, LLC. -- https://worldsinglesnetworks.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAD4thx-dwJkYYsGDWnD%3DAc7oaNBHqykGPzYhTHdWQRJmbk1DEw%40mail.gmail.com. -- You rec
RE: ANN: jedi-time 0.1.4
Hi Sean, Admittedly, I’ve never used REBL, and I did struggle with the shape and name of the `nav` arguments... In particular I’m struggling to understand why would anyone use `nav` to navigate to a key that already exists in the map...Can’t we just use `get` or `get-in`? You used the :format as an example, which works with nil, :iso, or a String pattern as the last arg to nav. But again, :format is NOT in the datafied representation. In essence, I’ve tried to use `nav` to navigate to things that can be expensive and don’t necessarily belong in the actual datafied representation. If the second argument to `nav`, is expected to be a key already present in the map, then I really don’t understand what is the point of `nav`. kind regards, Dimitris From: Sean Corfield Sent: 02 February 2020 07:36 To: Clojure Mailing List Subject: Re: ANN: jedi-time 0.1.4 This is very cool but I would strongly recommend you try using this with REBL so you can figure out how to make the `nav` part work in a more natural way. nav is intended to work with a key and value (from the datafied structure), but your nav expects special values so it doesn't work with REBL. You can put (java.time.Instant/now) into REBL and your datafication produces a great data representation, but you can't navigate into it using the keys (and values) of the data structure itself. You can put :format into the nav-> bar and it defaults to a format you can get a string back, but none of the other nav calls will work. You might consider combining the :format key with the actual format, e.g., :format-iso, :format-yy-MM-dd and if the key is something your don't recognize, just let it behave like regular data navigation. I think you're trying to do too much with nav, beyond "navigation". I think you could split some of the "clever" navigation out into a transform function that takes a datafied time and produces a new datafied time, and then let nav do the "conversion" back to Java objects. You've complected the transforms and the conversion right now. If you're on Slack, I'm happy to DM about this in more detail (when you're back from traveling). Sean On Sat, Feb 1, 2020 at 6:02 AM dimitris wrote: Hi folks, The first public release of `jedi-time` should be hitting clojars any minute now. I am traveling next week so may be slow to reply to feedback/bugs/PRs... https://github.com/jimpil/jedi-time Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/8dbb9c5b-0ab0-fc76-6dc6-5e75b93d452a%40gmail.com. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles Networks, LLC. -- https://worldsinglesnetworks.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAD4thx-dwJkYYsGDWnD%3DAc7oaNBHqykGPzYhTHdWQRJmbk1DEw%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email
Re: ANN: jedi-time 0.1.4
This is very cool but I would strongly recommend you try using this with REBL so you can figure out how to make the `nav` part work in a more natural way. nav is intended to work with a key and value (from the datafied structure), but your nav expects special values so it doesn't work with REBL. You can put (java.time.Instant/now) into REBL and your datafication produces a great data representation, but you can't navigate into it using the keys (and values) of the data structure itself. You can put :format into the nav-> bar and it defaults to a format you can get a string back, but none of the other nav calls will work. You might consider combining the :format key with the actual format, e.g., :format-iso, :format-yy-MM-dd and if the key is something your don't recognize, just let it behave like regular data navigation. I think you're trying to do too much with nav, beyond "navigation". I think you could split some of the "clever" navigation out into a transform function that takes a datafied time and produces a new datafied time, and then let nav do the "conversion" back to Java objects. You've complected the transforms and the conversion right now. If you're on Slack, I'm happy to DM about this in more detail (when you're back from traveling). Sean On Sat, Feb 1, 2020 at 6:02 AM dimitris wrote: > Hi folks, > > The first public release of `jedi-time` should be hitting clojars any > minute now. I am traveling next week so may be slow to reply to > feedback/bugs/PRs... > > https://github.com/jimpil/jedi-time > > > Kind regards, > > Dimitris > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/8dbb9c5b-0ab0-fc76-6dc6-5e75b93d452a%40gmail.com > . > -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles Networks, LLC. -- https://worldsinglesnetworks.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAD4thx-dwJkYYsGDWnD%3DAc7oaNBHqykGPzYhTHdWQRJmbk1DEw%40mail.gmail.com.
ANN: jedi-time 0.1.4
Hi folks, The first public release of `jedi-time` should be hitting clojars any minute now. I am traveling next week so may be slow to reply to feedback/bugs/PRs... https://github.com/jimpil/jedi-time Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/8dbb9c5b-0ab0-fc76-6dc6-5e75b93d452a%40gmail.com.
