[ClojureScript] Re: goog component stylesheets
On Monday, December 12, 2016 at 2:21:20 PM UTC-6, Elric Erkose wrote: > I was playing with goog.ui.editor.DefaultToolbar.makeToolbar. It doesn't > render properly because, among others, I'm missing the button stylesheet. Is > anyone aware of a cdn that provides the goog stylesheets? I am unaware of any cdn, but the css for the google closure library components is included in the closure-library jar under the "goog.css" package (so inside a jar named "google-closure-library-#.#-TIME-COMMIT.jar, under the goog/css directory in that jar). This jar is a dependency of clojurescript, so if you have clojurescript in your classpath you will also have this. (There is some other css at css.inlay, I don't remember that it is for.) If you have some kind of ring handler serving static assets off your classpath when you run clojurescript, you should be able to serve this css off the same process. The css will be at "/goog/css/", possibly with some prefix. It's been a long time since I used google closure components, so I don't remember how the components got their required css. I think you had to match it up manually and make sure you had the right link rel=stylesheet elements set up, absent some tooling (plovr?) that did it for you. I don't mean to discourage your experimentation, but the modern clojurescript ui libraries (especially the react-based ones like re-frame, reagent, rum, om, om.next, etc) are all much, much nicer to work with than the google closure component system. Our company made some heroic efforts to use them and to write our own components, both from JS and later from clojurescript, but after react came out we switched and never looked back. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Re: where is the format function
goog.string.format definitely still exists: http://google.github.io/closure-library/api/goog.string.format.html goog.string also has many specialized formatting functions. For example, for leading zeros, use goog.string/padNumber: http://google.github.io/closure-library/api/goog.string.html#padNumber On Monday, September 12, 2016 at 9:05:05 AM UTC-5, Karel Miarka wrote: > Have you already found the answer? Could you please share it? > > On Thursday, May 1, 2014 at 5:26:40 AM UTC+2, Yehonathan Sharvit wrote: > > It seems that “format” has been removed from cljs. > > > > It was added 2 years ago in > > https://github.com/clojure/clojurescript/commit/8f518760a3df8b351208e97bb70270856623bb0a > > > > > > > > > > Also, goog.string.format is not available any more. > > > > > > > > My question is: what is the best way to add leading zeros in cljs? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Re: figwheel websocket configuration error?
I don't see a figwheel dependency in your project.clj. Is it a transient dependency of something else? Being able to listen on anything other than localhost is a more recent ability (post 0.5.2). I'm not sure if any released figwheel on clojars supports it. The reason I am not sure is there are no github releases or git version tags after 0.5.2 and all the clojars links to release versions link to HEAD, so I don't know what's in 0.5.3 and up. On Friday, June 3, 2016 at 1:42:30 PM UTC-5, Federico Marani wrote: > Hi all, > > I am having some trouble configuring figwheel to be visible from another > computer in my network. I configured it to listen to 0.0.0.0, but the > websocket handler does not connect correctly. Anyone able to give me a hint > on where the problem might be? > > this is my project.clj - http://pastebin.com/PQG49FzG > > Thks -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Re: Reuse Protocol Implementations Across Many Types
It is annoying that extend does not exist in Clojurescript. The implementation
of protocols has changed some since that post, but I'm not sure if that changed
extend's feasibility.
In the meantime, you are not doing anything so dynamic that you cannot do it
with extend-type. To share implementations, just make a function and call it
from within the protocol implementation:
(defn contents-impl [value]
(map (fn [[key value]] (MyMapEntry. key value)) value))
(extend-type PersistentArrayMap
Styled
(contents [value] (contents-impl value)))
On Wednesday, May 4, 2016 at 10:31:02 AM UTC-5, Nate Young wrote:
> I have a protocol that a generic rendering method uses:
>
>
> ```
> (defprotocol Styled
> (css-class [this])
> (contents [this]))
> ```
>
>
> and I want plain cljs maps to implement it. As I have constantly re-learned,
> there are two map types, so I currently have two `extend-type` clauses:
>
>
> ```
> (extend-type PersistentArrayMap
> Styled
> (css-class [_]
> "fig-map")
>
>
> (contents [value]
> (map (fn [[key value]]
> (MyMapEntry. key value))
> value)))
>
>
> (extend-type PersistentHashMap
> Styled
> (css-class [_]
> "fig-map")
>
>
> (contents [value]
> (map (fn [[key value]]
> (MyMapEntry. key value))
> value)))
> ```
>
>
> but this makes changes to how maps implement `Styled` a bit perilous and
> tedious. In Java-land, I could lean on `clojure.core/extend`:
>
>
> ```
> (let [map-styled
> {:css-class (constantly "fig-map")
> :contents (fn [value]
> (map (fn [[key value]]
> (MapEntry. key value))
> value))}]
> (extend PersistentArrayMap
> Styled
> map-styled)
>
>
> (extend PersistentHashMap
> Styled
> map-styled))
> ```
>
>
> but this doesn't appear to be a thing in ClojureScript.
>
>
> Is there a language feature that allows for concise reuse of protocol
> implementations across types? Or am I abusing protocols/creating my own
> problems by attempting to extend the myriad built-in Clojure types to a
> protocol? (and how should I be framing a solution)?
>
>
>
>
> I did find this mailing list topic from a few years back:
> https://groups.google.com/forum/#!topic/clojurescript/GZypP_YV4l0
> which I read as saying that `extend` is tricky to implement (and I think
> `specify` might be missing the mark for my use case).
>
>
> Thanks!
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: ClojureScript and multi-page website
And obviously when I said "websockets" above I meant "webworkers"! On Fri, Feb 26, 2016 at 7:29 PM, Francis Avila <fav...@breezeehr.com> wrote: > Don't forget the reference documentation: > https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules > > On Fri, Feb 26, 2016 at 6:07 PM, J David Eisenberg < > jdavid.eisenb...@gmail.com> wrote: > >> On Friday, February 26, 2016 at 2:52:28 PM UTC-8, Francis Avila wrote: >> > I think what you want are multiple Google Closure modules: >> http://swannodette.github.io/2015/02/23/hello-google-closure-modules/ >> > >> > Make a single project for all pages, place each page's entry point into >> a separate namespace and an independent module, and then on each html page >> include the common module followed by the page-specific module. The Closure >> (not cloJure!) compiler will work out the js dependency graph and move code >> among the files optimally so you only have as much javascript per page as >> you need. >> > >> > This technique also works great with websockets: have browser-thread >> entrypoints in their own module and websocket entry points in another >> module. If you make sure the websocket entry points can't reach code that >> uses browser objects (like document or window) everything will Just Work. >> >> Thank you; it seems that this will do what I want, and the article about >> it arrived JIT. :) >> >> > >> > On Friday, February 26, 2016 at 3:31:23 PM UTC-6, J David Eisenberg >> wrote: >> > > I'm working on a web site which, for various reasons, achieves its >> purpose best with multiple pages rather than as a single-page app. All the >> pages will need to share some code in common. >> > > >> > > In a plain vanilla JS environment, I could do something like this on >> page1.html: >> > > >> > > >> > > >> > > >> > > and something similar on page2.html (with
Re: [ClojureScript] Re: ClojureScript and multi-page website
Don't forget the reference documentation: https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules On Fri, Feb 26, 2016 at 6:07 PM, J David Eisenberg < jdavid.eisenb...@gmail.com> wrote: > On Friday, February 26, 2016 at 2:52:28 PM UTC-8, Francis Avila wrote: > > I think what you want are multiple Google Closure modules: > http://swannodette.github.io/2015/02/23/hello-google-closure-modules/ > > > > Make a single project for all pages, place each page's entry point into > a separate namespace and an independent module, and then on each html page > include the common module followed by the page-specific module. The Closure > (not cloJure!) compiler will work out the js dependency graph and move code > among the files optimally so you only have as much javascript per page as > you need. > > > > This technique also works great with websockets: have browser-thread > entrypoints in their own module and websocket entry points in another > module. If you make sure the websocket entry points can't reach code that > uses browser objects (like document or window) everything will Just Work. > > Thank you; it seems that this will do what I want, and the article about > it arrived JIT. :) > > > > > On Friday, February 26, 2016 at 3:31:23 PM UTC-6, J David Eisenberg > wrote: > > > I'm working on a web site which, for various reasons, achieves its > purpose best with multiple pages rather than as a single-page app. All the > pages will need to share some code in common. > > > > > > In a plain vanilla JS environment, I could do something like this on > page1.html: > > > > > > > > > > > > > > > and something similar on page2.html (with
Re: [ClojureScript] Re: Clojurescript string equivalence in Chrome
Issue added to v8: https://bugs.chromium.org/p/v8/issues/detail?id=4773 On Sunday, February 21, 2016 at 2:21:12 PM UTC-6, Stephen Nelson wrote: > Great job finding and analysing that. I think the appropriate place to report > upstream is https://bugs.chromium.org/p/v8/issues/list. Seeing as you did the > hard work of finding a javascript reproduction you should submit it and get > the credit, but I can if you don't want to follow up on it. > > > On Fri, Feb 19, 2016 at 4:47 AM, Francis Avila <fav...@breezeehr.com> wrote: > At http://dev.clojure.org/jira/browse/CLJS-1574 I added a smaller > reproducible case that is pure JS. Basically all you need to do is use > triple-equal with mixed types. The first non-string compare will cause > subsequent string compares to be slow. If you use == instead there is no > slowdown. Clearly a chrome/v8 issue. > > > > This code isn't hot, so it's not related to the higher-tier optimizing JITs. > > > > > > On Tuesday, February 16, 2016 at 7:58:51 PM UTC-6, Stephen Nelson wrote: > > > I've had an interesting day debugging a very strange performance problem in > > Google Chrome. > > > > > > http://dev.clojure.org/jira/browse/CLJS-1574 > > > > > > `` > > > > (test) > > > cljs equiv: 0.005 seconds > > > > (= :added :ns) > > > false > > > > (test) > > > cljs equiv: 1.517 seconds > > > ``` > > > > > > I've never heard of equality causing side-effects before. My suspicion is a > > Chrome JIT bug. Has anyone seen anything like this? > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescrip...@googlegroups.com. > > To post to this group, send email to clojur...@googlegroups.com. > > Visit this group at https://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
[ClojureScript] Re: Clojurescript string equivalence in Chrome
At http://dev.clojure.org/jira/browse/CLJS-1574 I added a smaller reproducible case that is pure JS. Basically all you need to do is use triple-equal with mixed types. The first non-string compare will cause subsequent string compares to be slow. If you use == instead there is no slowdown. Clearly a chrome/v8 issue. This code isn't hot, so it's not related to the higher-tier optimizing JITs. On Tuesday, February 16, 2016 at 7:58:51 PM UTC-6, Stephen Nelson wrote: > I've had an interesting day debugging a very strange performance problem in > Google Chrome. > > http://dev.clojure.org/jira/browse/CLJS-1574 > > `` > > (test) > cljs equiv: 0.005 seconds > > (= :added :ns) > false > > (test) > cljs equiv: 1.517 seconds > ``` > > I've never heard of equality causing side-effects before. My suspicion is a > Chrome JIT bug. Has anyone seen anything like this? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: ANN: ClojureScript 1.7.170, Enhanced Build Pipeline
FYI since this was written lein-figwheel 0.5.0 (not snapshot) was released which fixes this dependency problem, so specifying cljs manually in :plugins is no longer necessary. I imagine the figwheel snapshot was somehow either running the compiler in the wrong environment (i.e. the leinigen plugin process instead of the project process), or was rewriting the project process's dependencies incorrectly before running itself in the project context. On Monday, November 16, 2015 at 3:14:46 PM UTC-6, Daniel Compton wrote: > Can someone explain why it's necessary to manually add a dependency on > clojurescript in the :plugins vector? > > > :plugins [[lein-figwheel "0.5.0-SNAPSHOT"] > [org.clojure/clojurescript "1.7.170"]] ;; Overrides broken > lein-figwheel dependency. > > > Shouldn't the version of ClojureScript specified in :dependencies always be > used? > > > On Wed, Nov 11, 2015 at 3:18 AM Andreas Liljeqvist <bon...@gmail.com> wrote: > > Works without problem with boot-cljs. > Roughly 20% decrease in compilation time. > > > Great work. > > > On Mon, Nov 9, 2015 at 7:24 PM Francis Avila <fav...@breezeehr.com> wrote: > > > Debug dependency problems with `lein deps :plugin-tree` and `:tree`. These > show you what your actual dependencies are and why. > > Sent from my iPhone > > > On Nov 9, 2015, at 12:15 PM, David Nolen <dnolen...@gmail.com> wrote: > > > > > It appears one of your dependencies is pulling in an older version of Clojure. > > > David > > > On Mon, Nov 9, 2015 at 11:03 AM, David Petrovics <dpetr...@gmail.com> wrote: > Hi Francis, > > > > I tried figwheel 0.5.0-SNAPSHOT, got the (No such var: ana/forms-seq*) > exception, then added [org.clojure/clojurescript "1.7.170"] to the plugins > and am now seeing: > > > > java.io.FileNotFoundException: Could not locate cljs/analyzer__init.class or > cljs/analyzer.clj on classpath: , compiling:(figwheel_sidecar/utils.clj:1:1) > > > > I'm on [lein-cljsbuild "1.1.1"], [org.clojure/clojurescript "1.7.170"], > [org.clojure/clojure "1.7.0"], [org.omcljs/om "0.8.8"], > [lein-figwheel "0.5.0-SNAPSHOT"] > > > > Thanks! > > > > > > On Saturday, November 7, 2015 at 5:44:03 AM UTC-5, Francis Avila wrote: > > > For future travelers. > > > > > > If you use figwheel 0.5.0-SNAPSHOT you will get this exception: > > > > > > > > > clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: No > > such var: ana/forms-seq*, compiling:(figwheel_sidecar/utils.clj:49:21) > > > > > > figwheel 0.5.0-SNAPSHOT has a dependency on cljs 1.7.145 even though it > > needs 1.7.170. > > > > > > To resolve this error you must explicitly depend on clojurescript in your > > plugins. Example: > > > > > > :plugins [[lein-figwheel "0.5.0-SNAPSHOT"] > > > [org.clojure/clojurescript "1.7.170"]] ;; Overrides broken > >lein-figwheel dependency. > > > > > > lein deps :tree shows cljs 1.7.170 is used. > > > > > > So, > > > > > > > > > > > > On Saturday, November 7, 2015 at 3:30:05 AM UTC-6, Maria Geller wrote: > > > > Try using 0.5.0-SNAPSHOT for figwheel ;) > > > > > > > > On Saturday, November 7, 2015 at 9:59:24 PM UTC+13, Francis Avila > > > wrote:I'm getting the following exception with figwheel builds (using > > > 0.4.1): > > > > > > > > > > > > > > > > java.lang.AbstractMethodError: Method > > > clojurescript_build/core/CompilableSourcePaths._find_sources(Ljava/lang/Object;)Ljava/lang/Object; > > > is abstract > > > > > > > > at clojurescript_build.core.CompilableSourcePaths._find_sources > > > (core.clj:-1) > > > > > > > > > > > > > > > > > > > > > > > > (cljsbuild works fine with version 1.1.1) > > > > > > > > > > > > > > > > Nolan said "All the mentioned tools [inc. figwheel] have already > > > accounted for this change." I don't see any mention in the figwheel docs > > > about cljs 1.7.170 compatibility or any commit message that mentions it. > > > Can anyone confirm this is actually true for figwheel? > > > > >
Re: [ClojureScript] Re: ANN: ClojureScript 1.7.170, Enhanced Build Pipeline
Debug dependency problems with `lein deps :plugin-tree` and `:tree`. These show you what your actual dependencies are and why. Sent from my iPhone > On Nov 9, 2015, at 12:15 PM, David Nolen <dnolen.li...@gmail.com> wrote: > > It appears one of your dependencies is pulling in an older version of Clojure. > > David > >> On Mon, Nov 9, 2015 at 11:03 AM, David Petrovics <dpetrov...@gmail.com> >> wrote: >> Hi Francis, >> >> I tried figwheel 0.5.0-SNAPSHOT, got the (No such var: ana/forms-seq*) >> exception, then added [org.clojure/clojurescript "1.7.170"] to the plugins >> and am now seeing: >> >> java.io.FileNotFoundException: Could not locate cljs/analyzer__init.class or >> cljs/analyzer.clj on classpath: , compiling:(figwheel_sidecar/utils.clj:1:1) >> >> I'm on [lein-cljsbuild "1.1.1"], [org.clojure/clojurescript "1.7.170"], >> [org.clojure/clojure "1.7.0"], [org.omcljs/om >> "0.8.8"], [lein-figwheel "0.5.0-SNAPSHOT"] >> >> Thanks! >> >> On Saturday, November 7, 2015 at 5:44:03 AM UTC-5, Francis Avila wrote: >> > For future travelers. >> > >> > If you use figwheel 0.5.0-SNAPSHOT you will get this exception: >> > >> > >> > clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: No >> > such var: ana/forms-seq*, compiling:(figwheel_sidecar/utils.clj:49:21) >> > >> > figwheel 0.5.0-SNAPSHOT has a dependency on cljs 1.7.145 even though it >> > needs 1.7.170. >> > >> > To resolve this error you must explicitly depend on clojurescript in your >> > plugins. Example: >> > >> > :plugins [[lein-figwheel "0.5.0-SNAPSHOT"] >> > [org.clojure/clojurescript "1.7.170"]] ;; Overrides broken >> > lein-figwheel dependency. >> > >> > lein deps :tree shows cljs 1.7.170 is used. >> > >> > So, >> > >> > >> > >> > On Saturday, November 7, 2015 at 3:30:05 AM UTC-6, Maria Geller wrote: >> > > Try using 0.5.0-SNAPSHOT for figwheel ;) >> > > >> > > On Saturday, November 7, 2015 at 9:59:24 PM UTC+13, Francis Avila >> > > wrote:I'm getting the following exception with figwheel builds (using >> > > 0.4.1): >> > > >> > > >> > > >> > > java.lang.AbstractMethodError: Method >> > > clojurescript_build/core/CompilableSourcePaths._find_sources(Ljava/lang/Object;)Ljava/lang/Object; >> > > is abstract >> > > >> > > at clojurescript_build.core.CompilableSourcePaths._find_sources >> > > (core.clj:-1) >> > > >> > > >> > > >> > > >> > > >> > > (cljsbuild works fine with version 1.1.1) >> > > >> > > >> > > >> > > Nolan said "All the mentioned tools [inc. figwheel] have already >> > > accounted for this change." I don't see any mention in the figwheel docs >> > > about cljs 1.7.170 compatibility or any commit message that mentions it. >> > > Can anyone confirm this is actually true for figwheel? >> > > >> > > >> > > >> > > On Friday, November 6, 2015 at 6:05:19 AM UTC-6, David Nolen wrote: >> > > >> > > > ClojureScript, the Clojure compiler that emits JavaScript source code. >> > > >> > > > >> > > >> > > > >> > > >> > > > README and source code: https://github.com/clojure/clojurescript >> > > >> > > > >> > > >> > > > >> > > >> > > > Leiningen dependency information: >> > > >> > > > >> > > >> > > > >> > > >> > > > [org.clojure/clojurescript "1.7.170"] >> > > >> > > > >> > > >> > > > >> > > >> > > > This release includes a major refactor of the build pipeline thanks to >> > > >> > > > Juho Teperi. This change along with some greatly simplified >> > > >> > > > recompilation logic will mean much faster cold build times for larger >> > > >> > > > projects (some users have already reported >10X). >> > > >> > > > >> > > >> > > > >> > > >&
[ClojureScript] Re: ANN: ClojureScript 1.7.170, Enhanced Build Pipeline
For future travelers. If you use figwheel 0.5.0-SNAPSHOT you will get this exception: clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: No such var: ana/forms-seq*, compiling:(figwheel_sidecar/utils.clj:49:21) figwheel 0.5.0-SNAPSHOT has a dependency on cljs 1.7.145 even though it needs 1.7.170. To resolve this error you must explicitly depend on clojurescript in your plugins. Example: :plugins [[lein-figwheel "0.5.0-SNAPSHOT"] [org.clojure/clojurescript "1.7.170"]] ;; Overrides broken lein-figwheel dependency. lein deps :tree shows cljs 1.7.170 is used. So, On Saturday, November 7, 2015 at 3:30:05 AM UTC-6, Maria Geller wrote: > Try using 0.5.0-SNAPSHOT for figwheel ;) > > On Saturday, November 7, 2015 at 9:59:24 PM UTC+13, Francis Avila wrote:I'm > getting the following exception with figwheel builds (using 0.4.1): > > > > java.lang.AbstractMethodError: Method > clojurescript_build/core/CompilableSourcePaths._find_sources(Ljava/lang/Object;)Ljava/lang/Object; > is abstract > > at clojurescript_build.core.CompilableSourcePaths._find_sources (core.clj:-1) > > > > > > (cljsbuild works fine with version 1.1.1) > > > > Nolan said "All the mentioned tools [inc. figwheel] have already accounted > for this change." I don't see any mention in the figwheel docs about cljs > 1.7.170 compatibility or any commit message that mentions it. Can anyone > confirm this is actually true for figwheel? > > > > On Friday, November 6, 2015 at 6:05:19 AM UTC-6, David Nolen wrote: > > > ClojureScript, the Clojure compiler that emits JavaScript source code. > > > > > > > > > README and source code: https://github.com/clojure/clojurescript > > > > > > > > > Leiningen dependency information: > > > > > > > > > [org.clojure/clojurescript "1.7.170"] > > > > > > > > > This release includes a major refactor of the build pipeline thanks to > > > Juho Teperi. This change along with some greatly simplified > > > recompilation logic will mean much faster cold build times for larger > > > projects (some users have already reported >10X). > > > > > > > > > This is a breaking change for existing tooling. You will need to > > > upgrade lein-cljsbuild, lein-figwheel, and boot-cljs if you intend to > > > adopt this version of ClojureScript. All the mentioned tools have > > > already accounted for this change. Refer to the appropriate > > > documentation for your tooling to determine which version number you > > > should adopt. > > > > > > > > > Other interesting changes and fixes include newer Google Closure > > > Compiler and Library dependencies, self hosting tweaks, a Google > > > Closure modules (:modules compiler option) regression, > > > improved warnings, and minor REPL enhancements. > > > > > > > > > As always feedback welcome! > > > > > > > > > ### Enhancements > > > * Refactor build pipeline > > > * CLJS-1478: Self-host: Allow static-fns opt > > > > > > > > > ### Changes > > > * Generate larger range of random UUIDs > > > * make browser REPL file reloads less chatty > > > * CLJS-1475: indicate that cljs.reader/read is safe > > > * CLJS-1470: Bump GCL Dependency > > > * bump Google Closure dep > > > > > > > > > ### Fixes > > > * in system-time check that js/process.hrtime is actually a thing > > > * CLJS-1228: cljs.util/topo-sort is polynomial on larger dependency graphs > > > * check that performance.now method actually exists > > > * CLJS-1476: Self-host: Protocol prefixing broken for three- (or more) > > segment namespaces > > > * CLJS-1472 Patch for CLJS-1467 causes regression for nodejscli > > > * CLJS-1469 :modules regression > > > * CLJS-1445: Syntax error for var args in protocol methods > > > * Warn if protocol impl methods do not match its protocol > > > * CLJS-1451 Protocol impl do not support qualified method names > > > * CLJS-1422: cljs.js/eval-str fails for ns form on node.js with simple > > optimizations > > > * CLJS-1423: self-host: Requiring analyzer/compiler breaks unchecked Boolean > > > * CLJS-1466: Improperly munged output path for GClosure JavaScript > > > * CLJS-1467: Foreign Libraries not included when using :main with :simple > > or :advanced -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: ClojureScript 1.7.170, Enhanced Build Pipeline
I'm getting the following exception with figwheel builds (using 0.4.1): java.lang.AbstractMethodError: Method clojurescript_build/core/CompilableSourcePaths._find_sources(Ljava/lang/Object;)Ljava/lang/Object; is abstract at clojurescript_build.core.CompilableSourcePaths._find_sources (core.clj:-1) (cljsbuild works fine with version 1.1.1) Nolan said "All the mentioned tools [inc. figwheel] have already accounted for this change." I don't see any mention in the figwheel docs about cljs 1.7.170 compatibility or any commit message that mentions it. Can anyone confirm this is actually true for figwheel? On Friday, November 6, 2015 at 6:05:19 AM UTC-6, David Nolen wrote: > ClojureScript, the Clojure compiler that emits JavaScript source code. > > > README and source code: https://github.com/clojure/clojurescript > > > Leiningen dependency information: > > > [org.clojure/clojurescript "1.7.170"] > > > This release includes a major refactor of the build pipeline thanks to > Juho Teperi. This change along with some greatly simplified > recompilation logic will mean much faster cold build times for larger > projects (some users have already reported >10X). > > > This is a breaking change for existing tooling. You will need to > upgrade lein-cljsbuild, lein-figwheel, and boot-cljs if you intend to > adopt this version of ClojureScript. All the mentioned tools have > already accounted for this change. Refer to the appropriate > documentation for your tooling to determine which version number you > should adopt. > > > Other interesting changes and fixes include newer Google Closure > Compiler and Library dependencies, self hosting tweaks, a Google > Closure modules (:modules compiler option) regression, > improved warnings, and minor REPL enhancements. > > > As always feedback welcome! > > > ### Enhancements > * Refactor build pipeline > * CLJS-1478: Self-host: Allow static-fns opt > > > ### Changes > * Generate larger range of random UUIDs > * make browser REPL file reloads less chatty > * CLJS-1475: indicate that cljs.reader/read is safe > * CLJS-1470: Bump GCL Dependency > * bump Google Closure dep > > > ### Fixes > * in system-time check that js/process.hrtime is actually a thing > * CLJS-1228: cljs.util/topo-sort is polynomial on larger dependency graphs > * check that performance.now method actually exists > * CLJS-1476: Self-host: Protocol prefixing broken for three- (or more) > segment namespaces > * CLJS-1472 Patch for CLJS-1467 causes regression for nodejscli > * CLJS-1469 :modules regression > * CLJS-1445: Syntax error for var args in protocol methods > * Warn if protocol impl methods do not match its protocol > * CLJS-1451 Protocol impl do not support qualified method names > * CLJS-1422: cljs.js/eval-str fails for ns form on node.js with simple > optimizations > * CLJS-1423: self-host: Requiring analyzer/compiler breaks unchecked Boolean > * CLJS-1466: Improperly munged output path for GClosure JavaScript > * CLJS-1467: Foreign Libraries not included when using :main with :simple or > :advanced -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Trouble with core.async and/or WebSockets on Chrome/Android.
On Wednesday, October 14, 2015 at 10:30:04 PM UTC-5, Fenton Travers wrote: > Has anyone done WebSockets and core.async successful on mobile browser: > Android+Chrome? > > Google, suggests that WebSockets are supported on, but for some reason the > combo is not working in my cell phone. Hmmm... We have done this successfully with production applications, but only very recent android versions support WebSockets. Note the supported versions here: http://caniuse.com/#feat=websockets -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Extending protocol to an existing JavaScript type
Extending a protocol to one of the global JS objects is bad for the same reason
it is bad in Javascript: you are modifying a global object. Your
extend-protocol is like saying Function.prototype.FOO_foo = function(this,
arg){...} in javascript. (The "FOO_foo" is a long namespaced and mangled
property name, but you are still modifying the global.)
You can extend "function" (and "object", "number", "string", "array", and
"boolean") instead of js/Function (or js/Object, etc). This will implement the
protocol from the "outside" (doing type checks on its argument) instead of
assigning a new member to the global's prototype. E.g.:
(extend-protocol Foo
function
(foo [this] (println this)))
I'm not sure if you also need to extend IFn: I think "function" means only
native js functions and not clojurescript objects implementing IFn. (Test with
a multi-arity cljs function to verify.)
You can also extend the "default" type, which means everything will implement
the protocol that doesn't have a more specific implementation.
I don't know where these magic protocol type names are documented.
On Thursday, September 3, 2015 at 6:58:48 AM UTC-5, Scott Nelson wrote:
> (defprotocol Foo
> (foo [arg]))
>
> (extend-protocol Foo
> js/Function
> (foo [arg]
> (println arg)))
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Need Help
On Tuesday, August 11, 2015 at 4:00:19 PM UTC-5, Eduard Bondarenko wrote: clj-js can be used? You can, but #js is a reader literal and thus evaluated at compile time: the emitted javascript contains literal JS arrays and objects and no intermediate vectors or maps are created at runtime. cljs-js is runtime: the vectors and maps are created first, then transformed into arrays and objects. Prefer #js when possible. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Need Help
On Tuesday, August 11, 2015 at 2:05:12 AM UTC-5, Eduard Bondarenko wrote:
I think you don't need to nest #js, only one on start. Am I correct?
You are incorrect. In fact, there needs to be one more #js for the vector to
make it a js array. Using threading can clean this up a bit too and make it
read more like the original js:
(defn home-did-mount []
(- (js/$ js/document)
(.ready (fn []
(- (js/$ #example)
(.dataTable #js{:columnDefs
#js[#js{:orderable false
:targets 0}]}))
As for whether this is the best way to use dataTable with reagent, that I am
not sure about. The hardcoded #example is suspicious, probably better to use
a react ref or getDOMNode() instead if reagent exposes this.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] performance tuning cljs
On Friday, August 7, 2015 at 10:45:47 AM UTC-5, ducky wrote: Great post. Regarding boolean type hinting, I believe this is down to an optimisation done while emitting the javascript and not by the closure compiler. Correct. There is an internal function/macro cljs.core/truth_ which implements the boolean semantics of clojure (i.e., undefined, nil and false are falsey, rest truthy). The ^boolean type hint allows the cljs compiler to avoid a emitting a call to truth_ when it knows that the value will have the same truthiness in both clojure and javascript. Clojure and js truthiness differ for 0, (empty-string) and NaN: these are all truthy in cljs and falsy in js. The boolean hint is really for true boolean values (true or false), but if you are desperate for performance somewhere you can cheat if you know it won't be any of these values. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Can I use atom inside the function?
On Monday, June 22, 2015 at 2:45:19 PM UTC-5, marc fawzi wrote: Idioms aside, what is the material benefit of using volatile over a locally scoped atom? I googled a bit and it seems that it has less concurrency guarantees and thus less overhead in Clojure but for ClojureScript is it really any lighter than an atom? Sent from my iPhone In ClojureScript the performance difference is probably marginal. (In Clojure the difference is more pronounced.) Concretely, the Volatile object has only one property (state) instead of the Atom's four (state, metadata, validator function, and watchers) and the vswap! and vreset! macro and function do not have any conditionals for validation or watcher notification. Notice this means volatiles do not support metadata, validators, or watchers. In most situations the advanced-compiled output for vreset! is an inline property set (e.g. my_volatile.state = newval), i.e. the function call is eliminated. This is less likely for an atom's reset! because the compiler may not be able to eliminate the validation and watcher notification code. However this is unlikely to make any difference in real-world usage. Volatiles are as close as one can get to a platform-native mutable local variable in clojure and clojurescript right now. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: Can I use atom inside the function?
On Monday, June 22, 2015 at 5:09:49 PM UTC-5, marc fawzi wrote: It's what I had imagined. So is it fair to say that what is idomatic in Clojure may not be idiomatic in ClojureScript? ClojureScript itself uses volatile! in all its stateful transducer implementations (just like Clojure), which is a pretty strong argument that it is idiomatic cljs. The negligible advantage it offers in ClojureScript does not justify losing the functionality of the atom IMO but I may be wrong Volatile is used in precisely those circumstances where the additional features of atom should *not* be used. Not merely aren't needed, but should be prohibited from use because the state it holds is not meant to be shared. Validation and notification are features to facilitate sharing state. This is to me the advantage it has over an atom in cljs: it makes clear that this is a mutable local that is not meant to escape to the caller or provide access to shared state. Volatile says mutation for speed, not for shared access. Atoms do not signal that by themselves because they are meant for shared access. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Can I use atom inside the function?
Yes, this is fine.
It is slightly more idiomatic to use volatile! (introduced in Clojure 1.7 and
recent ClojureScripts) if you just need local mutation and don't intend on
sharing the atom:
(defn load-url-async
[url success error]
(let [loader (.get http url (fn [res]
(let [buffer (volatile! )]
(.on res data #(vswap! buffer str %))
(.on res end #(success @buffer)))]
(.on loader error error))
On Monday, June 22, 2015 at 11:06:32 AM UTC-5, Honza Břečka wrote:
Hi, I'm not sure if I can rewrite the following piece of JavaScript targeting
node:
var loadUrl = function(url, success, error) {
http.get(url, function(res) {
var buffer = '';
res.on('data', function(chunk) {
buffer += chunk;
});
res.on('end', function() {
success(buffer);
});
}).on('error', function(e) {
error(e);
});
};
to this:
(defn load-url-async
[url success error]
(let [loader (.get http url (fn [res]
(let [buffer (atom )]
(.on res data #(swap! buffer str %))
(.on res end #(success @buffer)))]
(.on loader error error))
Can someone experienced confirm that I can use atom inside the function?
Thanks
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Inconsistent handling of \space in Clojure ClojureScript
Your first issue with cljs.reader looks like a bug. Your second issue is because clojure/java has a distinct char type but clojurescript/javascript does not. In cljs, the character literal syntax produces a one-character string, but in clj it produces a 16-bit unsigned int interpreted as a utf-16 character. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: How to create UUIDs?
Use (-UUID ...). The way uuids are constructed was recently broken to add support for a cached hash value. A public constructor was also added. Details: http://dev.clojure.org/jira/browse/CLJS-1256 -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: How to create UUIDs?
Sorry, should be (uuid ...)! -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: hash equality between Clojure and ClojureScript
There's no contract, but strings, keywords, and symbols should hash the same, and collections of these (vectors, lists, maps, sets) should hash the same. It's difficult to hash numbers the same between Clojure and Clojurescript. Clojurescript numbers are all doubles (because JS), so they should in theory hash the same as Clojure doubles. Clojure hashes doubles using Java's Double.hashCode(), which relies on knowing the exact bits of the double. These bits are not available in Javascript (at least not easily or without using typedarrays). I'm also not sure if this particular implementation of hashCode is part of the Java spec (i.e. implemented the same by all JDKs and JVMs.) Of course in practice the same clojure form (as read) will not hash the same in clj and cljs because clj uses longs most of the time. You could take a hybrid approach where integers in cljs are hashed like longs in Clojure. This works up to 52 bits, but longs with more bits than that are not representable in Clojurescript. This is an approach I was pursuing in my murmur3 hashing implementation for cljs: http://dev.clojure.org/jira/browse/CLJS-754 https://github.com/favila/clojurescript/blob/murmur3/src/cljs/cljs/core.cljs#L https://github.com/favila/clojurescript/blob/murmur3/src/cljs/cljs/murmur3.cljs#L61 In practice you will hash the same most of the time if you most deal with integer numbers, but any doubles, bigdecimals, or large integers will still hash differently. This is what happens in clojurescript now: (js-mod (Math/floor o) 2147483647) On Sunday, April 19, 2015 at 11:03:08 PM UTC-5, Peter Taoussanis wrote: Hi there, Am running Clojure 1.7.0-beta1, ClojureScript 0.0-3196. Just noticed: (hash 1) ; 1, ClojureScript (hash 1 ) ; 1392991556, Clojure (.hashCode 1) ; 1, Clojure i.e. numeric hashes aren't consistent between Clojure and ClojureScript. I'm assuming that's intentional? This got me wondering: is there an official contract somewhere describing hash behaviour similarities we _can_ safely depend on? Keywords, strings, and collections of these seem to produce matching hashes (?) - but is that dependable behaviour or subject to change? Thanks a lot , cheers! :-) -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Regular expressions do not support ^start and end$ of input characters?
This is an edge case of clojure.string/split with limits and non-consuming assertions. ^ and $ are fully supported with the meaning of the underlying regex engine (which may be subtly different in javascript and java). This is clearly wrong. It occurs because clojure.string/match uses the size of the match to determine where to split. Since the match is always empty, it always splits at index 0. cljs.user= (clojure.string/split 123 #$ 2) [ 123] However, I'm not sure why you consider Clojure's answers to be correct. I would expect this in Clojure: user=(clojure.string/split 123 #^ 2) [ 123] On Sunday, April 19, 2015 at 10:39:28 AM UTC-5, Dominykas Mostauskis wrote: I am having trouble using the ^ and $ characters under Clojurescript. Equivalent calls in Clojure work fine. Workarounds? Unexpected cljs behaviour: cljs.user= (clojure.string/split 123 #$ 2) [ 123] cljs.user= (clojure.string/split 123 #^ 2) [ 123] Clojure works fine: user= (clojure.string/split 123 #$ 2) [123 ] user= (clojure.string/split 123 #^ 2) [123] -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: [Reagent, React] value of select/option's attribute is incorrect.
Generally the React elements mirror dom objects rather than html tags and
attributes.
For example, :multiple and :selected are booleans, not strings.
Also, the select element has a value property you can set directly instead of
messing with :selected.
https://facebook.github.io/react/docs/forms.html#why-select-value
Code should be more like:
(defn duallist []
[:div.row
[:div.col-md-7
[:select {:multiple true
:value [option2 option3]
:size 10
:name duallistbox_demo
:class demo
:style {:display none}}
[:option {:value option1} Option 1]
[:option {:value option2} Option 2]
[:option {:value option3} Option 3]
[:option {:value option5} Option 5]
]
]
]
)
On Monday, March 30, 2015 at 5:32:54 AM UTC-5, Bin Li wrote:
I created this reagent component:
(defn duallist []
[:div.row
[:div.col-md-7
[:select {:multiple multiple
:size 10
:name duallistbox_demo
:class demo
:style {:display none}}
[:option {:value option1} Option 1]
[:option {:value option2 :selected selected} Option 2]
[:option {:value option3 :selected selected} Option 3]
[:option {:value option5} Option 5]
]
]
]
)
But it reader this html code:
select multiple= size=10 name=duallistbox_demo2 class=demo2
style=display: none; data-reactid=.0.0.0
option value=option1 data-reactid=.0.0.0.0Option 1/option
option value=option2 selected= data-reactid=.0.0.0.1Option 2
/option
option value=option3 selected= data-reactid=.0.0.0.2Option 3
/option
option value=option5 data-reactid=.0.0.0.3Option 5/option
/select
The attribute multiple= and selected= , their values are not as expected.
Any ideas?
Thanks in advance!
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Support for prefix lists in ns?
Would you reject a patch which adds (only) prefix lists to the ns form, or is this a feature you never want to see in ClojureScript? (Not that I'm going to rush out and write one: just want to know your stance here.) On Friday, February 20, 2015 at 10:51:36 AM UTC-6, David Nolen wrote: There is no way around this. David On Fri, Feb 20, 2015 at 11:38 AM, Tom Locke t...@tomlocke.com wrote: Fair enough. Are there any tips for reducing the size of large ns forms? For example I have a util namespace, and I consider the functions in there part of my core vocabulary, alongside all the regular core functions and macros. I don’t want to see them with a namespace prefix in my code. Given the lack of refer :all, I end up with a long refer list which I frequently have to maintain. Is there any way around this? Thanks Tom On 20 Feb 2015, at 12:57, David Nolen dnolen...@gmail.com wrote: It's not supported. ClojureScript's ns form is a restrictive subset of the functionality provided in Clojure. This is a good thing, what's there already involves an amazing amount of complexity. David On Fri, Feb 20, 2015 at 2:48 AM, Tom Locke t...@tomlocke.com wrote: Are prefix lists supported in ClojureScript's (ns ...)? It seems not, unless I am misunderstanding the syntax. e.g. (ns my.namespace (:require (foo [baa baz])) should be equivalent to (ns my.namespace (:require [foo.baa] [foo.baz]) but gives a compiler error Only :as alias and :refer (names) options supported in :require Is this expected? Thanks Tom -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/jWqMeJUYU14/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: phonegap, cljs and deviceready event
We do phonegap dev with CLJS, but we don't use many phonegap features (yet). Don't try to skip the deviceready step. Like the DOM-ready event, you can get away with not waiting for it if you are careful, but why bring that pain on yourself? Phonegap/cordova documentation on deviceready: http://docs.phonegap.com/en/4.0.0/cordova_events_events.md.html#deviceready On Wednesday, February 18, 2015 at 10:34:33 AM UTC-6, Sven Richter wrote: Hi, Does anyone here do phonegap development with clojurescript? I was reading up a bit today and looked at sources I found: https://gist.github.com/zentrope/bf359cec33f6fcc02be4 and now I wonder if I have to wait for the deviceready event? In this gist there is some ceremony to build the components with om, sent the event when the device is ready and catch it somewhere else to start drawing the rest of the dom. Is this a requirement? Is there a given reason to do so? Thanks, Sven -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: muting specific warnings with the cljs compiler
You may be hitting CLJS-907 (cf CLJS-917), fixed in 0.0-2629 and later.
On Tuesday, February 3, 2015 at 8:05:04 PM UTC-6, Chris Zheng wrote:
I'm trying to figure out how to best deal with an issue on the newer versions
of the class compiler:
https://github.com/purnam/purnam/issues/8
I've reproduced the issue causing the warning in this particular piece of code
(ns compiler.issue-1
(:require [purnam.test])
(:use-macros [purnam.core :only [? !]]))
(set! js/aa #js {})
(def a js/aa)
(! a.b.c )
(+ 2 (? a.b.c) 3)
-
Running the compiler with clojurescript 0.0-2411 yields a particular
warning:
WARNING: cljs.core/+, all arguments must be numbers, got [number #{nil
clj-nil}] instead. at line 9 test/cljs/compiler/issue_1.cljs
the previous versions of clojurescript do not give this warning. I'm hoping
to get a bit of help/advice on how to deal with this.
-
you can get the warnings by:
git clone https://github.com/purnam/purnam.git
cd purnam
git checkout compilation-error
lein cljsbuild once
-
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Path names in :advanced compile
Andrew, the metadata you are seeing is added by the CLJS compiler to the
Clojure objects it creates as it is reading CLJS code. You did not add it
explicitly in your code anywhere, and we're not saying you did.
The problem here is that the metadata did not *stay* in Clojure but got emitted
into the compiled js code.
So what likely happened is that some *Clojure* code (e.g. cljs a macro) emitted
an object constructed by the Compiler, but the metadata on that object was not
stripped out before being emitted as js code.
We need a minimum reproducible case. Here is a possibility to explore:
;;CLJ code
(defmacro macro-identity [x] x)
;; CLJS code
(def do-i-have-extra-metadata? (macro-identity {:foo :bar}))
Then see if the compiled output of do-i-have-extra-metadata? has extra metadata.
If that does not seem to work, look for places in your codebase where some
object is crossing from clojurescript-clojure-clojurescript. Start with
Clojure macros.
On Tuesday, February 3, 2015 at 12:06:11 PM UTC-6, David Nolen wrote:
You have as much of an idea why this happening as I do.
Which is zero :)
Without a minimal reproducer there is nothing for anyone to do.
You need to sort yourself what line of your ClojureScript or your
ClojureScript dependencies is generating these maps.
Then maybe someone can offer a solution.
David
On Tue, Feb 3, 2015 at 12:50 PM, Andrew S hell...@floatingmachine.com wrote:
Ok, I'm sorry if I'm missing the train of thought on this, but how
does any ordinary clojure(script) map lead to what you call metadata
leakage that contains paths to files? Of course I use maps all over
the place (doesn't everyone?), but I don't see how this connects to
the problem I'm having.
On Tue, Feb 3, 2015 at 6:40 PM, David Nolen dnolen...@gmail.com wrote:
Yes {:foo :bar}
David
On Tue, Feb 3, 2015 at 12:35 PM, Andrew S hell...@floatingmachine.com
wrote:
Ok, can you clarify the type of map literal that would do this? I have
not written any of my own macros on this app, but perhaps a library I
depend on has them. By map literal, do you just mean a {:foo :bar}
type of syntax, or something else? I also have not added any metadata
myself to anything in the app using the caret or with-meta syntax.
On Tue, Feb 3, 2015 at 6:29 PM, David Nolen dnolen...@gmail.com
wrote:
The problem is metadata leakage. This has nothing to do with specifying
paths in your code. Somewhere you are writing map literals (perhaps in a
macro?) and compiler metadata is leaking.
David
On Tue, Feb 3, 2015 at 11:38 AM, Andrew S
hell...@floatingmachine.com
wrote:
I can try to produce an example if I know where to start. There is
nowhere in my app that I am specifying a path to a file, so I'm not
sure where this is happening.
On Tue, Feb 3, 2015 at 5:37 PM, David Nolen dnolen...@gmail.com
wrote:
Looks like metadata leakage. Need a minimal example though.
Thanks,
David
On Tue, Feb 3, 2015 at 10:57 AM, Andrew S
hell...@floatingmachine.com
wrote:
Grepping over the files created by a :none optimization reveals the
path in places like this:
cljs.core.PersistentArrayMap(null, 5, [new
cljs.core.Keyword(null,end-column,end-column,1425389514),55,new
cljs.core.Keyword(null,end-line,end-line,1837326455),101,new
cljs.core.Keyword(null,column,column,2078222095),3,new
cljs.core.Keyword(null,line,line,212345235),96,new
cljs.core.Keyword(null,file,file,-1269645878),/Users/andrew/path/to/file.cljs],
null)));
Does this shed any light on the cause of this? I have no idea what
this cljs.core.Keyword is doing with a file path.
On Tue, Feb 3, 2015 at 4:30 PM, Mike Fikes mikef...@gmail.com
wrote:
Try the :pseudo-names compiler option to see what the :advanced
code
is
referring to
(https://github.com/clojure/clojurescript/wiki/Compiler-Options#pseudo-names).
--
Note that posts from new members are moderated - please be patient
with
your first post.
---
You received this message because you are subscribed to a topic in
the
Google Groups ClojureScript group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojurescript/6qSmNpSQeI4/unsubscribe.
To unsubscribe from this group and all its topics, send an email
to
clojurescrip...@googlegroups.com.
To post to this group, send email to
clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
hellofunk
--
Note that posts from new members are moderated - please be patient
Re: [ClojureScript] Self-hosting ClojureScript -- how far away is it, and how can I help?
And as I said in reply to your other post https://groups.google.com/d/msg/clojure/gNPUmCNHrKg/ySLU8iDf6WwJ if you really need a self-hosted lisp on node.js *today* there's always WISP. https://github.com/Gozala/wisp http://jeditoolkit.com/try-wisp/ The biggest thing you give up is clojure's data structures but you can regain those through mori or immutable-js. On Tuesday, January 27, 2015 at 10:37:22 AM UTC-6, David Nolen wrote: https://github.com/clojure/clojurescript/wiki/Bootstrapping-the-Compiler Some people are already working on tools.reader. Feature expression like functionality is underway for 1.7.0. If you want to help now is good time to start reading the source of the ClojureScript compiler :) David On Tue, Jan 27, 2015 at 11:33 AM, Adam Avramov falle...@gmail.com wrote: Hey folks :) I see the development of ClojureScript is progressing at a steady pace, however the coveted self-hosted compiler seems to remain as mythical a beast as always. Long story short, I honestly can't wait any longer. I beg you, good people, be so kind as to point me towards any areas where I can help make it happen. I know a fair deal of JavaScript (browser and Node.js) and Python, but I can even get up to speed with Java if need be. Give me directions, tickets, areas of interest, people I should pester, anything. I just need a robust Lisp on Node.js so I can do magic with it. I did try going with the old CLJS-on-CLJS repo from 2013, and played with it quite intently for a while until inevitably hitting a wall -- here's half a thing I built before I ran into the incompleteness of that runtime: https://github.com/egasimus/cljs-audio-experiments Cheers, Adam -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Using `not` for keywords
There is no protocol for truthiness, which is what you want. nil and false
are false, everything else is true.
Even if there were a protocol for truthiness, you could not use :yes and :no
(keywords), you would have to create your own custom type and implement the
protocol on it. (Think about it: what if the truthiness of a *specific* keyword
depended on application code you didn't write? E.g. if some library globally
redefined the truthiness protocol on keywords so that :no is false?)
Clojure is philosophically opposed to making truthiness user-definable. Many
other languages (including lisp and scheme) have not-very-simple truthiness
rules that Clojure deliberately simplified. Allowing user-definable truthiness
would bring all that complexity back *and then some*.
You have a problem-domain-specific use of :yes and :no and a
problem-domain-specific notion of truthiness. You can either use functions
which implement that domain notion (which you have done, and which is the best
approach I think), or you can write your *own* protocol for this and extend it
either to custom YES NO types or keywords.
You could also create a boundary in your application where you convert from a
:yes-:no representation to a more native true-false.
It smells like a bad design that you have the *same* function and code
accepting both :yes and :no *and* true and false. Since this is a
domain-specific problem and type, it seems like the same code shouldn't be used
in both cases. I.e., your not function should be:
(defn a-not [answer]
(case answer
:yes :no
:no :yes
(throw (ex-info (str Not a valid questionnaire answer: (pr-str answer))
{}
On Wednesday, January 14, 2015 at 2:50:21 PM UTC-6, Yehonathan Sharvit wrote:
In my app, I am using :yes and :no sometimes instead of true and false.
I’d like to know what is the best way to extends the `not` function to be
able to handle :yes and :no properly.
I was expecting some kind of Boolean protocol but I wasn’t able to find it.
I could write this:
(defn not [x]
(case x
:yes :no
:no :yes
(cljs.core.not x)))
(map not [false true :yes :no]); (true false :no :yes)
But I’m not sure it is the most idiomatic solution.
Any ideas?
—
Sent from Mailbox
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Turning off optimization to speed compilation during development
On Wednesday, November 26, 2014 9:09:58 AM UTC-6, Matthew Gertner wrote: My colleague was complaining about waiting ~20 seconds for his ClojureScript to compile and discovered this post on Stack Overflow: http://stackoverflow.com/questions/20917202/auto-building-clojurescript-files-for-compojure-app. In a nutshell, compilation time goes _way_ down if `optimization` is set to `:none`, but some hackery is needed to get the resulting JS to run. (I didn't check yet whether `:none` is a supported value or whether any unsupported value would have the same effect.) Is there some option for turning off optimization completely that we haven't been able to find? If not, is there some reason not to support this? Wouldn't it be possible to adapt the parser so that it emits runnable JS without any optimization at all during the dev process? The compilation time speedup is really significant. What you describe is exactly what :optimization :none does. It emits javascript generated by the clojurescript compiler *without* compiling that javascript with the google closure compiler. It requires different script elements in the html because the clojurescript compiler outputs one js file per cljs file, but the google closure compiler squashes it into one js file. There is a ticket[1] that has a proposal to simplify this so you can use the same html in both cases. [1]: http://dev.clojure.org/jira/browse/CLJS-851 -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Check for interface implementation?
On Tuesday, November 25, 2014 11:51:27 AM UTC-6, Brendan Younger wrote: Now, if only there was documentation mentioning satisfies? and explaining the difference between interfaces/protocols in ClojureScript... instance? is a Clojure(Script) host interop form that checks the class hierarchy of an object using the semantics of the underlying platform. E.g., in Java, instance? means is this an instance of some class or interface or one of their parents?. In javascript it means is this constructor's prototype in the object's prototype chain?. In both languages (instance? klass obj) is the same as obj instanceof klass. Protocols are a native Clojure(Script) concept and are not provided by the underlying platform. satisfies? tests that a protocol is implemented for some instance's type (directly or indirectly). In Clojure, there are interfaces (a Java concept) and protocols (a Clojure concept). Most of Clojure's core interfaces are true *java interfaces*, not *protocols*. So you *cannot* say (satisfies? clojure.lang.IRef x) (you will get a null pointer exception). You *must* say (instance? clojure.lang.IRef x) In ClojureScript, however, all Clojure core interfaces are *protocols*. You *must* say (satisfies? IWatchable x). (instance? cljs.core.IWatchable x) will not work. The Google Closure Compiler has a thing it calls interfaces for compile-time typechecking, but it is not available at runtime and not used by ClojureScript. There is nothing like a Java interface in Javascript or ClojureScript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Check for interface implementation?
In ClojureScript these are protocols, not interfaces. So you instead say (satisfies? cljs.core/IWatchable x) On Monday, November 24, 2014 12:45:37 PM UTC-6, Brendan Younger wrote: Hi all, I'm wondering how to check if a given value implements an interface in ClojureScript. Specifically, I want to know if it implements cljs.core.IWatchable. In Clojure (accounting for the different interface name), it would be: (instance? clojure.lang.IRef value) I've tried this in ClojureScript: (instance? cljs.core.IWatchable value) but cljs.core.IWatchable is not a constructor function, so it fails. Note that I cannot use (instance? Atom value) since my value may not be a ClojureScript atom. So far, I've been doing: (exists? (aget value cljs$core$IWatchable$_add_watch$arity$3)) but it feels (and looks) like a dirty hack. Any suggestions? Brendan Younger -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] clojurescript wrapping javascript function call twice.
The on_success function is not the outer wrapper function but the inner returned function. The outer function is immediately-invoked, not assigned to on_success. The reason you see so many function wrappers in the generated js is that js provides no other way of introducing a new scope. Advanced compilation will get rid of most of these wrappers. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Idiomatic way of accessing JavaScript properties in nested namespaces
There's no question that it's allowed. You can use js/a.b.c However, it is *less idiomatic* because there's no analogous construct in Clojure (not ClojureScript) code. In Clojure, a symbol referencing a var in a namespace will only ever have a name part without dots. The fact that the CLJS-445 patch to warn on dotted name parts of js/name constructs was initially accepted by Nolan in the first place is itself evidence that this construct is less idiomatic. Either way it's not a big deal. No one is going to get too upset if you use js/a.b.c instead of (.. js/a -b -c) On Friday, August 29, 2014 12:37:32 PM UTC-5, Rafal Spacjer wrote: On the other hand, I've found this JIRA bug: http://dev.clojure.org/jira/browse/CLJS-455 with the comment of David Nolen: This patch creates issues around using constructors provided by libraries outside ClojureScript and GClosure. Also from Rich's original commit support js prefix, it seems like JS style access after the / was actually intended so maybe using dots after js/ is allowed W dniu piątek, 29 sierpnia 2014 07:09:36 UTC+2 użytkownik Rafal Spacjer napisał: Sounds good, thank you. Of course I agree, that using dots (like in (js/console.log x)) is faster to write. W dniu czwartek, 28 sierpnia 2014 23:45:55 UTC+2 użytkownik Francis Avila napisał: Avoid dots in the name part of symbols. js/a.b.c works to reference a.b.c by value (i.e. without calling it), but it's not idiomatic. Prefer (.. js/a -b -c), or using your examples: (.. js/Foo -Bar -Foo2 -myProperty) (.. js/Foo -Bar -Foo2 myMethod) The js pseudo-namespace is special because it emits the symbol as normal js property access, but if it were a *real* namespace there would be no dotted symbols in it. (That said, I cheat all the time e.g. with (js/console.log x).) On Thursday, August 28, 2014 3:22:53 PM UTC-5, Rafal Spacjer wrote: Hello, I' curious what is a preferable way of accessing properties or methods in nested JavaScript namespaces. Lets assume that external library define such property: Foo.Bar.Foo2.myProperty in global namespace. what is idiomatic way of accessing 'myProperty': (.-myProperty js/Foo.Bar.Foo2) or (.. js/Foo -Bar -Foo2 -myProperty) Same question for a method, if we have such statement: Foo.Bar.Foo2.myMethod(); how should we invoke 'myMethod'? Is this correct: (.myMethod js/Foo.Bar.Foo2) ? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Idiomatic way of accessing JavaScript properties in nested namespaces
Avoid dots in the name part of symbols. js/a.b.c works to reference a.b.c by value (i.e. without calling it), but it's not idiomatic. Prefer (.. js/a -b -c), or using your examples: (.. js/Foo -Bar -Foo2 -myProperty) (.. js/Foo -Bar -Foo2 myMethod) The js pseudo-namespace is special because it emits the symbol as normal js property access, but if it were a *real* namespace there would be no dotted symbols in it. (That said, I cheat all the time e.g. with (js/console.log x).) On Thursday, August 28, 2014 3:22:53 PM UTC-5, Rafal Spacjer wrote: Hello, I' curious what is a preferable way of accessing properties or methods in nested JavaScript namespaces. Lets assume that external library define such property: Foo.Bar.Foo2.myProperty in global namespace. what is idiomatic way of accessing 'myProperty': (.-myProperty js/Foo.Bar.Foo2) or (.. js/Foo -Bar -Foo2 -myProperty) Same question for a method, if we have such statement: Foo.Bar.Foo2.myMethod(); how should we invoke 'myMethod'? Is this correct: (.myMethod js/Foo.Bar.Foo2) ? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: map with anonymous function
As others have said, #() is like a function body, so the first item in its list
must be callable or a macro. But no one mentioned you can use do:
#(do [:th %])
On Sunday, August 3, 2014 7:53:47 AM UTC-5, Paul Cowan wrote:
I am using om and soblano and I have a map function that works when I declare
at like this, on the last line of the function below:
(defn ical [data]
(reify
om/IDisplayName
(display-name [_]
(or (:react-name opts) calendar))
om/IRender
(render [this]
(html/html [:div
[:div.calendar-toolbar
[:div.btn-group.pull-right
[:a.right {:href #} Right]
[:a.left {:href #} Left]]
[:h3 August 2014]]
[:table.table
[:thead
[:tr (map (fn [day] [:th day]) weekdays)
But when I try and use the map with the anonymous function syntax like this:
[:table.table
[:thead
[:tr (map ([:th %]) weekdays)
I get the following error:
Uncaught Error: Invalid arity: 1
Cheers
Paul Cowan
Cutting-Edge Solutions (Scotland)
blog: http://thesoftwaresimpleton.com/
website: http://www.cuttingedgesolutionsscotland.com/
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: [ANN] Longshi a ClojureScript port of Fressian
The difference in performance between native and non-native string encoding (using the fastest js implementations I can manage to write, granted) is at most 2x to 3x, which is certainly an improvement but not enough to overcome the approximately order-of-magnitude difference in overall encoding and decoding speed that we're looking at now. So the benefit is that using a binary encoding will make sense in more circumstances, but will still be slow enough that something JSON-backed is a better choice in most cases. On Mon, Aug 4, 2014 at 9:58 AM, David Nolen dnolen.li...@gmail.com wrote: On Mon, Aug 4, 2014 at 10:51 AM, Francis Avila fav...@breezeehr.com wrote: I've looked closely at utf-8 encoders/decoders in JS vs TextEncoder, and I'm not sure fast string encoding/decoding alone is going to bring us the kind of speed improvements we need to make binary formats a clear win over JSON. (Some of this might be because the ArrayBuffer implementations are slower than they could be.) Relevant JSPerfs (bops is the library used by messagepack-js): http://jsperf.com/utf8-encoding-methods/2 These numbers look very good, what are your reservations w/ respect to performance? David -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/xhdrGunEXPE/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Re: [ANN] Longshi a ClojureScript port of Fressian
I thought MessagePack js implementations were quite a bit slower than 4-5x. Do you know of any benchmarks? String encoding/decoding is definitely big part of the slowdown, not disagreeing. MessagePack doesn't even have a string type: I think it's only convention that their raw type contains utf-8 bytes if semantically a string, and this is a big headache for interop. Couldn't transit conceivably store strings as raw utf16 bytes or even arrays of packed fixnum/uint16, tag the type at the transit level, and completely sidestep the string encoding issue? On Mon, Aug 4, 2014 at 10:20 AM, David Nolen dnolen.li...@gmail.com wrote: On Mon, Aug 4, 2014 at 11:14 AM, Francis Avila fav...@breezeehr.com wrote: The difference in performance between native and non-native string encoding (using the fastest js implementations I can manage to write, granted) is at most 2x to 3x, which is certainly an improvement but not enough to overcome the approximately order-of-magnitude difference in overall encoding and decoding speed that we're looking at now. Order of magnitude for what? Fressian? Or are you talking about existing JavaScript MessagePack implementations. It's my impression these are only 4-5X slower than JSON and that a large contributor to the slowdown is string decoding. David -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/xhdrGunEXPE/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: ANN: ClojureScript 0.0-2277
FYI, using the :psuedo-names compiler option is very handy for debugging
advanced-compile munging issues, e.g.:
:compiler {:optimizations :advanced
:pseudo-names true
...}
On Wednesday, July 30, 2014 10:11:17 AM UTC-5, Thomas Heller wrote:
Geez, 2277 actually works just fine. 2234 doesn't work, but it actually
doesn't work with either closure-library version. Forgot that I reverted to
2234 due to the keyword issue.
2277 + [org.clojure/google-closure-library 0.0-20140718-946a7d39]
seems fine, except for that keyword issue.
Sorry about the confusion, I will shut up now until I have something solid.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: Ran tests with v20140417
Would you mind seeing if http://dev.clojure.org/jira/browse/CLJS-790 is
resolved by this version of the compiler?
On Tuesday, April 8, 2014 8:15:05 AM UTC-5, Tim Visher wrote:
Hi All,
v20140417 was just released to Maven Central.
With the following patch:
diff --git a/project.clj b/project.clj
index d80ceef..0afea52 100644
--- a/project.clj
+++ b/project.clj
@@ -12,7 +12,7 @@
[org.clojure/data.json 0.2.3]
[org.clojure/tools.reader 0.8.3]
[org.clojure/google-closure-library
0.0-20130212-95c19e7f0f5f]
- [com.google.javascript/closure-compiler v20131014]
+ [com.google.javascript/closure-compiler v20140407]
[org.mozilla/rhino 1.7R4]]
:profiles {:1.5 {:dependencies [[org.clojure/clojure 1.5.1]]}
:1.6 {:dependencies [[org.clojure/clojure
1.6.0-master-SNAPSHOT]]}}
I ran:
$ V8_HOME=/usr/local/bin SPIDERMONKEY_HOME=/usr/local/bin
JSC_HOME=/usr/local/bin script/t
est
Testing with V8
Tests completed without exception
Testing with SpiderMonkey
out/core-advanced-test.js:533: Error: Assert failed: (not (integer? 1e+308))
Testing with JavaScriptCore
Tests completed without exception
NASHORN_HOME not set, skipping Nashorn tests
Tested with 3 out of 4 possible js targets
Just FYI! :)
--
In Christ,
Timmy V.
http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
