[ANN] tools.deps.alpha 0.6.488 and clj 1.10.0.414
tools.deps.alpha 0.6.488 and clj 1.10.0.414 are now available. Changes: * TDEPS-114 Canonicalize Maven RELEASE or LATEST version marker * Error handling improvements for unresolvable Maven versions If on Mac, use `brew upgrade clojure` or on Linux see https://clojure.org/guides/getting_started for updated scripts. -- 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] tools.deps.alpha 0.6.488 and clj 1.10.0.414
Does it take some time for the brew repo to update? I'm getting this: (! 520)-> brew upgrade clojure Error: clojure 1.10.0.411 already installed And brew update says everything is up to date. Sean On Wednesday, February 13, 2019 at 12:19:03 PM UTC-8, Alex Miller wrote: > > tools.deps.alpha 0.6.488 and clj 1.10.0.414 are now available. > > Changes: > > * TDEPS-114 Canonicalize Maven RELEASE or LATEST version marker > * Error handling improvements for unresolvable Maven versions > > If on Mac, use `brew upgrade clojure` or on Linux see > https://clojure.org/guides/getting_started for updated scripts. > -- 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] tools.deps.alpha 0.6.488 and clj 1.10.0.414
Oh, I mistakenly misread the successful test pass as a merge. Should be available in the next half day or so. (Or just watch https://github.com/Homebrew/homebrew-core/pull/36964) On Wednesday, February 13, 2019 at 3:27:00 PM UTC-6, Sean Corfield wrote: > > Does it take some time for the brew repo to update? I'm getting this: > > (! 520)-> brew upgrade clojure > Error: clojure 1.10.0.411 already installed > > > And brew update says everything is up to date. > > Sean > > On Wednesday, February 13, 2019 at 12:19:03 PM UTC-8, Alex Miller wrote: >> >> tools.deps.alpha 0.6.488 and clj 1.10.0.414 are now available. >> >> Changes: >> >> * TDEPS-114 Canonicalize Maven RELEASE or LATEST version marker >> * Error handling improvements for unresolvable Maven versions >> >> If on Mac, use `brew upgrade clojure` or on Linux see >> https://clojure.org/guides/getting_started for updated scripts. >> > -- 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.
Compiling with load instead of compile?
Hey all, I've been working on internal build tools where I work, and when looking into how other build tools like lein do their aot :all compilation, it seems that they all rely on some brittle namespace finder library, which searches either the classpath, or a folder of files and tries to identity all the ns declarations. >From that, they call compile in a loop for every namespace they found. But, compile just goes ahead and converts the namespace into a resource path in a very brittle way, just replaces dots for forward slashes, and dashes by underscores. That's because, `load-one` is actually used to compile, which internally relies on `load`. Load takes a resource path which needs to be found on the classpath, not a namespace. Now, there are some packages which have source files that have either a different ns name then their file name, or they use in-ns and are actually evaluating into an existing namespace defined in another file. Lein actually fails to compile these, because the namespace it finds are looked up as resources on the classpath by compile and it can't find the resource, because the resource path does not match the namespace. So, for my build tool aot :all compilation, I decided to instead use `load` with *compile-files* bound to true. And I just convert each source file in the source dir to a classpath resource path. >From my perspective, this seems a better way to do it, that is more reliable, and frankly a lot simpler. But since no one else did it this way, I'm curious if there is any known issue with this approach? Regards! -- 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: Compiling with load instead of compile?
On Wednesday, February 13, 2019 at 7:46:43 PM UTC-6, Didier wrote: > > Hey all, > > I've been working on internal build tools where I work, and when looking > into how other build tools like lein do their aot :all compilation, it > seems that they all rely on some brittle namespace finder library, which > searches either the classpath, or a folder of files and tries to identity > all the ns declarations. > Or you use a hard-coded list (like the Clojure build itself). > From that, they call compile in a loop for every namespace they found. > But, compile just goes ahead and converts the namespace into a resource > path in a very brittle way, just replaces dots for forward slashes, and > dashes by underscores. > This is exactly the algorithm used by the runtime to load every Clojure namespace, so I don't think this particular part is brittle at all. > That's because, `load-one` is actually used to compile, which internally > relies on `load`. Load takes a resource path which needs to be found on the > classpath, not a namespace. > > Now, there are some packages which have source files that have either a > different ns name then their file name > This is pretty rare as it's impossible for the runtime to load it in the normal way when required (it must be explicitly loaded via one of the load methods). > , or they use in-ns and are actually evaluating into an existing namespace > defined in another file. > Slightly more common, but still comparatively rare to the very common case of 1 ns per file. (clojure itself does this a number of times) > Lein actually fails to compile these, because the namespace it finds are > looked up as resources on the classpath by compile and it can't find the > resource, because the resource path does not match the namespace. > > So, for my build tool aot :all compilation, I decided to instead use > `load` with *compile-files* bound to true. And I just convert each source > file in the source dir to a classpath resource path. > > From my perspective, this seems a better way to do it, that is more > reliable, and frankly a lot simpler. But since no one > else did it this way, I'm curious if there is any known issue with this > approach? > Seems like a reasonable alternative to me. > Regards! > -- 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: Compiling with load instead of compile?
Awesome, thanks! Ya, I guess in that sense root-resource isn't brittle. I meant it more, brittle in the context of what other build tools were doing/assuming. Like when load-one converts a namespace into its corresponding root resource, its not smart. It's just a string replace. So if the namespace name differs from the filename, root-resource isn't actually able to find the resource for the corresponding namespace. Anyways, thanks for the response! On Wednesday, 13 February 2019 19:33:19 UTC-8, Alex Miller wrote: > > > > On Wednesday, February 13, 2019 at 7:46:43 PM UTC-6, Didier wrote: >> >> Hey all, >> >> I've been working on internal build tools where I work, and when looking >> into how other build tools like lein do their aot :all compilation, it >> seems that they all rely on some brittle namespace finder library, which >> searches either the classpath, or a folder of files and tries to identity >> all the ns declarations. >> > > Or you use a hard-coded list (like the Clojure build itself). > > >> From that, they call compile in a loop for every namespace they found. >> But, compile just goes ahead and converts the namespace into a resource >> path in a very brittle way, just replaces dots for forward slashes, and >> dashes by underscores. >> > > This is exactly the algorithm used by the runtime to load every Clojure > namespace, so I don't think this particular part is brittle at all. > > >> That's because, `load-one` is actually used to compile, which internally >> relies on `load`. Load takes a resource path which needs to be found on the >> classpath, not a namespace. >> >> Now, there are some packages which have source files that have either a >> different ns name then their file name >> > > This is pretty rare as it's impossible for the runtime to load it in the > normal way when required (it must be explicitly loaded via one of the load > methods). > > >> , or they use in-ns and are actually evaluating into an existing >> namespace defined in another file. >> > > Slightly more common, but still comparatively rare to the very common case > of 1 ns per file. (clojure itself does this a number of times) > > >> Lein actually fails to compile these, because the namespace it finds are >> looked up as resources on the classpath by compile and it can't find the >> resource, because the resource path does not match the namespace. >> >> So, for my build tool aot :all compilation, I decided to instead use >> `load` with *compile-files* bound to true. And I just convert each source >> file in the source dir to a classpath resource path. >> >> From my perspective, this seems a better way to do it, that is more >> reliable, and frankly a lot simpler. But since no one >> > else did it this way, I'm curious if there is any known issue with this >> approach? >> > > Seems like a reasonable alternative to me. > > >> Regards! >> > -- 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.
