[ANN] freactive.core - generalized reactive atom, cursor and expression library
I have separated the code for reactive atoms, cursors and expressions from freactive (https://github.com/aaronc/freactive) into a separate freactive.core library: https://github.com/aaronc/freactive.core. The code for these data structures has evolved significantly since I released freactive, however, I would still consider it alpha quality with an API subject to change. The biggest change I have in mind is mainly for a much more capable and sophisticated cursor implementation. Currently the Clojure Java and Clojurescript API's are more or less in line but the Java API is definitely more experimental. The Java atoms, cursors and expressions all work with fx-clj: https://github.com/aaronc/fx-clj. I haven't had much time to work on the ClojureCLR port and probably won't, but pull requests are welcome. freactive itself has evolved significantly since I released it as well and is almost ready for a 0.2.0 release. Most of the latest code is on the develop branch. This includes a working DOM diffing implementation (which actually performs quite well) and various speed and memory usage enhancements. I'm still not 100% sold on the name freactive - so far the suggestion I've liked the most is fresco. Hopefully before this hits 1.0, it can have a different name. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] fx-clj - Clojure library for JavaFX that supports reactive programming
Finally, an official release of fx-clj, my Clojure library for JavaFX: https://github.com/aaronc/fx-clj. I've been using it for quite a number of months now and most of the core functionality is pretty stable. This library works with my freactive.core ( https://github.com/aaronc/freactive.core) reactive atoms, cursors and expressions and supports a hiccup-like syntax so you can use it in a way similar to freactive (and also to a lesser extent reagent)! Right now, data binding only works on properties and not child elements, but in JavaFX this is less of an issue because most interesting stuff happens with properties. Please post any issues on github. Pull requests and contributions welcome. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Hi Leon, So the reason for rx bindings not being default is really quite simple - freactive is not a macro framework but uses pure functions and I preferred giving more power to the user rather than doing something auto-magically that may not always be desired. One could write a simple macro that wraps all the relevant forms with an rx but I'm not sure this would be a good idea - you would lose the ability to be specific about bindings (rx's are only one type of thing that can be bound), it would add overhead (you don't need a binding on every form) and using macros can have other unintended consequences (you couldn't use pure functions that return virtual DOM - i.e. hiccup vectors). The main macro freactive provides is the rx macro which is really a thin wrapper macro which generates an instance of ReactiveExpression for its body - it is one type of thing that can be bound, but not the only thing (atoms, cursors, etc. can be bound directly). Now, it may seem that this makes freactive more verbose than say Reagent, but this is not really true at all - you don't have to use rx's everywhere. If you just wrap whole functions/components in a single rx, you'll get something pretty similar to a React component (especially when diffing gets enabled in the next major version) - the performance will be quite good (probably similar to React). The ability to place bindings (i.e. rx's, atoms, etc.) directly on attributes or text nodes allows additional performance gains because the binding is direct and specific - you don't need to use it if it feels unnecessary, but the framework allows it and will optimize based on what you tell it. Does that make sense? Basically using more rx's may allow better performance for things like animations, but it's totally optional - you can just use one rx around the whole body of a component if you like... Regarding transitions and callbacks, this API will change a little in the next version (the transition names will change) but the general concepts will remain the same. Right now, :on-show receives a callback, but in the next version it won't whereas :on-hide will and it will need to be called. The reason for needing to call this callback is because this callback is actually what hides/removes the element. The :on-hide transition is there so that you can apply some sort of fade effect, but if you don't call the callback, the element won't actually go away. This gives the user considerable power to screw things up (by not calling the callback) but I think it is useful to allow this so that people can apply fade transitions. On Sat, Dec 20, 2014 at 3:18 PM, Leon Grapenthin grapenthinl...@gmail.com wrote: Hi Aaron, I am currently experimenting with freactive. I find it quite awesome to begin with. Here are some questions that I found unanswered: - Why are rx-bindings not the default? It feels a bit redundant to wrap forms in (rx ...) all the time. - What is the rationale behind the second argument callback (to one of :on-hide or :on-show)? I noticed that sometimes it is passed and sometimes it isn't and that I have to call it when it is passed... On Thursday, December 18, 2014 3:28:12 AM UTC+1, Aaron Craelius wrote: I've just posted gists about the items-view and observable collections proposed for freactive. In case anyone is interested in discussing please comment on the gists themselves. observable collections: https://gist.github.com/aaronc/0654151190b9145dd473 items-view: https://gist.github.com/aaronc/5d497aa61e27ce924178 And yes, these components would be separate modules from freactive core and dom, the observable collections could be used independently of the items-view and everything could (and probably will be) split into separate projects. -- 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/99myJ9vLeKQ/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 clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more
Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
I've just posted gists about the items-view and observable collections proposed for freactive. In case anyone is interested in discussing please comment on the gists themselves. observable collections: https://gist.github.com/aaronc/0654151190b9145dd473 items-view: https://gist.github.com/aaronc/5d497aa61e27ce924178 And yes, these components would be separate modules from freactive core and dom, the observable collections could be used independently of the items-view and everything could (and probably will be) split into separate projects. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
There are no restrictions on events and attributes (although some
attributes may need a special handler if they don't work properly with
setAttribute - please submit an issue on github). Looking at your code,
maybe the issue is the event handler names - I believe the DOM events are
called dragstart, dragend, etc. without a hyphen.
On Mon, Dec 1, 2014 at 10:39 AM, Sven Richter sver...@googlemail.com
wrote:
Hi,
I am currently trying to make drag and drop work with freactive, but fail
so far. This is my code:
[:thead [:tr
(for [col (first (:content struct))]
[:td [:div {:draggable true
:on-drag-start (fn [e] (println dragged))
:on-drag-over (fn [e] (.preventDefault e))
:on-drag-enter (fn [e] (.preventDefault e))
:on-drop (fn [e] (.preventDefault e)(println
dropped))
:on-drag-end (fn [_] (println drag end))}
col]
])]]
But nothing happens, no matter what I try. Are there any restrictions?
Should this be done in a different way?
Best Regards,
Sven
Am Montag, 17. November 2014 03:20:29 UTC+1 schrieb Aaron Craelius:
freactive (pronounced f reactive for functional reactive) is a new
high performance, pure Clojurescript, declarative DOM library:
https://github.com/aaronc/freactive
It has a syntax very similar to that of Reagent and was in fact inspired
by Reagent, Om, and others.
I came up with it when I was doing some DOM programming after having
spending a fair amount of time working with JavaFX (see my soon to be
announced library fx-clj: https://github.com/aaronc/fx-clj). I thought Om
and Reagent were very nice to work with (and actually inspired some what I
did with fx-clj), but I felt from my desktop GUI experience, that I could
take things a few steps further.
freactive's main advantages over existing solutions are probably
built-in animations support and slightly higher performance.
Here are it's goals from the README:
Provide a simple, intuitive API that should be almost obvious to those
familiar with Clojure (inspiration from reagent)Allow for high-performance
rendering good enough for animated graphics based on a purely declarative
syntaxAllow for reactive binding of any attribute, style property or child
node
Allow for coordinated management of state via cursors (inspiration from
om)Provide deeply-integrated animation supportAllow for cursors based on
paths as well as lenses
Provide a generic items view component for efficient viewing of large
data sets
Minimize unnecessary triggering of update eventsCoordinate all updates
via requestAnimationFrame wherever possibleBe easy to debug
Be written in pure Clojurescript
Provide support for older browsers via polyfills (not yet implemented)
Any feedback is welcome!!
I'm not sure I like the name freactive - but it was the best I could
think of at the time. Suggestions for alternative names are welcome.
--
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/99myJ9vLeKQ/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 clojurescr...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
So, you've made a good observation about the spec - it doesn't proscribe any convention for dealing with sequences of items. The reason for this is pretty much that the DOM is the only modern UI framework that I've worked with that doesn't include something like an items view. So, I understand that an items view may seem like a hackish solution, but from my perspective, it's actually the least hackish solution. I think something like React's key resolution is much more hackish. That said, I have actually been thinking about implementing something along the lines of what React is doing with keys because I see its use case and it wouldn't be that hard. In any event, this is a good item for discussion. On Thu, Nov 27, 2014 at 1:40 AM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: I've noticed that you did not mention Items View in UI-SPEC and describe it as something orthogonal in freactive readme. Yes, it is really could be implemented independently, and yes, it must be decoupled from core. But it reveals drawback in abstract spec — how in terms of UI-SPEC model list of items should be rendered? Current model only supports full rerender, you need items view hackery to overcome this and apply changes only where data has been changed. But dynamic lists of things is so common case, so spec should contain conceptual key to solve it without additional entities such as items view with its own magic. I'm not sure I have solution right now, but I think it is thing worth to think about. But, m.b., I am not right, and lists should stay opaque for reactive model. Don't know, 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 a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/99myJ9vLeKQ/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 clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 24, 2014 3:49:22 PM UTC-5, Andrew Rosa wrote: Aaron, Still need to study the more detailed docs, but from what I read from UI-SPEC the only thing I get confused about was the event/lifecycle. Okay - that's something that would be platform-specific. It's still being worked out for the freactive. See: https://github.com/aaronc/freactive/issues/8 Just a suggestion about the name, if there is time for that: despite of the chosen one, IMO will be a good thing unify all (potential) libraries under single name. So you'll end up with lib.core, lib.dom, lib.fx, lib.wpf. This way will be much more easy to follow the related libraries - after all, even with diferencies they will be tied by major common idioms. Exactly! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Fresco isn't bad. I think it's better than freactive at least. Seems to be relatively popular for a name, but no big projects: https://github.com/search?o=descp=1q=frescos=starstype=Repositoriesutf8=✓ On Sun, Nov 23, 2014 at 3:05 AM, Olli Piepponen kot...@gmail.com wrote: If you are open to name suggestions, how about Fresco http://en.wikipedia.org/wiki/Fresco? -- 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/99myJ9vLeKQ/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 clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Glad to see all the enthusiasm about names :) If you think of others, you can let me know. Probably leaning towards something artistic sounding like fresco so far... But anyway, more importantly did anyone check out the docs I just posted? In particular the UI spec one: https://github.com/aaronc/freactive.core/blob/master/UI-SPEC.md. What do people think about the idea of trying to generalize conventions for writing reactive UI's? Decomplecting state management from the underlying UI renderer, common semantics, etc... On Sunday, November 23, 2014 2:44:49 PM UTC-5, Henrik wrote: Hacker News has sort of noticed: https://news.ycombinator.com/item?id=8648491 On Sunday, November 23, 2014 8:32:11 PM UTC+1, Jason Lewis wrote: Furthermore (it occurs to me) cesium is used to drive atomic clocks... so if you're using an atom to maintain state... even more relevance. Relevance? Wait, it's Cognitect now :) Jason Lewis vox 410.428.0253 twitter @canweriotnow blog http://decomplecting.org else http://about.me/jason.lewis On Sun, Nov 23, 2014 at 2:20 PM, Jason Lewis ja...@decomplecting.org wrote: Cesium is the most reactive element of all... and the name isn't taken on Clojars. Cesium will react explosively even with ice. Jason Lewis vox 410.428.0253 twitter @canweriotnow blog http://decomplecting.org else http://about.me/jason.lewis On Sun, Nov 23, 2014 at 1:21 PM, Gary Trakhman gary.t...@gmail.com wrote: The two best ones I can think of right now Halogen: they're known as highly reactive elements. Precipitate: both a noun and a verb, the solid that falls out of a solution, or to bring about such a reaction. Other chemical-ish names considered Enantiopure - Containing compounds of only a single chirality Fullerene - Bucky-Balls, they're just cool Recycle - 'Save the trees', and also 'recycle streams' from chemical engineering. On Sun, Nov 23, 2014 at 12:37 PM, Aaron Craelius aaronc...@gmail.com wrote: Fresco isn't bad. I think it's better than freactive at least. Seems to be relatively popular for a name, but no big projects: https://github.com/search?o=descp=1q=frescos=starstype=Repositoriesutf8=✓ On Sun, Nov 23, 2014 at 3:05 AM, Olli Piepponen kot...@gmail.com wrote: If you are open to name suggestions, how about Fresco? -- 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/99myJ9vLeKQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com. To post to this group, send email to clojur...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Hi Niels, It is true that this comparison is a bit stacked because basically freactive only modifies the needed attributes without needing to diff the whole structure. I'm not sure if I understand totally your other questions - maybe you could clarify a little. Regarding diffing - in terms of rerendering whole subtrees every time reactive will not perform as well as react even if diffing is implemented - it is not designed that way. It is designed for direct to-site binding as opposed to binding that could be anywhere (thus the need for diffing). As a result - however - items/collection view type components (as in desktop GUI frameworks) will be needed when dealing with large collections - if they are used, however, the system should theoretically scale much better than a diffing system. Yes there are tradeoffs, but I believe the tradeoffs will probably be worth it. Of course, this is something for discussion and experimentation. Please keep in mind all that for me this was kind of an experiment for me and I am actually pleasantly surprised with the results. On Thu, Nov 20, 2014 at 3:53 PM, Niels van Klaveren niels.vanklave...@gmail.com wrote: This looks pretty impressive, both in already implemented features and performance. I can't help but wonder though if the example chosen to compare performance with React/ Reagent isn't stacked a bit because effectively all nodes are rerendered all the time ? Wouldn't this effectively nullify performance gains from different diffing behavior ? I know it's in the cards, but how is the performance difference now while only needing to rerender parts of the dom ? On Monday, November 17, 2014 10:03:08 PM UTC+1, Aaron wrote: On Monday, November 17, 2014 2:42:38 PM UTC-5, Aaron wrote: On Monday, November 17, 2014 2:27:17 PM UTC-5, Ruslan Prokopchuk wrote: I've played a little bit with freactive today, and investigated this idea with using polymer components — it works! I'm unsure of right usage of rx, especially on conditional rendering — (rx (if @state ... does autorerendering, but (rx (if (:key @state) ... does not. And there are some questions about how to structure app properly. I'm too tired to formulate them today, but bigger than performance demo examples and more documentation are welcome, because I'm very enthusiastic to use freactive in real projects! Hope I can make the intended usage and specifics about update/invalidation behavior more clear - but probably another day as well. Structuring large apps is something we're figuring out as we go... Okay, this is what I want to say about structuring an app - I think the ideal way would be to have a single (rx (dispatch-state @state)) at the root of the app where dispatch-state is something like a multi-method. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/99myJ9vLeKQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Do I correctly understand, that freactive does not care about tag names, and I can use any ones (potentially injecting polymer or smth like pieces)? Yes! It tries to work with pure DOM nodes wherever possible. In freactive, Clojurescript vectors are virtual DOM - so the hiccup vectors are very close to the actual DOM. Although it may not work quite yet, you should even be able to inject DOM nodes you created outside of freactive's rendering framework and it will treat them opaquely. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 9:19:29 AM UTC-5, Max Gonzih wrote: Wow! Amazing! I see some ClojureCLR code in this repository, but from brief look it's not clear why is it there. Are you also experimenting on CLR support? Yes, I'm not sure if it's in a working state right now, but I was experimenting with it - I should add that to the docs. The way this started actually is I wanted some reactive atoms for JavaFX. I also have done a lot of work with WPF - see my ClojureWPF: https://github.com/aaronc/ClojureWpf - so I wanted to integrate it there too, but alas... I'm mostly moving away from .NET these days... but I started out as a ClojureCLR dev. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 12:02:32 PM UTC-5, Diogo Almeida wrote: This is really cool (especially if what Ruslan said is the case). What would the best practice be for stateful effects? Do you have any plans of adding the equivalent of React's lifecycle methods? So I plan to write more about this soon as I have it all more or less worked out in my head. Briefly, :on-show and :on-hide are lifecycle callbacks - I intend to rename them to something like :did-mount and :will-unmount respectively. The only other lifecycle callbacks make sense in freactive's update cycle are :will-mount and :did-unmount - but I'm not even sure there is a use case or it's a good idea. freactive tries to manage state in a different way that is fundamentally tied to IDeref watches (and invalidation watches which aren't yet documented). Input definitely welcome as these facilities are developed. As for state transitions, they will be based on the data-state attribute and have :on-state and :after-state callbacks. The recommended way will be to use a state-machine ref bound to :data-state - I also have this more or less worked out in my head... more details soon. Also, the reagent comparison doesn't work over https, because you use the http version of React.js. Fixed! http://aaronc.github.io/freactive-reagent-comparison/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 2:32:18 PM UTC-5, Shaun LeBron wrote: How does it perform its dom-diffing? So, it does not actually do diffing. It is very close to being able to, but if this is added it will be sort of an extra optimization as opposed to a core algorithm. Instead of diffing, changes are bound directly to the site they are to be applied using rx's and atoms directly on attributes, style properties, text nodes and DOM nodes. So, changes are detected and applied more locally so there is in most cases very little to diff. The only case where it might be needed is for large collections, but that's where the items-view or collections-view comes in (more on this coming soon I hope) - which will be much more scalable than diffing. All this is how any serious desktop GUI framework does it (like Qt/QML, JavaFX, WPF) and freactive is just trying to emulate that. Does that make it clear? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
On Monday, November 17, 2014 2:27:17 PM UTC-5, Ruslan Prokopchuk wrote: I've played a little bit with freactive today, and investigated this idea with using polymer components — it works! I'm unsure of right usage of rx, especially on conditional rendering — (rx (if @state ... does autorerendering, but (rx (if (:key @state) ... does not. And there are some questions about how to structure app properly. I'm too tired to formulate them today, but bigger than performance demo examples and more documentation are welcome, because I'm very enthusiastic to use freactive in real projects! Hope I can make the intended usage and specifics about update/invalidation behavior more clear - but probably another day as well. Structuring large apps is something we're figuring out as we go... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] freactive - high performance, pure Clojurescript, declarative DOM library
freactive (pronounced f reactive for functional reactive) is a new high performance, pure Clojurescript, declarative DOM library: https://github.com/aaronc/freactive It has a syntax very similar to that of Reagent and was in fact inspired by Reagent, Om, and others. I came up with it when I was doing some DOM programming after having spending a fair amount of time working with JavaFX (see my soon to be announced library fx-clj: https://github.com/aaronc/fx-clj). I thought Om and Reagent were very nice to work with (and actually inspired some what I did with fx-clj), but I felt from my desktop GUI experience, that I could take things a few steps further. freactive's main advantages over existing solutions are probably built-in animations support and slightly higher performance. Here are it's goals from the README: - Provide a *simple, intuitive API https://github.com/aaronc/freactive/#hello-world* that should be almost obvious to those familiar with Clojure (inspiration from reagent https://github.com/reagent-project/reagent) - Allow for *high-performance https://github.com/aaronc/freactive/#performance* rendering *good enough for animated graphics http://aaronc.github.io/freactive/dom-perf* based on a purely declarative syntax - Allow for *reactive binding of any attribute, style property or child node* - Allow for *coordinated management of state via cursors https://github.com/aaronc/freactive/#cursors* (inspiration from om https://github.com/swannodette/om) - Provide *deeply-integrated animation https://github.com/aaronc/freactive/#animations* support - Allow for cursors based on paths as well as *lenses* - Provide a generic items view component https://github.com/aaronc/freactive/#items-view for *efficient viewing of large data sets* - *Minimize unnecessary triggering of update events* - Coordinate all updates via *requestAnimationFrame* wherever possible - Be easy to debug https://github.com/aaronc/freactive/#debugging-reactive-expressions - Be written in *pure Clojurescript* - Provide support for older browsers via polyfills (not yet implemented) Any feedback is welcome!! I'm not sure I like the name freactive - but it was the best I could think of at the time. Suggestions for alternative names are welcome. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ANN: lein-clr 0.2.0 for ClojureCLR
On Fri, Mar 1, 2013 at 6:48 PM, Rainer Schuster schuster-rai...@web.dewrote: 2. I assume, you created your a nuget and added it to a local repo. I don't have one and don't know what version you are using. 3. I deleted the Clojure and Nuget.Core dependency. Using Stable Nuget.Core Version 2.2.0 but thats not an issue. Don't delete Clojure, I'm not using a local repo. It's in the Nuget main repo, it's just unlisted because there hasn't been an official release yet. You should just be able to do Nuget package restore and everything should work. I suggest just pulling a fresh copy of nleiningen and try just building it unmodified. If you have any problems let me know. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: lein-clr 0.2.0 for ClojureCLR
My Clojure.dll shouldn't break ngen. I ilmerge'd it from AOT compiled assemblies - it doesn't use embedded assemblies which would break ngen. For me ngen seems to work fine. Open up the Clojure.dll from nuget in Ilspy or DotPeek to see how it's done. Btw, I just posted a new build on nuget today in preparation for hopefully an official public release soon - I'm hoping this will be possible even next week. I'll leave this build unlisted under the assumption that we can make it official quite soon. See here: https://nuget.org/packages/Clojure/ On Fri, Mar 1, 2013 at 6:57 PM, Rainer Schuster schuster-rai...@web.dewrote: Btw. I like how you package all the clojure assemblies into clojure.dll, very smart. But that'll break ngen speed up, doesn't it? Atm. I'm running a native x86 image of clojure-clr (1.4.1) which is pretty descent, regarding the startup. I'll try building a ngened versio of your current fork and running nlein as a module Am Samstag, 2. März 2013 00:48:28 UTC+1 schrieb Rainer Schuster: Thx and great work. I have a working nlein.exe ... and had serveral issues so far. First of all: Im using VS2012. Don't this is not an issue. 1. your packages.config from Bootstrap has the following content ?xml version=1.0 encoding=utf-8? packages package id=Clojure version=1.4.0.1 targetFramework=net40-Client / package id=IronPython version=2.7.3 targetFramework=net40-Client / package id=Mono.Cecil version=0.9.5.4 targetFramework=net40-Client / package id=Nuget.Core version=2.3.0-alpha002 targetFramework=net40-Client / /packages 2. I assume, you created your a nuget and added it to a local repo. I don't have one and don't know what version you are using. 3. I deleted the Clojure and Nuget.Core dependency. Using Stable Nuget.Core Version 2.2.0 but thats not an issue. 4. cloned YOUR clojure master (and setup DLR and test dependencies as described in the clojure-clr wiki) 5. compiled 1.5.0-master-SNAPSHOT 6. Added the reference for clojure.dll from output dir to the Bootstrap solution 7. Compiled Bootstrap 8. Microsoft.Scripting is missing (not referenced, and therefore not copied over to the output dir). 9. Copied Microsoft.Scripting.dll to the bin\Debug 10. running script\repl.bat throws: Unhandled Exception: System.**TypeInitializationException: The type initializer for 'Bootstrap.Program' threw an exception. --- System.**TypeInitializationException: The type initializer for 'clojure.lang.RT' threw an exception. --- System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at clojure.lang.RT..cctor() --- End of inner exception stack trace --- at clojure.lang.RT.var(String ns, String name) at Bootstrap.Program..cctor() in d:\Projects\Playground\** clojure\test\clr\clode_org\**nleiningen\Bootstrap\**Bootstrap\Program.cs:line 11 --- End of inner exception stack trace --- at Bootstrap.Program.Main(String[**] args) 11. removed the IronPython dependencies because the Microsoft.Scripting from clojure-clr is a different one you are using. The most recent version from IronPyhton 2.7.3 isn't not compatible with clojure. 12. added Microsoft.Scripting.dll and Microsoft.Dynamic.dll as Reference 13. finally executed your instructions (haha its friday and we have step 13) Clojure 1.5.0-master-SNAPSHOT user= (use 'nleiningen.core) nil user= (main compile) Error: #MissingMethodException System.MissingMethodException: Cannot find instance field/property/member name SourcePath at CallSite.Target(Closure , CallSite , Object ) at System.Dynamic.**UpdateDelegates.**UpdateAndExecute1[T0,TRet](**CallSite site, T0 arg0) at nleiningen/core$load_**dependencies__457.__interop_**SourcePath460(Object ) at nleiningen/core$load_**dependencies__457.invoke() in eval:line 70 at nleiningen/core$bootstrap_**project__590.invoke() in eval:line 165 at nleiningen/core$compile_**project__797.doInvoke(Object ) in eval:line 239 at clojure.lang.RestFn.invoke() at nleiningen/core$main$fn__873__**878.invoke() in eval:line 418 at nleiningen/core$main__881.**doInvoke(Object ) in eval:line 407 -1 14. Added a (println asmref) to load-dependencies. output: #ZipPackageAssemblyReference .NETFramework,Version=v4.0 Mono.Cecil.dll (lib\net40\Mono.Cecil.dll) 16. Wtf... ok, get-dependency-assembly-**references uses nuget to resolve the dependencies 17. Used the 2.3.0-alpha002 Version again ... tada works ... Am Freitag, 1. März 2013 02:59:18 UTC+1 schrieb Aaron: Rainer, I've pushed some updates to nleiningen. Be sure you do a git submodule update first. There is now a Bootstrap project that you can build from VS 2010 - enable Nuget package restore on it first and then try
Re: ANN: lein-clr 0.2.0 for ClojureCLR
Hi Rainer, glad you're checking this out. This code (as I believe I mentioned above) requires a special build of the ClojureCLR compiler (see this github branch https://github.com/aaronc/clojure-clr - I just merged it with the clojure-clr master). I'm going to try to make some effort today to see if I can get Dave the patches so he can review them for inclusion in clojure-clr master. Hopefully soon we can have an official nuget package. Here's ClojureClrEx: https://github.com/aaronc/ClojureClrEx On Thu, Feb 28, 2013 at 11:55 AM, Rainer Schuster schuster-rai...@web.dewrote: I had a quick look into nleiningen. I'm not able to bootstrap the build atm. Can't build the ClojureClrEx dep. What I basically did was: git clone https://github.com/aaronc/nleiningen.git git submodules init git submodules update nuget install Nuget.Core -o packages $env:CLOJURE_LOAD_PATH=./src;./ClojureClrEx/src/;./ClojureClrEx created an init.clj with content and changed nleiningen.core/main to nleiningen.core/-main init.clj: (assembly-load-from packages/Nuget.Core.2.2.0/lib/net40-Client/NuGet.Core.dll) nleiningen.signing is missing from the sources. Just commented it out from nleiningen/core.clj afterwards executed: Clojure.Main.exe -i .\init.clj -m nleiningen.core repl Mono.Cecil.dll Loaded #RuntimeAssembly Mono.Cecil, Version=0.9.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Mono.Cecil.Mdb.dll Loaded #RuntimeAssembly Mono.Cecil.Mdb, Version=0.9.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Mono.Cecil.Pdb.dll Loaded #RuntimeAssembly Mono.Cecil.Pdb, Version=0.9.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Mono.Cecil.Rocks.dll Loaded #RuntimeAssembly Mono.Cecil.Rocks, Version=0.9.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Trying to resolve ClojureClrEx project.clj not found Mono.Cecil.dll Loaded #RuntimeAssembly Mono.Cecil, Version=0.9.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Mono.Cecil.Mdb.dll Loaded #RuntimeAssembly Mono.Cecil.Mdb, Version=0.9.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Mono.Cecil.Pdb.dll Loaded #RuntimeAssembly Mono.Cecil.Pdb, Version=0.9.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Mono.Cecil.Rocks.dll Loaded #RuntimeAssembly Mono.Cecil.Rocks, Version=0.9.5.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 Compile path: D:\Projects\Playground\clojure\test\clr\clode_org\nleiningen\bin Error loading ClojureClrEx : #NullReferenceException System.NullReferenceException: Object reference not set to an instance of an object. at clojure.lang.CljCompiler.Ast.GenContext..ctor(String sourceName, String assyName, String extension, String directory, Boolean createDynInitHelper) in D:\work\clojure-clr-1.4.1-fix\Clojure\Clojure\CljCompiler\Ast\GenContext.cs:line 105 at clojure.lang.CljCompiler.Ast.GenContext.CreateWithExternalAssembly(String sourceName, String assyName, String extension, Boolean createDynInitHelper) in D:\work\clojure-clr-1.4.1-fix\Clojure\Clojure\CljCompiler\Ast\GenContext.cs:line 86 at clojure.lang.CljCompiler.Ast.GenContext.CreateWithExternalAssembly(String assyName, String extension, Boolean createDynInitHelper) in D:\work\clojure-clr-1.4.1-fix\Clojure\Clojure\CljCompiler\Ast\GenContext.cs:line 91 at nleiningen/core$compile_project__1078.doInvoke(Object ) in eval:line 233 at clojure.lang.RestFn.invoke() in D:\work\clojure-clr-1.4.1-fix\Clojure\Clojure\Lib\RestFn.cs:line 456 at nleiningen/core$load_sub_project$fn__788__792.invoke() in eval:line 152 at nleiningen/core$load_sub_project__795.invoke(Object ) in eval:line 144 at nleiningen/core$bootstrap_project$fn__826__830.invoke() in eval:line 171 Clojure 1.4.1 uncommented the local-dependencies in the project file, because ClojureClrEx doesn't have a project.clj, only a csproj. Therefore I added the ClojureClrEx to the load path and now the repl works. but compile fails with Compile path: D:\Projects\Playground\clojure\test\clr\clode_org\nleiningen\bin Unhandled Exception: System.MissingMethodException: Cannot find member Compile matching args at CallSite.Target(Closure , CallSite , Object , Object , Object , Object , Object , Object ) at CallSite.Target(Closure , CallSite , Object , Object , Object , Object , Object , Object ) at nleiningen/core$compile_project$fn__959__963.__interop_Compile965(Object , Object __temp_1, Object __temp_2, Object __temp_3, Object __temp_4, Object __temp_5) at nleiningen/core$compile_project$fn__959__963.invoke() in eval:line 239 at nleiningen/core$compile_project__1078.doInvoke(Object ) in eval:line 238 at clojure.lang.RestFn.invoke() in D:\work\clojure-clr-1.4.1-fix\Clojure\Clojure\Lib\RestFn.cs:line 456 at nleiningen/core$_main__1146.doInvoke(Object ) in eval:line 393 at clojure.lang.RestFn.invoke(Object arg1) in D:\work\clojure-clr-1.4.1-fix\Clojure\Clojure\Lib\RestFn.cs:line 468 at
Re: ANN: lein-clr 0.2.0 for ClojureCLR
Ok, sounds good. I can do that. I have 2-3 pretty specific changes that I can outline. I also have one bug fix (support for IntPtr and UIntPtr in HostExpr). Should I maybe start a separate thread in this group describing the proposed changes or should we do this via JIRA or github? I'm not really sure whether the best method for doing this is git format-patch (which generates a lot of patches) or some other method. On Mon, Dec 17, 2012 at 4:14 PM, dmiller dmiller2...@gmail.com wrote: Aaron, tools.logging and nrepl are important. I'm glad to see the effort. I haven't forgotten about your single-DLL work. I'm going to have plenty of time next week if you can get something to me. -David On Saturday, December 15, 2012 5:15:16 PM UTC-6, Aaron wrote: Cool. I'm just seeing this now. I actually spent some time a while back getting a very simple nleiningen working in ClojureCLR. I had nuget downloads working and also the ability to AOT compile namespaces and merge them into a single DLL. It's not fully ready for prime time yet though, in part because it depends on some custom modifications to the ClojureCLR compiler. In the long run, I'd like to work together on getting a full lein clr implementation working. I'd love to discuss further if you have time. By the way Dave - speaking of custom modifications to ClojureCLR, this past week, my colleague and I merged your latest master with our changes ( https://github.com/**kocubinski/clojure-clrhttps://github.com/kocubinski/clojure-clr). I hope to put together some formal patches soon which clearly identify the changes I'm suggesting for the main compiler. While we're at it, a few other things I'm working on or have working in clojure-clr are: tools.logging and pinvoke (https://github.com/aaronc/**ClojureClrExhttps://github.com/aaronc/ClojureClrEx) - logging is mostly ported but with only one backend working, pinvoke/dllimport works great, but no docs a nice interface to WPF (https://github.com/aaronc/**ClojureWpfhttps://github.com/aaronc/ClojureWpf) - pretty stable, but again no docs yet nrepl (https://github.com/aaronc/**tools.nrepl/tree/clrhttps://github.com/aaronc/tools.nrepl/tree/clr) - needs quite a bit more work Unfortunately, I haven't been too diligent with documentation, but I hope to correct that as time allows. On Sunday, November 18, 2012 4:03:03 PM UTC-5, Shantanu Kumar wrote: Hi, I pushed lein-clr 0.2.0 https://github.com/**kumarshantanu/lein-clrhttps://github.com/kumarshantanu/lein-clr JARs to Clojars a little while ago. The focus of this release is to 1. add dependency support (via NuGet/wget/curl, Leiningen :dependencies) 2. lower the bar to get started with ClojureCLR (with automated download of ClojureCLR) 3. remove the need to call `assembly-load-from` in code The changelog and TODO are here: https://github.com/** kumarshantanu/lein-clr/blob/**master/CHANGES.mdhttps://github.com/kumarshantanu/lein-clr/blob/master/CHANGES.md I hope this release is usable enough to start building ClojureCLR apps and libraries with it. This is an early project and can certainly use feedback and contribution. Please let me know what you think. Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Where is Clojure CLR ?
I tried it a while back and couldn't get it working, but I have since heard that it was updated. I wouldn't be the one to ask though. In my case, I prefer Emacs for editing lisp and it is much lighter on system resources than Visual Studio. On Thu, Sep 6, 2012 at 10:55 PM, Erlis Vidal er...@erlisvidal.com wrote: Hi Aaron, thanks for your response, I'll take a look at your set up and I'll give it a try. Have you tried vsClojure? It's a Visual Studio extension that will allow us to write clojure from within the Visual Studio, very interesting...I was trying to make it work and I was not able to compile...I'm sure I'm doing something wrong, but I couldn't make it work. Some one knows if there is something special to do to make this work? The github page doesn't have much information about this https://github.com/vsClojure/vsClojure Thanks, Erlis On Thu, Sep 6, 2012 at 8:42 PM, Aaron aaroncrael...@gmail.com wrote: I can personally attest to the quality of the ClojureCLR compiler using it on a daily basis for production code. I have never had any problems with stability and I have found the code gen to be of quite high quality (via inspection with Reflector). It is the build and development environment which is lagging a little behind. For my work I've basically had to set up my own environment which I can say was a small price to pay for the productivity gains my team has seen. Here's how my setup looks: I'm using a custom build of the compiler ( https://github.com/aaronc/clojure-clr) which allows me to package .clj files into C# DLL's as embedded resources. I also have a little prototype build tool that has some leiningen like functionality which allows me to easily start up a repl with the right paths referenced and also allows me to AOT compile and package multiple clojure files. For development, I use emacs *inferior-lisp* quite comfortably. I'm hoping that some of my changes to the compiler will be merged into the main branch soon and I also hope to share the rest of my custom tools on github as soon as I get a little more free time. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript error messages
Not yet. I'll have to take care of that. On Mon, Mar 19, 2012 at 5:48 PM, David Nolen dnolen.li...@gmail.com wrote: On Mon, Mar 19, 2012 at 1:36 PM, Aaron aaroncrael...@gmail.com wrote: I pushed the patch to my fork on github in this commit: https://github.com/aaronc/clojurescript/commit/3193ed6e27061765782da32d36a63b0f7630f5e9 Should I submit a pull request? Clojure doesn't take pull requests. Have you sent in your CA? If so open a ticket and attach a patch in JIRA. Thanks! David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
