Fork me on GitHub

Given a seq that contains vectors and strings, arranged as 0-2 vectors, 1+ strings, 0-1 vectors: how do you most efficiently consolidate the strings in the middle?


Two examples: [[:foo] [:bar] "T" "h" "i" "s" " " "S" "e" "c" "t" "i" "o" "n" [:tags]] ➡️ [[:foo] [:bar] "This Section" [:tags]] ["This Section"] ➡️ ["This Section"]


(->> thing (drop-while (complement string?)) (take-while string?))


@gfredericks: That looks like an excellent way to get just the strings. Apply str to that and I'm golden.


Okay, got another one. Given a nested tree of seqs, where some seqs start with a keyword and others with a string: how does one pop open any seqs that start with a string?



([:title "Sample Org File"] [:author "Seylerius"] ("This is an attempt to test Org-Mode processing." [:section [:h [:stars "*"] [:keyword "TODO"] [:priority "A"] "T" "h" "e" " " "*" "F" "i" "r" "s" "t" "*" " " ":" " " "S" "e" "c" "t" "i" "o" "n" [:tags "foo" "bar"]] "This *is* /the/ _content_ +oof+ of the first section. There's also a list. " "+ First UL" "+ Second UL" "+ Third UL" ""] [:section [:h [:stars "**"] "The First SubSection"] "This subsection contains a nested list." "1. The first OL" "+ UL 1.1" "+ UL 1.2" "2. The second OL" "+ UL 2.1" "+ UL 2.2" "3. The third OL" "+ UL 3.1" "+ UL 3.2"] [:section [:h [:stars "**"] "The Second SubSection"] "1. OL 1 of List 1" "2. OL 2 of List 1" "There are two lists in this subsection" "1. OL 1 of List 2" "2. OL 2 of List 2" ""] [:section [:h [:stars "**"] "The Third SubSection"] "This subsection has a table." "| Name | Value |" "|------+-------|" "| One  | Foo   |" "| Two  | Bar   |"] [:section [:h [:stars "**"] "The Fourth SubSection"] "This subsection has a definition list." "+ Foo :: Foo" "+ Bar :: Bar" ""] [:section [:h [:stars "*"] "The Final Section"] "Thus ends the sample." ""]))
([:title "Sample Org File"] [:author "Seylerius"] "This is an attempt to test Org-Mode processing." [:section [:h [:stars "*"] [:keyword "TODO"] [:priority "A"] "T" "h" "e" " " "*" "F" "i" "r" "s" "t" "*" " " ":" " " "S" "e" "c" "t" "i" "o" "n" [:tags "foo" "bar"]] "This *is* /the/ _content_ +oof+ of the first section. There's also a list. " "+ First UL" "+ Second UL" "+ Third UL" ""] [:section [:h [:stars "**"] "The First SubSection"] "This subsection contains a nested list." "1. The first OL" "+ UL 1.1" "+ UL 1.2" "2. The second OL" "+ UL 2.1" "+ UL 2.2" "3. The third OL" "+ UL 3.1" "+ UL 3.2"] [:section [:h [:stars "**"] "The Second SubSection"] "1. OL 1 of List 1" "2. OL 2 of List 1" "There are two lists in this subsection" "1. OL 1 of List 2" "2. OL 2 of List 2" ""] [:section [:h [:stars "**"] "The Third SubSection"] "This subsection has a table." "| Name | Value |" "|------+-------|" "| One  | Foo   |" "| Two  | Bar   |"] [:section [:h [:stars "**"] "The Fourth SubSection"] "This subsection has a definition list." "+ Foo :: Foo" "+ Bar :: Bar" ""] [:section [:h [:stars "*"] "The Final Section"] "Thus ends the sample." ""])


Maybe something with walk, but I'm not sure how to break the seq apart after I've identified one.


to break apart a string just (map str (seq s))


@dpsutton: Not quite what I'm aiming at. I need to break apart seqs that start with strings into their individual items as part of the parent seq.


[[:foo "a"] [:bar] ("baz" "bar" [:foo "b"])] ➡️ [[:foo "a"] [:bar] "baz" "bar" [:foo "b"]]


As far down as necessary to return the tree to be hiccup compliant.


i don't think hiccup cares about the sequences actually


have you rendered them?


Inataparse flails and says it's not compliant if I try to use insta/transform without popping the non-compliant seq.


Basically, given a seq, how do you return its contents unwrapped?


this doesn't recurse on the lists though, so not sure if you'll have lists inside of lists, etc


@dpsutton: Actually, this gives me an idea. Thanks, this is very nearly what I need.


@seylerius that should recurse on each list


and assumes vectors are not to be modified at all


Trouble is vectors might contain lists sometimes.


Going to hit it with a pass off fixing the tree after each thing that might add a new list. Think I've got it...


just reduce each vector


a vector can contain that stuff because that case is identical to the one we started with


ie, recurse


@lmergen I'm trying to build a model of music theory for music generation and analysis. I thought it would be helpful to have a circular list to define the concept of pitch classes. Something like (def pitch-classes (cycle [:c :db :d :e :eb :f :f# :g :ab :a :b])) although I suppose cycle is only infinite in one direction and I'll need to go both ways but you get the idea. I figure it will be useful to say (take n pitch-classes) then filter/map over them to generate chord progressions. I know I can come up with other ways to do this but half of this project is about learning clojure with the goal of representing musical contexts as directly as possible. I could just be more careful but it sucks worrying that you'll crash the REPL especially if I plan to use this for live performance down the road.


Damnit, the list in this isn't passing list?.


what do you mean


If I filter with list?, I get an empty seq.


did you try my snippet above on it?


what are you filtering?


The sample data I listed.


ah. yeah. don't think filter can get rid of lists


What's annoying is that this function is failing. It seems to be because the list in the middle of the list is not passing the list? test.

(defn tree-reducer
  [tree item]
  (if (list? item)
    (concat tree item)
    (conj tree item)))


Yours didn't pop the list either.


Gah. I'll just search on collections that aren't vectors.


i thought mine does "pop" the list


in your example, we can't just concat the item, we need to check for nested sublists


so we concat and then reduce inside of the list, each element of it, looking for vectors, other lists, strings, etc


There we go. I modified yours to check for (and (coll? e) (not (vector? e)), and that fixed it.


The list didn't accept its list-ness.


which collection was messing it up? a sequence?


Yeah. Must've been a generic seq.


oh well. you're set then?


Yep. I'll put this in as my tree fixer, and run that between parsers.


Thanks, dude.


awesome. best of luck


I have a faint recollection that I read discussions about the new version of in this channel. Is anyone here involved in the refactoring effort?


Is there any way to call the java bit shifting operators? I'm not too familiar with java and was hoping that the operators << etc had functions behind them that I could call


and in case its an x,y problem, I'm trying to get the most significant bits from an integer


(defn mask-partition-from-tempid [tempid]
  (bit-or tempid 0x7FFFFFFF00000000))


I built up a lazy list of bit-masks of 1's from the least significant bit, and then shift right and and it with the correct bit mask. Trouble is sometimes my integers get promoted to longs, so i was wondering if there was a way to reach out and do it in java so i knew there would be no type promotion


Hi, using luminus / compojure, how do I redirect and update the session?


ok, its (assoc (redirect "/") :session :session)


how to achieve the following: {:a [1 2]} [3 4] -> {:a [1 2 3 4]}. That is i have a map with a key that holds a list and and more of the list that I want to conj onto it.


(update-in m [:a] conj [3 4])


concat instead of conj i think


(update-in {:a [1 2]} [:a] (comp vec concat) [3 4])


to watch the vector return type


i always forget the seq return


no problem fenton. happy coding


actually, into is enough

(update-in m [:a] into [3 4])


thnk god its clojure! 🙂


ah very nice


(update {:a [1 2]} :a into [3 4])


Note that update is new in 1.8, so you can’t use it in older versions.


k...clojure code almost makes me cry for a wasted 15 years of my life!


fenton, it's okay to like vb5


is there a more elegant way to achieve: (def mm {:long-keyword 1 :b 2}) -> [:long-keyword (:long-keyword mm)]-> [:long-keyword 1]


((juxt identity mm) :long-keyword)


@radon will go read about that now! never used juxt before.


Also great for getting the minimum and maximum of a collection at the same time:

(apply (juxt min max) [7 4 3 0 19]) => [0 19]


@radon that is really neat...


@fenton: select-keys might also help you with similar problems.

(select-keys {:a 1 :b 2} [:a])
=> {:a 1}
(first (select-keys {:a 1 :b 2} [:a]))
=> [:a 1]


noob question: is there such thing as an "opaque" type in clojure? by that i mean an record/object/hash whose values can't be read/fetched by anyone other than the namespace that created / knows how to manage that object?


kinda like encapsulation/private fields in OOP


or is everything just a hash/map/set/vector that everyone can operate on?


Yes, mostly. This is usually less of a concern because the data is immutable. So even though everyone can operate on it, they can’t change it.


But I’m not sure what your specific use case is, and maybe someone else will have a better answer.


i still mostly work out of a ruby codebase and find that a lot of the design decisions i make are to effectively hide/privatize as much of the data accessors as possible so that future developers are steered in the right direction


i bet someone would read what i just wrote and wonder if there isn't some accidental complecting happening since we're using OOP, but...


do clojure developers run into situations where since the data is lying out in the open (no private fields, encapsulation) that the next developer adding a feature to a large project starts digging into the internals of some data structure rather than adhering to a design meticulously laid out by a previous developer?


i hope i'm making sense...


Hmm, that is a broad question. In my experience most CLJ devs prefer things to be open so they can be built upon rather than wrestled with.


As in: having a few well thought out abstractions and generic data types that anyone can operate on with existing functions.


Most data is a map, than can be managed as the user not the implementor sees fit.




someday i'll get my hands dirty w clojure


again I’m just one dude


others might really disagree or do it differently


@machty A lot of that kind of data hiding happens in function closures.


Data structures don’t often need state; it’s functions that need state when they operate on data structures.


I believe - from what I've seen of Hickey's philosophy and how it's extended into Clojure - the data is central; the model is exposed so that other functions can act on it clearly. It also fits in with the feedback loops and rapid incremental development cycles of a REPL, as well as the benefits of referential transparency. All the needs for privatization of data tend to disappear when you're not worrying about shared or global state.


I think that was the theme of one of his keystone talks, I'd have to dig it up again though...


I think it was either 'Are We There Yet?' or 'The Value of Values', both of which can be found from


You tend to spend more time coming up with the right state and data representation in Clojure than you do coming up with the right interface.


i don't think all the needs for privatization disappear. i understand how they do when mutability is out of the question, but still whether you're using OOP or a functional style, you are building dependencies in your code; if you have any sort of top level state, or any kind of object composed of other objects that gets passed around, then anyone can dig in and read any values from that object and make decisions based on their understand of the present-day shape of that object


Function-level scoping. 😉


You don't blindly leave global values lying around, for sure.


In Clojure, dependencies are often simply what's passed into a function.


i guess specifically if you have some deeply nested map that uses :mykey and then it's changed to :newkey, then anyone who might have been digging into that structure from another side of the program will have to be updated or be broken


Yep. Hence the time spent making sure that state is well-selected.


hence my question about opaque types: it seems like it'd be nice to still have a single namespace that knows how to operate on a proprietary data structure, but to everyone else the data is opaque and you're forced to use the functions exposed by that namespace


The same would happen if you changed a method signature in OOP; just takes some getting used to those breaking changes occurring along a different medium.


methods are less brittle than internal state; that's kind of the point of them


(also to control/limit where mutation happens, but even with out that concern there are design/dependency considerations)


There is no mutation in Clojure unless explicitly stated. 🙂


yes i am quite aware 🙂


there's still the issue of limiting dependencies between code


I think it's more in line with OOP than you may think. Think of it from a module integration perspective.


In general, while it may be function endpoints that bind two modules together, they generally negotiate that exchange through a common medium of data.


They share some model that defines the shape of how both modules can see their slice of the world in common.


You can encapsulate that, yes, but if the model changes both sides change with it.


The same problem exists, it's just along a differently shaped seam.


i've been using data as a boundary between modules in my ruby projects lately to great effect, but even still, the blob passed between modules can benefit from opaqueness and only exposing a set of functions (methods) that know how to interact with it. And I believe that's actually a place where records/protocols could fit in nicely, but it still seems strange to me that there's no way to prevent someone from bypassing the utility record "methods" and just grab at the internals


Give it some time. Consider it from the perspective of "I'll provide a set of tools to make interaction easier, but you can create your own custom tools at your own risk." It's extensibility a la carte, really.


This talk in particular helped shape my mindset a bit in how Clojure can be used:


Kind of an oddball of a talk, but the concept of crafting simple tools that perform flexible tasks for your particular needs resonated well.


Seems that most of your concern is around how a data model evolves over time, which is a challenge in all paradigms (I suppose that makes it an orthogonal problem...)


So it's mostly a matter of figuring out how to combat that in Clojure. That I have less experience in; anyone able to chime in with their experience there?


@machty if you need an indirection between data representation and data querying protocols or multimethods are a great fit :)


the point is just that this indirection should not be the default; one of thd key aspects of programming with values is that values are explicit.


From my perspective, declaring something private in a map of data returned by (or passed in to) a function makes no sense. I can’t think of a reason I’d want to. If I want something not accessible in the map, I don’t add it to the map. I’m passing around data (to which I want the external code to have access) and functions, not objects containing data and functions. You can declare things private in a namespace. I do it all the time, but more with the intention of defining the public interface than preventing direct access. Functions inside a map which access private data in their namespace aren’t exposing that data. They control the access just as in OOP. I don’t see how this differs significantly from the OOP model. You still have well defined public functions which control how external code interfaces with the namespace and uses its private data. Any change to the public interface has the same consequences in both paradigms. It might help if instead of thinking about passing objects around, you thought about being able to send just the public data and functions from the object instead of having to send the entire object. These functions still have access to the internal state, it just doesn’t come along with them.


Private data within a namespace is more like pure ambient context at that point.


does anyone know when can we expect to see clojure.spec functions in


@ag maybe when 1.9.0 is released?


oh cool, thanks. I can’t wait for when it’s out and people add awesome examples on It’s hard to learn straight from docstrings.


there are some good videos on the cognitect blog


so here's a strange one. I'm using to access microsoft sql server. I'm using a dependency on "3.0" on windows and fedora 24. We were running the the webserver on ubuntu 14.04 and recently upgraded to ubuntu 16.04. Now I'm getting the error that java.sql.SQLException: No suitable driver found for jdbc:sqlserver://<valid-connection-string>


anyone have any experience wrestling with the database driver across all of this?


on the machine we were limited to java 1.7, but after upgrading to 16.04 we upgraded to java 1.8


so I really want to turn stuartsierra's how-to-ns into a library/lein-plugin that can lint code and fix up namespace forms


but I was wondering if there was some other existing thing that I should try to build on rather than making a standalone thing


e.g., eastwood, cljfmt


slamhound breaks most of the projects I work on, though, so I'd have to figure out why that is before it'd be useful :/


I wonder why that would be


lots of edge cases; e.g. I think if you import a class just to use it in metadata, it thinks it's unused


if you require a namespace for side effects, it probably removes that too


that’s probably telling you something then!


well until multimethods are designed differently, requiring a namespace for side effects might be a reasonable thing to do

Drew Verlee23:08:59

i’m having a moment here, how does using something like clojure spec compare to using something like like thrift or protocal buffers. One obvious difference is that those are concerned about encoding & decoding, where spec is only interested in validation (right?). In that same vein i suppose spec seems similar to json-schema but is more powerful, because it can be used for data generation (property testing). Reading chapter 4 on Encoding and evolution.

Drew Verlee23:08:43

is something like strictly more powerful then something like Or i’m i comparing apples to oranges?