Re: Why we cannot do this now?
+1 On Wed, Jun 22, 2016 at 10:29 PM, Erik Assum wrote: > Using Cider and clj-refactor, you can do M-x cljr-add-project-dependency > to add (or update) a dependency. > > Erik. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why we cannot do this now?
Using Cider and clj-refactor, you can do M-x cljr-add-project-dependency to add (or update) a dependency. Erik. -- i farta > Den 22. jun. 2016 kl. 23.50 skrev Ritchie Cai : > > Just curious, how do you add new dependencies to a running REPL? Do you just > restart REPL? I used to able to add new dependencies using alembic, but it > seems it's not really compatible with clojure 1.8, not an option anymore. > > Thanks > Ritchie > >> On Monday, June 20, 2016 at 3:42:02 PM UTC-5, Sean Corfield wrote: >> On 6/19/16, 4:11 PM, "Sungjin Chun" > chu...@castlesoft.co.kr> wrote: >> > yes, I found that java -jar clojure.jar thing is very fast compared to >> > boot repl >> >> It’s probably worth pointing out here that most developers’ typical workflow >> involves starting up a REPL and then just leaving it running for a long time >> so they don’t have to deal with the startup time very often. See things like >> Component et al and various people talking about the “Clojure Reloaded >> Workflow” in blog posts and conference talks. >> >> I use Emacs + CIDER and probably only start up a REPL two or three times a >> week. The rest of the time, I’m just eval’ing into an existing REPL process. >> >> Sean Corfield -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> >> "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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why we cannot do this now?
On 6/22/16, 2:50 PM, "Ritchie Cai" wrote: > Just curious, how do you add new dependencies to a running REPL? Do you just > restart REPL? Our project is pretty stable so we don’t add new dependencies very often (nor change existing ones), so yes, we just restart the REPL in the project context. We also run a REPL server inside several of our long-running processes so we can actually update running server processes on the fly if we need to (it’s certainly very handy for analyzing and debugging any problems we run into in production!). Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why we cannot do this now?
Just curious, how do you add new dependencies to a running REPL? Do you just restart REPL? I used to able to add new dependencies using alembic, but it seems it's not really compatible with clojure 1.8, not an option anymore. Thanks Ritchie On Monday, June 20, 2016 at 3:42:02 PM UTC-5, Sean Corfield wrote: > > On 6/19/16, 4:11 PM, "Sungjin Chun" > on behalf of chu...@castlesoft.co.kr > wrote: > > yes, I found that java -jar clojure.jar thing is very fast compared to > boot repl > > It’s probably worth pointing out here that most developers’ typical > workflow involves starting up a REPL and then just leaving it running for a > long time so they don’t have to deal with the startup time very often. See > things like Component et al and various people talking about the “Clojure > Reloaded Workflow” in blog posts and conference talks. > > I use Emacs + CIDER and probably only start up a REPL two or three times a > week. The rest of the time, I’m just eval’ing into an existing REPL > process. > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why we cannot do this now?
I just wanted to raise my hand as a developer who rarely uses a long-lived REPL and is glad that startup time is a priority. (I've been doing Lisp for decades and have done lots of the long-lived REPL style of development, so I know the tradeoffs involved.) John On Mon, Jun 20, 2016 at 1:51 PM, Gregg Reynolds wrote: > +1 > On Jun 20, 2016 3:41 PM, "Sean Corfield" wrote: > >> On 6/19/16, 4:11 PM, "Sungjin Chun" > of chu...@castlesoft.co.kr> wrote: >> > yes, I found that java -jar clojure.jar thing is very fast compared to >> boot repl >> >> It’s probably worth pointing out here that most developers’ typical >> workflow involves starting up a REPL and then just leaving it running for a >> long time so they don’t have to deal with the startup time very often. See >> things like Component et al and various people talking about the “Clojure >> Reloaded Workflow” in blog posts and conference talks. >> >> I use Emacs + CIDER and probably only start up a REPL two or three times >> a week. The rest of the time, I’m just eval’ing into an existing REPL >> process. >> >> Sean Corfield -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> >> "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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why we cannot do this now?
+1 On Jun 20, 2016 3:41 PM, "Sean Corfield" wrote: > On 6/19/16, 4:11 PM, "Sungjin Chun" of chu...@castlesoft.co.kr> wrote: > > yes, I found that java -jar clojure.jar thing is very fast compared to > boot repl > > It’s probably worth pointing out here that most developers’ typical > workflow involves starting up a REPL and then just leaving it running for a > long time so they don’t have to deal with the startup time very often. See > things like Component et al and various people talking about the “Clojure > Reloaded Workflow” in blog posts and conference talks. > > I use Emacs + CIDER and probably only start up a REPL two or three times a > week. The rest of the time, I’m just eval’ing into an existing REPL process. > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why we cannot do this now?
On 6/19/16, 4:11 PM, "Sungjin Chun" wrote: > yes, I found that java -jar clojure.jar thing is very fast compared to boot > repl It’s probably worth pointing out here that most developers’ typical workflow involves starting up a REPL and then just leaving it running for a long time so they don’t have to deal with the startup time very often. See things like Component et al and various people talking about the “Clojure Reloaded Workflow” in blog posts and conference talks. I use Emacs + CIDER and probably only start up a REPL two or three times a week. The rest of the time, I’m just eval’ing into an existing REPL process. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why we cannot do this now?
Thank you for your detailed explanation; I've tested on Raspberry Pi(slooow) though it's not that fast, yes, I found that java -jar clojure.jar thing is very fast compared to boot repl. Now I understand why it takes so long. On Mon, Jun 20, 2016 at 12:43 AM Alex Miller wrote: > This is a nice trick and its one I have done myself on Clojure CLIs > (particularly with "help" options) to defer loading and give a faster feel > to startup. It is great to have a repl that starts super fast for people > learning Clojure to get started, or to spin one up to try something. > > However, the time to start up a base Clojure repl (with no deps or app > code) is already subsecond - so you're saving no more than a second with > this approach. The problem is that (approximately) no one actually starts a > REPL this way. [You can find my ongoing notes on this subject at > http://dev.clojure.org/display/design/Improving+Clojure+Start+Time by the > way.] > > Most people start a REPL via Leiningen (or Boot), and the demo'ed > technique changes nothing about that experience. Leiningen still needs to > start the Clojure runtime, compile and load nrepl and all the tooling, > launch an nrepl server in a new JVM, connect to it, load all the middleware > code, and commonly even a vast amount of application code (based on common > patterns of project setup). If you look at the Luminus guestbook > application for example (not picking on this one, just one I happened to > look at), at dev time it loads env/dev/clj/user.clj prior to repl startup > which loads a vast number of dependency namespaces and application code, > which takes 10s of seconds, which dwarfs Clojure core load time. > > Because this a Clojure repl hack, it also does nothing to affect actually > running a Clojure application, which again must load the Clojure runtime > and your application code (which often involves compiling and loading a lot > of code) before it starts doing anything. > > So while this is a nice demo, I don't see that it actually changes > anything for the vast majority of actual "Clojure start time issues" people > experience on a daily basis. That said, this is an acknowledged pain point > that we still care about very much! I'm sure there will be more work on > this to come. > > On Saturday, June 18, 2016 at 9:25:37 PM UTC-5, Sungjin Chun wrote: >> >> Yes, I want this kind of instant speed (I hope this kind of speed is >> possible in >> emacs + side). >> >> https://www.youtube.com/watch?v=D3gpQth8uTI&feature=youtu.be >> >> Have you seen this? Why we simply cannot do this? >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/ejxIxPPYd84/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why we cannot do this now?
This is a nice trick and its one I have done myself on Clojure CLIs (particularly with "help" options) to defer loading and give a faster feel to startup. It is great to have a repl that starts super fast for people learning Clojure to get started, or to spin one up to try something. However, the time to start up a base Clojure repl (with no deps or app code) is already subsecond - so you're saving no more than a second with this approach. The problem is that (approximately) no one actually starts a REPL this way. [You can find my ongoing notes on this subject at http://dev.clojure.org/display/design/Improving+Clojure+Start+Time by the way.] Most people start a REPL via Leiningen (or Boot), and the demo'ed technique changes nothing about that experience. Leiningen still needs to start the Clojure runtime, compile and load nrepl and all the tooling, launch an nrepl server in a new JVM, connect to it, load all the middleware code, and commonly even a vast amount of application code (based on common patterns of project setup). If you look at the Luminus guestbook application for example (not picking on this one, just one I happened to look at), at dev time it loads env/dev/clj/user.clj prior to repl startup which loads a vast number of dependency namespaces and application code, which takes 10s of seconds, which dwarfs Clojure core load time. Because this a Clojure repl hack, it also does nothing to affect actually running a Clojure application, which again must load the Clojure runtime and your application code (which often involves compiling and loading a lot of code) before it starts doing anything. So while this is a nice demo, I don't see that it actually changes anything for the vast majority of actual "Clojure start time issues" people experience on a daily basis. That said, this is an acknowledged pain point that we still care about very much! I'm sure there will be more work on this to come. On Saturday, June 18, 2016 at 9:25:37 PM UTC-5, Sungjin Chun wrote: > > Yes, I want this kind of instant speed (I hope this kind of speed is > possible in > emacs + side). > > https://www.youtube.com/watch?v=D3gpQth8uTI&feature=youtu.be > > Have you seen this? Why we simply cannot do this? > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Why we cannot do this now?
Yes, I want this kind of instant speed (I hope this kind of speed is possible in emacs + side). https://www.youtube.com/watch?v=D3gpQth8uTI&feature=youtu.be Have you seen this? Why we simply cannot do this? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
