Fork me on GitHub

if I do (js/alert "hello") I get a popup in the electron window so it sounds to me like I'm in a cljs repl


I'm having trouble connecting to my postgresql database (getting a PSQLException: The ResultSet is closed.) and am at a loss for how to debug it.


I've had this issue before years ago when I tried to use my own JDBC wrapper. The likely problem is that the update is happening but its trying to return the rows in a lazy sequence. Whatever is trying to use that lazy sequence may be doing so after the connection has already closed. You could try using doall to ensure that it reads the data immediately rather than lazily.


Using and am not sure how to tell if a connection to the DB is failing or if I have some sort of mal-formed query


@mitchell_clojure Feel free to share your code, either here or in #sql if you want a smaller audience focused on SQL stuff.


I suspect you're doing something lazily and the connection is closing before you realize the result set sequence, based on that message.


Hey thanks for reaching out Sean. I think I coincidentally JUST figured out the issue as you wrote


the postgre driver was migrated from postgresql -> org.postgresql group ID


and so I was using a much older dependency version


Oh, yeah, they had a massive version jump... up to 42.x.y.z I think ?


lol yeah, good memory


Trust me, the quirkiness of several JDBC drivers is indelibly stamped on my poor ol' memory 😞


It's much appreciated!


I was trying out and wondered why the templates generate projects named first.second. I mean, I understand namespacing things inside the project, but why would the project itself default to that style instead of just first?


Maybe it's just a small detail I shouldn't think too much about, but if it is a good practice I would like to know.


Just to be clear my question is about the command clj -A:new figwheel-main hello-world.core generating a directory called hello-world.core instead of a project called hello-world with a src, hello-world and core.clj or whatever.


Single segment namespaces are a bad idea. They map to segment Java packages (which I believe are going to be outlawed?).


clj-new requires qualified project names like my-test/project or multi-segment projects like project.main.


The top-level folder name isn't important -- you can easily rename that if you want. But the structure inside the project is important.


Leiningen tried to "avoid" this problem by slapping .core on the end of every project name that was a single segment...


Oh, perfect. I understand the importance inside the project, but was confused about the top-level directory naming.


...but that left us with hundreds of projects that had a core.clj file 😞


Feel free to open an issue on clj-new's GitHub repo. I've been annoyed by it too sometimes πŸ™‚


Haha ok πŸ™‚ Thank you!


If you use a qualified name, you get the project name you "expect"

seanc@DESKTOP-QU2UJ1N:~/clojure$ clj -A:new app something/project
Generating a project called project based on the 'app' template.
seanc@DESKTOP-QU2UJ1N:~/clojure$ tree project
β”œβ”€β”€ LICENSE
β”œβ”€β”€ deps.edn
β”œβ”€β”€ doc
β”‚   └──
β”œβ”€β”€ resources
β”œβ”€β”€ src
β”‚   └── something
β”‚       └── project.clj
└── test
    └── something
        └── project_test.clj

6 directories, 7 files


In that case, shouldn't the top-level directory be something?


No, because the assumption is you'd use fbarros/project-a and fbarros/project-b etc


I can certainly improve the clj-new documentation...


Hmm, that is still a bit confusing to me. Do you have a reading recommendation?


On proper namespacing I mean.


Wait, so you mean that the name of a projects main file shouldn't be main.clj or core.clj, but instead the name of the project itself?


I thought namespacing was just about src/something/core.clj instead of src/core.clj.


Having your default project entry point ending in core is an anti-pattern caused by Leiningen.


There are two things at play here: the group/artifact ID used for deployment (to Clojars) and the namespace tree. If you're producing a library that other people use, you want your project's namespaces to not clash with anyone else's.


You also want the group/artifact to not clash.


So <my-unique-id>/<my-project-name> is really what you want every time.


Yours would be fbarros/project, mine would be seancorfield/project. For example.


Now we both have a project.clj file but the namespaces are different and could be used in the same project.


Does that help?


It does! It will take me a bit longer to wrap my head around it (coming from front-end development with index.html, index.js, etc) but it makes sense. I just had this misunderstanding because I thought namespacing problems were caused by having src/core.clj instead of src/project/core.clj. I thought the second version was fine. But now I see that you may have many things called project, so the spot for project there is more important and should be my name as a solo developer or the name of the company I'm working for maybe.


Have I understood correctly?


The namespace can be a.b.c. The main things are to a) avoid single-segment names and b) to create a name that likely won't conflict with other people's projects.


Perfect. I get it now. Thank you again! πŸ˜„


So you generally want something globally unique (so your projects won't clash with other people's) followed by something locally unique (so that project won't conflict with your other projects).


Makes perfect sense.


I dedicate an unhealthy amount of cognitive time to naming stuff so this will surely help me.


Naming is hard.


Some projects take liberties -- but unless you're pretty sure you're going to have something globally unique, you shouldn't.


For example, expectations. It's a single segment namespace ("bad") with the same group/artifact ID (also a bit "bad").


date-clj ("bad"). (that's it's group/artifact name, which is doubly-bad for including clojure in it) and it's namespace is just java-time which is terrible.


I just released seancorfield/next.jdbc which has a namespace structure next.jdbc.* which also breaks the rules (the group/artifact ID is good, but the namespace is less good). But it's a follow-on from org.clojure/java.jdbc and* so I feel I can get away with it a bit πŸ™‚


I have no knowledge of Java but I can see how distinguishing things named like that could be difficult.


Java's heritage is why we get things like com.stuartsierra.component πŸ™‚


What would be the ideal name if it wasn't a follow-on?


Hard to say really. Only Clojure itself and Contrib projects should really have clojure in their namespace. But* would probably have been a bit "safer"... but also a bit redundant so it's a trade off.


I just hated the idea of using as the namespace structure. πŸ™‚ I just don't want my name all over other people's code like that.


Your name is in our hearts and minds already haha but yeah, I get it. What about that com. or org.? I see that a lot.


That always seems a bit pointless to me. In reality there are very few conflicts where the domain is the same but the TLD is different.


Although is a firm of Australian lawyers, last I looked (I'm ).


If you're an organization that has both .org and .com domains for open source and commercial stuff then, yeah, I can understand putting the TLD in as well... but even so... REBL has a namespace of cognitect.rebl.* so... πŸ™‚

πŸ˜… 4

The official documentation on Namespaces is very terse.


Which "official documentation"?


Yeah, that first paragraph is... accurate but dense and not entirely helpful for beginners πŸ™‚


hi ppl, I have one function in my application that uses (all-ns) but I noticed that when I start the application, clojure does not load all namespaces by default (is that true?), because the (count (all-ns)) returns 379 and them when I use cider-load-all-project-ns the count does up to 439.


is that something that I'm missing on πŸ˜•


just found this library and it worked great πŸ˜ƒ


Hi. I have a general question about idiomatic Clojure. I read somewhere (can't remember where) that having your whole application state to hold in one atom, and have all the functions to operate on that atom, is bad practice. But how then else you can operate... many atoms?


where did you see that @olekss.janis? in clojure, you’d most likely keep your application state in a database. when running clojurescript in the browser, i think it’s fine to have your state in an atom. that’s what re-frame does.

Roger Amorin Vieira20:05:51

Hi, my name is Roger, I'm new here and in clojure. I'm having troubles with a simple thing can someone help me? I have 2 maps element - {:id 1 :info "information"} key - {:key_name "id"} And i'm trying to get the id using the key name like that: (get element (get key :key_name)) And i'm get nil

Roger Amorin Vieira20:05:00

I'm also try in repl get with string like: (get element "id") but isnt work, I know the correct is with ':' but I cannot use it how can i fix this?

Roger Amorin Vieira20:05:11

I figure out, using function keyword


That’s the one. πŸ‘ You might want to consider getting the data in the key map to be already a keyword.

πŸ‘ 4
Eric Ervin20:05:46

@olekss.janis It'll depend on the kind of application. I feel like I learned the idiom of putting the universe in a map in an atom from the Clojure community.


yeah, the problem with namespaces continues. The function all-ns only returns previouesly loaded namespaces. In my application I want to dynamically search for a specific metadata on functions definitions, but for that I would need to get access to all namespaces in the project. One option is to use the library and perform a require on each symbol returned by (b/namespaces-on-classpath).. but I find this slow... looks like a hack, is it?


@iagwanderson If you want to access metadata on symbols that have not yet been loaded by your application, your only real choice is to issue a require for any corresponding namespaces that have not yet been loaded.


Is the metadata you want specific to your application or could you find it on any function in any library that your app might reference?


@seancorfield yes, the metadata is specific to my application.


@iagwanderson So you'd only need to require those namespaces that are "inside" your application and that have not already been loaded -- that's a much smaller set of files, I suspect, and shouldn't take long to do -- since "most" namespaces would already be loaded. You could probably use to get that list fairly easily... I'm trying to remember what we did for source-based analysis...


I endup using the library bultitude cited above, and used a simple (map require my-namespaces)


and it worked, but I was thinking if there aren't a better way to do so


Given that you want require for side-effects only, you want run! not map -- and as long as my-namespaces is just that small set of namespaces you haven't already loaded, that's probably fine.


I changed my (doall (map ..)) to use run! thanks