Re: clojureshell-maven-plugin - easier clojure startup with maven
On Fri, Sep 4, 2009 at 3:58 AM, J. McConnell wrote: > On Thu, Sep 3, 2009 at 12:40 PM, Fredrik Appelberg < > fredrik.appelb...@gmail.com> wrote: > >> >> I've just released the first tentative version of Clojureshell. It's a >> simple maven plugin that allows you to easily start a clojure REPL or run a >> Swank server in the context of any maven project. > > > This looks great, thanks Fredrik! The first time I tried to run "mvn > clojureshell:repl" I received an error about the plugin not being found. > Running "mvn -X clojureshell:repl" results in the following snippet: > > [INFO] Searching repository for plugin with prefix: 'clojureshell'. > [DEBUG] Loading plugin prefixes from group: nu.mulli > [INFO] nu.mulli: checking for updates from mulli.nu > [DEBUG] repository metadata for: 'nu.mulli' could not be found on > repository: mulli.nu > Hm... Could you post (or email me) the relevant portions of your settings.xml? Also, what version of maven are you running? I've tested this on three machines (two linux, one OSX), but it strikes me that they all run maven 2.0.9; I haven't tested running any previous (or later) versions at all. If you are really anxious the get going, you could download the source from github, then run 'mvn install' to install it locally. Then you should be all set; try invoking it with the qualified name 'mvn nu.mulli:clojureshell-maven-plugin:repl' to see if it's working. Hope this helps, -- Fredrik == What am I up to? http://twitter.com/appelberg --~--~-~--~~~---~--~~ 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: No line information in debugger
Well, I was a little quick. NetBeans seems to work ok but JSwat still doesn't show any line number information. I had made sure that all JVM had been shutdown prior to my re-testing, so go figure. On Sep 3, 11:56 pm, Bokeh Sensei wrote: > FIXED! > > I found in the Java Preferences -> Advanced ->Enable Tracing and > Enable Logging were checked. > I unchecked them and also reset all JVMs to their defaults, using the > reset button :) > > And it works, my line numbers get generated by the JVM and I can debug > in NetBeans > > On Sep 3, 9:12 pm, Bokeh Sensei wrote: > > > > > Actually I was just doing a load-file from the Repl. > > > I'm currently trying the Netbeans Enclojure plugin but same results. > > In Enclojure, I'm using the same code, except it's called from the > > generated -main function. > > > It compiles and runs just fine, it's just not possible to set > > breakpoints for some reason. In Netbean, the Toggle Line BP is grayed > > out. > > Since Netbeans generates the project for you, I thought at least that > > should give me a good classpath to work with... > > > In JSwat, no line numbers and can't set bps. > > I'm sure there's nothing wrong with either tools, so it must be > > something on my side, but not knowing (yet) how this works, I'm kinda > > stuck... > > > On Sep 3, 6:24 pm, Stuart Sierra wrote: > > > > I don't know about JSwat, but I know that code entered directly at the > > > REPL (or eval'ed from SLIME) doesn't have line numbers. > > > -SS > > > > On Sep 3, 5:25 pm, Bokeh Sensei wrote: > > > > > I can't get JSwat to display and break on lines in my Clojure code. > > > > Does anybody knows how this works? > > > > What files, output could I verify to get myself out of this problem? > > > > > (I can get attach JSwat to a Repl, no problem, can pause it and > > > > continue it) --~--~-~--~~~---~--~~ 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: clojureshell-maven-plugin - easier clojure startup with maven
On Fri, Sep 4, 2009 at 3:25 AM, Mark Derricutt wrote: > Cool, I've meaning to reply to your post about merging that into > maven-clojure-plugin but have been snowed under at $work this week. I've > never actually looked at swank but from what I understand of it it'd be darn > useful. Swank/Slime is really cool; you can start your server and leave it running, then connect from the same machine or over the network (I think you can also have multiple clients connecting to the same server). Re: merging the plugins, I realized yesterday that we probably have a licensing clash. Clojureshell bundles code from swank-clojure, so I must license it under GPLv3. That could be a problem. Cheers, -- Fredrik == What am I up to? http://twitter.com/appelberg --~--~-~--~~~---~--~~ 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: clojureshell-maven-plugin - easier clojure startup with maven
On Fri, Sep 4, 2009 at 9:35 AM, Fredrik Appelberg < fredrik.appelb...@gmail.com> wrote: > > > On Fri, Sep 4, 2009 at 3:58 AM, J. McConnell wrote: > >> On Thu, Sep 3, 2009 at 12:40 PM, Fredrik Appelberg < >> fredrik.appelb...@gmail.com> wrote: >> >>> >>> I've just released the first tentative version of Clojureshell. It's a >>> simple maven plugin that allows you to easily start a clojure REPL or run a >>> Swank server in the context of any maven project. >> >> >> This looks great, thanks Fredrik! The first time I tried to run "mvn >> clojureshell:repl" I received an error about the plugin not being found. >> Running "mvn -X clojureshell:repl" results in the following snippet: >> >> [INFO] Searching repository for plugin with prefix: 'clojureshell'. >> [DEBUG] Loading plugin prefixes from group: nu.mulli >> [INFO] nu.mulli: checking for updates from mulli.nu >> [DEBUG] repository metadata for: 'nu.mulli' could not be found on >> repository: mulli.nu >> > > Hm... Could you post (or email me) the relevant portions of your > settings.xml? > > Also, what version of maven are you running? I've tested this on three > machines (two linux, one OSX), but it strikes me that they all run maven > 2.0.9; I haven't tested running any previous (or later) versions at all. > > If you are really anxious the get going, you could download the source from > github, then run 'mvn install' to install it locally. > Then you should be all set; try invoking it with the qualified name 'mvn > nu.mulli:clojureshell-maven-plugin:repl' to see if it's working. > Er. Forgot about this, but build instructions should be: 1. git clone git://github.com/fred-o/clojureshell-maven-plugin.git 2. cd clojureshell-maven-plugin 3. git submodule init 4. git submodule update 5. mvn install Cheers, -- Fredrik == What am I up to? http://twitter.com/appelberg --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Fixing production systems on-the-fly
I was thinking about the capability of changing production systems on the fly. E.g. by having an accessible repl in a running production system. If you have a bug in a function, you can fix it by re-def'ing it - that is great. However, suppose you want to do a system upgrade where you want to change several things. Now you could just re-def each var one at a time, but this might produce an inconsistent program in the interval where you have re-def'ed some but not all vars. This first thing you would want is sort-of a atomic update of all vars, similarly to what is possible with refs. Is this possible somehow? If not are there any techniques or best practices for these "system upgrades"? /Karl --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
You have to be prepared to deal with potential inconsistencies: a
closure (or any object) can hold a reference to the value of a
function.
(defn foo [x] (str x "v1"))
(def s (map foo [:a :b :c]))
(defn foo [x] (str x "v2"))
s ; (":av1" ":bv1" ":cv1")
Christophe
On Fri, Sep 4, 2009 at 10:22 AM, Krukow wrote:
>
> I was thinking about the capability of changing production systems on
> the fly. E.g. by having an accessible repl in a running production
> system.
>
> If you have a bug in a function, you can fix it by re-def'ing it -
> that is great. However, suppose you want to do a system upgrade where
> you want to change several things. Now you could just re-def each var
> one at a time, but this might produce an inconsistent program in the
> interval where you have re-def'ed some but not all vars.
>
> This first thing you would want is sort-of a atomic update of all
> vars, similarly to what is possible with refs. Is this possible
> somehow? If not are there any techniques or best practices for these
> "system upgrades"?
>
>
> /Karl
>
> >
>
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.blogspot.com/ (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: Fixing production systems on-the-fly
On Sep 4, 11:22 am, Krukow wrote: > I was thinking about the capability of changing production systems on > the fly. E.g. by having an accessible repl in a running production > system. > > If you have a bug in a function, you can fix it by re-def'ing it - > that is great. However, suppose you want to do a system upgrade where > you want to change several things. Now you could just re-def each var > one at a time, but this might produce an inconsistent program in the > interval where you have re-def'ed some but not all vars. > > This first thing you would want is sort-of a atomic update of all > vars, similarly to what is possible with refs. Is this possible > somehow? If not are there any techniques or best practices for these > "system upgrades"? > > /Karl Hm, I don't think it's possible to have transactional updates involving multiple Vars, but you can always keep functions in Refs: (def foo (ref (fn foo [x] x))) then, because IRefs forward calls to their values, you can just do (foo 1) and it works. :) When you want to update multiple refs, all you should need to do is (dosync (ref-set foo newfn) (ref-set another-foo anothernewfn)) ... This approach requires a bit of manual work and discipline, but probably is worth investigating -- Jarkko --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
2009/9/4 Jarkko Oranen > > On Sep 4, 11:22 am, Krukow wrote: > > I was thinking about the capability of changing production systems on > > the fly. E.g. by having an accessible repl in a running production > > system. > > > > If you have a bug in a function, you can fix it by re-def'ing it - > > that is great. However, suppose you want to do a system upgrade where > > you want to change several things. Now you could just re-def each var > > one at a time, but this might produce an inconsistent program in the > > interval where you have re-def'ed some but not all vars. > > > > This first thing you would want is sort-of a atomic update of all > > vars, similarly to what is possible with refs. Is this possible > > somehow? If not are there any techniques or best practices for these > > "system upgrades"? > > > > /Karl > > Hm, I don't think it's possible to have transactional updates > involving multiple Vars, but you can always keep functions in Refs: > (def foo (ref (fn foo [x] x))) > > then, because IRefs forward calls to their values, you can just do > (foo 1) and it works. :) > When you want to update multiple refs, all you should need to do is > (dosync (ref-set foo newfn) (ref-set another-foo anothernewfn)) ... > > This approach requires a bit of manual work and discipline, but > probably is worth investigating > And still, if on the calling side you need to apply a consistent state of several functions, you'll need to also make these calls from within a dosync too ... --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
Don't forget about classic stuff, like rigorous testing. I've tried updating live production systems with Rails before, and it's burned me (Think bringing down the entire production website). Small changes you "are sure will work" often have subtle implications in different environments. A few things I've been burned by before: * Is your fix the right thing? We all make mistakes. * Is the database in a similar state? Production might have nulls/ other weird values. * Is the filesystem in a similar state? This is important if your system depends on user files (like flickr). * Is the JVM the same version? * Are all the dependent .JARs the same revision? * Are there differences between the development & production OS (not as a big deal w/ Java, but still worth considering) * Are the configuration options on the production servers that are different. * Will your application source code be in the same state as the production system? What happens when you restart? This is annoying enough in development, let alone production. * Will you lose the history of he bug? Since Clojure is functional, it's really easy to recreate a unit test of the failure condition. Make sure to capture the existence of the bug. * Will your fix scale? Admittedly, this is harder to test than most other things. I know a lot my code is O(n) or O(n^2) first time around, and I could easily speed it up an order of magnitude just by indexing So I guess my final response to deploying untested changes to a production system is "Don't do it". My $.02 Sean On Sep 4, 4:22 am, Krukow wrote: > I was thinking about the capability of changing production systems on > the fly. E.g. by having an accessible repl in a running production > system. > > If you have a bug in a function, you can fix it by re-def'ing it - > that is great. However, suppose you want to do a system upgrade where > you want to change several things. Now you could just re-def each var > one at a time, but this might produce an inconsistent program in the > interval where you have re-def'ed some but not all vars. > > This first thing you would want is sort-of a atomic update of all > vars, similarly to what is possible with refs. Is this possible > somehow? If not are there any techniques or best practices for these > "system upgrades"? > > /Karl --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
On Sep 4, 1:38 pm, Christophe Grand wrote: > You have to be prepared to deal with potential inconsistencies: a > closure (or any object) can hold a reference to the value of a > function. OK - I realized this already for running threads, e.g., executing a function where a var means one thing the first time around and another the second. But your example points out that laziness and closures makes this even worse :-( I guess the conclusion is that you can't really fix live production systems without some downtime without carefully designing the system for this upfront (following certain conventions), i.e., you don't get this *for free* by using a LISP (of course the development aspects of change on-the-fly are still good). Now I am a complete Erlang novice, but I think OTP has (some kind of) built-in support for system upgrades. It might be worth checking out to see if there is something we can adapt to Clojure? /Karl --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
On Sep 4, 1:38 pm, Christophe Grand wrote: > You have to be prepared to deal with potential inconsistencies: a > closure (or any object) can hold a reference to the value of a > function. In some circumstances, I am careful to pass vars rather than fns, if I know they are going to be held. That makes things easier during development, and when I want to roll in updates in production. - Chas --~--~-~--~~~---~--~~ 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: Eval troubles
On Sep 4, 1:55 am, Miron Brezuleanu wrote: > I'm not sure this is an interpreter/compiler issue :-) I think it is > more of a resource allocation problem, i.e. what features to add to > Clojure and when. True, it's that Clojure does not have first-class environments, either dynamic or lexical. I think it's been discussed, but not very seriously. -SS --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
On Sep 4, 4:22 am, Krukow wrote: > I was thinking about the capability of changing production systems on > the fly. E.g. by having an accessible repl in a running production > system. This is a popular list question. The short answer is "no." It might work for correcting a single, isolated function. But in general, there are too many potential interactions to do this safely. If you really want system-wide, real-time code upgrades, then Erlang is your friend, but that's a radically different virtual machine model, not easily replicated. Java servlet containers like Tomcat support "hot deploy" to a limited extent, but it's tricky to use. -SS --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
Erlang allows two versions of a module to be stored in memory at any given time. This allows you to do hot code swapping at runtime without taking down the running server. Clojure can obviously do the same thing, but Erlang offers a convenient builtin mechanism for shelling into the running Erlang VM. I've been thinking about how this would be accomplished in Clojure, and it seems you could simply have a thread listening for a connection and then write a small function to inject the new code across the listening socket. This way, you could fire up your REPL, load your library, and then just call your hot-swap function to send a new callback to the running server without any additional dependencies such as Nailgun (which I wouldn't use in production anyway). -Travis On Sep 4, 8:59 am, Krukow wrote: > On Sep 4, 1:38 pm, Christophe Grand wrote: > > > You have to be prepared to deal with potential inconsistencies: a > > closure (or any object) can hold a reference to the value of a > > function. > > OK - I realized this already for running threads, e.g., executing a > function where a var means one thing the first time around and another > the second. But your example points out that laziness and closures > makes this even worse :-( > > I guess the conclusion is that you can't really fix live production > systems without some downtime without carefully designing the system > for this upfront (following certain conventions), i.e., you don't get > this *for free* by using a LISP (of course the development aspects of > change on-the-fly are still good). > > Now I am a complete Erlang novice, but I think OTP has (some kind of) > built-in support for system upgrades. It might be worth checking out > to see if there is something we can adapt to Clojure? > > /Karl --~--~-~--~~~---~--~~ 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: clojureshell-maven-plugin - easier clojure startup with maven
On Sep 3, 12:40 pm, Fredrik Appelberg wrote: > I've just released the first tentative version of Clojureshell. It's a > simple maven plugin that allows you to easily start a clojure REPL or run a > Swank server in the context of any maven project. Here's a rough-and-ready pom.xml for using the Clojureshell plugin with a single project. This is based on the example developed in my last blog post. http://paste.lisp.org/display/86560 -SS --~--~-~--~~~---~--~~ 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: Another Clojure Box - Version 1.4
I like Scite but I also use Linux. Any guidance on what steps I would need to take to port just the Scite part of ACV to linux? What specific config files? Thanks, On Fri, Sep 4, 2009 at 7:30 PM, Shantanu Kumar wrote: > > Not sure if I am the only one - I was not able to make the copy-to- > REPL and execute-block-of-code work using the keyboard shortcuts > mentioned on the URL, nor using any other method. I am using Windows > XP 32-bit with JDK 1.6.0_16. > > I look forward to somebody correcting me what I am doing wrong. :-) > > Regards, > Shantanu > > On Sep 3, 8:37 pm, Darmac wrote: > > Hi, > > I just release version 1.4 of ACB. > > > > Changelog: > > ++ Customized version of SciTE 2.01. It's accept \n in tooltips and > > have a simple clojure lexer (don't use lisp lexer any more). > > ++ Better SciTE autocomplete (recognize ?,- and others keyword > > symbols) > > ++ Now you can resize file explorer in SciTE (bug fixed) > > > > With the customized clojure SciTE lexer I have more freedom in order > > to make SciTE more confortable (better syntax, better folding, etc.) > > > > Give it a try and tell me what you think!! > > > > http://sites.google.com/site/dariomac/Home/projects/anotherclojurebox > > > -- John --~--~-~--~~~---~--~~ 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: Another Clojure Box - Version 1.4
Not sure if I am the only one - I was not able to make the copy-to- REPL and execute-block-of-code work using the keyboard shortcuts mentioned on the URL, nor using any other method. I am using Windows XP 32-bit with JDK 1.6.0_16. I look forward to somebody correcting me what I am doing wrong. :-) Regards, Shantanu On Sep 3, 8:37 pm, Darmac wrote: > Hi, > I just release version 1.4 of ACB. > > Changelog: > ++ Customized version of SciTE 2.01. It's accept \n in tooltips and > have a simple clojure lexer (don't use lisp lexer any more). > ++ Better SciTE autocomplete (recognize ?,- and others keyword > symbols) > ++ Now you can resize file explorer in SciTE (bug fixed) > > With the customized clojure SciTE lexer I have more freedom in order > to make SciTE more confortable (better syntax, better folding, etc.) > > Give it a try and tell me what you think!! > > http://sites.google.com/site/dariomac/Home/projects/anotherclojurebox --~--~-~--~~~---~--~~ 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: clojureshell-maven-plugin - easier clojure startup with maven
On Fri, Sep 4, 2009 at 3:35 AM, Fredrik Appelberg < fredrik.appelb...@gmail.com> wrote: > On Fri, Sep 4, 2009 at 3:58 AM, J. McConnell wrote: > >> On Thu, Sep 3, 2009 at 12:40 PM, Fredrik Appelberg < >> fredrik.appelb...@gmail.com> wrote: >> >>> >>> I've just released the first tentative version of Clojureshell. It's a >>> simple maven plugin that allows you to easily start a clojure REPL or run a >>> Swank server in the context of any maven project. >> >> >> This looks great, thanks Fredrik! The first time I tried to run "mvn >> clojureshell:repl" I received an error about the plugin not being found. >> Running "mvn -X clojureshell:repl" results in the following snippet: >> >> [INFO] Searching repository for plugin with prefix: 'clojureshell'. >> [DEBUG] Loading plugin prefixes from group: nu.mulli >> [INFO] nu.mulli: checking for updates from mulli.nu >> [DEBUG] repository metadata for: 'nu.mulli' could not be found on >> repository: mulli.nu >> > > Hm... Could you post (or email me) the relevant portions of your > settings.xml? > I think there may be some issues with the way my company has us configure Maven. I'm checking with someone to see if that's the problem. I can't install from source either because it looks like all requests for dependencies, regardless of the tag in the POM, are routed through our internal repository, so I can't grab your org.clojure:clojure-lang:1.0 jar hosted on milli.nu. > Also, what version of maven are you running? I've tested this on three > machines (two linux, one OSX), but it strikes me that they all run maven > 2.0.9; I haven't tested running any previous (or later) versions at all. > I'm also on 2.0.9. Thanks for the help. I'll update you if the problem does not end up being on my side, but I strongly suspect it is. Thanks, - J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
from OO to Lisp style (a blog post)
Hi, In using the Jwt library, for which I only found examples in object oriented languages that structure the code in class definitions and do heavy usage of instance variables, I was in a situation where I wondered how I could best structure my code. With help on the IRC channel I got to a working solution which I document in a blog post at http://www.nsa.be/index.php/eng/Blog/From-OO-to-Lisp-style-structuring-my-Clojure-Jwt-app I'm interested in feedback and advices for improvements Thanks Raph --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
> Now I am a complete Erlang novice, but I think OTP has (some kind of) > built-in support for system upgrades. It might be worth checking out > to see if there is something we can adapt to Clojure? There are several tiers of reliability that determine what kinds of fixes/upgrades you can do. At low levels (2-3 nines) you can run with one machine and fix it as you go. At 4-5 nines, you use redundant machines (and georedundancy), and having a stable machine image is important for hardware swaps. You never fix on the server unless the alternative is dropping calls, and the customer is on the phone *right now*. (That's the worst environment to figure out a fix, of course.) Above that (6 nines) is the realm of ATC and telephony, where you might not be able to afford to bring a system down at all. Erlang/OTP was designed for this space, so it includes hot-swappable components, though you test and verify them beforehand! Re consistency: I seem to recall Pascal Costanza working on activation of layers, so you can swap a whole set of stuff across your program. He spoke about it at ILC2009, but I'm not sure I've found the right paper. Common Lisp-specific, though. -R --~--~-~--~~~---~--~~ 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: Another Clojure Box - Version 1.4
Shantanu, The copy-to-REPL and execute-block-of-code works like this: 1- it copy the selected text in scite to a temp file inside \bin\scite \tools\SendCommand 2- call SendCommand.exe from the same folder 3- SendCommand will send the content of the temp file to the REPL, execute it and the delete temp file. Be sure that: - the REPL it's working fine (if it let you work normally then it's fine). - the folder \bin\scite\tools\SendCommand have write/read permissions. - BE SURE that ACB it's in the root of a unit (C: or D: or something like that). I have been reported that this version don't work fine inside folders (I'll be fixing that for the next version) Let me know if it's work!!! On Sep 4, 12:00 pm, Shantanu Kumar wrote: > Not sure if I am the only one - I was not able to make the copy-to- > REPL and execute-block-of-code work using the keyboard shortcuts > mentioned on the URL, nor using any other method. I am using Windows > XP 32-bit with JDK 1.6.0_16. > > I look forward to somebody correcting me what I am doing wrong. :-) > > Regards, > Shantanu > > On Sep 3, 8:37 pm, Darmac wrote: > > > > > Hi, > > I just release version 1.4 of ACB. > > > Changelog: > > ++ Customized version of SciTE 2.01. It's accept \n in tooltips and > > have a simple clojure lexer (don't use lisp lexer any more). > > ++ Better SciTE autocomplete (recognize ?,- and others keyword > > symbols) > > ++ Now you can resize file explorer in SciTE (bug fixed) > > > With the customized clojure SciTE lexer I have more freedom in order > > to make SciTE more confortable (better syntax, better folding, etc.) > > > Give it a try and tell me what you think!! > > >http://sites.google.com/site/dariomac/Home/projects/anotherclojurebox --~--~-~--~~~---~--~~ 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: from OO to Lisp style (a blog post)
Hi Ralph, First off, nice post! We need more of these types of tutorials on GUI in clojure, they're very useful. On make-login-widget you can probably do a doto when you do this part: > (.addWidget layout (WLabel. "Login:") 0 0 ) > (.addWidget layout login-field 0 1 ) > (.addWidget layout (WLabel. "Password:") 1 0 ) > (.addWidget layout password-field 1 1) > (.addWidget layout submit-button 2 0 1 2) Can be like (doto layout (add ) (add)) I don't have any experience using Jwt, but with regard to listeners and such, I've been using a 'continuation passing' style when writing little toy applications using swing. I guess the best way to explain it is that rather than using .trigger on the signal in the do-login function block, you would just apply a passed in (possibly anonymous) function. I can give an example: Think of this as pseudocode that may or may not run, as I only have Swing for ui on this computer. (defn make-login-form [logged-in-fn wrong-creds-fn] (let [layout (WGridLayout.) container (WContainerWidget.) password-field (doto (WLineEdit. container) (.setEchoMode WLineEdit$EchoMode/Password ) ) password #(.getText password-field) login-field (WLineEdit. container) login #(.getText login-field) do-login (fn [evt] (if (authenticate (login) (password)) (logged-in-fn) (wrong-creds-fn))) submit-button (WPushButton. "Login")] (-> submit-button .clicked (.addListener container ( create-listener [mouse-event] (do-login mouse-event (doto layout (.addWidget (WLabel. "Login:") 0 0 ) (.addWidget login-field 0 1 ) (.addWidget (WLabel. "Password:") 1 0 ) (.addWidget password-field 1 1) (.addWidget submit-button 2 0 1 2)) (.setLayout container layout) (.setFocus login-field) container)) (defn make-login-app ([env continuation] (let [wapp (new WApplication env) root (.getRoot wapp) result-text (WText. "") user nil dialog (WDialog. "test") dialog-container (.getContents dialog) app-screen (make-app-screen) form (make-login-form #(do (.remove dialog) (.setText (-> app-screen .getLayout (.getItemAt 0) .getWidget) "Logged in!") (continuation)) #(do (.setText (-> app-screen .getLayout (.getItemAt 0) .getWidget) "Wrong credentials!")))] (.setTitle wapp "Login Example") (doto dialog (.. getContents (addWidget form)) .show) (.addWidget root app-screen) wapp)) ([env] (make-login-app env identity))) And so then, to get a dialog that is like a sequence of panels, you can go through and do like: (make-login-app env make-next-widget) Anyway, is not particularly any better than using signal passing technique, but is another approach that you might consider in your application. On Sep 4, 11:01 am, rb wrote: > Hi, > > In using the Jwt library, for which I only found examples in object > oriented languages that structure the code in class definitions and do > heavy usage of instance variables, I was in a situation where I > wondered how I could best structure my code. > > With help on the IRC channel I got to a working solution which I > document in a blog post > athttp://www.nsa.be/index.php/eng/Blog/From-OO-to-Lisp-style-structurin... > > I'm interested in feedback and advices for improvements > > Thanks > > Raph --~--~-~--~~~---~--~~ 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: Fixing production systems on-the-fly
I just put together some example code to demonstrate "hot updates" with Clojure. http://paste.lisp.org/display/86576 It allows you to connect to a REPL via port 12345 and dynamically update things as necessary. To address the issue of updating multiple definitions at once, you'd do something like the following (after modifying main.clj): tra...@travis-desktop:~$ nc localhost 12345 clojure.core=> (require 'main :reload) Right now the main thread simply prints message in a loop, but I've tried changing main.clj to modify both the print-hello function and value of message, and it worked great. You can also connect to the repl and do something like the following, but it doesn't provide the same safety as the seemingly atomic require function does. clojure.core=> (ns main) nil main=> (def message "hola") #'main/message -Travis On Sep 4, 4:22 am, Krukow wrote: > I was thinking about the capability of changing production systems on > the fly. E.g. by having an accessible repl in a running production > system. > > If you have a bug in a function, you can fix it by re-def'ing it - > that is great. However, suppose you want to do a system upgrade where > you want to change several things. Now you could just re-def each var > one at a time, but this might produce an inconsistent program in the > interval where you have re-def'ed some but not all vars. > > This first thing you would want is sort-of a atomic update of all > vars, similarly to what is possible with refs. Is this possible > somehow? If not are there any techniques or best practices for these > "system upgrades"? > > /Karl --~--~-~--~~~---~--~~ 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: Another Clojure Box - Version 1.4
John, If you want to use this version of SciTE in linux I can send you the scite source and you will have to compile it. If you don't want to compile it I can send the properties files in order to use the lisp lexer with your standard scite version. Let me know what you want! On Sep 4, 12:06 pm, John Newman wrote: > I like Scite but I also use Linux. > > Any guidance on what steps I would need to take to port just the Scite part > of ACV to linux? What specific config files? > > Thanks, > > On Fri, Sep 4, 2009 at 7:30 PM, Shantanu Kumar > wrote: > > > > > > > > > Not sure if I am the only one - I was not able to make the copy-to- > > REPL and execute-block-of-code work using the keyboard shortcuts > > mentioned on the URL, nor using any other method. I am using Windows > > XP 32-bit with JDK 1.6.0_16. > > > I look forward to somebody correcting me what I am doing wrong. :-) > > > Regards, > > Shantanu > > > On Sep 3, 8:37 pm, Darmac wrote: > > > Hi, > > > I just release version 1.4 of ACB. > > > > Changelog: > > > ++ Customized version of SciTE 2.01. It's accept \n in tooltips and > > > have a simple clojure lexer (don't use lisp lexer any more). > > > ++ Better SciTE autocomplete (recognize ?,- and others keyword > > > symbols) > > > ++ Now you can resize file explorer in SciTE (bug fixed) > > > > With the customized clojure SciTE lexer I have more freedom in order > > > to make SciTE more confortable (better syntax, better folding, etc.) > > > > Give it a try and tell me what you think!! > > > >http://sites.google.com/site/dariomac/Home/projects/anotherclojurebox > > -- > John --~--~-~--~~~---~--~~ 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: Another Clojure Box - Version 1.4
Would I be able to achieve the auto-complete function with just a properties file, without having to recompile? On Fri, Sep 4, 2009 at 11:14 PM, Darmac wrote: > > John, > > If you want to use this version of SciTE in linux I can send you the > scite source and you will have to compile it. > If you don't want to compile it I can send the properties files in > order to use the lisp lexer with your standard scite version. > > > Let me know what you want! > > On Sep 4, 12:06 pm, John Newman wrote: > > I like Scite but I also use Linux. > > > > Any guidance on what steps I would need to take to port just the Scite > part > > of ACV to linux? What specific config files? > > > > Thanks, > > > > On Fri, Sep 4, 2009 at 7:30 PM, Shantanu Kumar >wrote: > > > > > > > > > > > > > > > > > Not sure if I am the only one - I was not able to make the copy-to- > > > REPL and execute-block-of-code work using the keyboard shortcuts > > > mentioned on the URL, nor using any other method. I am using Windows > > > XP 32-bit with JDK 1.6.0_16. > > > > > I look forward to somebody correcting me what I am doing wrong. :-) > > > > > Regards, > > > Shantanu > > > > > On Sep 3, 8:37 pm, Darmac wrote: > > > > Hi, > > > > I just release version 1.4 of ACB. > > > > > > Changelog: > > > > ++ Customized version of SciTE 2.01. It's accept \n in tooltips and > > > > have a simple clojure lexer (don't use lisp lexer any more). > > > > ++ Better SciTE autocomplete (recognize ?,- and others keyword > > > > symbols) > > > > ++ Now you can resize file explorer in SciTE (bug fixed) > > > > > > With the customized clojure SciTE lexer I have more freedom in order > > > > to make SciTE more confortable (better syntax, better folding, etc.) > > > > > > Give it a try and tell me what you think!! > > > > > >http://sites.google.com/site/dariomac/Home/projects/anotherclojurebox > > > > -- > > John > > > -- John --~--~-~--~~~---~--~~ 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: Another Clojure Box - Version 1.4
Yes, of course... You need clojure.properties and clojure-keywords.properties to make autocomplete work. But you need to change filter.clj=... for filter.lisp because the standard version of scite don't have a clojure lexer. You also need clojure.api (this is the key of autocomplete) If you can't make it works, let me know and I send you the files (without guarantee ;-) On Sep 4, 4:08 pm, John Newman wrote: > Would I be able to achieve the auto-complete function with just a properties > file, without having to recompile? > > > > > > On Fri, Sep 4, 2009 at 11:14 PM, Darmac wrote: > > > John, > > > If you want to use this version of SciTE in linux I can send you the > > scite source and you will have to compile it. > > If you don't want to compile it I can send the properties files in > > order to use the lisp lexer with your standard scite version. > > > Let me know what you want! > > > On Sep 4, 12:06 pm, John Newman wrote: > > > I like Scite but I also use Linux. > > > > Any guidance on what steps I would need to take to port just the Scite > > part > > > of ACV to linux? What specific config files? > > > > Thanks, > > > > On Fri, Sep 4, 2009 at 7:30 PM, Shantanu Kumar > >wrote: > > > > > Not sure if I am the only one - I was not able to make the copy-to- > > > > REPL and execute-block-of-code work using the keyboard shortcuts > > > > mentioned on the URL, nor using any other method. I am using Windows > > > > XP 32-bit with JDK 1.6.0_16. > > > > > I look forward to somebody correcting me what I am doing wrong. :-) > > > > > Regards, > > > > Shantanu > > > > > On Sep 3, 8:37 pm, Darmac wrote: > > > > > Hi, > > > > > I just release version 1.4 of ACB. > > > > > > Changelog: > > > > > ++ Customized version of SciTE 2.01. It's accept \n in tooltips and > > > > > have a simple clojure lexer (don't use lisp lexer any more). > > > > > ++ Better SciTE autocomplete (recognize ?,- and others keyword > > > > > symbols) > > > > > ++ Now you can resize file explorer in SciTE (bug fixed) > > > > > > With the customized clojure SciTE lexer I have more freedom in order > > > > > to make SciTE more confortable (better syntax, better folding, etc.) > > > > > > Give it a try and tell me what you think!! > > > > > >http://sites.google.com/site/dariomac/Home/projects/anotherclojurebox > > > > -- > > > John > > -- > John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
NPE calling clojure.lang.Compiler.load() from Java
This code snippet blows up with a NullPointerException
public class TestClj {
public static void main(String[] args) throws Exception {
System.out.println( clojure.lang.Compiler.load(new
java.io.StringReader("42")) );
}
}
Exception in thread "main" java.lang.ExceptionInInitializerError
at clojure.lang.Namespace.(Namespace.java:32)
at clojure.lang.Namespace.findOrCreate(Namespace.java:122)
at clojure.lang.Compiler.(Compiler.java:181)
at TestClj.main(TestClj.java:4)
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at clojure.lang.RT.(RT.java:295)
... 4 more
Caused by: java.lang.NullPointerException
at clojure.lang.RT.baseLoader(RT.java:1495)
at clojure.lang.RT.load(RT.java:377)
at clojure.lang.RT.load(RT.java:371)
at clojure.lang.RT.doInit(RT.java:406)
at clojure.lang.RT.(RT.java:292)
... 4 more
This is caused by the fact that the static initializer for
Compiler.LOADER is getting initialized _after_ a few other static Vars
that call Namespace.findOrCreate, which assumes that Compiler.LOADER
has already been initialized.
The fix I found to work is by simply moving the definition of LOADER
just before the definition of SOURCE.
Can someone please fix this in master? (I would have just fixed it
myself, but I didn't know about the whole contributor agreement
stuff...)
Thanks,
Jonathan
--~--~-~--~~~---~--~~
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: NPE calling clojure.lang.Compiler.load() from Java
On Sep 4, 4:09 pm, Jonathan Tran wrote:
> This code snippet blows up with a NullPointerException
>
> public class TestClj {
> public static void main(String[] args) throws Exception {
> System.out.println( clojure.lang.Compiler.load(new
> java.io.StringReader("42")) );
> }
>
> }
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at clojure.lang.Namespace.(Namespace.java:32)
> at clojure.lang.Namespace.findOrCreate(Namespace.java:122)
> at clojure.lang.Compiler.(Compiler.java:181)
> at TestClj.main(TestClj.java:4)
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at clojure.lang.RT.(RT.java:295)
> ... 4 more
> Caused by: java.lang.NullPointerException
> at clojure.lang.RT.baseLoader(RT.java:1495)
> at clojure.lang.RT.load(RT.java:377)
> at clojure.lang.RT.load(RT.java:371)
> at clojure.lang.RT.doInit(RT.java:406)
> at clojure.lang.RT.(RT.java:292)
> ... 4 more
>
> This is caused by the fact that the static initializer for
> Compiler.LOADER is getting initialized _after_ a few other static Vars
> that call Namespace.findOrCreate, which assumes that Compiler.LOADER
> has already been initialized.
>
> The fix I found to work is by simply moving the definition of LOADER
> just before the definition of SOURCE.
>
> Can someone please fix this in master? (I would have just fixed it
> myself, but I didn't know about the whole contributor agreement
> stuff...)
>
Fixed - thanks for the report.
Rich
--~--~-~--~~~---~--~~
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: Example of using ANTLR from Clojure?
I don't know anything about it, but counterclockwise uses antlr. http://groups.google.com/group/clojuredev-devel/browse_thread/thread/1428233ef12b6231 -Mike --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
