Re: s/valid? does not tell me if the data is valid as supplied
I've been using the macro below to make "types" in the context of clara-rules, where "type" has a specific semantic. If you're going to do something like this, you definitely should have a very well-defined notion of what "type" means. (defmacro def-derive "Macros to wrap useful pattern of defining a spec and calling derive on the spec and a \"parent\" spec to create a hierarchy." ([child-name parent-name] `(def-derive ~child-name ~parent-name ~parent-name)) ([child-name parent-name spec] `(do (#?(:clj clojure.spec.alpha/def :cljs cljs.spec.alpha/def) ~child-name (#?(:clj clojure.spec.alpha/merge :cljs cljs.spec.alpha/merge) ~parent-name ~spec)) (derive ~child-name ~parent-name On Wednesday, February 21, 2018 at 5:34:00 PM UTC-8, Didier wrote: > > I would actually love it if Spec was extended to have the concept of types. > > Something where every spec could be tied to a Type, and types could be > constructed to have Hierarchies. > > Not sure what the syntax would be like, but say: > > (s/def :String ::name string?) > (s/def :String ::address (s/and string? (complement string/blank?))) > (s/def :Person ::person (s/keys :req [::name ::address])) > (s/def :Homeless ::homeless (s/keys :req [::name])) > > (s/defisa :Homeless :Person) > > Types would still be predicates, and all spec would be a Type too. Types > would be optional though. A Type is the OR of all the specs predicates > defined as that Type and its children types. So in the above, :Homeless is > (s/or ::person ::homeless). > > Now, this idea might need to be refined, but the goal would be so that > Spec could be used as a modeling languages for other languages. So I could > from a Spec auto-generate a Java class model, or a Ruby model, etc. Since > now I can relate predicates to types myself. It could also allow for better > static analysis. > > Also, might make spec extra complicated and confused to mix both > predicates and types, but that could depend how its done and managed. > > On Tuesday, 20 February 2018 02:41:38 UTC-8, Jan Rychter wrote: >> >> I've been using spec for a while now, in a reasonably large code base >> (>30k lines of Clojure and ClojureScript) and there is an issue that bit me >> several times. >> >> I use conformers for coercing data that is *almost* what I need, usually >> when reading from JSON (RethinkDB). Common conformers are keyword and set. >> And it works really well, except for one problem: there is no way to know >> if data has been conformed or not. >> >> Calling s/valid? will tell me if the data is valid *if it has been >> conformed*. But what if it hasn't? Can I use the data? Is it "valid" >> according to the spec I wrote? >> >> This is a very real problem: I've spent considerable time chasing bugs >> where there was a code path which did not call s/conform. The data passed >> all validations done with valid? and the bug manifested itself far down the >> road, where something expected a keyword instead of a string, or a set >> instead of a vector. >> >> Here is a specific minimal example demonstrating what I'm talking about: >> >> (ns spectest >> (:require [clojure.spec.alpha :as s])) >> >> (s/def ::test-spec (s/and (s/conformer keyword) keyword?)) >> >> (s/conform ::test-spec "a") ;; :a >> (s/valid? ::test-spec "a") ;; true >> >> I expected the last valid? to return false, because my code does not >> expect a string, it expects a keyword, according to the spec. >> >> I might be missing something, but I would much rather see valid? tell me >> if the data is valid for use (as supplied) and have a separate >> valid-when-conformed? which tells me if the data is, well, valid when >> conformed. It seems to me that the current valid? that does two things is >> confusing and not very useful for contracts. >> >> At the very least I'd really like to see a function that tells me if the >> data is valid *as supplied*, as this is the function that I'd want to use >> when enforcing contracts everywhere in my code. >> >> Alternatively, I could stop using conformers altogether, and write >> explicit data conversion functions. That might not be a bad idea, but it >> seems other people started using conformers, too, so eventually I'll hit >> the same problem again. >> >> --J. >> >> -- 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. For more options,
Re: [ANN and RFC] Bifurcan: impure functional data strucures
Both, actually. The algorithm incrementally builds a tree via simulation. There's a step of traversing the current version of the tree to find a leaf, which requires immutability, as I have to remember the path taken (the path is generated via simulation, not by walking an existing tree structure, so requires updates to the state maps). But once at a leaf, I run multiple simulations in parallel, and provided each starts with an independent mutable "copy", then the subsequent states can be mutable. That should be a big perf win, since it's where the algo spends a lot of it's time. The data structures that hold the statistics about the states in the tree could also be mutable. These are keyed by state maps, hoping improved hash/equality performance will help a little there as well. On Sunday, April 23, 2017 at 1:18:56 PM UTC-7, Zach Tellman wrote: > > Are you relying on the immutability of these structures, or are they > effectively always transient? > On Sun, Apr 23, 2017 at 11:02 AM Dave Dixon <dave.d...@gmail.com > > wrote: > >> FWIW, the use-case I have essentially involves Monte Carlo simulations. >> So we start with a state (non-empty map), and then make a series of >> modifications to it. Various statistics are held in hash-maps keyed by the >> state, so there's a lot of lookups and modifications in those maps. >> >> That said, I'm not sure if for this particular case I care too much using >> Clojure idioms vs. direct API access. The algorithms tend to be >> hand-tweaked for performance anyway. The big win for me in wrapping >> bifurcan would be the ability to use spec without having to write >> specialized specs, generators, etc. >> >> >> On Thursday, April 20, 2017 at 9:53:56 PM UTC-7, Zach Tellman wrote: >> >>> Sure, happy to elaborate. Bifurcan offers potential performance wins a >>> few different ways: >>> >>> * We can use standard Java equality semantics, bypassing all the >>> overhead of the hash calculations and enhanced numeric equality checks >>> (this can lead to moderate performance gains) >>> * We can use a mutable data structure as long as it never escapes a >>> local context (this can lead to significant performance gains) >>> * We can use the extra capabilities the data structures expose, like >>> concatenation, slicing, set operations, etc. (this is too dependent on the >>> use case to really quantify) >>> >> >>> it would be easy to have a `map` and `map*` method that expose Clojure >>> and Java equality semantics, respectively, but that puts a big onus on the >>> developer to determine if the latter is safe for their use case. I've been >>> bit by this when I've used j.u.c.ConcurrentHashMap before, so I expect >>> people will suffer similarly weird bugs. >>> >>> However, I think there's a way to use the mutable data structures. >>> Technically, transient data structures allow arbitrary persistent data >>> structures to be batch updated, but in practice they tend to be empty, and >>> after they're populated they tend to be treated as read-only. >>> >>> If we're convinced this is common enough, every empty transient data >>> structure could be mutable, and when we make it persistent we could wrap it >>> in a "virtual" collection [1] which allows updates without touching the >>> base collection. This would allow for faster writes, faster reads, and >>> only marginally slower updates if those are required. >>> >>> This is all predicated on a bunch of assumptions that are hard to >>> validate, but if this describes enough real-world use cases, it could lead >>> to a big, easy performance win. It's even possible to automatically >>> replace the base Clojure collections with these alternatives using >>> something like Sleight [2]. >>> >>> Anyway, that's what I've been mulling over. If anyone has opinions, I'm >>> happy to hear them. >>> >>> Zach >>> >>> [1] >>> https://github.com/lacuna/bifurcan/blob/master/src/io/lacuna/bifurcan/Maps.java#L103 >>> [2] https://github.com/ztellman/sleight >>> >>> On Thu, Apr 20, 2017 at 8:55 AM Dave Dixon <dave.d...@gmail.com> wrote: >>> >>>> Sounds great. If you have time, I'd certainly like to hear your >>>> thoughts on the issues of equality semantics and transients, maybe I can >>>> ponder and make some suggestions based on my target use-case. >>>> >>>> >>>> On Tuesday, April 18, 2017 at
Re: [ANN and RFC] Bifurcan: impure functional data strucures
FWIW, the use-case I have essentially involves Monte Carlo simulations. So we start with a state (non-empty map), and then make a series of modifications to it. Various statistics are held in hash-maps keyed by the state, so there's a lot of lookups and modifications in those maps. That said, I'm not sure if for this particular case I care too much using Clojure idioms vs. direct API access. The algorithms tend to be hand-tweaked for performance anyway. The big win for me in wrapping bifurcan would be the ability to use spec without having to write specialized specs, generators, etc. On Thursday, April 20, 2017 at 9:53:56 PM UTC-7, Zach Tellman wrote: > Sure, happy to elaborate. Bifurcan offers potential performance wins a > few different ways: > > * We can use standard Java equality semantics, bypassing all the overhead > of the hash calculations and enhanced numeric equality checks (this can > lead to moderate performance gains) > * We can use a mutable data structure as long as it never escapes a local > context (this can lead to significant performance gains) > * We can use the extra capabilities the data structures expose, like > concatenation, slicing, set operations, etc. (this is too dependent on the > use case to really quantify) > > it would be easy to have a `map` and `map*` method that expose Clojure and > Java equality semantics, respectively, but that puts a big onus on the > developer to determine if the latter is safe for their use case. I've been > bit by this when I've used j.u.c.ConcurrentHashMap before, so I expect > people will suffer similarly weird bugs. > > However, I think there's a way to use the mutable data structures. > Technically, transient data structures allow arbitrary persistent data > structures to be batch updated, but in practice they tend to be empty, and > after they're populated they tend to be treated as read-only. > > If we're convinced this is common enough, every empty transient data > structure could be mutable, and when we make it persistent we could wrap it > in a "virtual" collection [1] which allows updates without touching the > base collection. This would allow for faster writes, faster reads, and > only marginally slower updates if those are required. > > This is all predicated on a bunch of assumptions that are hard to > validate, but if this describes enough real-world use cases, it could lead > to a big, easy performance win. It's even possible to automatically > replace the base Clojure collections with these alternatives using > something like Sleight [2]. > > Anyway, that's what I've been mulling over. If anyone has opinions, I'm > happy to hear them. > > Zach > > [1] > https://github.com/lacuna/bifurcan/blob/master/src/io/lacuna/bifurcan/Maps.java#L103 > [2] https://github.com/ztellman/sleight > > On Thu, Apr 20, 2017 at 8:55 AM Dave Dixon <dave.d...@gmail.com > > wrote: > >> Sounds great. If you have time, I'd certainly like to hear your thoughts >> on the issues of equality semantics and transients, maybe I can ponder and >> make some suggestions based on my target use-case. >> >> >> On Tuesday, April 18, 2017 at 9:32:32 AM UTC-7, Zach Tellman wrote: >> >>> To be clear, my intention was always to wrap the implementations in the >>> appropriate Clojure interfaces, and I don't believe that will cause much, >>> if any, of a performance hit (inlining is magic). However, there are some >>> real questions regarding how to expose non-standard equality semantics, and >>> whether transients should be represented using the immutable or mutable >>> collection variants. >>> >>> For what it's worth, I have about 1/3 of an implementation of >>> Clojure-compatible versions of these data structures, I just wanted to mull >>> on the above questions a bit before going further. I'm happy to discuss >>> them here in more depth if you have any questions or opinions. >>> >>> Zach >>> >>> On Tue, Apr 18, 2017 at 6:53 AM Dave Dixon <dave.d...@gmail.com> wrote: >>> >> Stared at this a bit yesterday. Seems like if you want to leverage spec >>>> while using bifurcan, then the bifurcan types need to have the Clojure >>>> wrapper. The alternative appears to be re-implementing at least a large >>>> subset of collection-related spec code, which is a lot to bite off. Also >>>> tried updating some existing code to use bifurcan. Similar to spec, there >>>> are going to be cases which are less perf sensitive, where it would be >>>> nice >>>> to use code that is polymorphic for collec
Re: [ANN and RFC] Bifurcan: impure functional data strucures
Sounds great. If you have time, I'd certainly like to hear your thoughts on the issues of equality semantics and transients, maybe I can ponder and make some suggestions based on my target use-case. On Tuesday, April 18, 2017 at 9:32:32 AM UTC-7, Zach Tellman wrote: > > To be clear, my intention was always to wrap the implementations in the > appropriate Clojure interfaces, and I don't believe that will cause much, > if any, of a performance hit (inlining is magic). However, there are some > real questions regarding how to expose non-standard equality semantics, and > whether transients should be represented using the immutable or mutable > collection variants. > > For what it's worth, I have about 1/3 of an implementation of > Clojure-compatible versions of these data structures, I just wanted to mull > on the above questions a bit before going further. I'm happy to discuss > them here in more depth if you have any questions or opinions. > > Zach > > On Tue, Apr 18, 2017 at 6:53 AM Dave Dixon <dave.d...@gmail.com > > wrote: > >> Stared at this a bit yesterday. Seems like if you want to leverage spec >> while using bifurcan, then the bifurcan types need to have the Clojure >> wrapper. The alternative appears to be re-implementing at least a large >> subset of collection-related spec code, which is a lot to bite off. Also >> tried updating some existing code to use bifurcan. Similar to spec, there >> are going to be cases which are less perf sensitive, where it would be nice >> to use code that is polymorphic for collections, and drop down to the fast >> interface in perf-sensitive parts. >> >> >> On Monday, April 17, 2017 at 1:52:39 PM UTC-7, Dave Dixon wrote: >>> >>> What is the issue with wrapping in Clojure interfaces? Added overhead of >>> function calls? >>> >>> I'm finding myself in the process of doing some of this, at least for >>> constructors. Also thinking of generating predicates/generators for use >>> with spec. >>> >>> On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote: >>> >>>> This is a slightly irregular announcement, because it's not for a >>>> Clojure library. Rather, it's for a library written purely in Java: >>>> https://github.com/lacuna/bifurcan. >>>> >>>> This is a collection of mutable and immutable data structures, designed >>>> to address some of my personal frustrations with what's available in the >>>> Clojure and Java ecosystems. Notably, they have pluggable equality >>>> semantics, so while they *can* use Clojure's expensive hash and equality >>>> checks, they don't *have* to. They also provide high-performance mutable >>>> variants of the data structure which share an API with their immutable >>>> cousins. >>>> >>>> I'm posting it here to ask for people's thoughts on how, if at all, >>>> this should be exposed as a Clojure library. It would be simple to simply >>>> wrap them in the Clojure interfaces and make them behave identically to >>>> Clojure's own data structures, but that kind of obviates the point. >>>> However, creating an entirely new set of accessors means that we can't >>>> leverage Clojure's standard library. >>>> >>>> It's possible that I'm alone in my frustrations, and no Clojure wrapper >>>> is necessary. But if this does solve a problem you have, I'd like to hear >>>> more about what it is, and how you think Bifurcan might help. Please feel >>>> free to reply here, or to grab me at Clojure/West and talk about it there. >>>> >>>> Thanks in advance, >>>> Zach >>>> >>> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@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+u...@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 a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/1m_I7IrDGb0/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+u...@googlegroups.com . >>
Re: [ANN and RFC] Bifurcan: impure functional data strucures
Stared at this a bit yesterday. Seems like if you want to leverage spec while using bifurcan, then the bifurcan types need to have the Clojure wrapper. The alternative appears to be re-implementing at least a large subset of collection-related spec code, which is a lot to bite off. Also tried updating some existing code to use bifurcan. Similar to spec, there are going to be cases which are less perf sensitive, where it would be nice to use code that is polymorphic for collections, and drop down to the fast interface in perf-sensitive parts. On Monday, April 17, 2017 at 1:52:39 PM UTC-7, Dave Dixon wrote: > > What is the issue with wrapping in Clojure interfaces? Added overhead of > function calls? > > I'm finding myself in the process of doing some of this, at least for > constructors. Also thinking of generating predicates/generators for use > with spec. > > On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote: > >> This is a slightly irregular announcement, because it's not for a Clojure >> library. Rather, it's for a library written purely in Java: >> https://github.com/lacuna/bifurcan. >> >> This is a collection of mutable and immutable data structures, designed >> to address some of my personal frustrations with what's available in the >> Clojure and Java ecosystems. Notably, they have pluggable equality >> semantics, so while they *can* use Clojure's expensive hash and equality >> checks, they don't *have* to. They also provide high-performance mutable >> variants of the data structure which share an API with their immutable >> cousins. >> >> I'm posting it here to ask for people's thoughts on how, if at all, this >> should be exposed as a Clojure library. It would be simple to simply wrap >> them in the Clojure interfaces and make them behave identically to >> Clojure's own data structures, but that kind of obviates the point. >> However, creating an entirely new set of accessors means that we can't >> leverage Clojure's standard library. >> >> It's possible that I'm alone in my frustrations, and no Clojure wrapper >> is necessary. But if this does solve a problem you have, I'd like to hear >> more about what it is, and how you think Bifurcan might help. Please feel >> free to reply here, or to grab me at Clojure/West and talk about it there. >> >> Thanks in advance, >> Zach >> > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [ANN and RFC] Bifurcan: impure functional data strucures
What is the issue with wrapping in Clojure interfaces? Added overhead of function calls? I'm finding myself in the process of doing some of this, at least for constructors. Also thinking of generating predicates/generators for use with spec. On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote: > This is a slightly irregular announcement, because it's not for a Clojure > library. Rather, it's for a library written purely in Java: > https://github.com/lacuna/bifurcan. > > This is a collection of mutable and immutable data structures, designed to > address some of my personal frustrations with what's available in the > Clojure and Java ecosystems. Notably, they have pluggable equality > semantics, so while they *can* use Clojure's expensive hash and equality > checks, they don't *have* to. They also provide high-performance mutable > variants of the data structure which share an API with their immutable > cousins. > > I'm posting it here to ask for people's thoughts on how, if at all, this > should be exposed as a Clojure library. It would be simple to simply wrap > them in the Clojure interfaces and make them behave identically to > Clojure's own data structures, but that kind of obviates the point. > However, creating an entirely new set of accessors means that we can't > leverage Clojure's standard library. > > It's possible that I'm alone in my frustrations, and no Clojure wrapper is > necessary. But if this does solve a problem you have, I'd like to hear > more about what it is, and how you think Bifurcan might help. Please feel > free to reply here, or to grab me at Clojure/West and talk about it there. > > Thanks in advance, > Zach > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [ANN and RFC] Bifurcan: impure functional data strucures
I think this would solve an issue I'm facing. I'm working on implementing variations of Monte Carlo tree search for very large trees, with states and actions represented by maps. There are several lookup tables indexed by either state or state-action pairs. I haven't done any detailed benchmarking or perf analysis, but I'm guess that hash/equality consumes no small amount of time. On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote: > > This is a slightly irregular announcement, because it's not for a Clojure > library. Rather, it's for a library written purely in Java: > https://github.com/lacuna/bifurcan. > > This is a collection of mutable and immutable data structures, designed to > address some of my personal frustrations with what's available in the > Clojure and Java ecosystems. Notably, they have pluggable equality > semantics, so while they *can* use Clojure's expensive hash and equality > checks, they don't *have* to. They also provide high-performance mutable > variants of the data structure which share an API with their immutable > cousins. > > I'm posting it here to ask for people's thoughts on how, if at all, this > should be exposed as a Clojure library. It would be simple to simply wrap > them in the Clojure interfaces and make them behave identically to > Clojure's own data structures, but that kind of obviates the point. > However, creating an entirely new set of accessors means that we can't > leverage Clojure's standard library. > > It's possible that I'm alone in my frustrations, and no Clojure wrapper is > necessary. But if this does solve a problem you have, I'd like to hear > more about what it is, and how you think Bifurcan might help. Please feel > free to reply here, or to grab me at Clojure/West and talk about it there. > > Thanks in advance, > Zach > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Custom generators for custom predicate functions
Thanks Alex. I agree it probably isn't "needed", was just a little surprised to discover the asymmetry. Mostly was curious if there was some deeper design decision, e.g. that you need to start with some set of primitive predicates upon which you can start building named specs. On Thursday, December 8, 2016 at 9:23:11 AM UTC-8, Alex Miller wrote: > > In general, you shouldn't need to do this (it is better to attach the > generator to the spec). Generator mappings are provided for core Clojure > predicates so that many common predicates gen automatically and so that > they can be combined (via things like s/and) with other predicates that > filter but don't gen. > > I was not part of the design discussion, but I assume that it would open a > can of worms around conflicts, ordering, and function resolution that Rich > and Stu didn't want to open at this time. Nothing precludes this from being > expanded later if deemed useful. > > On Thursday, December 8, 2016 at 10:56:29 AM UTC-6, Dave Dixon wrote: >> >> Though one can obviously attach a custom generator to a keyword-named >> spec, it appears there is no way to do the same for a custom predicate >> function. I see that the generators for predicate functions testing for >> core primitives are hard-coded in the private >> clojure.spec.gen\gen-builtins. Curious why this isn't extensible, since it >> naively seems similar to the keyword case, but with the custom generator >> keyed by a symbol rather than a map. >> >> Dave >> > -- 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. For more options, visit https://groups.google.com/d/optout.
Custom generators for custom predicate functions
Though one can obviously attach a custom generator to a keyword-named spec, it appears there is no way to do the same for a custom predicate function. I see that the generators for predicate functions testing for core primitives are hard-coded in the private clojure.spec.gen\gen-builtins. Curious why this isn't extensible, since it naively seems similar to the keyword case, but with the custom generator keyed by a symbol rather than a map. Dave -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Clojars Private/Commercial Repos
+1. Neither S3 or Archiva have worked out well for us long term. On Monday, June 29, 2015 at 6:50:44 PM UTC-7, Daniel Compton wrote: Hi folks I wondered if one possible solution for ensuring Clojars long-term viability and maintenance would be to use it to host private repositories for paying users as well? For many people, the thought of setting up and maintaining Nexus or Archiva isn't an appealing one. I'm aware of the S3 wagon, and perhaps that's what people use if they don't want Nexus. I'd be interested to hear what other people are doing, and whether Clojars would be a good middle ground between simplicity and functionality. Many Clojure users already have Clojars accounts and will have setup Lein to deploy here already. Additionally, many people would support Clojars for the goodwill factor. On the other hand I'm aware this would require more development effort, there may not be much demand for this, and the infrastructure costs may not be large enough that it's worth going down this route. Just a thought, Daniel. -- -- Daniel -- 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. For more options, visit https://groups.google.com/d/optout.
Re: datomic - datascript transfers
We're having success with the Datomic - Datascript scenario by treating the Datascript DB as an immutable value, rather than a ref + transactor, at least in the case for user's interactively changing data. When the user loads the data required for a scenario (e.g. editing an entity), we hold the value as obtained from datomic and the updated value used by applying user changes through the with or with-db functions. When the user chooses to commit, we essentially diff the sets of datoms between the original and changed Datascript values (twice - once to get adds and once for retracts), as well as identify the Datascript id's of added entities. On the server, the new Datascript id's are converted into Datomic temp id's, and we just transact the transformed diff. There are some differences in behavior which need to be worked around, particularly the behavior of :db/ident. We strictly use :db/ident only for attribute names and enums. This allows us to do the appropriate transformations to the data and pull patterns so that the differences between Datascript and Datomic are more or less hidden. Works very well for editing hierarchical entities. The parent can simply pass it's Datascript value and the appropriate child id to the child editor. If the user commits the child changes, the parent simply takes the updated value of the db; if the user cancels, the parent doesn't need to do anything, as it is already holding the unchanged value. On Tuesday, February 17, 2015 at 2:00:03 AM UTC-8, henry w wrote: For anyone else looking at this option, here is some code which is doing the work on the cljs side. https://gist.github.com/henryw-erudine/73cbcdea1eda150e78da The server code is straightforward so not included. -- 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. For more options, visit https://groups.google.com/d/optout.
