Re: core.async over websocket + cljs + clojure
I recently gave a talk about doing this. You can find the code for my talk here: https://github.com/ckirkendall/chatter-box, Its a group chat application that has the feel of twitter. It uses core.async and websockets. The core.async code is bit dated but the websocket stuff should be good to go. If your interested in seeing the talk: http://www.youtube.com/watch?v=jj6eQieGWqolist=TLaY6nSMlp35yusQFm7HAZPE607i_re1Cv CK On Thursday, January 23, 2014 2:39:06 AM UTC-5, t x wrote: Hi, I apologize for my vague question. Does anyone have a good example / blog / library for using the core.async abstraction across a websocket. * one side of the channel is in clojure land * other side of the channel is in cljs land * I promise that all messages can be encoded via pr-str and read via clojure.edn/read-string What I'm struggling with are matters of: * how to ensure data is not lost even when websocket disconects / reconnects * naming on client/server side to ensure messages go to right channels on both sides * issues I haven't even begun to imagine. Good news: * I control both sides: both the clj and cljs side, so any workable design is fine. Thanks! -- -- 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.
Enfocus is now 1.0.0 and production ready!
After more than a year of use, I am happy to announce that Enfocus has finally reached 1.0.0. Enfocus is a DOM manipulation and templating library written in ClojureScript. It was originally inspired by Christophe Grand's awesome Clojure library, Enlive. Like Enlive, its main focus is on *decoupling design and presentation logic*. Demo/Documentation Site: http://ckirkendall.github.com/enfocus-site/ GitHub: https://github.com/ckirkendall/enfocus Sample Site: https://github.com/ckirkendall/The-Great-Todo *Core Features:* - Basic DOM manipulation - Event management - Effects (fade-in, move, resize, ...) - Remote Templates Snippets - Compiled Templates Snippets - CSS3 selectors - XPath selectors - Custom function based selectors (think Laser: https://github.com/Raynes/laser) -- -- 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: who uses enfocus/clojurescript in the wild ?
ClojureScript/Enfocus is being used by several people to build production software. If you want an unbiased opinion you might hop on the Clojure IRC channel and chat with Robert Stuttaford(@RobStuttaford). He is currently a very active user. Enfocus was originally envisioned to allow designers and developers to better integrate their skills than traditional workflow. I originally envisioned the designer building a working prototype of a site using static html/css and then a developer could take these raw documents and use enfocus to make it dynamic. It also provides a very clean declarative style to working with the dom. As far as support and bugs, I think we have done fairly well. Enfocus has spent the last year in snapshot mode because I wanted to get enough real world usage to vet out bugs. I am happy to report we are currently vetting the 1.0.0 release candidate and I personally feel its production grade at this point. If you have any questions ping me on twitter @crkirkendall or post a message to enfocus users group. http://groups.google.com/group/enfocus Creighton Kirkendall On Tuesday, February 12, 2013 7:22:03 AM UTC-5, faenvie wrote: hi clojure-users, as i am thinking about using enfocus ( http://ckirkendall.github.com/enfocus-site/) for building up the clientside-logic for a new site, i am interested in reports of people who have done so already. i am esp curious about how the development-process works out and what main-problems are experienced, running the site. thanks have a successful day -- -- 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: who uses enfocus/clojurescript in the wild ?
I recently added support for xpath and custom selectors in addition to the standard ccs3 selector. I added these to get around some of the limitations of goog.dom.query and querySelector. I would be interested in your specific use case to see if we can't provide a custom selector to handle it. CK On Tuesday, February 12, 2013 8:01:11 AM UTC-5, Herwig Hochleitner wrote: I have successfully used ClojureScript to write a Car2Go App for Blackberry: http://appworld.blackberry.com/webstore/content/19205189/ The big challenge there was actually the volatile platform (mandatory battery pulls after reading the geolocation anyone?), while ClojureScript has played along gorgeously. I tried enfocus at first, but then I decided to port enlive to ClojureScript, to get a consistent selector behavior between server and client. Also the missing root selector (impossible in enfocus with element.querySelector) was a dealbreaker. -- -- 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: who uses enfocus/clojurescript in the wild ?
I would be very interested in your code. Awhile back I did add support for most enlive selectors to enfocus. So you can use something like [:td :#id1] in your enfocus templates. This does have limitations though. I also have been working on adding string css3 selector support to enlive through a simple compiler that would take a valid css3 selector and produce an enlive selector. I haven't gotten a lot of time to work on it, but the parser phase is pretty complete. It would also make a good basis for pure clojurescript selector engine like Sizzle instead of using goog.dom.query. CK On Tuesday, February 12, 2013 9:09:27 AM UTC-5, Herwig Hochleitner wrote: 2013/2/12 ckirkendall ckirk...@gmail.com javascript: I recently added support for xpath and custom selectors in addition to the standard ccs3 selector. I added these to get around some of the limitations of goog.dom.query and querySelector. I would be interested in your specific use case to see if we can't provide a custom selector to handle it. My (rather unspecific) use case is: The same selector syntax (and semantics) for server- and client side. As soon as I've also fully ported the templating stuff: hopefully server and client templates from the same source. My syntax compiler is a straight port of enlive's state-machine-generator, so with enfocus' support for custom selectors, it might be feasible to offer enlive selectors in enfocus based on that port. If you are interested in that, let me know. I'll gladly share the code and experiences from porting, I just don't want to do a public release yet. -- -- 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: Closure Accordion Widget
It would also be trivial to use enfocus' resize functionality to implement a pure clojurescript one. I am planning on building a set of UI tools like accordion data tables, and tabs for enfocus. Enfocus supports quite a few base level animations. If you would like I might be able to through together a sample. https://github.com/ckirkendall/enfocus - source http://ckirkendall.github.com/enfocus-site/ - demo site CK On Monday, November 26, 2012 2:09:44 PM UTC-5, Jordan wrote: If you do decide you are interested in a non-Jquery solution, I think that you could probably combine a few animated zippys[1] to get the same functionality as an accordion with a little additional CLJS code. [1] http://closure-library.googlecode.com/svn/docs/class_goog_ui_AnimatedZippy.html On Mon, Nov 26, 2012 at 1:45 PM, Aaron Cohen aa...@assonance.orgjavascript: wrote: I've only used it at a very shallow level, but https://developers.google.com/closure/library/docs/overview has seemed quite nice to me? On Sat, Nov 24, 2012 at 7:14 PM, Jonathan Fischer Friberg odys...@gmail.com javascript: wrote: I don't think there's a consensus. You will have to weigh the pros/cons and choose what fits you best. For example: closure integrates perfectly with the closure compiler while jquery does not. jquery has great documentation while closure does not. And so on. :) Jonathan On Sat, Nov 24, 2012 at 7:20 PM, J Elaych micro...@gmail.comjavascript: wrote: So I guess that means using jayq. Is that the new consensus on using clojurescript for guis? I see lots of discussion on closure vs jquery in clojurescript but it is hard to tell what is going to be the standard. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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 clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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 clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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: Enfocus issues
Thanks for point that out. It will be fixed shortly. CK On Friday, June 15, 2012 1:40:22 AM UTC-4, Andreas Kostler wrote: There you go...wrong on the example-page then. Thanks David On 15 June 2012 15:00, David Nolen dnolen.li...@gmail.com wrote: On Fri, Jun 15, 2012 at 1:23 AM, Andreas Kostler andreas.koest...@leica-geosystems.com wrote: (set! (.onload js/window) start) Should be (set! (.-onload js/window) start) -- 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: Enfocus issues
Andreas Thank you for pointing this out. I have fixed this on the readme page. I also noticed it is wrong in a few other places. I will fix them today also. Enfocus also has a google group if you run into more issues. https://groups.google.com/group/enfocus Creighton -- 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: ANN: clj-browserchannel-demo, cljs - clj communication
Nice work! I have been looking into this also. I think I have found something to keep me busy this weekend. On Mar 28, 7:45 am, Gijs S. gijsstuur...@gmail.com wrote: Here is the chat app on Heroku: http://cold-stream-6156.herokuapp.com/index.html -Gijs On Mar 28, 1:39 pm, Gijs S. gijsstuur...@gmail.com wrote: Hi, clj-browserchannel-demo demonstrates cross-browser compatible, real- time, bi-directional communication between ClojureScript and Clojure using Google Closure BrowserChannel. From the Google Closure API: A BrowserChannel simulates a bidirectional socket over HTTP. It is the basis of the Gmail Chat IM connections to the server. The javascript api of BrowserChannel is open-source and part of the Google Closure library. The server component is not, as is noted in the Google Closure book (Closure: The Definitive Guide by Michael Bolin). clj-browserchannel-demo is an example chat application using a server side implementation for BrowserChannel written in Clojure. The server component is for BrowserChannel version 8. This enables client-server and server-client communication in ClojureScript and Closure web apps, without any javascript dependencies other than the Google Closure library. The chat example runs in at least: * Chrome * Firefox * Internet Explorer 5.5+ (!!) * Android browser The code is on github:https://github.com/thegeez/clj-browserchannel-demo Read the README for instructions on running and for further background on the BrowserChannel protocol and capabilities. Cheers, Gijs Stuurmanhttp://twitter.com/thegeez/http://thegeez.github.com -- 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: Clarification on ClojureScript libraries
Base, Sean, Several of us are actively working on getting some of these issues resolved. I have a patch that I am finishing up testing on this week that will allow libraries to specify externs, libs and foreign-libs inside the library. This should fix some of the upstream dependency issues like the extern issue you described. I haven't ran across the :use issue but will try to reproduce. I tend to use required so that doesn't surprise me too much. Depending on the version of ClojureScript you are running, you may, or may not, be able to pull externs and libs from the classpath. Luke pushed my patch for this into the main branch a couple of weeks ago. If you do have the most recent and still see an issue with externs not pulling from the classpath let me know. Its probably a bug in the code I added. CK On Feb 7, 1:11 pm, Sean Corfield seancorfi...@gmail.com wrote: On Tue, Feb 7, 2012 at 8:18 AM, Base basselh...@gmail.com wrote: For the former, it is easy enough to just add the reference to the project.clj and it automagically appears in the lib. Does the same hold true for Clojurescript libraries? I cannot seem to get this to work correctly and end up dropping the files in the directory defined in the :source-path in the project.clj. I just went thru this last night with Chris Granger's jayq wrapper for jQuery. I added a standard project.clj dependency on the library [jayq 0.1.0-SNAPSHOT] and lein deps brought it in as expected. Things worked fine in :whitespace and :simple mode (:optimizations) but broke in :advanced mode. The reason was that externs (declarations of library names) was not picked up from the classpath (yet). The fix was to run: jar xf lib/jayq-*.jar externs in my project to extract the externs folder (containing the jquery.js declarations) into the top-level of my project. Forcing a recompile of the cljs then solved the problem. Another problem I ran into initially was not specifying :output-dir in the compilation options. The compiler caches the source cljs and compiled js and when I updated the jayq library (to pick up a fix from Chris - thank you!), the old source was still being used. Once I specified :output-dir I could see the problem and removing the generated files (or using lein cljsbuild clean) emptied that cache and forcing a recompile picked up the new source from the jayq JAR. Oh, and my first problem was that with multiple :use clauses for different cljs files in my ns declaration, the compiler seemed to get confused about which namespace symbols lived in so it would produce example.core.$.call(...) instead of jayq.core.$.call(...) or example.core.by_id(...) instead of example.util.by_id(...). I finally gave up on :use'ing multiple cljs code packages. I've had similar problems with :require but can't track down the specific situation that works vs fails (yet). Small problems but frustratingly hard to debug because a) the compilation produces giant JS files in non-advanced mode and incomprehensible JS files in advanced mode and b) the g-Closure compiler is a big black box so it's really hard to tell what's going on. I also (sometimes) got an HTTP request for /deps.js which no one on IRC seemed to be able to explain (so I just created an empty deps.js file to shut it up). ClojureScript is very promising - and I much prefer writing Clojure to writing JS - but as soon as you stray from a specific published example or from the simplest possible thing that works, you can get into a landmine-filled world of frustration at the moment. Things are improving rapidly tho'... -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 in IE 9 (does it work?)
I ran into the same thing with .setTimeout in enfocus. I moved to using the wrapper function inside the goog library. In the case of .setTimeout I used goog.async.Delay and for alert maybe you could use goog.ui.dialog. http://closure-library.googlecode.com/svn/docs/class_goog_ui_Dialog.html Creighton Kirkendall On Jan 16, 5:32 am, David Powell djpow...@djpowell.net wrote: On Mon, Jan 16, 2012 at 7:59 AM, gchristnsn gchrist...@gmail.com wrote: I can't even call `(js/alert test)' in IE 9, it compiles into: alert.call(null,test); and says: Invalid calling object (IE 9 standayrds mode, in IE 8 standards mode it doesn't recognize the `call' method) I need `alert' to debug some other glitch which arises in IE 9 (but all works fine in other browsers), is it by design? The problem is that things like window.alert on IE, are weird built-in things that aren't actually 'functions' in the javascript sense, in that they don't have Function as their prototype, so clojurescript's attempt to .call them fails. I think that this might actually be permitted behaviour? So, I'm not sure what the best solution is. As a quick workaround you could probably write your own myalert function in javascript that just calls window.alert, and include it at the top of your page - clojurescript will be able to call js/myalert. Perhaps clojurescript should have some sort of workaround for making these built-ins work on IE... Any ideas? -- Dave -- 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 goog libs - dispose - and garbage collection
Dave, I think you are right that my implementation does cause a memory leak over time. It interesting that I can't find a single example of someone calling dispose on an object like this. The google code for disposable hold a global reference to all disposable instances and only removes when dispose it called. It might be better to use the static function goog.Timer.callOnce(listener, opt_delay, opt_handler). Creighton Kirkendall On Jan 16, 6:25 pm, Dave Sann daves...@gmail.com wrote: If you use something like goog.async.Delay, or other goog closure libs that produce objects that have a dispose method, Is it imperative that .dispose is called when you are done with this object? What happens if not? memory leak? How do you manage this if you are passing such objects around in function closures or other structures where you may not (want to) know exactly when this may be no longer required? I was looking at this thread - and the conversion of js/setTimeout to goog.async.Delay, along with the enfocus implementation https://groups.google.com/d/msg/clojure/epHVbmcNzgs/3pVyS_AKCYUJ from enfocus: (defn setTimeout [func ttime] (. (new goog.async.Delay func ttime) (start))) what about functions such as this? (defn repeat-with-timeout [f t] (let [stop (f)] (if-not (= true stop) (js/setTimeout #(repeat-with-timeout f t) t Cheers Dave -- 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 goog libs - dispose - and garbage collection
Dave, I found a good explanation of disposables: http://groups.google.com/group/closure-library-discuss/browse_thread/thread/b2b38d0045464439 Creighton Kirkendall On Jan 16, 6:25 pm, Dave Sann daves...@gmail.com wrote: If you use something like goog.async.Delay, or other goog closure libs that produce objects that have a dispose method, Is it imperative that .dispose is called when you are done with this object? What happens if not? memory leak? How do you manage this if you are passing such objects around in function closures or other structures where you may not (want to) know exactly when this may be no longer required? I was looking at this thread - and the conversion of js/setTimeout to goog.async.Delay, along with the enfocus implementation https://groups.google.com/d/msg/clojure/epHVbmcNzgs/3pVyS_AKCYUJ from enfocus: (defn setTimeout [func ttime] (. (new goog.async.Delay func ttime) (start))) what about functions such as this? (defn repeat-with-timeout [f t] (let [stop (f)] (if-not (= true stop) (js/setTimeout #(repeat-with-timeout f t) t Cheers Dave -- 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: Libraries for ClojureScript.
Manjo, I think there is considerable benefit in keeping certain APIs similar between ClojureScript and Clojure. In places where the intent is the same I would suggest going with a familiar API. I took this approach with enfocus by basing it on enlive. It sped up my development because I didn't have to ponder if the semantics were usable. In the places where my feature set didn't line up, I found myself working and reworking the apis because they weren't clean enough or they seemed confusing. All of that being said, ClojuresSript is very young and I don't think we have a right way to do things yet. Right now I would be willing to try any testing library regardless if it matched Clojure. Creighton Kirkendall On Jan 15, 12:37 am, mmwaikar mmwai...@gmail.com wrote: Hi, My question is about design of libraries for ClojureScript. So for ex, there is clojure.test which has some public API. Now assume one has used it and is comfortable with its API. Now he has to write some ClojureScript code and wants to write some unit tests as well. Obviously, he'll use some pre-existing JS library / framework, but it will have its own API. Now - 1) Does it make sense to write a ClojureScript wrapper over existing JS libraries (as there are wrappers over many Java libraries / frameworks)? 2) Does it make sense, or is it better if this ClojureScript wrapper, exposes the same (as far as possible) or similar API to that of one of the Clojure libraries? The obvious advantage being the programmer has to get accustomed to just one API, which works for Clojure as well as ClojureScript. Please let me know your views. Thanks, Manoj. -- 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: Enlive reborn in ClojureScript - Enfocus (Dom Manipulation Lib)
Peter, Sean, Thanks for the encouraging words. Sean, you sort of help launched this idea. It was while looking at framework1's use of Enlive, at ClojureConj, that I began thinking about how to use this on the client side. Creighton Kirkendall On Jan 9, 11:36 am, Sean Corfield seancorfi...@gmail.com wrote: On Sun, Jan 8, 2012 at 10:48 PM, Peter Taoussanis ptaoussa...@gmail.com wrote: I also get the impression that Enlive itself seems to be quite widely misunderstood and consequently underrated. Haven't had a chance to take a serious look at this yet myself (I will!), but just wanted to throw my support behind the idea. I'll +1 both of these sentiments. I use Enlive for HTML emails that we send out at World Singles and we're pretty happy with it so I expect once we start using ClojureScript, we'd be interested in Enfocus. -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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 DOM-manipulation library?
I have written dom manipulation library for ClojureScript. I just finished it up but haven't announced it yet. It started out as a port of enlive to ClojureScript but has evolved into something much more powerful. I covers everything from event handling, effects and standard transformations. Below are links to the github and demo site. Demo Site: http://ckirkendall.github.com/enfocus-site/ Github: https://github.com/ckirkendall/enfocus Creightion Kirkendall On Jan 6, 3:16 am, Shantanu Kumar kumar.shant...@gmail.com wrote: Is anybody working on a DOM-manipulation library for ClojureScript? There are several JavaScript libraries that can probably be wrapped, but a ClojureScript library should be great. I noticed a short comparative list of jQuery basic operations vs JavaScript equivalent that looks interesting:http://sharedfil.es/js-48hIfQE4XK.html 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
Enlive reborn in ClojureScript - Enfocus (Dom Manipulation Lib)
Since some very cool side bar conversations at clojure conj I have been bent on porting Enlive to ClojureScript. It has finally reach a point where it is stable and useful, so I give you: Enfocus. Enfocus is a dom manipulation library for ClojureScript. Originally inspired by Christophe Grand's clojure based Enlive, it has evolved into a cross browser tool for building rich UIs. It supports all of the Enlive based transformations along with many more transformations geared towards managing live dom features, such as events and effects. Demo Site: http://ckirkendall.github.com/enfocus-site/ GitHub: https://github.com/ckirkendall/enfocus -- 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 DOM-manipulation library?
Chris, I am interested in your challenges. For Enfocus I had to implement several features that existed in jquery around events (mouseenter, mouseleave, window resize) but I wanted to keep the stack pure without any external dependencies. Enfocus might have been easier to implement if I had chosen JQuery but I was afraid that requiring an external dependency might be problem. I was able to port all of enlive transformation and quite a bit more. It provides similar model as JQuery where I have selector - action. Overall, I did not find it overly difficult to use the goog libraries for this. CK On Jan 6, 1:37 pm, Chris Granger ibdk...@gmail.com wrote: So there's pinot, but I've come to a relatively similar conclusion to Kovas that wrapping the goog libs aren't really the way to go. For one, I was basically replicating aspects of jQuery (like event delegation). Recently I started on doing some thing that makes jQuery play in the Clojure world really nicely. I'll get this onto github soon. Cheers, Chris. On Jan 6, 5:18 pm, kovas boguta kovas.bog...@gmail.com wrote: Yes. I've created a jquery wrapper conveniently called cljs-jquery , however there is no documentation, tests, or general housekeeping yet so haven't announced it. If you are brave,https://github.com/kovasb/cljs-jquery Previous libraries have followed the lead of the initial Clojurescript examples, and tried to wrap gclosure to make it more clojure-idiomatic. I think this whole approach is a mistake. This is not a generic data processing problem, so we shouldn't be converting the dom into verbose generic clojure structures with namespace prefixes everywhere. DOM manipulation is ideally suited to a DSL. JQuery already defines the primitives, and provides the implementation. Lets just wrap it. The idea of my library is trivial. Just have a macro that expands into a jquery call chain: $(selector).f(a,b).g(c,d) is represented by ($ selector (f a b) (g c d)) (note that f and g don't need buzz-killing namespace prefixes) For bonus points, selector can be a hiccup structure (or a hiccup structure with embedded dom objects) which ends up saving a huge amount of code when creating new elements. In general this is far more concise and easier to code than any other approach I've seen thus far. On Fri, Jan 6, 2012 at 3:16 AM, Shantanu Kumar kumar.shant...@gmail.com wrote: Is anybody working on a DOM-manipulation library for ClojureScript? There are several JavaScript libraries that can probably be wrapped, but a ClojureScript library should be great. I noticed a short comparative list of jQuery basic operations vs JavaScript equivalent that looks interesting:http://sharedfil.es/js-48hIfQE4XK.html 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: Clojure Conj extracurricular activities spreadsheet
Please sign me up (or give me edit access to the document) for: ClojureScript Clojure Tooling The Web and Clojure Thank you! -- 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: BDD - Given When Then
I did just recently port Jim Weirich's ruby based rspec-given to Clojure. It is a very simple BDD framework build on top of clojure.test as a set of macros. You can find the link here. https://github.com/ckirkendall/ClojureGiven Creighton Kirkendall On Jul 11, 2:12 pm, Max Weber mm.we...@web.de wrote: Hi, I like to write some integration/acceptance tests in Clojure. At the moment I'm using cuke4duke (cucumber), but I'm not satisfied with it. For my unit tests I'm already using lazytest. In the acceptance tests I like to apply the typical Given When Then template (like cucumber do). So are there any nice alternatives to cucumber/cuke4duke? I know circumspec https://github.com/stuarthalloway/circumspec, but the project makes no progress anymore? What is the relationship between circumspec and lazytest https://github.com/stuartsierra/lazytest? How can acceptance tests be written with lazytest, which follow the Given When Then template (like thishttps://github.com/stuarthalloway/circumspec/blob/master/examples/the...circumspec example)? Best regards Max -- 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
New BDD framework for Clojure - ClojureGiven
Recently I sat through a presentation on Jim Weirich's ruby based rspec-given. I decided to see if it was possible to port it as a set of macros over clojure.test. Turns out that it was fairly easy to port the concepts over to clojure. Link: https://github.com/ckirkendall/ClojureGiven Basic Syntax: (ns cljgiven.test.core (:use [cljgiven.core]) (:use [clojure.test])) (defspec basic-spec (Given [t1 (+ 1 x) t2 (- 2 t1)]) ;this is lazy (Given! [y 3]) ;this is not (Context let us test t1 (Given [x (+ 1 y)]);this is lazy (When result (+ 1 t1)) ;lazy Givens above evaluated now (Then (= 6 result))) (Context let us test t2 (Given! [x (+ 1 3)]) ;not lazy (When result2 (+ t2 x)) (Then (= 2 result2 -- 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
Using agents in libraries bad?
It seems that having non-daemon threads in the agents pool and requiring a call shutdown agents before the jvm exits makes using agents in a library very difficult. You either need to have as part of your api a function that calls (shutdown-agents) or require the consumer to know you are using agents. Having the API calls seems scary because it can affect other running programs, if its not use properly or in the wrong context. Other places that even these two options fail is any library that is used by a web application in a java web container. Nether party can call (shutdown-agents) because you could affect other sites in the same app server. -- 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: :gen-class possibly missing a compile time check when extending abstract classes that implement interfaces
I added an explanation of this a comment to the documentation on http://clojuredocs.org On May 29, 3:01 pm, Sean Corfield seancorfi...@gmail.com wrote: I also ran into this recently - doing the exact same thing (a log4j appender). I was a bit surprised and I wonder if Clojure is effectively generating abstract classes rather than concrete classes? (Do we have no way to specify the difference? Is that only an artifact of the Java compiler, not the JVM bytecode?) As you say, the fix tends to be easy (read the class API docs and implement the missing methods) but the behavior needs to be clearly documented (on clojure.org) to help people avoid the problem I think... Sean On Sun, May 29, 2011 at 7:04 AM, ckirkendall ckirkend...@gmail.com wrote: I ran into this when creating a log4j appender in Clojure. I extended the AppenderSkeleton, an abstract class. This abstract class implements Appender. Appender defines two methods that don't appear in the AbstractSkeleton (requiresLayout close). I was able to compile the Clojure class, without the two methods in question, with no error. I then threw a runtime exception when I tried to use the class. The fix was easy but it seems this should probably be checked at compile 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
Re: :gen-class possibly missing a compile time check when extending abstract classes that implement interfaces
I disagree currently this is a compile time checks provided by javac. On May 30, 11:42 am, Meikel Brandmeyer m...@kotka.de wrote: Hi, I think, clojure just generates a class with stubs for all methods, which check whether an implementing function exists. If yes, they call it. If no, they pass on to super. If there is no such method in super, they throw a reasonable exception. Eg. I get the following for a class implementing Iterable without defining -iterator: UnsupportedOperationException iterator (foo.Bar/-iterator not defined?) foo.Bar.iterator (:-1) What might be a problem though, is that your superclass claims to implement a given interface without actually doing so. Then clojure sees the implemented methods, but calling them will fail. My gut feeling is, that the abstract class should document, that you have to implement these methods. Having javac point you to such a fact is not good-style, IMHO. Sincerely Meikel -- 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
:gen-class possibly missing a compile time check when extending abstract classes that implement interfaces
I ran into this when creating a log4j appender in Clojure. I extended the AppenderSkeleton, an abstract class. This abstract class implements Appender. Appender defines two methods that don't appear in the AbstractSkeleton (requiresLayout close). I was able to compile the Clojure class, without the two methods in question, with no error. I then threw a runtime exception when I tried to use the class. The fix was easy but it seems this should probably be checked at compile time. Clojure 1.2.1 Log4j 1.2.15 -- 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
