Re: Cyclic namespace dependencies!
On Friday, December 30, 2016 at 8:59:46 PM UTC-5, puzzler wrote: > > On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge > wrote: > >> I can see that, and even spec has this use case. In Spec it's solved by >> having both A and B in one namespace and using declare to forward-declare >> the constructors (or defns in this case). >> >> So I guess the way I see it the tradeoff is a declare and >> all-in-one-namespace vs a massive complexity addition to the compiler and >> the redefinition of compilation units. The declare method seems like the >> cleaner route. >> >> > I wonder whether there could be something like an `external-declare` that > would satisfy Rich's concerns about knowing how to intern unencountered > vars, while allowing cyclical references when needed. > The macros defined in ‘scarlett.core’ here: https://github.com/scgilardi/scarlett are an experiment along those lines. *scarlett* Provides macros to declare vars in namespaces other than *ns* To be used sparingly to overcome otherwise cyclic namespace dependencies *Usage* (ns-declare my-module startup shutdown) declares my-module/startup and my-module/shutdown (declare+ module-a/startup module-b/startup) declares module-a/startup and module-b/startup They work by using “declare” after switching to the target namespace using “in-ns” (and switching back at the end). They have to be issued at the “top level” (as is highly recommended for ns, declare, def, etc.) to be effective and they contain code to notify with an exception if they are used at other than the top level. (The exception is preferable to silent failure or a confusing error message.) The macros rely on the compiler behavior of handling top-level “do” forms in a special way: evaluating each of the contained forms sequentially *at the top level*, effectively removing the nesting and allowing each contained form to be compiled and evaluated before compiling the next one. Macro expansion facilities other than the compiler (e.g., in an editor or debugger) may not duplicate that subtle behavior so the expansions they produce may not accurately reflect the expansion that will be produced and seen by the compiler. There may be contexts where that causes trouble at development time. I’m not aware of these being used anywhere in other than experimental/POC code. —Steve -- 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: clojure.spec bug?
> On Dec 30, 2016, at 9:42 AM, John Schmidt wrote:
>
> (s/def ::game1 #(satisfies? Game %))
> (s/def ::game2 (partial satisfies? Game))
>
> (s/explain ::game2 (spec-test.foo/->Foo))
> val: #spec_test.foo.Foo{} fails spec: :spec-test.core/game2 predicate:
> (partial satisfies? Game) < WAT
> nil
It looks like the spec macros aren’t resolving the Game reference in the game2
spec. You can use macroexpand-1 to see what was happening at the top-level.
The internal macros get a little complicated so I can’t say if code expressions
like this were intended to work. It doesn’t hurt to file a bug.
I think the usual way to write this would be to define your own little
predicate first and then use that var in the spec.
(def my-game? (partial satisfies? Game))
(s/def ::game3 my-game?)
If you want to work around the immediate issue, try using the fully qualified
symbol for the protocol. (I prefer ::game3 FWIW.)
(s/def ::game4 (partial satisfies? spec-test.core/Game))
--
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: Cyclic namespace dependencies!
Be really careful with Potemkin. I've had a lot of build issues (especially around AOT) with that library. I'll try to put this as kindly as I can...it's a bit of a hack that leverages some undocumented aspects of the Clojure API. As such it's been the source of some really weird compile errors that have taken me many hours to debug. So much so that some libraries have go so far as to copy-paste certain files from potemkin (macros around map-like type creation), in order not to get the more fragile parts of the library (var reorganization). In short...the language wasn't designed to do what Potemkin tries to make it do when it comes to vars. I really recommend against using the library. On Sat, Dec 31, 2016 at 7:32 AM, squeegee wrote: > > > On Friday, December 30, 2016 at 8:59:46 PM UTC-5, puzzler wrote: >> >> On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge >> wrote: >> >>> I can see that, and even spec has this use case. In Spec it's solved by >>> having both A and B in one namespace and using declare to forward-declare >>> the constructors (or defns in this case). >>> >>> So I guess the way I see it the tradeoff is a declare and >>> all-in-one-namespace vs a massive complexity addition to the compiler and >>> the redefinition of compilation units. The declare method seems like the >>> cleaner route. >>> >>> >> I wonder whether there could be something like an `external-declare` that >> would satisfy Rich's concerns about knowing how to intern unencountered >> vars, while allowing cyclical references when needed. >> > > The macros defined in ‘scarlett.core’ here: https://github.com/ > scgilardi/scarlett are an experiment along those lines. > > *scarlett* > > Provides macros to declare vars in namespaces other than *ns* > > To be used sparingly to overcome otherwise cyclic namespace dependencies > > *Usage* > > (ns-declare my-module startup shutdown) > > declares my-module/startup and my-module/shutdown > > (declare+ module-a/startup module-b/startup) > > declares module-a/startup and module-b/startup > > > They work by using “declare” after switching to the target namespace using > “in-ns” (and switching back at the end). They have to be issued at the “top > level” (as is highly recommended for ns, declare, def, etc.) to be > effective and they contain code to notify with an exception if they are > used at other than the top level. (The exception is preferable to silent > failure or a confusing error message.) > > > The macros rely on the compiler behavior of handling top-level “do” forms > in a special way: evaluating each of the contained forms sequentially *at > the top level*, effectively removing the nesting and allowing each > contained form to be compiled and evaluated before compiling the next one. > Macro expansion facilities other than the compiler (e.g., in an editor or > debugger) may not duplicate that subtle behavior so the expansions they > produce may not accurately reflect the expansion that will be produced and > seen by the compiler. There may be contexts where that causes trouble at > development time. > > > I’m not aware of these being used anywhere in other than experimental/POC > code. > > > —Steve > > -- > 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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: clojure.spec bug?
You can file a jira on this.
On Saturday, December 31, 2016 at 10:16:00 AM UTC-6, miner wrote:
>
>
> On Dec 30, 2016, at 9:42 AM, John Schmidt
> wrote:
>
> (s/def ::game1 #(satisfies? Game %))
> (s/def ::game2 (partial satisfies? Game))
>
>
> (s/explain ::game2 (spec-test.foo/->Foo))
> val: #spec_test.foo.Foo{} fails spec: :spec-test.core/game2 predicate:
> (partial satisfies? Game) < WAT
> nil
>
>
> It looks like the spec macros aren’t resolving the Game reference in the
> game2 spec. You can use macroexpand-1 to see what was happening at the
> top-level. The internal macros get a little complicated so I can’t say if
> code expressions like this were intended to work. It doesn’t hurt to file
> a bug.
>
> I think the usual way to write this would be to define your own little
> predicate first and then use that var in the spec.
>
> (def my-game? (partial satisfies? Game))
>
> (s/def ::game3 my-game?)
>
> If you want to work around the immediate issue, try using the fully
> qualified symbol for the protocol. (I prefer ::game3 FWIW.)
>
> (s/def ::game4 (partial satisfies? spec-test.core/Game))
>
>
>
>
>
>
>
--
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: Order preservation and duplicate removal policy in `distinct`
Replying to many things in this thread at once here... Re lazy sequences, I think you can take it as implicit and rely on the input seq order is retained (same as other sequence functions). Re duplicates, the current implementation retains the first element, but as mentioned this is not stated in the doc string (so probably should not be something you rely upon). "Equality" in this case is based upon set contains? checks, which ultimately use Clojure's "equiv" notion of equality (NOT Java's .equals). In general for Clojure, equality is based on values and two duplicate values will be indistinguishable. However, two cases where that might not be the case are when they have meta (which is not considered in equality) or if they are arbitrary Java objects (which fall back to .equals behavior). If you wanted to file a jira on anything here, a jira to add a line to the doc string stating that the first duplicate is kept would be the only thing possibly worth doing. Alex On Wednesday, December 28, 2016 at 10:22:53 AM UTC-6, Mike Rodriguez wrote: > > The doc for `distinct` is: > "Returns a lazy sequence of the elements of coll with duplicates removed. > Returns a stateful transducer when no collection is provided." > > (1) In the lazy sequence case, I've thought that maybe it is assuemd there > is a guarantee that the order of the input seq is preserved. However, this > isn't stated. Is this an assumption to rely on for `distinct` and, more > generally, the Clojure seq-based API functions? > > (2) In either case, when there are duplicates, there do not seem to be any > guarantees on which one of the duplicates will be preserved. Should this > be stated? I'm thinking that maybe this is about Clojure's design > philosophy being that equal values to not ever need to be distinguished > between, so the API doesn't explicitly support this concern. However, > there are times when identity relationships can matter - performance would > be one that comes to mind. > - This has some relationship to the Scala question @ > http://stackoverflow.com/questions/6735568/scala-seqlike-distinct-preserves-order > > There have been a few occasions where I relied on (or wanted to rely on) > (1). I haven't had many cases where (2) matters, but I could see it coming > up on perhaps rare occasions. > > -- 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: maven-shade-plugin issues with Clojure core (or any clj) AOT compilation
This seems like a pretty straightforward bug with maven-shade-plugin not preserving information that it should, so it seems like it should be fixed there. On Wednesday, December 28, 2016 at 7:06:11 AM UTC-6, Mike Rodriguez wrote: > > Background: > > This problem is specific to building jars that contain AOT (Ahead Of Time) > compiled Clojure code using Maven and the maven-shade-plugin. > > Clojure AOT compilation depends on timestamps of .class files vs .clj > files being accurate. When both .class files and their associated .clj > files exist, the AOT .class files are only used by the compiler if their > last modified timestamp is strictly greater than the last modified > timestamp of the associated .clj file. > > Also note that the Clojure core jar itself is deployed AOTed. > > I know that much of the Clojure ecosystem uses Leiningen as a build tool > (and boot now too I guess). This problem doesn't apply to Leiningen (and I > haven't looked at boot). > > Problem: > > The maven-shade-plugin is popular for building shaded/uber/standalone jars > in Maven. Typically this means the jar will include some/all of its > dependency jars' files. The maven-shade-plugin has an unfortunate property > though. It does not preserve the timestamps on files that are added to > this final shaded jar. The resulting jar actually ends up with all files > inside of it having the same timestamp (when the jar was created). In > particular, if you originally had AOT Clojure .class files and .clj files > with different last modified timestamps, now they will have the same > timestamps in the shaded jar. > > I've brought this up before @ > http://stackoverflow.com/questions/19594360/preserving-timestamps-on-clojure-clj-files-when-building-shaded-jar-via-maven-s > > I have rarely seen people bring up issues around this with > maven-shade-plugin beyond this particular case. I believe I have seen a > complaint or two around the timestamp loss during shading (I can't find > them now), but nothing that has gained any traction (I may try to bring it > up to the plugin people soon though). > > When the AOTed .class file is ignored in favor of the .clj file, the > namespace is JIT (Just-In-Time) compiled. There are several issues with > this. > > 1) Performance: It makes the AOT files mostly worthless since they are > not saving you on startup time costs anymore. Everything is JITed anyways. > 2) Errors: The reloading of the .clj files is a forced reload of the .clj > namespaces involved. This can cause classpath clashes among ClassLoaders. > - There are quite a few CLJ Jiras out there that faced trouble dealing > with the mix of reloading namespaces and AOT compilation. > > You may be thinking, "Just don't build your Clojure jars with Maven. Use > Leiningen instead perhaps?" > This is fine when it is something you control. However, what if I want to > use Clojure to develop a library that may be consumed by Java consumers who > very likely will be using Maven. If my library is going to be shaded into > a standalone jar with maven-shade-plugin by this Java consumer (again, > likely) then this scenario can happen. > > Another thought that may occur is to just avoid AOT compilation of my > library application to avoid the problem (this is recommended in the > community I believe). However, Clojure core is AOT compiled and it will > get included in the shaded jar. That alone is enough to cause the issue. > > Example: > > I have a GitHub repo to show a minimum example of where this can be a > problem. In particular it shows a way for the problem (2) to occur. > @ https://github.com/mrrodriguez/mvn-shade-test > > This repo has a Java API through shade.ShadeJava that will cause the > Clojure compiler to require the shade.main namespace using JIT compilation. > However, shade.main uses clojure.pprint, which is AOT compiled via Clojure > core. > > clojure.pprint was chosen here just because it one of the cases I've seen > come up that actually fail with problem (2) from above. Even if there were > no failures though, the Clojure core namespaces would be getting recompiled > with problem (1). > > -- 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: foo.spec?
There's a Javascript port - https://github.com/prayerslayer/js.spec On Thursday, December 29, 2016 at 12:17:47 PM UTC-6, Rich Morin wrote: > > Does anyone know of efforts to port clojure.spec to other languages? I > thought I had seen someone mention versions for Haskell and Scala, but I > can't find any information on this. FWIW, my interest is in having > elixir.spec and/or ruby.spec... > > -r > -- 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: Cyclic namespace dependencies!
As a counterpoint to this, note that ClojureScript does the same thing (for different reasons, but the same mechanism): https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/core.cljc#L91-L101 On 1 January 2017 at 05:24, Timothy Baldridge wrote: > Be really careful with Potemkin. I've had a lot of build issues > (especially around AOT) with that library. I'll try to put this as kindly > as I can...it's a bit of a hack that leverages some undocumented aspects of > the Clojure API. As such it's been the source of some really weird compile > errors that have taken me many hours to debug. So much so that some > libraries have go so far as to copy-paste certain files from potemkin > (macros around map-like type creation), in order not to get the more > fragile parts of the library (var reorganization). > > In short...the language wasn't designed to do what Potemkin tries to make > it do when it comes to vars. I really recommend against using the library. > > On Sat, Dec 31, 2016 at 7:32 AM, squeegee wrote: > >> >> >> On Friday, December 30, 2016 at 8:59:46 PM UTC-5, puzzler wrote: >>> >>> On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge >>> wrote: >>> I can see that, and even spec has this use case. In Spec it's solved by having both A and B in one namespace and using declare to forward-declare the constructors (or defns in this case). So I guess the way I see it the tradeoff is a declare and all-in-one-namespace vs a massive complexity addition to the compiler and the redefinition of compilation units. The declare method seems like the cleaner route. >>> I wonder whether there could be something like an `external-declare` >>> that would satisfy Rich's concerns about knowing how to intern >>> unencountered vars, while allowing cyclical references when needed. >>> >> >> The macros defined in ‘scarlett.core’ here: https://github.com/scgil >> ardi/scarlett are an experiment along those lines. >> >> *scarlett* >> >> Provides macros to declare vars in namespaces other than *ns* >> >> To be used sparingly to overcome otherwise cyclic namespace dependencies >> >> *Usage* >> >> (ns-declare my-module startup shutdown) >> >> declares my-module/startup and my-module/shutdown >> >> (declare+ module-a/startup module-b/startup) >> >> declares module-a/startup and module-b/startup >> >> >> They work by using “declare” after switching to the target namespace >> using “in-ns” (and switching back at the end). They have to be issued at >> the “top level” (as is highly recommended for ns, declare, def, etc.) to be >> effective and they contain code to notify with an exception if they are >> used at other than the top level. (The exception is preferable to silent >> failure or a confusing error message.) >> >> >> The macros rely on the compiler behavior of handling top-level “do” forms >> in a special way: evaluating each of the contained forms sequentially *at >> the top level*, effectively removing the nesting and allowing each >> contained form to be compiled and evaluated before compiling the next one. >> Macro expansion facilities other than the compiler (e.g., in an editor or >> debugger) may not duplicate that subtle behavior so the expansions they >> produce may not accurately reflect the expansion that will be produced and >> seen by the compiler. There may be contexts where that causes trouble at >> development time. >> >> >> I’m not aware of these being used anywhere in other than experimental/POC >> code. >> >> >> —Steve >> >> -- >> 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. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > 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 > "
Re: Cyclic namespace dependencies!
I think Timothy Baldridge had a great answer. For example, I often have records which use each other's constructors. But you can put your factoy methods in a map of dependencies. I generally have a build function which takes a hash map as an argument, associates the various data and functions that other modules depend on, and returns the updated hashmap. Each module has such a function and at the top level I build the composite map with the modules I'll be using. Not only does this eliminate those nasty cyclic dependencies, it allows me to easily swap different implementations by just changing the choice of build functions to call at the top level. -- 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] Instaparse 1.4.5
Mark, Thanks for the 1.4.5 fixes; defparser is now working properly with clojure.java.io/resources and :auto-whitespace in my compiler. :) On Fri, Dec 30, 2016 at 04:02:02PM -0800, Mark Engelberg wrote: > Instaparse is a library for generating parsers from context-free grammars. > https://github.com/engelberg/instaparse > > This new release fixes a regression reported in 1.4.4, released last week, > involving the application of `insta/parser` to a URL. > > Also, 1.4.4's new macro `defparser` now properly supports all the relevant > optional parameters from the function `parser`, as suggested by user Jeaye > Wilkerson. > > Thanks to Alex Engelberg for implementing these fixes/enhancements: > https://github.com/Engelberg/instaparse/pull/151 > > -- > 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. -- 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. signature.asc Description: PGP signature
