[ClojureScript] Re: ANN: Om 0.8.6, Hello CLJSJS
On Sunday, February 1, 2015 at 9:16:05 PM UTC+1, Sebastian Bensusan wrote: > I changed the tutorial to use a new version of the figwheel template > https://github.com/bhauman/figwheel-template. When the new template is > published to Clojars we can update the Om wiki. I'll move on to the > Intermediate tutorial. If by the time I'm done with all of the tutorials the > template is not published I'll do it myself. > > > > The new version: > > > https://github.com/bensu/basic-om-tut/blob/master/Basic-Tutorial.md > > > Feedback is welcome. Hope this helps. > > > > On Saturday, January 31, 2015 at 5:19:35 PM UTC+1, David Nolen wrote:Template > preferred. > > On Saturday, January 31, 2015, Sebastian Bensusan wrote: > Sure, I'll explore Figwheel's new REPL and add that instead. > > > > What about adding/configuring Figwheel? Should it be step by step inside the > tutorial, from mies-om to mies-om + Figwheel? Or it should just start with a > ready to go template "mies-om-wheel"? > > > > Thanks > > > > Sebastian Bensusan > > > > On Saturday, January 31, 2015 at 1:26:34 AM UTC+1, David Nolen wrote: > > > I would prefer just Figwheel. Relying only on Figwheel also means you could > > probably go out with an updated tutorial much sooner. > > > > > > > > > Thanks, > > > David > > > > > > > > > On Fri, Jan 30, 2015 at 4:10 PM, Sebastian Bensusan > > wrote: > > > > > > > > > Hi David and Dan, > > > > > > I edited Om's Basic Tutorial > > (https://github.com/swannodette/om/wiki/Basic-Tutorial) to be used with > > Chestnut. Most of the work (not much!) was changing "evaluate in > > LightTable" to "save in your text editor". I don't know what the procedure > > is for updating a Wiki and having this conversation, should I open an issue > > on Om? I have it as a standalone repo in case someones wants to propose a > > change or make a pull request: > > > > > > > > > https://github.com/bensu/basic-om-tut > > > > > > > > > > > > Two issues: > > > > > > > > > 1. Chestnut 0.6.0 (current stable version) uses Om 0.7.3 and I needed to > > deref a cursor inside a go loop in order for things to work. See > > https://github.com/swannodette/om/issues/315 and > > https://github.com/swannodette/om/commit/92a3e0cf698769fb59bb3744faddaea40b37412d. > > Om version is bumped to 0.8.3 beta in v0.7.0-SNAPSHOT-20141226 > > > > > > > > > 2. Chestnut's 0.6.0 doesn't reload the index.html (not on save, not on > > refresh). The whole process needs to be restarted. See: > > https://github.com/plexus/chestnut/issues/84 This was addressed in > > v0.7.0-SNAPSHOT-20141207. > > > > > > > > > I would wait until Chestnut 0.7.0 stable is published in Clojars before > > adding this tutorial to the Om Wiki. Otherwise, if you feel the extra > > dependency on Chestnut is also too much, I'll fork mies-om and add Figwheel > > there for the tutorial. > > > > > > > > > After revising this work, I'll move on to the next tutorial. > > > > > > > > > Best > > > > > > > > > Sebastian Bensusan > > > > > > > > > > > > > > > > > > > > > On Tuesday, January 27, 2015 at 5:25:09 PM UTC+1, David Nolen wrote: > > > I think expecting every last thing to work especially from third parties > > who may be wisely lagging behind is unlikely at least for the near future. > > > > > > > > > I haven't kept up with Light Table and what issues it may have. Now is > > probably a good time to remove the Light Table centric nature of the Om > > tutorials and switch to a Figwheel based thing that doesn't require > > anything more than your text editor of choice. > > > > > > > > > The wiki has always been community editable and I would love to see people > > push it forward especially with stuff like this. I will have less time for > > such things as I focus more on Om core and ClojureScript enhancements. > > > > > > > > > > > > David > > > > > > > > > On Tue, Jan 27, 2015 at 10:46 AM, Olav Nymoen wrote: > > > Just testing clojurescript out so many possible pitfalls on my side here. > > > > > > > > > > > > Does the new javascript externals stuff break lighttables live external > > browser functionality? > > > > > > > > > > > > Following the basic intro tutorial I cannot get live updates to work. The > > mies-om om-tut is based on 0.8.4 , and it cannot reference > > com.facebook.react, while 0.8.6 cannot find cljsjs.react. > > > > > > > > > > > > It compiles nicely with lein, but I can't seem to get the lighttable live > > REPL stuff to work. > > > > > > > > > > > > Olav > > > > > > > > > > > > > > > > > > On Tuesday, January 27, 2015 at 1:57:19 AM UTC+1, David Nolen wrote: > > > > > > > The only significant change is that Om now relies on the cljsjs.react > > > artifact instead of the one I maintained myself. cljsjs.react has the > > > benefit that usage of React with addons instead of plain React may be > > > configured via Maven in your pom.xml or your
Re: [ClojureScript] Re: ANN: Om 0.8.6, Hello CLJSJS
Indeed, "data" is better than "app". Khalid aka DjebbZ @Dj3bbZ On Mon, Feb 2, 2015 at 10:49 AM, Sebastian Bensusan wrote: > Thanks Khalid, > > The way I see it, Om has three concepts regarding state: > > 1. The global state defined with atom. Named `app-state` > 2. The cursor passed to each component with the relevant parts of the > global state. Named `app` > 3. Local state of each component, initialized in `IInitState` and > manipulated with `(set-state! owner korks v)` and `(get-state owner)`. It > is a property of the owner object so it is not directly referenced. > > I agree that `app` is ambiguous for 2 but I wouldn't like to call it > `app-state` nor `state` since those could also be confused with 1 and 3. > Nothing better than `cursor` or `data` comes to mind. Some other parts of > the Documentation (the Example in https://github.com/swannodette/om) use > `data` and I think it works even if it is a meaningless term for a fn > argument. If you agree and nobody raises objections I'll change `app` to > `data`. > > Sebastian > > -- > 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/bruQ9os5wmM/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: Touch events and React.js/Om
No need to fiddle with other libs or complicated build steps, React js handle
this very well.
Simply handle the touchend event and preventDefault().
In React's JSX syntax :
...
myHandler: function(event) {
event.preventDefault();
... // do your stuff
}
The preventDefault() call avoids the click to trigger 300ms after the touch
event.
--
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: Touch events and React.js/Om
I didn't notice any usability issue of this kind. Touching triggers touchend and no click, clicking on desktop triggers click normally, and scrolling triggers none of them. Maybe our use cases were different, hence the need for you to introduce fastclick. -- 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: File uploads in ClojureScript + React
On Saturday, February 14, 2015 at 3:26:53 PM UTC+1, Michiel Borkent wrote: > I am currently looking at the options for supporting file uploads in several > browsers in a ClojureScript SPA. > > My first attempt was posting a form with a file upload with cljs-http. This > didn't work because the Ring/compojure app started to complain about the > content boundary not being in order. Also just using cljs-http will not work > for IE9 of course. > > Next, I gave goog.net.iframeIO a try. This will work for the spectrum of > browsers we have to support, but working with iframes for modern browsers > doesn't feel right. > > Then I tried jquery-file-upload. Still playing around with it, but I'm pretty > sure this will give me what I need, as it has a fallback mechanism for older > browser via iframe transport. > > I wonder what other options I have and what is convenient in combination with > React and ClojureScript. > > Feel free to post some examples to your open source projects or give any > other helpful tips. > > Thanks, > > Michiel Borkent Why do you need a plugin at all ? A basic form with the input type=file should work fine. Supported since IE 3.0 I think... -- 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: ClojureScript Google Closure Module support
Haven't tried yet the new modules compilation strategy, but I know a very good strategy available in the JS world with Browserify and its plugin factor-bundle. Basically, factor-bundle analyses all the emitted code and put in a single file every single module (written like node modules) that appears twice or more in the various emitted files into a single file. So there's never duplication of code. Example: module A requires module B. module C requires modules B & D. You compile A & C. Browserify would output 3 files : A.js, C.js and another (custom name) common.js that would include modules B and D. It handles automatically the exposition of B and D so that anyone can "require" them. Result and benefits: A.html contain script tags for A.js and common.js. C.html contain script tags for B.js and the same common.js. So common.js is cacheable by browsers out the box, reducing the payload. The other benefit is that each page requires only 2 script tag. We're currently using this process in production, it's one of the best in the JS world. I think the idea is awesome, especially since it requires almost no configuration. Factor-bundle manages to find all common code by analysing the dependency graph. Since Google Closure Modules / CLJS namespace also create a dependency graph I'm pretty sure it's somehow possible. No ? -- 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: ClojureScript Google Closure Module support
Browserify : https://github.com/substack/node-browserify Factor-bundle : https://github.com/substack/factor-bundle -- 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: ClojureScript Google Closure Module support
On Wednesday, February 18, 2015 at 2:59:52 PM UTC+1, Khalid Jebbari wrote: > Browserify : https://github.com/substack/node-browserify > Factor-bundle : https://github.com/substack/factor-bundle Sorry, Google Groups messed up this link https://github.com/substack/node-browserify -- 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: ClojureScript Google Closure Module support
Thanks for the clear explanation. It's pretty clear I should play with it to see how it goes. -- 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-frame - sanity check for re-usable components
On Friday, March 27, 2015 at 2:39:37 PM UTC+1, Jamie Orchard-Hays wrote:
> Does it make sense to pass the reusable component's context as an argument to
> it? ie,
>
> (defn ReusableComponent [some-context] )
>
> Jamie
>
> On Mar 27, 2015, at 8:54 AM, Colin Yates wrote:
>
> > In re-frame event dispatching is handled by (dispatch [:discriminator
> > detail]). A corresponding (register-handler :discriminator (fn [db [_
> > detail]]) then reacts to that dispatched event.
> >
> > My question is how are people managing this with re-usable components? For
> > example, I have a tree and when selecting a node in that tree something
> > should happen. But this is where it gets all polymorphic as _what_ happens
> > depends on the client who instantiated the tree. I can see the following
> > ways forward:
> >
> > - tree is configured with a 'context' key which is combined with the
> > discriminator so rather than the tree emitting :node-selected it emits
> > :consumer-a-node-selected. Consumer a can then handle
> > consumer-a-node-selected and consumer b can handle (go on, guess)
> > consumer-b-node-selected
> > - a variation on the above involving writing your own dispatching logic...
> > - tree doesn't use dispatch as the event bus, rather it takes in an
> > instance of a Protocol:
> > IRespondToTree
> > (on-node-select [this node])
> > - tree is parameterised with a map of fns {:node-selected-fn ...} etc.
> >
> > How would you all handle it? (I am leaning towards the first one).
> >
> > --
> > 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.
Not sure I'm going to answer the question directly, since I've never used
re-frame, Reagent or Om. I'm just an experienced React.js developer VERY
interested with Clojure(Script).
If you want reusable components, whatever wrapper you use around React, here's
the plan.
You should create 2 types of components : dumb and smart. Dumb components do 2
simple things : display stuff and handle input/events. The way they handle
should be agnostic to any kind of library and should use only language-level
feature. Functions. So the dumb component use function it's been passed and
call it with the input/event. The smart components wrap dumb components and
connect to the outside world with whatever your stack uses (channels, events,
ratoms, what not).
This way your dumb components are always reusable, whatever stack/project
they're incorporated in. They can also be displayed in a simple page for your
graphics or HTML/CSS team to check their look. The smart components handle
whatever logic you want to put in them. So from a stack/page/project to
another, only the smart components change, no the dumb ones. This keep UI
consistent and separate concerns.
Hope it's clear and helpful.
--
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: react - performance difference between hiding or removing elements?
On Friday, March 27, 2015 at 2:40:45 PM UTC+1, Colin Yates wrote: > I realise this is one of those 'it depends', but in general, is it > recommended to hide elements in react or not render them? > > For example, I have an SPA with a bunch of top-level pages. Each page has a > number of tabs, each tab might be a tree or a table and so on. > > I could render the whole thing and hide non-relevant things with 'visible: > hidden', or I could only render what is actually needed. > > I went with the second as it seems 'cleaner' somehow, but it does mean you > need to track more things: > - scroll positions of various panels > - expanded/collapsed state > - etc. > > On the other hand, rendering everything and using the hidden class might > overwhelm the dom and I am unsure of how expensive a reflow caused by > showing/hiding compared to replacing the dom. > > The general opinion I get from google, stack overflow and react docs is to > only render what is needed, but nothing definitive. > > If it matters, this is a closed intranet with pretty lame PCs, so waiting a > while for the app to load is fine. Switching between tabs/panels, expanding > tree nodes etc. should be as quick as possible. > > Has anybody done any studies/offer any guidance? > > Thanks! I've seen a talk wednesday by a guy specialised in Web Perf. He clearly stated that BIG DOM makes stuff slow. I would definitely not render them. Hiding/showing should be reserved for small parts of a component, i.e. an error message in a form. -- 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: react - performance difference between hiding or removing elements?
By the way, he developped a nice tool (and open-sourced it!) to measure perf based on a lot of criteria : http://yellowlab.tools/ -- 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-frame - sanity check for re-usable components
If you're more interesed into the pattern I described, you can read more here : https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0. This is really where the React.js community is headed. -- 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-frame - sanity check for re-usable components
Yes, dumb components don't encapsulate beahvior. Indeed if you generic
behaviour you need as someone proposed to push a generic event, and the app
handles it specifically.
Khalid aka DjebbZ
@Dj3bbZ
On Fri, Mar 27, 2015 at 4:45 PM, Jamie Orchard-Hays
wrote:
> Good articles. Thanks, Mike. In my apps I think of them as "generic" and
> "specific", or something like that. IOW, I want some generic views that are
> dumb and know nothing about the app and can be used where ever I need them.
> They get composed into specific views.
>
> Jamie
>
>
> On Mar 27, 2015, at 10:12 AM, Mike Thompson
> wrote:
>
> > On Saturday, March 28, 2015 at 12:58:17 AM UTC+11, Khalid Jebbari wrote:
> >> On Friday, March 27, 2015 at 2:39:37 PM UTC+1, Jamie Orchard-Hays wrote:
> >>> Does it make sense to pass the reusable component's context as an
> argument to it? ie,
> >>>
> >>> (defn ReusableComponent [some-context] )
> >>>
> >>> Jamie
> >>>
> >>> On Mar 27, 2015, at 8:54 AM, Colin Yates
> wrote:
> >>>
> >>>> In re-frame event dispatching is handled by (dispatch [:discriminator
> detail]). A corresponding (register-handler :discriminator (fn [db [_
> detail]]) then reacts to that dispatched event.
> >>>>
> >>>> My question is how are people managing this with re-usable
> components? For example, I have a tree and when selecting a node in that
> tree something should happen. But this is where it gets all polymorphic as
> _what_ happens depends on the client who instantiated the tree. I can see
> the following ways forward:
> >>>>
> >>>> - tree is configured with a 'context' key which is combined with the
> discriminator so rather than the tree emitting :node-selected it emits
> :consumer-a-node-selected. Consumer a can then handle
> consumer-a-node-selected and consumer b can handle (go on, guess)
> consumer-b-node-selected
> >>>> - a variation on the above involving writing your own dispatching
> logic...
> >>>> - tree doesn't use dispatch as the event bus, rather it takes in an
> instance of a Protocol:
> >>>> IRespondToTree
> >>>> (on-node-select [this node])
> >>>> - tree is parameterised with a map of fns {:node-selected-fn ...} etc.
> >>>>
> >>>> How would you all handle it? (I am leaning towards the first one).
> >>>>
> >>>> --
> >>>> 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.
> >>
> >> Not sure I'm going to answer the question directly, since I've never
> used re-frame, Reagent or Om. I'm just an experienced React.js developer
> VERY interested with Clojure(Script).
> >>
> >> If you want reusable components, whatever wrapper you use around React,
> here's the plan.
> >>
> >> You should create 2 types of components : dumb and smart. Dumb
> components do 2 simple things : display stuff and handle input/events. The
> way they handle should be agnostic to any kind of library and should use
> only language-level feature. Functions. So the dumb component use function
> it's been passed and call it with the input/event. The smart components
> wrap dumb components and connect to the outside world with whatever your
> stack uses (channels, events, ratoms, what not).
> >>
> >> This way your dumb components are always reusable, whatever
> stack/project they're incorporated in. They can also be displayed in a
> simple page for your graphics or HTML/CSS team to check their look. The
> smart components handle whatever logic you want to put in them. So from a
> stack/page/project to another, only the smart components change, no the
> dumb ones. This keep UI consistent and separate concerns.
> >>
> >> Hope it's clear and helpful.
> >
> >
> > I'm not sure how much this perspective applies to the Clojurescript
> wrappings, but here are further references:
> > https://medium.com/@learnreact/container-components-c0e67432e005
> > https://medium.com/@dan
Re: [ClojureScript] re-frame - sanity check for re-usable components
If this approach suits you better, fine. Remember, this approach is coming
from the React.js world, where everything is mutable and where there's no
committment to a particular way of passing data/events. For my current
projects, we indeed encapsulated both markup and behaviour, but it was hard
sometimes to make it reusable without changing/hacking it. We didn't use a
global method for sharing state like Flux, so it may explain why.
Khalid aka DjebbZ
@Dj3bbZ
On Fri, Mar 27, 2015 at 6:45 PM, Daniel Kersten wrote:
> Marc, can you tell us a little more about the approach your taking?
>
> On Fri, 27 Mar 2015 at 17:43 Marc Fawzi wrote:
>
>> Yeah but then what are you really reusing? I have components that have
>> sophisticated behavior... sharing just the markup and styles is of limited
>> value since what I want to share in effect is the smart components, which
>> is why I had settled on components encapsulating behavior as a pattern...
>> works better for me to share the whole component (with its behavior) rather
>> than just the dumb part....
>>
>> On Fri, Mar 27, 2015 at 10:25 AM, Khalid Jebbari <
>> khalid.jebb...@gmail.com> wrote:
>>
>>> Yes, dumb components don't encapsulate beahvior. Indeed if you generic
>>> behaviour you need as someone proposed to push a generic event, and the app
>>> handles it specifically.
>>>
>>> Khalid aka DjebbZ
>>> @Dj3bbZ
>>>
>>> On Fri, Mar 27, 2015 at 4:45 PM, Jamie Orchard-Hays
>>> wrote:
>>>
>>>> Good articles. Thanks, Mike. In my apps I think of them as "generic"
>>>> and "specific", or something like that. IOW, I want some generic views that
>>>> are dumb and know nothing about the app and can be used where ever I need
>>>> them. They get composed into specific views.
>>>>
>>>> Jamie
>>>>
>>>>
>>>> On Mar 27, 2015, at 10:12 AM, Mike Thompson
>>>> wrote:
>>>>
>>>> > On Saturday, March 28, 2015 at 12:58:17 AM UTC+11, Khalid Jebbari
>>>> wrote:
>>>> >> On Friday, March 27, 2015 at 2:39:37 PM UTC+1, Jamie Orchard-Hays
>>>> wrote:
>>>> >>> Does it make sense to pass the reusable component's context as an
>>>> argument to it? ie,
>>>> >>>
>>>> >>> (defn ReusableComponent [some-context] )
>>>> >>>
>>>> >>> Jamie
>>>> >>>
>>>> >>> On Mar 27, 2015, at 8:54 AM, Colin Yates
>>>> wrote:
>>>> >>>
>>>> >>>> In re-frame event dispatching is handled by (dispatch
>>>> [:discriminator detail]). A corresponding (register-handler :discriminator
>>>> (fn [db [_ detail]]) then reacts to that dispatched event.
>>>> >>>>
>>>> >>>> My question is how are people managing this with re-usable
>>>> components? For example, I have a tree and when selecting a node in that
>>>> tree something should happen. But this is where it gets all polymorphic as
>>>> _what_ happens depends on the client who instantiated the tree. I can see
>>>> the following ways forward:
>>>> >>>>
>>>> >>>> - tree is configured with a 'context' key which is combined with
>>>> the discriminator so rather than the tree emitting :node-selected it emits
>>>> :consumer-a-node-selected. Consumer a can then handle
>>>> consumer-a-node-selected and consumer b can handle (go on, guess)
>>>> consumer-b-node-selected
>>>> >>>> - a variation on the above involving writing your own dispatching
>>>> logic...
>>>> >>>> - tree doesn't use dispatch as the event bus, rather it takes in
>>>> an instance of a Protocol:
>>>> >>>> IRespondToTree
>>>> >>>> (on-node-select [this node])
>>>> >>>> - tree is parameterised with a map of fns {:node-selected-fn ...}
>>>> etc.
>>>> >>>>
>>>> >>>> How would you all handle it? (I am leaning towards the first one).
>>>> >>>>
>>>> >>>> --
>>>> >>>> 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 Goo
Re: [ClojureScript] re-frame - sanity check for re-usable components
Staying tuned ! I'm not in SF, will there be slides or videos ? > Le 27 mars 2015 à 20:16, Marc Fawzi a écrit : > > > You can have your cake and eat it. > > Will present the complete approach on the next Reagent meetup in SF, and > while we are talking about having a presentation about re-frame port of > ANgular's phonecat example, the reusable "smart" components presentation will > be based on RAW Reagent, nothing added. > > Stay tuned. > > >> On Fri, Mar 27, 2015 at 10:58 AM, Khalid Jebbari >> wrote: >> If this approach suits you better, fine. Remember, this approach is coming >> from the React.js world, where everything is mutable and where there's no >> committment to a particular way of passing data/events. For my current >> projects, we indeed encapsulated both markup and behaviour, but it was hard >> sometimes to make it reusable without changing/hacking it. We didn't use a >> global method for sharing state like Flux, so it may explain why. >> >> >> >> Khalid aka DjebbZ >> @Dj3bbZ >> >>> On Fri, Mar 27, 2015 at 6:45 PM, Daniel Kersten wrote: >>> Marc, can you tell us a little more about the approach your taking? >>> >>>> On Fri, 27 Mar 2015 at 17:43 Marc Fawzi wrote: >>>> Yeah but then what are you really reusing? I have components that have >>>> sophisticated behavior... sharing just the markup and styles is of limited >>>> value since what I want to share in effect is the smart components, which >>>> is why I had settled on components encapsulating behavior as a pattern... >>>> works better for me to share the whole component (with its behavior) >>>> rather than just the dumb part >>>> >>>>> On Fri, Mar 27, 2015 at 10:25 AM, Khalid Jebbari >>>>> wrote: >>>>> Yes, dumb components don't encapsulate beahvior. Indeed if you generic >>>>> behaviour you need as someone proposed to push a generic event, and the >>>>> app handles it specifically. >>>>> >>>>> Khalid aka DjebbZ >>>>> @Dj3bbZ >>>>> >>>>>> On Fri, Mar 27, 2015 at 4:45 PM, Jamie Orchard-Hays >>>>>> wrote: >>>>>> Good articles. Thanks, Mike. In my apps I think of them as "generic" and >>>>>> "specific", or something like that. IOW, I want some generic views that >>>>>> are dumb and know nothing about the app and can be used where ever I >>>>>> need them. They get composed into specific views. >>>>>> >>>>>> Jamie >>>>>> >>>>>> >>>>>> On Mar 27, 2015, at 10:12 AM, Mike Thompson >>>>>> wrote: >>>>>> >>>>>> > On Saturday, March 28, 2015 at 12:58:17 AM UTC+11, Khalid Jebbari >>>>>> > wrote: >>>>>> >> On Friday, March 27, 2015 at 2:39:37 PM UTC+1, Jamie Orchard-Hays >>>>>> >> wrote: >>>>>> >>> Does it make sense to pass the reusable component's context as an >>>>>> >>> argument to it? ie, >>>>>> >>> >>>>>> >>> (defn ReusableComponent [some-context] ) >>>>>> >>> >>>>>> >>> Jamie >>>>>> >>> >>>>>> >>> On Mar 27, 2015, at 8:54 AM, Colin Yates >>>>>> >>> wrote: >>>>>> >>> >>>>>> >>>> In re-frame event dispatching is handled by (dispatch >>>>>> >>>> [:discriminator detail]). A corresponding (register-handler >>>>>> >>>> :discriminator (fn [db [_ detail]]) then reacts to that dispatched >>>>>> >>>> event. >>>>>> >>>> >>>>>> >>>> My question is how are people managing this with re-usable >>>>>> >>>> components? For example, I have a tree and when selecting a node in >>>>>> >>>> that tree something should happen. But this is where it gets all >>>>>> >>>> polymorphic as _what_ happens depends on the client who >>>>>> >>>> instantiated the tree. I can see the following ways forward: >>>>>> >>>> >>>>>> >>>> -
[ClojureScript] Re: [ANN] cljs-pikaday, a reagent date picker
Thx for the link to closureplease. Will help a lot ! -- 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 TodoMVC
On Friday, April 24, 2015 at 7:04:13 AM UTC+2, marc fawzi wrote: > http://todomvc.com/examples/reagent/ > > > https://github.com/tastejs/todomvc/blob/master/examples/reagent/readme.md > > > > :) Nice to have an example in the official TodoMVC repo. -- 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] Using a state machine to design/program UI ?
Hello everyone, As a Javascript web developer, I'm thinking more and more about a good way to design interface so that I don't create a mess. Because I think the current "state of the art" of web UI development and frameworks is still a big mess. React.js and the CLJS wrapper around them help a bit but not that much I think. My goals are the following : - construct the complete UI logic outside of anything web related, so that it's testable without a browser and usable in other contexts (CLI, back-end, scripts, whatever) - being able to *visualize* the logic without having to read all the code, through diagrams and other means. I've heard in several places that state machines are a good way to handle such cases, since they're inherently event-driven and the web is too. So I start researching. The wikipedia page (https://en.wikipedia.org/wiki/Finite-state_machine) and the various linked pages are very instructive and indeed explain that a FSM can be used to model UI interaction. I found this 3-parts article series from IBM (http://www.ibm.com/developerworks/library/wa-finitemach1/index.html) that implements a tooltip using a state machine. Then I found 2 clojure libs that helps design a state machine : reduce-fsm (https://github.com/cdorrat/reduce-fsm) and automat (https://github.com/ztellman/automat). Both have the *very* nice feature of being able to generate a state diagram from the code, but only automat provides support for CLJS. I think a state machine fits very well with React.js and as so the various CLJS wrappers, since : - in an event-driven state machine, there's a loop listening to events. This event-loop is naturally provided by web browsers - defining strictly and formally the available states helps reduce bugs and maintain the application - the output is always defined by the combination of the input and the current state, which is *exactly* what the render function of React component are about : displaying DOM based only on the state of the component. Since this state is purely data, and CLJ/CLJS are kings when it comes to data, the benefits would be to be able to test the logic a component outside of the DOM and have components that simply emit events (with the associated payload) to the state machines. The various libs in the CLJ/CLJS ecosystem can help greatly : - the aforementioned automat lib to design and visualize a state machine - Prismatic's Schema (https://github.com/Prismatic/schema), Herbert (https://github.com/miner/herbert) and the likes to formally specify data types/shapes that come in and out of the state machine - test.check to generate lots of input to the state machine and check the output. This can't replace UI testing, but can complement it a lot. Note that Herbert is de facto compatible with test.check - The various React.js wrappers to take this state and simply project it to the DOM. This post is basically a reflection on the subject that I wanted to share and not lose in my mind since I'm new to state machines, and a question to the community : did you already use a state machine to program a web UI ? Successfully ? With which tools ? What do you think of the various libs (aka "the stack" lol) proposed above ? I know that a simple state machine trivially implemented with no libs at all and may seem often overkill. This post from Spotify (https://www.shopify.com/technology/3383012-why-developers-should-be-force-fed-state-machines) and this response (http://www.skorks.com/2011/09/why-developers-never-use-state-machines/) are really interested real world examples of usage (or not) of state machines. Phew ! It was long, I hope I wasn't boring and I'm looking forward to your answers. Let's discuss ! -- 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 a state machine to design/program UI ?
I forgot to add another useful resources, it's "Constructing the User Interface with statecharts" by Ian Horrocks. You can find it in Scribd https://www.scribd.com/doc/235638010/Ian-Horrocks-Constructing-the-User-Interface-Wit-BookZZ-org and Amazon http://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782/ref=sr_1_1?ie=UTF8&qid=1431514704&sr=8-1&keywords=constructing+user+interface+statechart -- 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: Using a state machine to design/program UI ?
I understand the relationship between state machines and event-log/CQRS. A program could just translate the UI events into events stored in an event log, and let them be consumed continually by a state machine. You would basically reduce the events log using the state machine as a reduction function. When you say logic end up in lot of different places, do you mean logic that should be related ? I'd like to understand more about that point. -- 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: Using a state machine to design/program UI ?
Ok, you talk about logic being on the server and the client. I thought you
were saying that related logic was spread across different points from an
architecture point of view, like "some in the event-log consumers", "some
in the components", "some in the request handlers" etc. (these are just
examples).
Khalid aka DjebbZ
@Dj3bbZ
On Wed, May 13, 2015 at 2:30 PM, Colin Yates wrote:
> Yeah, I didn't explain that second point well. Because of the lack of
> (my experience with) web based tooling I typically have most of the
> logic on the back end leaving the UI to be pure rendering only. With
> the symmetry of CLJ and CLJS that technical barrier has disappeared.
>
> Case in point, I am just now coding logic which summarises the
> criteria used to select the data you are seeing. Imagine a table with
> a set of tabs, each tab allowing you to restrict some criteria and the
> table shows you matching results. The logic to produce something like
> "Viewing 132 out of 3423 results for location 1 and location 2, across
> all woogies and non-active wibblies, ..." is less trivial then it
> might sound. Previously I would have returned this as part of the
> results returned from the server {:results [..] :total-count 3423
> :context "for location 1 ..."} where as now I am less nervous about
> that logic living on the web tier. Of course, there are other concerns
> for this case in point around data staleness (you don't want the
> context being updated before the results are updated etc.).
>
> tldr - the symmetry of CLJ and CLJS make it easier (for me at least)
> to put non-trivial logic on the front end
>
>
> On 13 May 2015 at 13:06, Khalid Jebbari wrote:
> > I understand the relationship between state machines and event-log/CQRS.
> A program could just translate the UI events into events stored in an event
> log, and let them be consumed continually by a state machine. You would
> basically reduce the events log using the state machine as a reduction
> function.
> >
> > When you say logic end up in lot of different places, do you mean logic
> that should be related ? I'd like to understand more about that point.
> >
> > --
> > 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.
>
> --
> 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/7STtgK5QiIc/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: Using a state machine to design/program UI ?
I have a question for you Kevin : when you modeled your logic with a state machine, were you able to unit test it outside of the browser ? (Sorry if the answer is in the video, I haven't watched it yet) > Le 14 mai 2015 à 00:00, Kevin Lynagh a écrit : > > In addition to the Horrocks book, take a look at "Practical UML Statecharts > in C / C++". > This book also describes Harel Statecharts, but goes into much more depth > about how one can implement them on embedded systems. > > I've been experimenting with using Harel Statecharts as an architecture for > ClojureScript applications, and it has been working out very well. > > This video from last year describes that work: > > https://www.youtube.com/watch?v=57wJpfMcfnU > > (I haven't open sourced any of these tools, though since I recorded that > video Figwheel came out and David has put a ton of work into the cljs > compiler, so you should be able to get up and running with those tools.) > > -- > 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/7STtgK5QiIc/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: Using a state machine to design/program UI ?
I just watched the video. Wow. Having a live statechart is even better than what I imagined. It reminds me somehow of the NoFlo JavaScript project. This would be an awesome lib to have... (Am I suggesting you should open source this statechart stuff ? :D). Seriously thank you for the pointers. I'll definitely study this methodology. > Le 14 mai 2015 à 00:00, Kevin Lynagh a écrit : > > In addition to the Horrocks book, take a look at "Practical UML Statecharts > in C / C++". > This book also describes Harel Statecharts, but goes into much more depth > about how one can implement them on embedded systems. > > I've been experimenting with using Harel Statecharts as an architecture for > ClojureScript applications, and it has been working out very well. > > This video from last year describes that work: > > https://www.youtube.com/watch?v=57wJpfMcfnU > > (I haven't open sourced any of these tools, though since I recorded that > video Figwheel came out and David has put a ton of work into the cljs > compiler, so you should be able to get up and running with those tools.) > > -- > 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/7STtgK5QiIc/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] Using a state machine to design/program UI ?
Ruslan, I haven't look at the code or tried your example. But being able to draw the program's logic and have it executed is even more than awesome. I'm not sure whether graph-to-code like what you did, or code-to-graph like what automat or Kevin's (from this thread) work do is better, but simply knowing that both are possible in the CLJ(S) world... I'm happy I started this thread. Khalid aka DjebbZ @Dj3bbZ On Thu, May 14, 2015 at 3:45 PM, Ruslan Prokopchuk wrote: > And that is why they should be compiled, not implemented directly in main > language of the project. I've made experimental yEd diagrams → CLJ(S) FSM > compiler and executor (https://github.com/ul/vfsm). Simple example of its > usage could be found here > https://github.com/ul/ampere/tree/master/examples/simple — open > resources/example.graphml with yEd ( > http://www.yworks.com/en/products/yfiles/yed/) to see how control logic > of handler is defined. What is the real fun, that it is easy to spot an > error in the logic looking on that graph. If you rewrite this state machine > in textual code, you will get something harder to inspect. > > четверг, 14 мая 2015 г., 6:39:02 UTC+3 пользователь Erik Price написал: > > Finite state machines are a useful modeling tool, but when implemented > in code they can involve a lot of boilerplate and complexity. These days I > prefer Rx-like paradigms for sophisticated handling of asynchronous events. > > > > > > e > > > > > > On Wed, May 13, 2015 at 5:54 AM, Khalid Jebbari > wrote: > > Hello everyone, > > > > > > > > As a Javascript web developer, I'm thinking more and more about a good > way to design interface so that I don't create a mess. Because I think the > current "state of the art" of web UI development and frameworks is still a > big mess. > > > > > > > > React.js and the CLJS wrapper around them help a bit but not that much I > think. > > > > > > > > My goals are the following : > > > > > > > > - construct the complete UI logic outside of anything web related, so > that it's testable without a browser and usable in other contexts (CLI, > back-end, scripts, whatever) > > > > - being able to *visualize* the logic without having to read all the > code, through diagrams and other means. > > > > > > > > I've heard in several places that state machines are a good way to > handle such cases, since they're inherently event-driven and the web is too. > > > > > > > > So I start researching. The wikipedia page ( > https://en.wikipedia.org/wiki/Finite-state_machine) and the various > linked pages are very instructive and indeed explain that a FSM can be used > to model UI interaction. I found this 3-parts article series from IBM ( > http://www.ibm.com/developerworks/library/wa-finitemach1/index.html) that > implements a tooltip using a state machine. > > > > > > > > Then I found 2 clojure libs that helps design a state machine : > reduce-fsm (https://github.com/cdorrat/reduce-fsm) and automat ( > https://github.com/ztellman/automat). Both have the *very* nice feature > of being able to generate a state diagram from the code, but only automat > provides support for CLJS. > > > > > > > > I think a state machine fits very well with React.js and as so the > various CLJS wrappers, since : > > > > - in an event-driven state machine, there's a loop listening to events. > This event-loop is naturally provided by web browsers > > > > - defining strictly and formally the available states helps reduce bugs > and maintain the application > > > > - the output is always defined by the combination of the input and the > current state, which is *exactly* what the render function of React > component are about : displaying DOM based only on the state of the > component. > > > > > > > > Since this state is purely data, and CLJ/CLJS are kings when it comes to > data, the benefits would be to be able to test the logic a component > outside of the DOM and have components that simply emit events (with the > associated payload) to the state machines. > > > > > > > > The various libs in the CLJ/CLJS ecosystem can help greatly : > > > > - the aforementioned automat lib to design and visualize a state machine > > > > - Prismatic's Schema (https://github.com/Prismatic/schema), Herbert ( > https://github.com/miner/herbert) and the likes to formally specify data > types/shapes that come in and out of the state machine > > > > - test.check to generate lots of input t
Re: [ClojureScript] Using a state machine to design/program UI ?
Generating a functional state machine from a diagram is awesome. Generating a diagram from the code of a state machine is awesome too. But state diagram are only 1 of the 2 visual representations of state machines AFAIK. The other is the state transition table : https://en.wikipedia.org/wiki/State_transition_table I already opened an issue to the automat repo, hoping Zach Tellman will consider generating the table from the code being a good idea. And also in Ruslan's vfsm to generate a state machine from a table. Visual programming for the win, really. Khalid aka DjebbZ @Dj3bbZ On Thu, May 14, 2015 at 10:20 PM, Jamie Orchard-Hays wrote: > No kidding. I have this long blog post germinating in my head about my > experiences with Om and re-frame now that I've developed a reasonably-sized > app in each. Problem is, I have no time to write it. One thing I've come to > appreciate about Om over Reagent is that despite it being more verbose, > it's always clear where you are WRT the React lifecycle and state. Reagent, > being less formal, lends itself to some confusion over what's happening > where. > > In general, I agree with some comments I've seen in this group recently > that we really have a long way to go with rich client web apps. It's still > way too time-consuming, painful and not formalized enough, even with the > awesome tools we have around already. Simple *and* easy is the brass ring. > > > On May 14, 2015, at 3:35 PM, Colin Yates wrote: > > +1 I keep thinking "yeah, this is the stack I will use, let's invest in > this" then something new comes along. Not good for those of use affected > with "grassisalwaysgreeneritus" :). > On 14 May 2015 19:39, "Jamie Orchard-Hays" wrote: > >> This is really interesting stuff. I'd looked over Hoplon a year ago and >> didn't use it as it wasn't React-based. I really liked the >> spread-sheet/cell metaphor. I wish I had more time to explore all of these >> libs! :) CLJS is enjoying quite a Cambrian explosion of interesting >> libraries. >> >> Jamie >> >> On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk >> wrote: >> >> > Jamie, exactly, I took re-frame (it's awesome!) and replaced >> subscriptions mechanism with Javelin cells. I like Javelin, it allows >> elegant and succinct data coordination. See todomvc example in the amper >> and re-frame repos for comparison. >> > >> > Also I've replaced Reagent with Om because of my internal needs, but >> re-frame architecture is View-agnostic in its heart, and I've implemented >> it in ampere. Now it includes only Om adapter, but more to come with >> examples (I plan to make todomvc views.cljs port for every supported View >> library). Hoplon does not require any adapter at all, for example ;-) >> > >> > -- >> > 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. >> >> -- >> 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. >> > > -- > 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. > > > -- > 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/7STtgK5QiIc/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 unsub
Re: [ClojureScript] Using a state machine to design/program UI ?
In the case of global app state combined with a state machine, where would the URL be stored ? Should it be considered a trigger/event of the state machine ? Should it be stored in the state as any other data ? > Le 15 mai 2015 à 03:22, Marc Fawzi a écrit : > > Thanks Brutha! :) > > Sent from my iPhone > >> On May 14, 2015, at 6:11 PM, Jamie Orchard-Hays wrote: >> >> Speaking of Cambrian Explosion, I saw in the latest LispCast a link to a new >> React CLJS lib from weavejester called Brutha: >> https://github.com/weavejester/brutha >> >> Jamie >> >>> On May 14, 2015, at 8:54 PM, Jamie Orchard-Hays wrote: >>> >>> Actually, I'm interested in local transitions (cell=) rather than local >>> state. That is, a view may be interested in transitions that only apply to >>> itself. I like the idea of encapsulating those transitions into the view >>> itself. re-frame's subscriptions are inherently global, at least to >>> whichever namespaces have required the subscriptions. This offers better >>> encapsulation as I understand them. >>> >>> Jamie >>> On May 14, 2015, at 8:27 PM, Daniel Kersten wrote: Personally I find that moving state out of components as re-frame's subscriptions and handlers encourage is a desirable trait and would be cautious about reintroducing local state. Keeping my data in one place (and handling updates and queries through a centralised place) has made it a lot easier for me to manage complex data and logic. I've played with javelin in the past and it's a fantastic library. I quite like the idea of using it as a replacement for (or perhaps together with?) re-frames subscriptions (so reagents ratoms, really), but in my opinion reliance on local state is a mistake. Having said that, I'd love to hear counterpoints. I'm quite interested in the topic of using state machines too. As re-frames readme mentions, app-db updates can be thought of as state transitions, but I think having well defined named states is a good idea as it's very difficult to determine what "state" your application is in by looking at it's data for any non trivial application. I also like the idea of knowing in advance what the valid transitions from any given state are as it's useful for generative testing and debugging and overall understanding of supplication logic. I'm currently mulling over the idea of combining re-frames app-db with a state machine (perhaps using automat). I feel like maybe a hybrid approach could work well, but an unsure how it would look. > On Thu, 14 May 2015 22:34 Jamie Orchard-Hays wrote: > I'm still in the early stages of digesting Javelin, but one idea I keep > having is using it locally in components to make subscriptions that are > otherwise global using reframe. > >> On May 14, 2015, at 4:20 PM, Jamie Orchard-Hays >> wrote: >> > >> No kidding. I have this long blog post germinating in my head about my >> experiences with Om and re-frame now that I've developed a >> reasonably-sized app in each. Problem is, I have no time to write it. >> One thing I've come to appreciate about Om over Reagent is that despite >> it being more verbose, it's always clear where you are WRT the React >> lifecycle and state. Reagent, being less formal, lends itself to some >> confusion over what's happening where. >> >> In general, I agree with some comments I've seen in this group recently >> that we really have a long way to go with rich client web apps. It's >> still way too time-consuming, painful and not formalized enough, even >> with the awesome tools we have around already. Simple *and* easy is the >> brass ring. >> >> >>> On May 14, 2015, at 3:35 PM, Colin Yates wrote: >>> >>> +1 I keep thinking "yeah, this is the stack I will use, let's invest in >>> this" then something new comes along. Not good for those of use >>> affected with "grassisalwaysgreeneritus" :). >>> On 14 May 2015 19:39, "Jamie Orchard-Hays" wrote: This is really interesting stuff. I'd looked over Hoplon a year ago and didn't use it as it wasn't React-based. I really liked the spread-sheet/cell metaphor. I wish I had more time to explore all of these libs! :) CLJS is enjoying quite a Cambrian explosion of interesting libraries. Jamie On May 14, 2015, at 2:26 PM, Ruslan Prokopchuk wrote: > Jamie, exactly, I took re-frame (it's awesome!) and replaced > subscriptions mechanism with Javelin cells. I like Javelin, it > allows elegant and succinct data coordination. See todomvc example > in the amper and re-frame repos for comparison. > >
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Trying to push forward the discussion about Web UI with state machines. I came up with the following decomposition of the core components of a web application : - application state - application data - business logic - ui logic - event processing - presentation layer - routing In this schema, I think the application state is the real core, because every other components is directly related to it, at least if you use a state machine. I came up with the following model. - application data : related to application state because both can easily represented as data. If we want a web app that is completely state-driven (I want this, for debugging, testing and time-travel capabilities), simply merge the data and the state in the same data entity. - business logic/ui logic : in a state machine there's the notion of "actions" executed with each transition (where necessary). So the logic could just be executed by the state machine itself. - event processing : a state machine can be event-driven, and this a perfect match with a web app since the web (and any UI for that matter) is inherently event driven. So the event/input of the state machine could just match the event triggered by the user, as well as custom events if necessary. - presentation layer : simply display the current app-state as HTML/CSS. In the React.js model, it would simply mean updating the app state and letting React render everything. - routing : this is where stuff gets complicated in my mind. In a proper application, lot of state is derived from the URLs. But not all state, for instance whether a modal is displayed or not, or whether a form is validated client side or not isn't tied to a URL. Which tend to let me think that there's some kind of hierarchy in the state machine. The URLs could be represented as events as well in the state machine, but could happen at anytime, whereas other events and related transition depend on the current state in a state machine. So it's like you have a top-level state machine for URLs, and each URL has its own state machine for all interactions in the page. Maybe page-state machine could be refined in multiple levels state machines too, not sure about that. It seems like Hierarchical State Machine may help here, but I haven't studied the subject yet at all. What do you think ? -- 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: Using a state machine to design/program UI ?
Indeed, the combination of all states/transitions could lead to something unreadable and unmanageable. I was talking about that with a colleague the other day. Don't have a solution (yet), I'm still learning and reading about FSM. As I was saying in my previous post, having some sort of hierarchy in states machines could help. It boils down to composability of state machines. A few weeks ago some folks showed me a web UI where they could drag and drop and connect state machines to produce a bigger one. The resulting state machine basically generated a new application they could use for a client. I was REALLY impressed. They were using Elixir for that but it doesn't matter. So, compatibility is key here. The aforementioned clojure libs are using data to represent FSMs, so the composition can be made easily I think (from a syntax point of view at least). Needs more thinking... -- 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: Using a state machine to design/program UI ?
I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. > Le 18 mai 2015 à 19:13, Daniel Kersten a écrit : > > From my understanding of it: > > Use higher level states and decouple them somewhat from the data. > > For example, games do have lots of dynamically changing data. In a modern > shooter you might have dozens of characters with positions, orientation, > velocity, health information, weapons, ammunition, etc all of which can be > constantly changing. And that's just taking the characters into account. > > I wouldn't go and build a state machine that enumerates all of the possible > transitions from a "twelve characters with done distribution of attributes in > this location moving in that direction" state. I'd break it down so that each > character has a high level state like "seeking powerup" or "running". > > Probably not a great example although it does illustrate that you might have > a hierarchy of state machines. In the game example, the highest level might > be something like "in play" or "paused" and the lowest might be an each > characters "firing weapon". > > In client side web app, you could say that each configuration of data is a > state (the re-frame readme mentions that you could think of the app-db like > this), but I think that's too fine grained to be useful. > > Instead I'd define higher level states (possibly in a hierarchy). I'd ask > myself, regardless of the data available, what are the logical states that a > user could be in and for each one, what are the actions that they can perform > (and what state does each action transition them to). > This could be as simple as pages and links, but with a rich single page > application it's more likely finer grained than that. Maybe what dialogs or > widgets are accessible. > > Again, you could then layer these into a hierarchy of state machines. > > One advantage of this is you always know what a user can do at any given time > because you can look at what state they're in. > > I think of FSM states as orthogonal to the data, not as the data itself. The > states dictate what data is accessible and what can be done to it; the data > doesn't dictate what state the application is in. > > I suppose terminology gets confusing, but this is the approach I'm toying > with. I'll see how that goes :) > > But yeah, needs more thinking. > > >> On Mon, 18 May 2015 16:55 Marc Fawzi wrote: >> Games are ideal candidate for straight-forward FSM implementation since you >> normally download the data at game load time and from there on you have a >> *relatively* small set of states that can be transitioned between based in >> user input. You can even apply state minimization techniques to reduce the >> total number of states. >> >> But in a web app you are continuously grabbing data from the server and that >> data is generated based on not only user input but also the state of the >> server side database and that server generated data would modify UI side app >> state and you have to account for all possibilities so the total number of >> states could grow wildly if your UI is data driven (where the state of the >> UI depends on the data in non-trivial ways) but even if your UI state >> dependence on server data was a trivial relationship you could still end up >> with a huge state diagram for the simplest viable business app if you >> include templating the view as part of the UI FSM on top of business logic. >> You could segment your app into micro apps and that will help regardless of >> whether you're building the app as FSM or not. >> >> And what if the state transitions are probability driven? How many states >> will you end up having to chart? >> >> Not convinced YET... >> >> Sent from my iPhone >> >> > On May 18, 2015, at 6:57 AM, Sean Tempesta wrote: >> > >> > Hi Khalid. I found your topic interesting so I thought I'd chime in. >> > Regarding your comments on routing: >> > >> > So, under normal conditions, the initial URL sets the FSM in motion (as an >> > event). We could call this entry point a routing state. Afterward, the >> > state transitions are controlling the urls (not the other way around), >> > right? >> > >> > Outside of normal conditions
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Thanks for the clarification, I didn't about them. Now I need even more reading and thinking :) > Le 18 mai 2015 à 22:23, Marc Fawzi a écrit : > > Back to composability > > I read about stacked vs hierarchical FSMs and it looks like what you want is > a stacked one not a hierarchical one... Subgraphs dont have to be entangled > with the global graph > > Sent from my iPhone > >> On May 18, 2015, at 10:26 AM, Khalid Jebbari >> wrote: >> >> I like how you break up the state machines, it has sense in web app. Page 1 >> has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated >> with it, the higher level FSM knowing just the higher level state of all >> widget displayed. Mmmh... Interesting. >> >>> Le 18 mai 2015 à 19:13, Daniel Kersten a écrit : >>> >>> From my understanding of it: >>> >>> Use higher level states and decouple them somewhat from the data. >>> >>> For example, games do have lots of dynamically changing data. In a modern >>> shooter you might have dozens of characters with positions, orientation, >>> velocity, health information, weapons, ammunition, etc all of which can be >>> constantly changing. And that's just taking the characters into account. >>> >>> I wouldn't go and build a state machine that enumerates all of the possible >>> transitions from a "twelve characters with done distribution of attributes >>> in this location moving in that direction" state. I'd break it down so that >>> each character has a high level state like "seeking powerup" or "running". >>> >>> Probably not a great example although it does illustrate that you might >>> have a hierarchy of state machines. In the game example, the highest level >>> might be something like "in play" or "paused" and the lowest might be an >>> each characters "firing weapon". >>> >>> In client side web app, you could say that each configuration of data is a >>> state (the re-frame readme mentions that you could think of the app-db like >>> this), but I think that's too fine grained to be useful. >>> >>> Instead I'd define higher level states (possibly in a hierarchy). I'd ask >>> myself, regardless of the data available, what are the logical states that >>> a user could be in and for each one, what are the actions that they can >>> perform (and what state does each action transition them to). >>> This could be as simple as pages and links, but with a rich single page >>> application it's more likely finer grained than that. Maybe what dialogs or >>> widgets are accessible. >>> >>> Again, you could then layer these into a hierarchy of state machines. >>> >>> One advantage of this is you always know what a user can do at any given >>> time because you can look at what state they're in. >>> >>> I think of FSM states as orthogonal to the data, not as the data itself. >>> The states dictate what data is accessible and what can be done to it; the >>> data doesn't dictate what state the application is in. >>> >>> I suppose terminology gets confusing, but this is the approach I'm toying >>> with. I'll see how that goes :) >>> >>> But yeah, needs more thinking. >>> >>> >>>> On Mon, 18 May 2015 16:55 Marc Fawzi wrote: >>>> Games are ideal candidate for straight-forward FSM implementation since >>>> you normally download the data at game load time and from there on you >>>> have a *relatively* small set of states that can be transitioned between >>>> based in user input. You can even apply state minimization techniques to >>>> reduce the total number of states. >>>> >>>> But in a web app you are continuously grabbing data from the server and >>>> that data is generated based on not only user input but also the state of >>>> the server side database and that server generated data would modify UI >>>> side app state and you have to account for all possibilities so the total >>>> number of states could grow wildly if your UI is data driven (where the >>>> state of the UI depends on the data in non-trivial ways) but even if your >>>> UI state dependence on server data was a trivial relationship you could >>>> still end up with a huge state diagram for the simplest viabl
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
This is it, Marc. The SFSM diagram represents exactly what I had in mind. Do you think they're viable in the context of a web app ? As long as they can be stacked as needed, they could handle any complexity of UIs, no ? Khalid aka DjebbZ @Dj3bbZ On Mon, May 18, 2015 at 10:34 PM, Marc Fawzi wrote: > "stack-based" is not exactly "stacked" but I was thinking chip design for > some reason ( > http://en.wikipedia.org/wiki/Three-dimensional_integrated_circuit) > > The one diagram that made it obvious: > > > http://gamedev.stackexchange.com/questions/25854/gamestate-management-hierarchical-fsm-vs-stack-based-fsm > > > > > On Mon, May 18, 2015 at 1:28 PM, Khalid Jebbari > wrote: > >> Thanks for the clarification, I didn't about them. >> >> Now I need even more reading and thinking :) >> >> Le 18 mai 2015 à 22:23, Marc Fawzi a écrit : >> >> Back to composability >> >> I read about stacked vs hierarchical FSMs and it looks like what you want >> is a stacked one not a hierarchical one... Subgraphs dont have to be >> entangled with the global graph >> >> Sent from my iPhone >> >> On May 18, 2015, at 10:26 AM, Khalid Jebbari >> wrote: >> >> I like how you break up the state machines, it has sense in web app. Page >> 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM >> associated with it, the higher level FSM knowing just the higher level >> state of all widget displayed. Mmmh... Interesting. >> >> Le 18 mai 2015 à 19:13, Daniel Kersten a écrit : >> >> From my understanding of it: >> >> Use higher level states and decouple them somewhat from the data. >> >> For example, games do have lots of dynamically changing data. In a modern >> shooter you might have dozens of characters with positions, orientation, >> velocity, health information, weapons, ammunition, etc all of which can be >> constantly changing. And that's just taking the characters into account. >> >> I wouldn't go and build a state machine that enumerates all of the >> possible transitions from a "twelve characters with done distribution of >> attributes in this location moving in that direction" state. I'd break it >> down so that each character has a high level state like "seeking powerup" >> or "running". >> >> Probably not a great example although it does illustrate that you might >> have a hierarchy of state machines. In the game example, the highest level >> might be something like "in play" or "paused" and the lowest might be an >> each characters "firing weapon". >> >> In client side web app, you could say that each configuration of data is >> a state (the re-frame readme mentions that you could think of the app-db >> like this), but I think that's too fine grained to be useful. >> >> Instead I'd define higher level states (possibly in a hierarchy). I'd ask >> myself, regardless of the data available, what are the logical states that >> a user could be in and for each one, what are the actions that they can >> perform (and what state does each action transition them to). >> This could be as simple as pages and links, but with a rich single page >> application it's more likely finer grained than that. Maybe what dialogs or >> widgets are accessible. >> >> Again, you could then layer these into a hierarchy of state machines. >> >> One advantage of this is you always know what a user can do at any given >> time because you can look at what state they're in. >> >> I think of FSM states as orthogonal to the data, not as the data itself. >> The states dictate what data is accessible and what can be done to it; the >> data doesn't dictate what state the application is in. >> >> I suppose terminology gets confusing, but this is the approach I'm toying >> with. I'll see how that goes :) >> >> But yeah, needs more thinking. >> >> On Mon, 18 May 2015 16:55 Marc Fawzi wrote: >> >>> Games are ideal candidate for straight-forward FSM implementation since >>> you normally download the data at game load time and from there on you have >>> a *relatively* small set of states that can be transitioned between based >>> in user input. You can even apply state minimization techniques to reduce >>> the total number of states. >>> >>> But in a web app you are continuously grabbing data from the server and >>> that data is generated based on not only user input but
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Regarding SFSMs, it looks like the top-level states would be URLs (in a well behaved application), and the nested ones would be for any widgets inside the pages. Just thinking out loud. Khalid aka DjebbZ @Dj3bbZ On Mon, May 18, 2015 at 10:49 PM, Khalid Jebbari wrote: > This is it, Marc. The SFSM diagram represents exactly what I had in mind. > Do you think they're viable in the context of a web app ? As long as they > can be stacked as needed, they could handle any complexity of UIs, no ? > > Khalid aka DjebbZ > @Dj3bbZ > > On Mon, May 18, 2015 at 10:34 PM, Marc Fawzi wrote: > >> "stack-based" is not exactly "stacked" but I was thinking chip design for >> some reason ( >> http://en.wikipedia.org/wiki/Three-dimensional_integrated_circuit) >> >> The one diagram that made it obvious: >> >> >> http://gamedev.stackexchange.com/questions/25854/gamestate-management-hierarchical-fsm-vs-stack-based-fsm >> >> >> >> >> On Mon, May 18, 2015 at 1:28 PM, Khalid Jebbari > > wrote: >> >>> Thanks for the clarification, I didn't about them. >>> >>> Now I need even more reading and thinking :) >>> >>> Le 18 mai 2015 à 22:23, Marc Fawzi a écrit : >>> >>> Back to composability >>> >>> I read about stacked vs hierarchical FSMs and it looks like what you >>> want is a stacked one not a hierarchical one... Subgraphs dont have to be >>> entangled with the global graph >>> >>> Sent from my iPhone >>> >>> On May 18, 2015, at 10:26 AM, Khalid Jebbari >>> wrote: >>> >>> I like how you break up the state machines, it has sense in web app. >>> Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM >>> associated with it, the higher level FSM knowing just the higher level >>> state of all widget displayed. Mmmh... Interesting. >>> >>> Le 18 mai 2015 à 19:13, Daniel Kersten a écrit : >>> >>> From my understanding of it: >>> >>> Use higher level states and decouple them somewhat from the data. >>> >>> For example, games do have lots of dynamically changing data. In a >>> modern shooter you might have dozens of characters with positions, >>> orientation, velocity, health information, weapons, ammunition, etc all of >>> which can be constantly changing. And that's just taking the characters >>> into account. >>> >>> I wouldn't go and build a state machine that enumerates all of the >>> possible transitions from a "twelve characters with done distribution of >>> attributes in this location moving in that direction" state. I'd break it >>> down so that each character has a high level state like "seeking powerup" >>> or "running". >>> >>> Probably not a great example although it does illustrate that you might >>> have a hierarchy of state machines. In the game example, the highest level >>> might be something like "in play" or "paused" and the lowest might be an >>> each characters "firing weapon". >>> >>> In client side web app, you could say that each configuration of data is >>> a state (the re-frame readme mentions that you could think of the app-db >>> like this), but I think that's too fine grained to be useful. >>> >>> Instead I'd define higher level states (possibly in a hierarchy). I'd >>> ask myself, regardless of the data available, what are the logical states >>> that a user could be in and for each one, what are the actions that they >>> can perform (and what state does each action transition them to). >>> This could be as simple as pages and links, but with a rich single page >>> application it's more likely finer grained than that. Maybe what dialogs or >>> widgets are accessible. >>> >>> Again, you could then layer these into a hierarchy of state machines. >>> >>> One advantage of this is you always know what a user can do at any given >>> time because you can look at what state they're in. >>> >>> I think of FSM states as orthogonal to the data, not as the data itself. >>> The states dictate what data is accessible and what can be done to it; the >>> data doesn't dictate what state the application is in. >>> >>> I suppose terminology gets confusing, but this is the approach I'm >>> toying with. I'll see how that goes :) >>> >>
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Indeed I was thinking during the while about the last project I participated, a classical web site with e-commerce processes and forms, for which FSM would have been useful (both client side and server side). I agree with you, there's no silver bullet when we consider the variety of applications possible on the web platform. > Le 18 mai 2015 à 23:54, Marc Fawzi a écrit : > > with a programing language like ClojureScript, we have multiple paradigms to > deploy to tackle different kinds of design challenges and come up with an > optimal solution to each challenge. > > It's hard to see how using a single-paradigm tool like FSM or SFSM or even > EFSM (the most robust FSM which tackle the complexity of web software > creation [1]) can deal with the novel challenges I run into when building a > cutting edge web app (e.g. real time, complex interactive data > visualizations) > > When was the last time when you've worked on a novel feature and did not meet > a novel challenge? Novel challenges abound in R&D oriented product > development and they are best dealt with when you have multiple paradigms > that you can deploy against it. > > If you're building cookie cutter, conventional, no thrills web apps, then > there are many single-paradigm tools that can be used, including but not > limited to FSMs. > > 1. > https://books.google.com/books?id=zvNvk-1OuBoC&pg=PA10&lpg=PA10&dq=stack+based+efsm&source=bl&ots=uIQZJAxkx3&sig=paxzhNUxozOVynvJxmGlSKINMh0&hl=en&sa=X&ei=DlxaVdfLJo3aoAT-_4CYBQ&ved=0CC0Q6AEwAg#v=onepage&q&f=false > >> On Mon, May 18, 2015 at 1:51 PM, Khalid Jebbari >> wrote: >> Regarding SFSMs, it looks like the top-level states would be URLs (in a well >> behaved application), and the nested ones would be for any widgets inside >> the pages. Just thinking out loud. >> >> Khalid aka DjebbZ >> @Dj3bbZ >> >>> On Mon, May 18, 2015 at 10:49 PM, Khalid Jebbari >>> wrote: >>> This is it, Marc. The SFSM diagram represents exactly what I had in mind. >>> Do you think they're viable in the context of a web app ? As long as they >>> can be stacked as needed, they could handle any complexity of UIs, no ? >>> >>> Khalid aka DjebbZ >>> @Dj3bbZ >>> >>>> On Mon, May 18, 2015 at 10:34 PM, Marc Fawzi wrote: >>>> "stack-based" is not exactly "stacked" but I was thinking chip design for >>>> some reason >>>> (http://en.wikipedia.org/wiki/Three-dimensional_integrated_circuit) >>>> >>>> The one diagram that made it obvious: >>>> >>>> http://gamedev.stackexchange.com/questions/25854/gamestate-management-hierarchical-fsm-vs-stack-based-fsm >>>> >>>> >>>> >>>> >>>>> On Mon, May 18, 2015 at 1:28 PM, Khalid Jebbari >>>>> wrote: >>>>> Thanks for the clarification, I didn't about them. >>>>> >>>>> Now I need even more reading and thinking :) >>>>> >>>>>> Le 18 mai 2015 à 22:23, Marc Fawzi a écrit : >>>>>> >>>>>> Back to composability >>>>>> >>>>>> I read about stacked vs hierarchical FSMs and it looks like what you >>>>>> want is a stacked one not a hierarchical one... Subgraphs dont have to >>>>>> be entangled with the global graph >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On May 18, 2015, at 10:26 AM, Khalid Jebbari >>>>>>> wrote: >>>>>>> >>>>>>> I like how you break up the state machines, it has sense in web app. >>>>>>> Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a >>>>>>> FSM associated with it, the higher level FSM knowing just the higher >>>>>>> level state of all widget displayed. Mmmh... Interesting. >>>>>>> >>>>>>>> Le 18 mai 2015 à 19:13, Daniel Kersten a écrit : >>>>>>>> >>>>>>>> From my understanding of it: >>>>>>>> >>>>>>>> Use higher level states and decouple them somewhat from the data. >>>>>>>> >>>>>>>> For example, games do have lots of dynamically changing data. In a >>>>>>>> modern shooter you might have dozens of characters with positions, >&g
Re: [ClojureScript] Re: Using a state machine to design/program UI ?
Am reading Horrocks' book. Did you ? > Le 19 mai 2015 à 06:17, Mike Thompson a écrit : > >> On Tuesday, May 19, 2015 at 3:13:23 AM UTC+10, Daniel Kersten wrote: >> From my understanding of it: >> >> Use higher level states and decouple them somewhat from the data. >> >> For example, games do have lots of dynamically changing data. In a modern >> shooter you might have dozens of characters with positions, orientation, >> velocity, health information, weapons, ammunition, etc all of which can be >> constantly changing. And that's just taking the characters into account. >> >> I wouldn't go and build a state machine that enumerates all of the possible >> transitions from a "twelve characters with done distribution of attributes >> in this location moving in that direction" state. I'd break it down so that >> each character has a high level state like "seeking powerup" or "running". >> >> Probably not a great example although it does illustrate that you might have >> a hierarchy of state machines. In the game example, the highest level might >> be something like "in play" or "paused" and the lowest might be an each >> characters "firing weapon". >> >> In client side web app, you could say that each configuration of data is a >> state (the re-frame readme mentions that you could think of the app-db like >> this), but I think that's too fine grained to be useful. >> >> Instead I'd define higher level states (possibly in a hierarchy). I'd ask >> myself, regardless of the data available, what are the logical states that a >> user could be in and for each one, what are the actions that they can >> perform (and what state does each action transition them to). >> >> This could be as simple as pages and links, but with a rich single page >> application it's more likely finer grained than that. Maybe what dialogs or >> widgets are accessible. >> >> Again, you could then layer these into a hierarchy of state machines. >> >> One advantage of this is you always know what a user can do at any given >> time because you can look at what state they're in. >> >> I think of FSM states as orthogonal to the data, not as the data itself. The >> states dictate what data is accessible and what can be done to it; the data >> doesn't dictate what state the application is in. >> >> I suppose terminology gets confusing, but this is the approach I'm toying >> with. I'll see how that goes :) > > > As Kevin Lynagh said earlier in this thread, the best book around on this > subject is Horrocks': > http://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782 > > Kevin also mentions a book I've not read yet: "Practical UML Statecharts in > C / C++". > > -- > Mike > > > -- > 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/7STtgK5QiIc/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] Isomorphic ClojureScript
Javascript developer speaking. The problem with isomorphic apps the Node.js way (not the Meteor way) is that you want to run the SAME code both sides, and client-side concerns aren't server-side concerns. Given it's the same language, and some thing are side-agnostic, indeed a great amount of code is shareable like templates (and event handling with React.js), which make the 1st render fast. But other concerns can't really be written the same way on both sides. Current solutions : - Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow you to replace 1-to-1 some files for server-side and client-side. So you need to write your own common interfaces, not easily done. - Use Meteor, and have simple "if(isClient/isServer)" in your code to split the concerns and let Meteor deal with rest. The thing is that Meteor is not really compatible with the rest of Node.js/npm ecosystem, and they make lot of choices for you about the stack. Something lacking with CLJX/CLJC AFAIK is that you can't target *both* Node.js and the browser from the same Clojure code base. -- 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] Using a state machine to design/program UI ?
You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays wrote: > For local state, I mean state that has to do only with the component > itself, nothing to do with the data itself. For example, if I have a > component that can switch between editing/reading states, I can't imagine > why I would want this information stored outside of the component itself. > > Jamie > > On May 19, 2015, at 11:58 AM, Daniel Kersten wrote: > > I don't think it implies local state, necessarily, although it may benefit > from it. I think alternatives can be modular too. > > For example, re-frame's approach of a central place to store data is like > a Blackboard system, which may even help modularity, not hinder it, because > modules don't need to know anything about each other - only that the data > they read and write is in the central place and may be (transparent to the > modules) be accessed/updated by multiple modules transparently (and > hopefully gets validated eg through a schema or constraint system to > prevent one module from writing data that breaks another module). > > On the other hand, local state implies encapsulation and encourages strict > interfaces to access it, which can also help modularity. In my personal > experience this has (more often than not) led to tightly coupled modules > instead, however. > > I personally prefer the re-frame single-place-for-data approach because in > my opinion its benefits outweigh its disadvantages, but perhaps I've just > been doing local state wrong :) (actually pretty likely!) > > > PS: It'll probably be some time before I get a chance to read Horrocks' > book. If anybody knows of any similar content available on the web for me > to read in the meantime, I'd love to hear of it! > > > On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays > wrote: > >> I agree. The word that came to mind while reading your comments, Daniel, >> was "modularity". Does modularity imply local state? Pondering... >> >> Jamie >> >> On May 18, 2015, at 1:26 PM, Khalid Jebbari >> wrote: >> >> I like how you break up the state machines, it has sense in web app. Page >> 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM >> associated with it, the higher level FSM knowing just the higher level >> state of all widget displayed. Mmmh... Interesting. >> >> Le 18 mai 2015 à 19:13, Daniel Kersten a écrit : >> >> From my understanding of it: >> >> Use higher level states and decouple them somewhat from the data. >> >> For example, games do have lots of dynamically changing data. In a modern >> shooter you might have dozens of characters with positions, orientation, >> velocity, health information, weapons, ammunition, etc all of which can be >> constantly changing. And that's just taking the characters into account. >> >> I wouldn't go and build a state machine that enumerates all of the >> possible transitions from a "twelve characters with done distribution of >> attributes in this location moving in that direction" state. I'd break it >> down so that each character has a high level state like "seeking powerup" >> or "running". >> >> Probably not a great example although it does illustrate that you might >> have a hierarchy of state machines. In the game example, the highest level >> might be something like "in play" or "paused" and the lowest might be an >> each characters "firing weapon". >> >> In client side web app, you could say that each configuration of data is >> a state (the re-frame readme mentions that you could think of the app-db >> like this), but I think that's too fine grained to be useful. >> >> Instead I'd define higher level states (possibly in a hierarchy). I'd ask >> myself, regardless of the data available, what are the logical states that >> a user could be in and for each one, what are the actions that they can >> perform (and what state does each action transition them to). >> This could be as simple as pages and links, but with a rich single page >> application it's more likely finer grained than that. Maybe what dialogs or >> widgets are accessible. >> >> Again, you could then layer these into a hierarchy of state machines. >> >> One advantage of this is you always know what a user can do at any given >>
Re: [ClojureScript] Isomorphic ClojureScript
@David, I didn't know this feature. Good to know ! @Marc : it's a matter of trade-offs. Node.js and the JVM are very different platforms. If developer convenience is very important, isomorphic the node.js way with Nashorn or Node could be a good thing. Depends on the developers :) Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 4:01 PM, Marc Fawzi wrote: > << Use CLJX/CLJC to split what goes to the JVM and what goes to the > browser from the same source. Nice, and you get Clojure everywhere>> > > I love this idea in principle but seeing how confusing reader conditionals > can be to a beginner I would personally stick with the Om/Reagent > isomorphic path (nashorn or node) > > > On Wed, May 20, 2015 at 6:56 AM, Khalid Jebbari > wrote: > >> Javascript developer speaking. The problem with isomorphic apps the >> Node.js way (not the Meteor way) is that you want to run the SAME code both >> sides, and client-side concerns aren't server-side concerns. Given it's the >> same language, and some thing are side-agnostic, indeed a great amount of >> code is shareable like templates (and event handling with React.js), which >> make the 1st render fast. But other concerns can't really be written the >> same way on both sides. >> >> Current solutions : >> - Use CLJX/CLJC to split what goes to the JVM and what goes to the >> browser from the same source. Nice, and you get Clojure everywhere >> - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow >> you to replace 1-to-1 some files for server-side and client-side. So you >> need to write your own common interfaces, not easily done. >> - Use Meteor, and have simple "if(isClient/isServer)" in your code to >> split the concerns and let Meteor deal with rest. The thing is that Meteor >> is not really compatible with the rest of Node.js/npm ecosystem, and they >> make lot of choices for you about the stack. >> >> Something lacking with CLJX/CLJC AFAIK is that you can't target *both* >> Node.js and the browser from the same Clojure code base. >> >> -- >> 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. >> > > -- > 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/T6no_srtBzc/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] Isomorphic ClojureScript
That's right ! Ideology leads nowhere. And we'll all have to write javascript (for browsers) one way or the other anyway :) > Le 20 mai 2015 à 16:25, Marc Fawzi a écrit : > > @khalid true re: trade offs... also, good to diversify thinking in just > one tech all day can be a path to ideological stuckness ... :) > >> On Wed, May 20, 2015 at 7:11 AM, Khalid Jebbari >> wrote: >> @David, I didn't know this feature. Good to know ! >> >> @Marc : it's a matter of trade-offs. Node.js and the JVM are very different >> platforms. If developer convenience is very important, isomorphic the >> node.js way with Nashorn or Node could be a good thing. Depends on the >> developers :) >> >> Khalid aka DjebbZ >> @Dj3bbZ >> >>> On Wed, May 20, 2015 at 4:01 PM, Marc Fawzi wrote: >>> << Use CLJX/CLJC to split what goes to the JVM and what goes to the browser >>> from the same source. Nice, and you get Clojure everywhere>> >>> >>> I love this idea in principle but seeing how confusing reader conditionals >>> can be to a beginner I would personally stick with the Om/Reagent >>> isomorphic path (nashorn or node) >>> >>> >>>> On Wed, May 20, 2015 at 6:56 AM, Khalid Jebbari >>>> wrote: >>>> Javascript developer speaking. The problem with isomorphic apps the >>>> Node.js way (not the Meteor way) is that you want to run the SAME code >>>> both sides, and client-side concerns aren't server-side concerns. Given >>>> it's the same language, and some thing are side-agnostic, indeed a great >>>> amount of code is shareable like templates (and event handling with >>>> React.js), which make the 1st render fast. But other concerns can't really >>>> be written the same way on both sides. >>>> >>>> Current solutions : >>>> - Use CLJX/CLJC to split what goes to the JVM and what goes to the browser >>>> from the same source. Nice, and you get Clojure everywhere >>>> - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow >>>> you to replace 1-to-1 some files for server-side and client-side. So you >>>> need to write your own common interfaces, not easily done. >>>> - Use Meteor, and have simple "if(isClient/isServer)" in your code to >>>> split the concerns and let Meteor deal with rest. The thing is that Meteor >>>> is not really compatible with the rest of Node.js/npm ecosystem, and they >>>> make lot of choices for you about the stack. >>>> >>>> Something lacking with CLJX/CLJC AFAIK is that you can't target *both* >>>> Node.js and the browser from the same Clojure code base. >>>> >>>> -- >>>> 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. >>> >>> -- >>> 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/T6no_srtBzc/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://group
Re: [ClojureScript] reagent-nodejs feedback request
To eliminate the need to use 2 different routers, the only possibility I see is to use a js library that works both on client and server-side. Backbone.js has a minimal router like this, you may also want to check crossroads.js or finch.js. But something tells me that you'll need to write some different boilerplate for server and client to plug into this. Both have different ways to "listen to" URL requests/changes. History.js is famous for doing this in the client I think. -- 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] Using a state machine to design/program UI ?
I mentioned it in the very first post of this discussion Khalid aka DjebbZ @Dj3bbZ On Fri, May 22, 2015 at 5:57 PM, Marc Fawzi wrote: > this looks like fun > > https://github.com/cdorrat/reduce-fsm > > ;) > > On Wed, May 20, 2015 at 7:26 AM, Marc Fawzi wrote: > >> Yup, well captured. >> >> On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari > > wrote: >> >>> You would want it if you want to inspect/debug/transmit/replay the whole >>> the state of your application. Having nothing encapsulated and everything >>> in a global state permits this. >>> >>> Khalid aka DjebbZ >>> @Dj3bbZ >>> >>> On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays >>> wrote: >>> >>>> For local state, I mean state that has to do only with the component >>>> itself, nothing to do with the data itself. For example, if I have a >>>> component that can switch between editing/reading states, I can't imagine >>>> why I would want this information stored outside of the component itself. >>>> >>>> Jamie >>>> >>>> On May 19, 2015, at 11:58 AM, Daniel Kersten >>>> wrote: >>>> >>>> I don't think it implies local state, necessarily, although it may >>>> benefit from it. I think alternatives can be modular too. >>>> >>>> For example, re-frame's approach of a central place to store data is >>>> like a Blackboard system, which may even help modularity, not hinder it, >>>> because modules don't need to know anything about each other - only that >>>> the data they read and write is in the central place and may be >>>> (transparent to the modules) be accessed/updated by multiple modules >>>> transparently (and hopefully gets validated eg through a schema or >>>> constraint system to prevent one module from writing data that breaks >>>> another module). >>>> >>>> On the other hand, local state implies encapsulation and encourages >>>> strict interfaces to access it, which can also help modularity. In my >>>> personal experience this has (more often than not) led to tightly coupled >>>> modules instead, however. >>>> >>>> I personally prefer the re-frame single-place-for-data approach because >>>> in my opinion its benefits outweigh its disadvantages, but perhaps I've >>>> just been doing local state wrong :) (actually pretty likely!) >>>> >>>> >>>> PS: It'll probably be some time before I get a chance to read Horrocks' >>>> book. If anybody knows of any similar content available on the web for me >>>> to read in the meantime, I'd love to hear of it! >>>> >>>> >>>> On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays >>>> wrote: >>>> >>>>> I agree. The word that came to mind while reading your comments, >>>>> Daniel, was "modularity". Does modularity imply local state? Pondering... >>>>> >>>>> Jamie >>>>> >>>>> On May 18, 2015, at 1:26 PM, Khalid Jebbari >>>>> wrote: >>>>> >>>>> I like how you break up the state machines, it has sense in web app. >>>>> Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM >>>>> associated with it, the higher level FSM knowing just the higher level >>>>> state of all widget displayed. Mmmh... Interesting. >>>>> >>>>> Le 18 mai 2015 à 19:13, Daniel Kersten a écrit : >>>>> >>>>> From my understanding of it: >>>>> >>>>> Use higher level states and decouple them somewhat from the data. >>>>> >>>>> For example, games do have lots of dynamically changing data. In a >>>>> modern shooter you might have dozens of characters with positions, >>>>> orientation, velocity, health information, weapons, ammunition, etc all of >>>>> which can be constantly changing. And that's just taking the characters >>>>> into account. >>>>> >>>>> I wouldn't go and build a state machine that enumerates all of the >>>>> possible transitions from a "twelve characters with done distribution of >>>>> attributes in this location moving in that direction" state. I'd break it >>>>> down so that each character has a high lev
Re: [ClojureScript] Isomorphic ClojureScript
The following book isn't our yet, but it's written by a real javascript expert. Pretty sure we will find inspiration to do isomorphic CLJS apps. https://leanpub.com/learn-javascript-react-nodejs-es6/ -- 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] Using a state machine to design/program UI ?
So the various states are encapsulated in a go loop ? I always knew that core.async could be used to model FSM's. Well, if you can share the code somehow, do so. > Le 1 juin 2015 à 15:26, Herwig Hochleitner a écrit : > > Wow, big thread. > I just want to offer, how I've done a FSM implementation in CLJS: > > - FSM edges are core.async channels > - FSM state changes are represented by passing a token object (which can > contain additional state vars) across an edge channel > - Each state is represented by a go-loop, with a single in-edge and multiple > out-edges > - After being passed the token by its in-edge, a state runs, then passes the > token to one of its out-edges > > All said and done, this mainly exploits the excellent work on core.async and > core.match. Overall, it smells a lot like actors, only that the possible > messages are pre-determined. > If you are interested, ping me for code. > -- > 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/7STtgK5QiIc/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] Using a state machine to design/program UI ?
Thx ! Will be an interesting read > Le 1 juin 2015 à 18:00, Herwig Hochleitner a écrit : > > 2015-06-01 17:35 GMT+02:00 Khalid Jebbari : >> So the various states are encapsulated in a go loop? > > In multiple go-loops, actually. > >> I always knew that core.async could be used to model FSM's. > > In a way, core.async go blocks desugar into an fsm implementation (reified > state, explicit state transitions). Maybe that's what makes them well-suited > to implementing FSMs on top. > >> Well, if you can share the code somehow, do so. > > https://www.refheap.com/101966 > -- > 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/7STtgK5QiIc/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] Enlive-style templating in server-side clojurescript?
There is a pure javascript solution that works well on Node.js : https://github.com/substack/hyperglue >From substack, a very talented Node.js developer. The concept is somehow >similar to Enlive. Given an HTML file, apply transformations on selectors >declaratively by passing an object. Check it out, it might do the job for now. On Monday, July 6, 2015 at 8:47:43 PM UTC+2, Creighton Kirkendall wrote: > Tim, > There is a current effort underway by Luke Vanderhart to port enlive to cljs. > I know that he has a working version in his repo. He is working towards > getting the changes accepted into main enlive project. > > > https://github.com/levand > > > > Creighton > > > On Tue, Nov 11, 2014 at 2:55 AM, Tim Galebach wrote: > Hi, I've been creating some nodejs servers in ClojureScript for some projects > I'm working on, and it has worked quite well so far. > > > > I now want to do some server-side templating, serving static html to the > client. The problem I'm running into so far is that most of the templating > libraries for ClojureScript (kioo, enfocus, etc.) seem to require the dom to > perform manipulations on HTML. > > > > Other solutions like hiccups are less viable because I want to be easily able > to mockup in HTML and also work with designers. > > > > I love the Enlive approach in Clojure; is there anything similar for cljs, or > something I'm missing in one of the existing libraries? > > > > -- > > 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] HTML DOM to Edn
I know that Enlive does this internally, it uses JSoup from Java to convert to plain Clojure data structure. Not sure it exposes this functionality directly though. -- 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] Scripting with Clojure(Script) : Plain Clojure ? Node.js ? Boot ? Planck ? Pixie ?
Hi every one, Just starting this thread to gather feedback from people who used CLJ(S) to script and replace, you know, shell/Python/Ruby/Whatever. Pretty sure it's a dream to code AND script with CLJ(S). I know that it's possible to do it with CLJS backed by Node.js/io.js, with Boot somehow, with plain Clojure, with Mike Fikes' Planck (only OSX for now though), and Timothy Baldridge's Pixie which is not Clojure but quite close. If you use any or several, please post your feeback here. It's a nice time to CLJ(S) all the things :) -- 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] Problems with code-splitting
Hello,
I'm trying to package all our trackers code (think Google analytics and the
likes) into different splits so that they don't make base JS package too
big and don't slow down time to interactive. Good idea, right ?
Our strategy is basically to write the trackers code in Javascript first
with Google Closure compiler in mind (goog.provide(), goog.require() etc.)
and add those libs to our CLJS project and also package it as a standalone
Javascript file for others non-CLJS project. So far it works really well,
until now that I'm trying to code-split them.
My first experiment fails because the code of the split ends up in the base
package instead, even though the split file is created. But this split file
is empty. Here's the configuration:
Linux
Boot 2.7.1 with boot-cljs 2.1.4
Clojure 1.9
ClojureScript 1.9.946
Java 8 (openjdk version "1.8.0_144")
CLJS compiler options:
```
{:main "yoda.core"
:libs ["trackers/google_analytics.js" ] ;; lot of trackers
here...
:modules{:google-analytics {:entries
'#{yoda.tracking.google-analytics} ;; cljs namespace that wraps the call to
JS tracker, to be able to call `(loader/set-loaded! :google-analytics)`
:output-to "js/google-analytics.js"}}
:asset-path "/yd/js/main.out"
:optimizations :simple
:source-map true
:parallel-build true
:verbosetrue}
```
I use the modules like this in the CLJS code:
```
;; CLJS wrapper namespace
(ns yoda.tracking.google-analytics
(:require [cljs.loader :as loader]
[trackers.google-analytics :as ga]))
(defn start [ga-tracking-id entity]
(ga/start ga-tracking-id entity))
(loader/set-loaded! :google-analytics)
;; Code that lazy-loads it somewhere else
(loader/load :google-analytics
(fn []
((resolve 'yoda.tracking.google-analytics/start)
ga-tracking-id entity)))
```
It seems to work when I look at the browser console:
log:Module loaded: cljs_base
log:Module loaded: google_analytics
But when I examine the cljs_base.js and google_analytics.js files, the
problem appears: cljs_base.js contains the code of my CLJS wrapper
namespace, and google_analytics.js is empty (apart from the comment for
source-map).
With the `:verbose true` option it looks like the CLJS compiler does the
work properly:
Building module :google-analytics
# ... several entries ...
adding entry [trackers.google-analytics] # the JS code
adding entry (yoda.tracking.google-analytics) # our CLJS wrapper namespace
module :google-analytics depends on :cljs-base
Furthermore I expected the google_analytics.js to be loaded with a network
request, but there's only the request to load cljs_base.js.
Is it because of cross module code motion ? It seems that the code of the
CLJS tracker is moved to the main module, but I don't understand why.
Thanks in advance for your help.
--
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] Problems with code splitting
Hello,
I'm trying to package all our trackers code (think Google analytics and the
likes) into different splits so that they don't make base JS package too
big and don't slow down time to interactive. Good idea, right ?
Our strategy is basically to write the trackers code in Javascript first
with Google Closure compiler in mind (goog.provide(), goog.require() etc.)
and add those libs to our CLJS project and also package it as a standalone
Javascript file for others non-CLJS project. So far it works really well,
until now that I'm trying to code-split them.
My first experiment fails because the code of the split ends up in the base
package instead, even though the split file is created. But this split file
is empty. Here's the configuration:
Linux
Boot 2.7.1 with boot-cljs 2.1.4
Clojure 1.9
ClojureScript 1.9.946
Java 8 (openjdk version "1.8.0_144")
CLJS compiler options:
```
{:main "yoda.core"
:libs ["trackers/google_analytics.js" ] ;; lot of trackers
here...
:modules{:google-analytics {:entries
'#{yoda.tracking.google-analytics} ;; cljs namespace that wraps the call to
JS tracker, to be able to call `(loader/set-loaded! :google-analytics)`
:output-to "js/google-analytics.js"}}
:asset-path "/yd/js/main.out"
:optimizations :simple
:source-map true
:parallel-build true
:verbosetrue}
```
I use the modules like this in the CLJS code:
```
;; CLJS wrapper namespace
(ns yoda.tracking.google-analytics
(:require [cljs.loader :as loader]
[trackers.google-analytics :as ga]))
(defn start [ga-tracking-id entity]
(ga/start ga-tracking-id entity))
(loader/set-loaded! :google-analytics)
;; Code that lazy-loads it somewhere else
(loader/load :google-analytics
(fn []
((resolve 'yoda.tracking.google-analytics/start)
ga-tracking-id entity)))
```
It seems to work when I look at the browser console:
log:Module loaded: cljs_base
log:Module loaded: google_analytics
But when I examine the cljs_base.js and google_analytics.js files, the
problem appears: cljs_base contains the code of my CLJS wrapper namespace,
and google_analytics.js is empty (apart from the comment for source-map).
With the `:verbose true` option it looks like the CLJS compiler does the
work properly:
Building module :google-analytics
# ... several entries ...
adding entry [trackers.google-analytics] # the JS code
adding entry (yoda.tracking.google-analytics) # our CLJS wrapper namespace
module :google-analytics depends on :cljs-base
Furthermore I expected the google_analytics.js to be loaded with a network
request, but there's only the request to load cljs_base.js.
Is it because of cross module code motion ? It seems that the code of the
CLJS tracker is moved to the main module, but I don't understand why.
Thanks in advance for your help.
--
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] Problems with code-splitting
No I'm really lazy loading from another namespace, our `yoda.tracking` where all happens. This ns doesn't `require` at all the lazy loaded module, it just `resolve` it. I will work on a minimal repro case based on boot-cljs next week. Thanks for your attention. -- 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] Problems with code-splitting
I managed to create a minimal reproduction repository. It’s definitely a problem of Boot-cljs, not of the CLJS compiler itself. The repo (with problem statement and instructions): https://github.com/DjebbZ/code-splitting-bug-boot-cljs Will post on boot-cljs issue too, it may help them spot the problem. On Saturday, February 3, 2018 at 2:37:18 PM UTC+1, Khalid Jebbari wrote: > > No I'm really lazy loading from another namespace, our `yoda.tracking` > where all happens. This ns doesn't `require` at all the lazy loaded module, > it just `resolve` it. I will work on a minimal repro case based on > boot-cljs next week. > > Thanks for your attention. > -- 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] Problems with code-splitting
Bug filed: https://github.com/boot-clj/boot-cljs/issues/183 On Monday, February 5, 2018 at 5:22:58 PM UTC+1, Khalid Jebbari wrote: > > I managed to create a minimal reproduction repository. It’s definitely a > problem of Boot-cljs, not of the CLJS compiler itself. > > The repo (with problem statement and instructions): > https://github.com/DjebbZ/code-splitting-bug-boot-cljs > > Will post on boot-cljs issue too, it may help them spot the problem. > > On Saturday, February 3, 2018 at 2:37:18 PM UTC+1, Khalid Jebbari wrote: >> >> No I'm really lazy loading from another namespace, our `yoda.tracking` >> where all happens. This ns doesn't `require` at all the lazy loaded module, >> it just `resolve` it. I will work on a minimal repro case based on >> boot-cljs next week. >> >> Thanks for your attention. >> > -- 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] Code-splitting question
Hello, Say I have 2 namespaces in CLJS/CLJC, A and B. A requires B explicitly. I want to produce a js file for each namespace, A.js and B.js. So I use the code-splitting feature, and create a dedicated module entry for each namespace, :A and :B. What's exactly the difference between specifying that module :A ":depends-on" :B and not specifying it ? Surely the compiler can understand the dependence by just analyzing the requires in code. -- 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: Code-splitting question
Thanks for the pointer. I've read the thread twice though and don't fully understand your answer. I'll try to play with :depends-on in our project next week and analyse the output. But detailed explanation is still welcome. Le 24 févr. 2018 10:51, "Thomas Heller" a écrit : > I answered a similar question a while ago: > https://groups.google.com/d/msg/clojurescript/Gk1XA0aIxJM/Ixu45z-wkEoJ > > > On Friday, February 23, 2018 at 7:06:43 PM UTC+1, Khalid Jebbari wrote: >> >> Hello, >> >> Say I have 2 namespaces in CLJS/CLJC, A and B. A requires B explicitly. >> >> I want to produce a js file for each namespace, A.js and B.js. So I use >> the code-splitting feature, and create a dedicated module entry for each >> namespace, :A and :B. >> >> What's exactly the difference between specifying that module :A >> ":depends-on" :B and not specifying it ? Surely the compiler can understand >> the dependence by just analyzing the requires in code. >> >> -- > 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/0s2xiicjm8U/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 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.
Re: [ClojureScript] Code-splitting question
Is it true to say that the dependency on :cljs-base is handled by the compiler ? It seems so when I look at the code generated in :none mode. I'd love to understand why it's not possible between modules. Le 24 févr. 2018 21:09, "David Nolen" a écrit : > You must specify :depends-on - the compiler will not do this for you. > > David > > On Fri, Feb 23, 2018 at 1:06 PM, Khalid Jebbari > wrote: > >> Hello, >> >> Say I have 2 namespaces in CLJS/CLJC, A and B. A requires B explicitly. >> >> I want to produce a js file for each namespace, A.js and B.js. So I use >> the code-splitting feature, and create a dedicated module entry for each >> namespace, :A and :B. >> >> What's exactly the difference between specifying that module :A >> ":depends-on" :B and not specifying it ? Surely the compiler can understand >> the dependence by just analyzing the requires in code. >> >> -- >> 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. >> > > -- > 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/0s2xiicjm8U/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 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] Code-splitting and closure libs problem ?
Hello,
I have a problem with one of the CLJS split module I lazy load. This CLJS
split depends on a manually written Closure library in Javascript, itself
depending on another manually written Closure lib. When the split loads and
is executed, it successfully loads its Closure dependency but this Closure
lib fails to load its own Closure dep. I can verify it in the browser
console, the transitive deep Closure lib namespace doesn't exist.
The goal is to lazy load external trackers (à la Google Analytics) only
when necessary, so I wrap the small JS code they require in a CLJS
namespace that I can lazy-load with cljs.loader. As a note, another reason
we wrap Closure tracker libs in CLJS ns is we also use them in non CLJS
projects so we can't directly `goog.require` cljs.loader in them.
Details:
Env:
Clojure 1.9.0
Clojurescript 1.9.946
Linux
openjdk version "1.8.0_162"
Boot 2.7.1 and boot-cljs 2.1.4
CLJS compiler options:
Boot-cljs main.cljs.edn
{:require [yoda.core]
:init-fns [yoda.core/init]
:compiler-options {:libs ["trackers/dataLayer.js"
"trackers/google_analytics.js" ;; depends
on trackers/dataLayer.js
"trackers/other_tracker.js"]
:output-dir "js"
:modules{:cljs-base{:output-to "js/main.js"}
:google-analytics {:entries
#{yoda.tracking.google-analytics-wrapper} ;; depends on
trackers/google_analytics.js
:output-to
"js/main.out/google_analytics_wrapper.js"}
:other-tracker{:entries
#{yoda.tracking.other-tracker-wrapper} ;; depends on
trackers/other_tracker.js
:output-to
"js/main.out/other_tracker_wrapper.js"
Other CLJS compiler options in build.boot:
(task-options! cljs {:compiler-options {:asset-path "/yd/js"
:optimizations :none
:source-map true
:parallel-build true
:verbose true}})
Code-loading in my-project.tracking namespace:
;; start external trackers
(loader/load :google-analytics
(fn []
((resolve
'my-project.tracking.google-analytics-wrapper/start) ga-tracking-id)))
(loader/load :other-tracker
(fn []
((resolve
'my-project.tracking.other-tracker-wrapper/start
The generated cljs_deps.js looks ok:
goog.addDependency("../trackers/dataLayer.js", ['trackers.dataLayer'],
['goog.array']);
goog.addDependency("../trackers/google_analytics.js",
['trackers.google_analytics'], ['trackers.dataLayer', 'goog.net.Cookies']);
goog.addDependency("../my_project/tracking/google_analytics_wrapper.js",
['my_project.tracking.google_analytics_wrapper'], ['cljs.loader',
'trackers.google_analytics', 'cljs.core']);
goog.addDependency("../trackers/other_tracker.js",
['trackers.other_tracker'], []);
goog.addDependency("../yoda/tracking/other_tracker_wrapper.js",
['yoda.tracking.other_tracker_wrapper'], ['trackers.other_tracker',
'cljs.loader', 'cljs.core']);
Problems:
1. The browser requests source-maps for all the Closure libs in trackers/
which is weird because the compilation doesn't change them. They're kept as
is. No need to use source-maps for plain JS code right ?
2. The browser requests source-maps at the wrong URI for split modules: it
tries to load them from the root path / directly. Here's the error in the
browser
Source map error: TypeError: NetworkError when attempting to fetch resource.
Resource URL: null
Source Map URL: google_analytics_wrapper.js.map ;; it should be
/yd/js/my_project/tracking/google_analytics_wrapper.js.map where it does
exist (verified on disk)
3. Printing the `trackers` global JS variable in the browser (for the
"trackers" part of the trackers.XXX namespaces) shows that it doesn't
contains the dataLayer namespace, the transitive Closure lib.
4. Code splitting works fine for the `other_tracker` split, I can verify
its code is executed. Hence problem #3 seems to come from the transitive
dependency.
I hope I was clear in explaining the problem. Happy to help you help me by
answering any question.
--
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] Creating a map entry
Is it possible to create a map entry directly with the MapEntry type? I see in
the source code of CLJS that the type expects 3 parameters, key val and hash.
I've glanced quickly at usages and it seems most usages revolves to (MapEntry.
k v nil). Is it ok to use in app? Is it too low-level? I'd like to use it in
situations where I populate a map from vectors, like (silly example)
(into {} (map-indexed (fn [idx v] (MapEntry. idx val nil) [1 2 3]))
And what does it mean in cljc code ? Is this ok in Clojure too?
--
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: Creating a map entry
olve_deps.invoke(alpha.clj:210)
at
clojure.tools.deps.alpha.script.make_classpath$create_classpath.invokeStatic(make_classpath.clj:59)
at
clojure.tools.deps.alpha.script.make_classpath$create_classpath.invoke(make_classpath.clj:52)
at
clojure.tools.deps.alpha.script.make_classpath$run.invokeStatic(make_classpath.clj:70)
at
clojure.tools.deps.alpha.script.make_classpath$run.invoke(make_classpath.clj:64)
at
clojure.tools.deps.alpha.script.make_classpath$_main.invokeStatic(make_classpath.clj:109)
at
clojure.tools.deps.alpha.script.make_classpath$_main.doInvoke(make_classpath.clj:84)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:702)
at clojure.core$apply.invokeStatic(core.clj:657)
at clojure.main$main_opt.invokeStatic(main.clj:317)
at clojure.main$main_opt.invoke(main.clj:313)
at clojure.main$main.invokeStatic(main.clj:424)
at clojure.main$main.doInvoke(main.clj:387)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.lang.Var.applyTo(Var.java:702)
at clojure.main.main(main.java:37)
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not
find artifact criterum:criterum:jar:0.4.4 in central
(https://repo1.maven.org/maven2/)
at
org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:48)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:365)
at
org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:583)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:259)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:498)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:399)
... 34 more
```
On Wednesday, October 17, 2018 at 11:35:25 PM UTC+2, Khalid Jebbari wrote:
>
> Is it possible to create a map entry directly with the MapEntry type? I
> see in the source code of CLJS that the type expects 3 parameters, key val
> and hash. I've glanced quickly at usages and it seems most usages revolves
> to (MapEntry. k v nil). Is it ok to use in app? Is it too low-level? I'd
> like to use it in situations where I populate a map from vectors, like
> (silly example)
>
> (into {} (map-indexed (fn [idx v] (MapEntry. idx val nil) [1 2 3]))
>
> And what does it mean in cljc code ? Is this ok in Clojure too?
>
>
--
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: Creating a map entry
Ooops, silly me... Thanks for catch.
On Thu, Oct 18, 2018, 4:55 PM Alex Miller wrote:
>
>
> On Thursday, October 18, 2018 at 4:07:32 AM UTC-5, Khalid Jebbari wrote:
>>
>>
>> PS: I couldn't get clojure cli to download criterium to run the
>> benchmark, so I ended up using the REPL provided by in my current app setup
>> (based on Clojure 1.9.0, Boot 2.8.2 and criterium 0.4.4, the latest stable
>> versions).
>> Here's the command I ran and the error:
>>
>> ```
>> > clj -Sdeps "{:deps {org.clojure/clojure {:mvn/version \"1.9.0\"}
>> criterum {:mvn/version \"0.4.4\"}}}"
>> Error building classpath. Could not find artifact
>> criterum:criterum:jar:0.4.4 in central (https://repo1.maven.org/maven2/)
>>
>
> You misspelled "criterium" in your deps.
>
> --
> 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/doSapNEhLjc/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 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: ANN: ClojureScript 1.10.439
Reporting build-times changes, in a ~15loc CLJ/CLJS/CLC project, on a 8-cores CPU machine, with :parallel-build always true and timings as reported by :compiler-stats true, using boot-cljs. I've run each build at least twice to check for variations. With CLJS 1.10.339 - :optimizations :none Compile sources, elapsed time: 11628.251228 msecs Compile sources, elapsed time: 1865.551867 msecs => Total: ~13.5 secs (13493.803095 msecs) - :optimizations :advanced Compile sources, elapsed time: 13882.684487 msecs Compile sources, elapsed time: 22.481435 msecs Optimizing with Google Closure Compiler, elapsed time: 15468.294224 msecs Optimizing 265 sources, elapsed time: 15892.028818 msecs => Total: ~45 secs (45265.488964 msecs) With CLJS 1.10.439 - :optimizations :none Compile sources, elapsed time: 11551.295873 msecs Compile sources, elapsed time: 1337.826701 msecs => Total: ~12.8 secs (12889.12257399 msecs) - :optimizations :advanced Compile sources, elapsed time: 12874.073566 msecs Compile sources, elapsed time: 23.319803 msecs Optimizing with Google Closure Compiler, elapsed time: 16746.485323 msecs Optimizing 265 sources, elapsed time: 17214.70572 msecs => Total: ~46.8 secs (46858.584412 msecs) No significant changes in compilation times, but it may be due to boot/boot-cljs overhead, no idea. This is completely unscientific, as it may not make use of the some things enabled only when using cljs.main. I've also received a warning for a :private-var-access in one of my dependencies, will open an issue there. End of report. And big thanks to all contributors! On Monday, November 5, 2018 at 7:34:18 PM UTC+1, 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.10.439"] > > Please refer the announce post for the details: > https://clojurescript.org/news/2018-11-02-release > > As always, feedback welcome! > > ## 1.10.439 > > ### Changes > * CLJS-2904: Default :npm-deps to false > * CLJS-2878: Update Closure Compiler to v20180805 > * CLJS-2827: Avoid var special in core macros for private var access > * CLJS-2819: Warn on non-dynamic earmuffed vars > * CLJS-2806: Bump test.check to 0.10.0-alpha3 > * CLJS-2815: Support string keys in :global-exports > * CLJS-2812: Support for overriding object printing > * CLJS-2805: Bump tools.reader to 1.3.0 > * CLJS-1702: Warning when using private vars > * Align ClojureScript AST to tools.analyzer > > ### Enhancements > * CLJS-2903: Support fingerprinting > * CLJS-2897: cljs.main: Display initial REPL prompt sooner > * CLJS-2884: Support for GraalJS RC6 > * CLJS-2859: Graal.JS: Enable high-res timers by default, allow > user-configuration > * CLJS-2831: Add a graaljs REPL environment > * CLJS-1997: Outward function type hint propagation > * CLJS-844: Optimize js->clj by switching to transients > * CLJS-2442: `set` and `vec` performance enhancements > > ### Fixes > * CLJS-2953: stest/with-instrument-disabled prints warning of private use > * CLJS-2728: Ability to disable macro spec checks > * CLJS-2843: s/explain of evaluated predicate yields :s/unknown > * CLJS-2951: Add a spec generator for some? > * CLJS-2940: Can't define nilable spec on undefined pred > * CLJS-2948: Stack overflow calling instrumented variadic fn with zero args > * CLJS-2793: Instrumenting breaks function with varargs > * CLJS-2934: Enhanced delay printing > * CLJS-2864: Optimize str macro for single arity case > * CLJS-1297: defrecord does not emit IKVReduce protocol > * CLJS-2937: docstring for to-array > * CLJS-2943: Update merge-with to use key / val > * CLJS-2941: seqable? should return true for nil > * CLJS-2915: Tests fail if directory has a period (.) in the path > * CLJS-2782: lein test fails if directory has hyphens > * CLJS-2911: Avoid infinite loop on infinite partitions > * CLJS-2906: cljs.main: Crash when with default REPL > * CLJS-2883: Instrumentation fails compilation with a large number of > spec'd functions > * CLJS-2896: Allow parallel analysis and compilation > * CLJS-2893: seq: use .-length instead of alength for strings > * CLJS-2890: fspec role in problem path is not useful > * CLJS-2887: Improve names in core macro specs > * CLJS-2891: stop including data in ex-info message > * CLJS-2888: Printing of spec problems buries the failing predicate which > should be more prominent > * CLJS-2861: Self-host: :checked-arrays not working > * CLJS-2852: Clojure imparity: ns-publics returns different arglists for > macros > * CLJS-2725: Doc on spec keywords > * CLJS-2665: Port clojure.spec.test.alpha/enumerate-namespace > * CLJS-2848: Default explain printer prints root val and spec > * CLJS-2846: [spec] s/tuple explain-data :pred problem > * CLJS-2847: s/coll-of and s/every gen is very slow if :kind specified > without :into > * CLJS-2841: [spec] instrument exception doesn't contain function name
[ClojureScript] ANN: ClojureScript 1.10.516
Congrats David and all contributors! Not a feedback but a question: does the new type inference have an influence on the generated JS code ? Can it make bundles smaller ? -- 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: ANN: ClojureScript 1.10.516
I get it. Maybe in the future the type inference could inform the Closure Compiler of the types, so that it could emit smaller code ? Really curious about it. On Friday, February 1, 2019 at 11:06:49 AM UTC+1, Thomas Heller wrote: > > > > On Friday, February 1, 2019 at 5:54:13 AM UTC+1, Khalid Jebbari wrote: >> >> Can it make bundles smaller ? >> > > Yes in theory, but only by a very small fraction. The cljs.core/str macro > may emit less code in certain situations for example but after :advanced > optimizations the difference will be very small. So I wouldn't expect any > substantial reductions overall, it is mostly about the compile time > warnings. > -- 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] Question about code-splitting and loading of dependent modules.
Hello, I create 3 modules in the :modules configuration, say :cljs-base, :a & :b, and know that module :a depends on code in the module :b (and in :cljs-base of course). If I manually load only :a with `(cljs.loader/load :a)`, will it automatically load :b? My local testing seems to show that it doesn't. -- 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: Question about code-splitting and loading of dependent modules.
In case it wasn't clear, the javascript file for :cljs-base is included as a script tag in the html, and it loads :a. On Friday, February 1, 2019 at 1:01:33 PM UTC+1, Khalid Jebbari wrote: > > Hello, > > I create 3 modules in the :modules configuration, say :cljs-base, :a & :b, > and know that module :a depends on code in the module :b (and in :cljs-base > of course). If I manually load only :a with `(cljs.loader/load :a)`, will > it automatically load :b? My local testing seems to show that it doesn't. > > -- 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: Question about code-splitting and loading of dependent modules.
Yes I did. Calling load :a loads :b in XHR then nothing, doesn't load :a
afterwards.
On Fri, Feb 1, 2019, 10:44 PM Thomas Heller You didn't show your config but did you correctly configure that :a
> depends on :b? eg. :depends-on #{:b}? That can't be inferred so you must
> manually configure it.
>
> On Friday, February 1, 2019 at 1:11:20 PM UTC+1, Khalid Jebbari wrote:
>>
>> In case it wasn't clear, the javascript file for :cljs-base is included
>> as a script tag in the html, and it loads :a.
>>
>> On Friday, February 1, 2019 at 1:01:33 PM UTC+1, Khalid Jebbari wrote:
>>>
>>> Hello,
>>>
>>> I create 3 modules in the :modules configuration, say :cljs-base, :a &
>>> :b, and know that module :a depends on code in the module :b (and in
>>> :cljs-base of course). If I manually load only :a with `(cljs.loader/load
>>> :a)`, will it automatically load :b? My local testing seems to show that it
>>> doesn't.
>>>
>>> --
> 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/NwRtAgr9ltc/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 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.
Re: [ClojureScript] Re: Question about code-splitting and loading of dependent modules.
I did this already in all modules. I noticed I had to add to the :main namespace (loader/set-loaded! :cljs-base) On Sat, Feb 2, 2019, 10:49 AM Thomas Heller In standard CLJS you must add a manual call to let the runtime know that > your module finished loading. > > (cljs.loader/set-loaded! :a) > > Somewhere near the "end" of your modules. Only with this call will the > runtime continue loading the code. > > https://clojurescript.org/guides/code-splitting > > > -- > 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/NwRtAgr9ltc/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 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: Question about code-splitting and loading of dependent modules.
I realize it's much better if I give the complete configuration.
latest ClojureScript stable 1.10.516
deps.edn alias: {:cljs {:main-opts ["-m" "cljs.main" "-co" "cljs-dev.edn"
"--compile"]}}
cljs-dev.edn file:
{:main "my-app.core"
:parallel-build true
:optimizations :simple
:output-dir "target/js"
:modules{:cljs-base {:output-to "target/js/main.js"
:source-map true}
:page1 {:entries#{"my-app.layout.page1"}
:output-to "target/js/page1.js"
:source-map true}
:page2 {:entries#{"my-app.layout.page2"}
:output-to "target/js/page2.js"
:source-map true}
:page3 {:entries#{"my-app.layout.page3"}
:output-to "target/js/page3.js"
:depends-on #{:components1}
:source-map true}
:page4 {:entries#{"my-app.layout.page4"}
:output-to "target/js/page4.js"
:depends-on #{:components1 :components2}
:source-map true}
:page5 {:entries#{"my-app.layout.page5"}
:output-to "target/js/page5.js"
:depends-on #{:components1 :components2}
:source-map true}
:components1 {:entries
#{"my-app.components.common.components1"}
:output-to "target/js/components1.js"
:source-map true}
:components2 {:entries
#{"my-app.components.common.components2"}
:output-to "target/js/components2.js"}}
}
So my point here is to remove code from cljs-base that is common to some
pages but not all of them and putting them into the split :components1 and
:components2. The compilation works, the split are good (I verified the
javascript produced for every file) but the runtime behavior is incorrect.
My problem is that when I load :page3 with (loader/load :page3
my-callback), I see a requests to components1.js with response 200 OK, but
no request to page3.js after, and my-callback is not executed.
On Friday, February 1, 2019 at 1:01:33 PM UTC+1, Khalid Jebbari wrote:
>
> Hello,
>
> I create 3 modules in the :modules configuration, say :cljs-base, :a & :b,
> and know that module :a depends on code in the module :b (and in :cljs-base
> of course). If I manually load only :a with `(cljs.loader/load :a)`, will
> it automatically load :b? My local testing seems to show that it doesn't.
>
>
--
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: Question about code-splitting and loading of dependent modules.
Indeed, I had forgotten to call set-loaded! for the components splits. I
feel stupid... Thanks for the help !
On Mon, Feb 4, 2019, 2:17 PM Thomas Heller To me that still sounds like you are missing a (cljs.loader/set-loaded!
> :components1) call in my-app.components.common.components1. Each module
> must call set-loaded! at some point. In shadow-cljs this is taken care of
> automatically but CLJS otherwise requires that you do this manually. If you
> have the set-loaded! calls in the proper places and it should work. If it
> doesn't I'd recommend creating a fully reproducible example and report it.
>
>
> On Monday, February 4, 2019 at 12:01:23 PM UTC+1, Khalid Jebbari wrote:
>>
>> I realize it's much better if I give the complete configuration.
>>
>> latest ClojureScript stable 1.10.516
>> deps.edn alias: {:cljs {:main-opts ["-m" "cljs.main" "-co" "cljs-dev.edn"
>> "--compile"]}}
>> cljs-dev.edn file:
>>
>> {:main "my-app.core"
>> :parallel-build true
>> :optimizations :simple
>> :output-dir "target/js"
>> :modules{:cljs-base {:output-to "target/js/main.js"
>> :source-map true}
>> :page1 {:entries#{"my-app.layout.page1"}
>> :output-to "target/js/page1.js"
>> :source-map true}
>> :page2 {:entries#{"my-app.layout.page2"}
>> :output-to "target/js/page2.js"
>> :source-map true}
>> :page3 {:entries#{"my-app.layout.page3"}
>> :output-to "target/js/page3.js"
>> :depends-on #{:components1}
>> :source-map true}
>> :page4 {:entries#{"my-app.layout.page4"}
>> :output-to "target/js/page4.js"
>> :depends-on #{:components1 :components2}
>> :source-map true}
>> :page5 {:entries#{"my-app.layout.page5"}
>> :output-to "target/js/page5.js"
>> :depends-on #{:components1 :components2}
>> :source-map true}
>> :components1 {:entries
>> #{"my-app.components.common.components1"}
>> :output-to "target/js/components1.js"
>> :source-map true}
>> :components2 {:entries
>> #{"my-app.components.common.components2"}
>> :output-to "target/js/components2.js"}}
>> }
>>
>> So my point here is to remove code from cljs-base that is common to some
>> pages but not all of them and putting them into the split :components1 and
>> :components2. The compilation works, the split are good (I verified the
>> javascript produced for every file) but the runtime behavior is incorrect.
>> My problem is that when I load :page3 with (loader/load :page3
>> my-callback), I see a requests to components1.js with response 200 OK, but
>> no request to page3.js after, and my-callback is not executed.
>>
>> On Friday, February 1, 2019 at 1:01:33 PM UTC+1, Khalid Jebbari wrote:
>>>
>>> Hello,
>>>
>>> I create 3 modules in the :modules configuration, say :cljs-base, :a &
>>> :b, and know that module :a depends on code in the module :b (and in
>>> :cljs-base of course). If I manually load only :a with `(cljs.loader/load
>>> :a)`, will it automatically load :b? My local testing seems to show that it
>>> doesn't.
>>>
>>> --
> 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/NwRtAgr9ltc/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 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] How does Clojurescript compilation scales with CPU?
Hello, We're using the parallel build option, and I noticed the difference in speed between my laptop and other laptops is basically proportional to the difference in speed of the CPUs (based on notebookcheck's benchmarks). I have 4C/8T 7700HQ CPU and my colleagues have a 8565U iirc (some have the 6600U). Mine is almost twice as fast in benchmarks, which is reflected in cljs compilation times. So my question is how does the cljs compiler scale with regards to CPU? Core count? Single thread perf? All cores frequencies? Is it capped to some number of cores? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/clojurescript/6d24e681-188b-44c8-905c-afd545794e3a%40googlegroups.com.
Re: [ClojureScript] Re: How does Clojurescript compilation scales with CPU?
Thanks for the detailed answer. Does it somewhat mean that splitting code into smaller namespaces can achieve faster compilation thanks to parallelization ? On Fri, Jan 17, 2020 at 10:43 AM Thomas Heller wrote: > It depends on the namespaces used. In general a CLJS namespaces can only > be compiled once all its dependencies have been compiled. So if those > dependendencies can be compiled in parallel they will use multiple threads > from a pool, which should keep all cores busy. In my experience a good > balance between core count and core speed matters. If you have big > namespaces that a lot of other namespaces depend on (eg. like cljs.core) > then its compilation will "block" all other threads so its important it > finishes fast (ie. fast cores). If you have lots a small namespaces that > are mostly independent then you can get maximum parallelization (ie. many > cores). > > I have a i7-8700K 6c and there are builds that aren't able to use all > cores due to the namespace setup (few very large ones). Others happily use > everything. Single core difference is gigantic to my previous CPU from a > macbook pro 2016. > > If you really really want to torture your CPU you can try > https://github.com/mfikes/fifth-postulate or > https://github.com/mfikes/coal-mine to compare. > > HTH, > Thomas > > On Friday, January 17, 2020 at 5:29:06 AM UTC+1, Khalid Jebbari wrote: >> >> Hello, >> >> We're using the parallel build option, and I noticed the difference in >> speed between my laptop and other laptops is basically proportional to the >> difference in speed of the CPUs (based on notebookcheck's benchmarks). I >> have 4C/8T 7700HQ CPU and my colleagues have a 8565U iirc (some have the >> 6600U). Mine is almost twice as fast in benchmarks, which is reflected in >> cljs compilation times. >> >> So my question is how does the cljs compiler scale with regards to CPU? >> Core count? Single thread perf? All cores frequencies? Is it capped to some >> number of cores? >> >> -- > 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/PwpVJNrF0Zc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojurescript+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojurescript/7a967f70-995e-49d3-9b25-a5b327689736%40googlegroups.com > <https://groups.google.com/d/msgid/clojurescript/7a967f70-995e-49d3-9b25-a5b327689736%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/clojurescript/CAM3R3BARm8m08%3DA1aSN%2B3rW9E0DUNGyuzyWgGTmf5fscGnFjpA%40mail.gmail.com.
Re: [ClojureScript] Re: How does Clojurescript compilation scales with CPU?
I may do some testing in the a close future and report here. I will either do it in our project or in a an open-source project that's "relevant" to show real-world numbers. Do you have an idea of such project? I think I will try to bench compilation time in advanced mode with a different number of cores activated by BIOS (I will soon have a 16C/32T machine, I hope the BIOS will allow me to deactivate some of them). Khalid aka DjebbZ @Dj3bbZ On Fri, Jan 17, 2020 at 11:58 AM Thomas Heller wrote: > Depends on the size I'd say but in theory yes. Lots of things factor into > the compilation times, even tiny namespaces can take a long time to compile > if some macro just takes a long time to do its thing. > > On Friday, January 17, 2020 at 11:18:21 AM UTC+1, Khalid Jebbari wrote: >> >> Thanks for the detailed answer. Does it somewhat mean that splitting code >> into smaller namespaces can achieve faster compilation thanks to >> parallelization ? >> >> >> On Fri, Jan 17, 2020 at 10:43 AM Thomas Heller wrote: >> >>> It depends on the namespaces used. In general a CLJS namespaces can only >>> be compiled once all its dependencies have been compiled. So if those >>> dependendencies can be compiled in parallel they will use multiple threads >>> from a pool, which should keep all cores busy. In my experience a good >>> balance between core count and core speed matters. If you have big >>> namespaces that a lot of other namespaces depend on (eg. like cljs.core) >>> then its compilation will "block" all other threads so its important it >>> finishes fast (ie. fast cores). If you have lots a small namespaces that >>> are mostly independent then you can get maximum parallelization (ie. many >>> cores). >>> >>> I have a i7-8700K 6c and there are builds that aren't able to use all >>> cores due to the namespace setup (few very large ones). Others happily use >>> everything. Single core difference is gigantic to my previous CPU from a >>> macbook pro 2016. >>> >>> If you really really want to torture your CPU you can try >>> https://github.com/mfikes/fifth-postulate or >>> https://github.com/mfikes/coal-mine to compare. >>> >>> HTH, >>> Thomas >>> >>> On Friday, January 17, 2020 at 5:29:06 AM UTC+1, Khalid Jebbari wrote: >>>> >>>> Hello, >>>> >>>> We're using the parallel build option, and I noticed the difference in >>>> speed between my laptop and other laptops is basically proportional to the >>>> difference in speed of the CPUs (based on notebookcheck's benchmarks). I >>>> have 4C/8T 7700HQ CPU and my colleagues have a 8565U iirc (some have the >>>> 6600U). Mine is almost twice as fast in benchmarks, which is reflected in >>>> cljs compilation times. >>>> >>>> So my question is how does the cljs compiler scale with regards to CPU? >>>> Core count? Single thread perf? All cores frequencies? Is it capped to some >>>> number of cores? >>>> >>>> -- >>> 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/PwpVJNrF0Zc/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> clojur...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/clojurescript/7a967f70-995e-49d3-9b25-a5b327689736%40googlegroups.com >>> <https://groups.google.com/d/msgid/clojurescript/7a967f70-995e-49d3-9b25-a5b327689736%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/PwpVJNrF0Zc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojurescript+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojurescript/fe80b84a-4c23-4789-9b27-8f84c631d93d%40googlegroups.com > <https://groups.google.com/d/msgid/clojurescript/fe80b84a-4c23-4789-9b27-8f84c631d93d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/clojurescript/CAM3R3BCE7cL9cBrPAVMKnzd6SZ65p3XeXbMM0wFMhs%2BjvqxN1A%40mail.gmail.com.
