This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (34)
- # boot (14)
- # cider (2)
- # cljs-dev (21)
- # cljsrn (1)
- # clojure (31)
- # clojure-android (10)
- # clojure-spec (12)
- # clojure-uk (3)
- # clojurescript (64)
- # cursive (31)
- # data-science (9)
- # datomic (27)
- # fulcro (11)
- # graphql (14)
- # jobs (1)
- # leiningen (1)
- # lumo (27)
- # off-topic (65)
- # om (2)
- # onyx (77)
- # pedestal (1)
- # re-frame (4)
- # shadow-cljs (6)
- # vim (1)
- # yada (3)
Real off: Julia language has some pretty cool introspects. With a simple macro, it returns you the "type coode", llvm code or native code that you run if you evaluate a block. http://blog.leahhanson.us/post/julia/julia-introspects.html
The Five Stages of Clojure: 1. I'm going to be so much more productive in Clojure! 2. It's so much fun learning Clojure! 3. It took me two weeks to set up my Clojure IDE.... 4. How the heck do I do XYZ in Clojure?? 5. I suck at Clojure.
Having set up and torn down three completely different Emacs configurations and then switching to Atom/ProtoREPL, I totally agree with 3!
been following your work since the day of CFML, to CF components, until I switched to Spring/Java. Got interest into clojure a couple of years ago, talks of RH, and the interest got stronger ever since. A few months back, out of curiosity to check on An Architect's View, found that our mentor already contributing to clojure community for more than a few years! Now, it's more than comforting to hear comments like these again from you, thank you @seancorfield
I'll never escape my past, it seems! 😆 Good to hear another former CFer finding their way to Clojure!
I definitely have moments of 5 but now that I've been doing Clojure in production for 6+ years, I'm back to 1 & 2 all the time now!
"3" in my case meant: * switching from vim to emacs * buying https://www.kinesis-ergo.com/ this took slightly more than two weeks
I'm still hoping someone will rewrite emacs in clojure, so I can do scripting in clojure instead of elisp
extending Atom in clojurescript would have lots of potential. someone has to do the hard work though... and keep up with a fast-moving target as Atom is
nice one, I like how simple the development process is (as per readme) but seems quite evident that Atom is not ready for primetime for serious Clojure work (if you know emacs already) when Atom is a more viable approach it'll have https://github.com/clojure-emacs/refactor-nrepl integration and such?
@vemv ProtoREPL provides a pretty solid base. I used Emacs/CIDER prior to switching to Atom/ProtoREPL and have zero regrets. I don't miss Emacs at all 🙂
I used Emacs back in the version 17, 18 days, switched to other editors just after 19 came out, as I recall. Went back to it just as 24 was in prerelease because I was using Clojure. Went through three complete rebuilds of my Emacs setup. Switched to ProtoREPL after seeing Jason's talk at Conj 2016. Never been happier!
@seancorfield: that is a strong recommendation; do you have a screencast of yourself workingin atom/proto-repl ?
I do not. Mostly because I spend so much of my time working on a proprietary code base.
Looking at Emacs release dates, that represents about a decade of usage '85-'95, and then about four years '12-'16. I tried a bunch of other Clojure solutions too during that time (even TextMate with a plugin!). I liked LightTable when it came out, but incompatibilities with OS X releases drove me away. I tried Sublime Text as well, but for various reasons it just annoyed me when working cross-platform.
@qqq What I can tell you about my workflow is that I generally have a REPL running, minimized to about three lines at the bottom of the screen and I almost never type into it. I write code in a source/test file, evaluate it with a hot key, look at the inline results (one of the things I loved about LightTable and also love about ProtoREPL with Ink), rinse and repeat. If I want to try "REPL stuff", I add a
(comment ...) to my source file and write my experiments inline in that, eval'ing into the REPL as I go.
For files with
-main functions, I generally have a
(comment ...) below the
-main function that has the steps needed to build my system
stop it, along with any convenient expressions for modifying logging levels etc (we use
Personally I use Atom a lot but not for Clojure at the moment. The day I can easily compose my own commands, modify just about anything at runtime, and be backed by an active community I'll be there for sure. It's unfortunate that protorepl stalled last June - let's hope activity recovers
Aye, I talked to Jason about that. He hopes to get back on it, but I think he would also welcome contributors.
To be honest, I have almost never used Emacs before and use Atom for most of my day-to-day development, so it was natural for me to try protorepl when getting started with Clojure. I nonetheless gave CIDER a try, and I find it miles and miles ahead in terms of UX compared to protorepl.
@hmaurer that’s exactly what happened to me 🙂 Started with Atom (since it was my standard tool) and switched to Emacs with CIDER. I regret not switching before.
Guys, is anybody familiar with any resource regarding “incremental I/O”? I don’t know the exact term for this, but the idea is that I don’t have access to the whole
InputStream, but rather parts of it. Specifically, I am trying to build a non-blocking chat server using Java NIO. I want to get more insight about how to accumulate client’s message parts and eventually combine parts into full messages
@lvbarbosaI am not quite sure wha tyou mean; you could just buffer incoming message chunks until you get a full one?
You guys motivated me to take a look at ProtoREPL and it indeed seems interesting! I'm finding it to be very easy to use. OTOH, I'm used to Cursive, which I find to be excellent to my needs - the fact it indexes the source without an active REPL makes things much quicker to me.
As for my CIDER experiences, I got frustrated over how easy it was to break my setup. Gave up after a week or so, with a few attempts to try it again which ended the same way.
@hmaurer Yes, that’s the thing I have in my mind. However, I am particularly having some troubles with how to decide whether a bunch of
ByteBuffers contains full messages or not. I tried parsing them to
Strings, but this breaks the system when the last byte read was just a piece of a unicode code point. My language (portuguese) has a lot of those (é ç ã etc)
e.g. each message would have this format: “[ID : SHORT] [LENGTH : SHORT] [CONTENT : BYTES]”
I can recall that .NET had a memory mapped stream. Maybe there is something similar in Java?
@hmaurer Hmm.. That’s clever. I was using a very simple “line-break oriented” approach
@lvbarbosa I don't know if this helps, but EDN, transit and fressian have an API for reading the next input from an input stream
I mean, that’s if you are using a binary protocol. I am sure you could get away with a text-based protocol or something
But basically, it could work like this: receive some bytes and add them to buffer. Do you have enough bytes in buffer to read a message header? ok, read it. Do you have enough bytes to read the message content? Yes? Read it. No? Wait for more bytes
@val_waeselynck that’s cheating! 😄 I want to write the whole solution to gain more experience
@hmaurer that’s ok, I now have some keywords to help me on the research 🙂 Thanks a lot!
Just a last thought: is it normal to feel bad when using Java objects in Clojure? 😄 I look at my code and it looks awful when doing interop. Let me try to find an example that I pasted in the #beginners channel asking for help